Beyond 'Garmin Device Interface Specifications'

[gavineadie]

Vadim ..

"Screenshot" has no documented protocol number (that I've found)

You're right about the 60CSx transfer sequence. When I had a 60CSx, that what's received and I could construct images as expected.

The 64s is different -- it sends "everything" in one transfer (one header record, 65,536 color map records, 1200 image pixel records). However, the stream of data doesn't seem consistent to me. For example, while the 'header' (similar, but not the same as, a BMP image file header), says each pixel will be 16 bits, the image records off the device only provide half what's required for that. When I treat that image data as 8-bit (instead of 16-bit) pixels, I get a distorted image. So far, I've not made an attempt to incorporate the color table, so my 'distorted image' is greyscale, but it's also visibly similar to what was on the screen.

Here's such an image I derived

*** edited to conform with forum posting guidelines ***

Spoiler

pictureZ.bmp

You see the roads and other markings and even text, but the most obvious 'distortion' is that, apart from any other concerns, this is only the left half of the screen, stretched to fill the 160 horizontal width; none of the right half is present.

The image data off the device is 1200 records of 16 bytes like, for example:

Code: Select all

01 00 00 00  60 01 00 00  f7 be ef 9d 7c 0f 00 00
-----------  -----------  -----------------------

The first 4 bytes (=1) are a code for 'image data' (the header is code =0, the color table is code =2). The second four bytes are an offset to where the pixels fall in the image, and the last 8 bytes are the image pixel data.

Those 1200 records, with 8 image bytes each, make a 240x160 8-bit frame (or, more like what I see, half a 240x160 16-bit frame).

As I was finishing this and checking things, I noticed, for the first time, these image offsets (the second four bytes) are too large and not equally spaced .. that's a clue, but what?!

[Vadim]

The 64s is different -- it sends "everything" in one transfer (one header record, 65,536 color map records, 1200 image pixel records). ... 'header' (similar, but not the same as, a BMP image file header), says each pixel will be 16 bits

I suspect that the image is encoded using 2 bytes (16 bits) per pixel.
And by the way, the "corrupted" picture confirms this. This is not a real grayscale - just a coincidence. Notice the vertical black lines in the image (every even column). These lines correspond to the most significant byte in the code of each 16bit pixel and in most cases it is usually =zero (corresponding to the black color). Your picture turned out with a kind of "interlacing".

240*160=38400 pixels
1200 records * 8 bytes per record = 9600 bytes - this is only a quarter (or 1/8 for 16-bit pixels) of the image

Therefore, it can be assumed that the image from the device was not completely received. Compare the results of your program with the results of xImage, if it supports your 64s.

The image data off the device is 1200 records of 16 bytes like, for example:

Code: Select all

01 00 00 00  60 01 00 00  f7 be ef 9d 7c 0f 00 00
-----------  -----------  -----------------------

... The second four bytes are an offset to where the pixels fall in the image, and the last 8 bytes are the image pixel data.

With what step does this offset increase? 1/4/8 ?
If=

• 1 -> record/packet number
• 4 -> pixel number
• 8 -> pixel offset in the image body

PS: Waiting for a dump of the xImage+64s work. Otherwise, it will be difficult to resolve this issue.
PPS: Strange, the message #p13450 I was replying to has disappeared somewhere...

Spoiler

It's good that a screenshot of it was saved:

LostPost.png

[gavineadie]

Vadim .. I have more that I have discovered!

I ended by last reply rather suddenly because I noticed something in the data, related to the offsets, that I'd missed before. Each image data packet from the device is, as I described last time an unchanging code [=1] in the first four bytes, an offset in the next four, and the last 32 bytes are image data. In my last message I was incorrect saying 8 bytes per record (I accidentally truncated my logging output but I did include the data in the image)

The offset tells where to place the image data in the image -- the first packet has a 0 offset so its image data starts the image, the second packet has an offset of 32 so its data immediately follows the first, likewise for the third, fourth and fifth packets. After the first five packets we have placed 160 consecutive bytes into the image, and each pixel takes two bytes so we've 'painted' the first 80 pixels .. so far, so good!

The sixth packet's offset places the next data at offset 192 which leaves a 160 byte gap in the image. This pattern repeats -- the data from each five packets is contiguous and separated from the previous five by 160 bytes. In other words we get 80 pixels of 16-bit data and 80 'empty' pixels per row. The device sends 240 rows like this with a resulting image that is a rendering of the left half on the screen -- no data is sent for the rightmost 80 columns.

I ran out of time tonight to complete the creation of the image in my program but I took all the pixel values and put them in a 160x240 spreadsheet and crudely colored the cells with this result:

Spoiler

pix2.png

Notice only the left half of the screen is sensible -- the right half is missing. You noted the interlacing artifact in my old image .. but it's gone in the new (16-bit pixels) one. Since my coloring is crude, the antialiasing paints pretty colored edges! I'm confident that with correct coloring the left side of this would be an exact copy of the left side off the screen.

Puzzles remain! Why does the GPS appear to send only half the screen? One answer could that the firmware has a bug -- I try not to consider that option but it is a possibility.

Another odd aspect is related to the color table -- it's huge; 65,536 color map records. I've not examined the color map data so I can't say anything about it but will note that the one image I've decoded and shown here has only 290 different colors.

And last, for now, is to note that the image is painted from the top row downwards (the 60CSx starts at the bottom row and paints upwards).

[gavineadie]

.. and more

• in my last note, I said ".. the image is painted from the top row downwards" -- this is true for the sequence of data sent from the device (the device sends the top row first), but in a BMP image (which is what the device generates with a manual screen capture), the top row is the last one in the pixel array data -- so "top" and "bottom" are different for the data stream and a generated BMP image.

• I changed my program to generate a BMP file (no more color-by-numbers spreadsheets!), and the BMP image was no better (or worse) than my previous manual construction. That is, it is still a badly colored left half of the screen.

• I further modified my program to incorporate the color table, so the pixel data would be colored correctly. However, adding the color table into the BMP file has no effect on the appearance. Typically a 16-bit BMP image file doesn't have a color table so I'm not entirely surprised that my images look the same with or without one.

The image antialiasing was too 'sparkly' which lead to me to realize that I might be making each 16-bit pixel from two bytes and not correcting for their endian-ness -- sure enough making the pixels big-endian improved the image. Again, I've stopped for the night .. the image enclosed is the latest product, the unmodified BMP file from my program. The colors are smoother but still wrong, probably because I've got the R-G-B bits out of order (tomorrow!)

Spoiler

picture7.bmp

I feel I'm very close to completing this little project. I'm also almost convinced that buggy 64s firmware is the cause of the "half screen" problem and it can't be fixed. I might guess that when changing from 8-bit pixels to 16-bit pixels, the Garmin programmer didn't account for needed to send twice as much data out the USB port (and since it's not documented anyway, nobody either noticed or, if they did, didn't think it was worth fixing).

[Vadim]

I'm confident that with correct coloring the left side of this would be an exact copy of the left side off the screen.

Bravo! Thanks for sharing information on this issue.

Puzzles remain! Why does the GPS appear to send only half the screen? One answer could that the firmware has a bug -- I try not to consider that option but it is a possibility.

The old device (60CSx), before transmitting the palette, first gave out the names of the pictures: “Screenshot” came first, then the names of various icons.
Perhaps in the new model (64s) the screenshot is split into 2 files? If so, then you need to download the second file and merge 2 files into one.

You may have to play around with the parameters of the command that initiates the transfer of a screenshot from the device. I can’t say more specifically, since I don’t have either such a device (64s) or a transfer dump.

Another odd aspect is related to the color table -- it's huge; 65,536 color map records. I've not examined the color map data so I can't say anything about it but will note that the one image I've decoded and shown here has only 290 different colors.

If you have more than 256 colors in your image, then you can no longer use the 8-bit palette and will have to switch to a 16-bit palette.
Fortunately, it is not necessary to save all 65,536 palette colors into an image file. For example, with .PNG you can save only the colors used in the palette. In your case, you can only save 290 colors instead of 65 thousand.

By the way, try an experiment:
Select a picture on the device (64s) screen with a small (<256) number of colors. For example, somewhere on the menu.
Try to get a screenshot.
Will the number of colors in the palette be reduced from 65,536 (16 bits) to 256 (8 bits) ?