My Bench Equipment
Thursday, March 20. 2008
Ideally I could use the USB port on my oscilloscope instead of the RS-232 port. Why? Because USB is much more commonplace, and it's probably faster.
What's the problem then? I don't know how to interface to the oscilloscope.
GDS-820C uses an FTDI serial->USB converter chip for USB connectivity. It should be as easy as installing the drivers, and connecting via USB.
The latest Virtual Com Port (VCP) drivers should be available for you here: http://www.ftdichip.com/Drivers/VCP.htm
Reverse Engineering the Communication Protocol
I was able to download a trial version of Serial Port Monitor 4.0 by Eltima Software.
By checking the hardware manager in windows I was able to determine that the oscilloscope was on COM4. I configured the serial port monitor to listen to all traffic on COM4, using the views: terminal, line, dump, and table. Additionally, I configured each view to 'redirect to file' in the event that when the program crashed -- I could recover the data. I also set up a custom filter to exclude 'IRP_MJ_READ' messages and 'IRP_MJ_WRITE' messages.
From running the 'FreeView' client program that works sporadically, I was able to get the following data from the 'line view' :
I set out to make my serial reader program set up the channel the exact same way. After a while, I determine that none of this matters. This is how the channel is used:
This seems to indicate that:
Further analysis of the COM sniffer program output shows that only one command is being sent to the oscilloscope over the USB virtual COM port: 0x57 00 00 0A.
At this point I realize what the USB port is for on the oscilloscope.. It's not a USB version of the RS-232 serial port. It's a special 'screenshot' port. I.e. The only purpose for this port, is to stream screenshots of the display to another computer. And most likely it's simply an RGB bitmap.
Here is the code I'm using up to this point.
Reverse Engineering the Data Stream
At this point I'm going to take a wild stab that the data stream is a bitmap image, which is simple streamed over USB in one contiguous series of bytes.
Considering the FreeView program spits out an RGB snapshot of 320x240 pixels. I am going to guess that I will need to read 320x240x3 bytes of data from the stream (at least). It is possible that there is an additional header of some sort.
example of freeview output
I modify my python script to send 0x57 00 00 0A to the oscilloscope to request an image. I then read all the bytes out of the receive buffer.
Running this multiple times gives me this output:
Which is interesting... It appears there are two distinct lengths of reply data.
3596 bytes.. 3596 - 3072 = 524
7564 bytes.. 7564 - 7168 = 396
There's no pattern. But if I read in until I time out..
I get: "i read in .. 40960 bytes."
40960 bytes / 320 = 128
(assuming that 1 byte = 1 pixel)
Now this is a little bit shy of the 240 pixels that I think the screen is. Now I think the screen is 16-colors (4bits per pixel) versus 8bits (256 colors). If We believe that, then we have:
40960bytes * (2pixels/1byte) / 320pixels = 256.
Which is more than enough needed for a 320x240 pixel screen.
Next, the data is saved to a binary file where I can play with it on my computer. I'll use XVI32 to look at it in hex. And I'll also use MATLAB for simple analysis.
In XVI32 the file hex looks like this:
Which, really tells us nothing right now as all the bytes look about the same.
Next up: Matlab.
Running this simple sequence of commands starts to show promise:
Now going into File->Colormap Editor, we can remap the number of colors in the image.
I was thinking 16 colors, so 0-15:
Will result in this image:
Which is excellent... just as I had hoped.
Changing the colormap makes it a little easier to read (and more like the FreeView version,) but the data is still not perfect. Something seems scrambled.
Display comments as (Linear | Threaded)
This would be very cool if you could make it work. I'm in the same boat as you; I'd like to capture longer waveforms from my scope.
I wrote some C code to read image data from this oscilloscope, based on the above code. It can be found on this page:
I made a small Linux/GTK app to read from the GDS-820C. It and my original code can be found here:
I'm looking into reverse engineering a protocol as well, this has been very interesting background reading.