SmallBot
reconn's
reconn's
world
world
.com

Google
 
Web reconnsworld.com


Email Statistics |

Tell a friend about
this site

Home

Forum!!

Robotics Projects:

Smallbot

Electronics Projects:

SMT Reflow

Serial Multiplexer

Project Log:

Current Projects

My Bench Equipment

Links:

Robotics and EE
Webring

Link to Us


Questions? Feedback? E-mail me Here

Want to know when
reconnsworld.com
is updated?

Join the reconnsworld.com mailing list!

Subscribe
Unsubscribe

Thursday, March 20. 2008

OscopeCapture: Reverse Engineering the USB Protocol?

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' :



----------------------------------------------------------------------------------
[20/03/2008 23:37:02]
985 IRP_MJ_DEVICE_CONTROL - Request operates a serial port
STATUS_SUCCESS
IOCTL_SERIAL_SET_BAUD_RATE - Request sets the baud rate on a COM port. Serial verifies the

specified baud rate
BaudRate - 1200
----------------------------------------------------------------------------------
[20/03/2008 23:37:02]
987 IRP_MJ_DEVICE_CONTROL - Request operates a serial port
STATUS_SUCCESS
IOCTL_SERIAL_SET_RTS - Request sets RTS
----------------------------------------------------------------------------------
[20/03/2008 23:37:02]
989 IRP_MJ_DEVICE_CONTROL - Request operates a serial port
STATUS_SUCCESS
IOCTL_SERIAL_SET_DTR - Request sets DTR
----------------------------------------------------------------------------------
[20/03/2008 23:37:02]
991 IRP_MJ_DEVICE_CONTROL - Request operates a serial port
STATUS_SUCCESS
IOCTL_SERIAL_SET_LINE_CONTROL - Request sets the line control register
StopBits - 0
Parity - 0
WordLength - 8
----------------------------------------------------------------------------------
[20/03/2008 23:37:02]
993 IRP_MJ_DEVICE_CONTROL - Request operates a serial port
STATUS_SUCCESS
IOCTL_SERIAL_SET_CHARS - Request sets the special characters that Serial uses for handshake

flow control
EofChar - 0
ErrorChar - 0
BreakChar - 0
EventChar - 0
XonChar - 17
XoffChar - 19
----------------------------------------------------------------------------------
[20/03/2008 23:37:02]
995 IRP_MJ_DEVICE_CONTROL - Request operates a serial port
STATUS_SUCCESS
IOCTL_SERIAL_SET_HANDFLOW - Request sets the configuration of handshake flow control
ControlHandShake - 0x1 (SERIAL_DTR_CONTROL)
FlowReplace - 0x40 (SERIAL_RTS_CONTROL)
XonLimit - 2048
XoffLimit - 512
----------------------------------------------------------------------------------
[20/03/2008 23:37:02]
997 IRP_MJ_DEVICE_CONTROL - Request operates a serial port
STATUS_SUCCESS
IOCTL_SERIAL_GET_TIMEOUTS - Returns the timeout values that Serial uses with read and write

requests
ReadIntervalTimeout - 50
ReadTotalTimeoutMultiplier - 50
ReadTotalTimeoutConstant - 100
WriteTotalTimeoutMultiplier - 100
WriteTotalTimeoutConstant - 100
----------------------------------------------------------------------------------
[20/03/2008 23:37:02]
999 IRP_MJ_DEVICE_CONTROL - Request operates a serial port
STATUS_SUCCESS
IOCTL_SERIAL_SET_TIMEOUTS - Request sets the timeout value's that the driver uses with read and

write requests
ReadIntervalTimeout - 50
ReadTotalTimeoutMultiplier - 50
ReadTotalTimeoutConstant - 100
WriteTotalTimeoutMultiplier - 100
WriteTotalTimeoutConstant - 100
----------------------------------------------------------------------------------





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:

  • no hardware flow control
  • connection is 1200-N-1. 1200 baud, No parity, 1 stop bit



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.

  1.  
  2. #
  3. # this is code to handle communication with my GDS-820C oscilloscope
  4. #
  5.  
  6. import serial
  7. ser = serial.Serial()
  8.  
  9. if ser.isOpen():
  10.     ser.close()
  11.  
  12. ser.port = 3;
  13. ser.baudrate=1200;
  14. ser.bytesize=8;
  15. ser.parity = serial.PARITY_NONE;
  16. ser.stopbits = serial.STOPBITS_ONE;
  17. ser.timeout = 10;
  18. ser.xonxoff = 0;
  19. ser.rtscts = 0;
  20. ser
  21. ser.open()
  22.    
  23. if ser.isOpen():
  24.     print "Serial port has been opened.\n"
  25.     ser.flush()
  26.     ser.flushInput()
  27.     ser.flushOutput()
  28. else:
  29.     print "Could not open serial port\n"
  30.  
  31. if ser.isOpen():
  32.  
  33.     if( ser.getDSR() == 1 ):
  34.         print " target is ready to talk.."
  35.     if( ser.getCTS() == 1 ):
  36.         print " target is ready to listen.."
  37.        
  38.     #ser.setRTS(level=1);
  39.     #ser.setDTR(level=1);
  40.     while( ser.getCTS() == 0 | ser.getDSR() == 0):
  41.         print "."
  42.  
  43.     #ser.flushInput();
  44.     #ser.flushOutput();
  45.    
  46.     #ser.write("*idn?\n")
  47.     ser.write("W\0\0\n");
  48.     #v = ser.readline()
  49.     v = ser.read(4096)
  50.     #print "version tag: ", v
  51.  
  52.     ser.flushInput();
  53.     ser.flushOutput();
  54.  
  55.     #ser.setRTS(level=0);
  56.     #ser.setDTR(level=0);
  57.  
  58.     ser.close();
  59.  



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.

  1.  
  2. #
  3. # this is code to handle communication with my GDS-820C oscilloscope
  4. #
  5.  
  6. import serial
  7. ser = serial.Serial()
  8.  
  9. if ser.isOpen():
  10.     ser.close()
  11.  
  12. ser.port = 3;
  13. ser.baudrate=1200;
  14. ser.bytesize=8;
  15. ser.parity = serial.PARITY_NONE;
  16. ser.stopbits = serial.STOPBITS_ONE;
  17. ser.timeout = 10;
  18. ser.xonxoff = 0;
  19. ser.rtscts = 0;
  20. ser
  21. ser.open()
  22.    
  23. if ser.isOpen():
  24.     print "Serial port has been opened.\n"
  25.     ser.flush()
  26.     ser.flushInput()
  27.     ser.flushOutput()
  28. else:
  29.     print "Could not open serial port\n"
  30.  
  31. if ser.isOpen():
  32.  
  33.     if( ser.getDSR() == 1 ):
  34.         print " target is ready to talk.."
  35.     if( ser.getCTS() == 1 ):
  36.         print " target is ready to listen.."
  37.        
  38.     while( ser.getCTS() == 0 | ser.getDSR() == 0):
  39.         print "."
  40.  
  41.     ser.flushInput();
  42.     ser.flushOutput();
  43.    
  44.     ser.write("W\0\0\n");
  45.  
  46.     print " there are " + str(ser.inWaiting()) + " bytes in the rcv buffer\n"
  47.  
  48.     iRead = 1;
  49.     toRead = 0;
  50.     v = ser.read(1)
  51.     while( ser.inWaiting() > 0 ):
  52.         toRead = ser.inWaiting()
  53.         v += ser.read( toRead )
  54.         iRead += toRead
  55.  
  56.     print "i read in " + str(iRead) + " bytes, and there are " + str(ser.inWaiting()) + " bytes remaining.\n"
  57.  
  58.     ser.flushInput();
  59.     ser.flushOutput();
  60.  
  61.     ser.close();
  62.  
  63.  



Running this multiple times gives me this output:


>>>
Serial port has been opened.

target is ready to talk..
target is ready to listen..
there are 0 bytes in the rcv buffer

i read in 3968 bytes, and there are 0 bytes remaining.

>>>
Serial port has been opened.

target is ready to talk..
target is ready to listen..
there are 3596 bytes in the rcv buffer

i read in 7564 bytes, and there are 0 bytes remaining.

>>>
Serial port has been opened.

target is ready to talk..
target is ready to listen..
there are 0 bytes in the rcv buffer

i read in 3968 bytes, and there are 0 bytes remaining.

>>>
Serial port has been opened.

target is ready to talk..
target is ready to listen..
there are 3596 bytes in the rcv buffer

i read in 7564 bytes, and there are 0 bytes remaining.

>>>




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..


v = ser.read(320*240*3)
print " i read in .. " + str(len(v)) + " bytes.\n"


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.


f=open("i.bin",'wb')
f.write( v )
f.close()



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:

  1.  
  2. fid = fopen('i2.bin', 'r')
  3. img = fread(fid, 320*256, 'ubit4=>uchar');
  4. b = reshape(img, 256, 320);
  5. c = fliplr(b);
  6. imshow(c)
  7. colormap(hot(16))
  8.  


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.


% better colormap
% ans =
%
% 0 0 0
% 0 0 0
% 1.0000 1.0000 0
% 0.6667 0 0
% 0 1.0000 1.0000
% 1.0000 0 0
% 0 1.0000 1.0000
% 0.9412 0.9412 0.9412
% 0.8000 0.8000 0.8000
% 0.7490 0.7490 0
% 0.0784 0.1686 0.5490
% 0.8627 0.8627 0.8627
% 1.0000 1.0000 0.2500
% 1.0000 1.0000 0.5000
% 1.0000 0 0
% 1.0000 1.0000 1.0000
%


    References
  • http://www.aggsoft.com/rs232-pinout-cable/pinout-and-signal.htm
  • http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm

Posted by Andrew in Oscilloscope Capture Program at 17:05 | Comments (4) | Trackbacks (0)

Trackbacks
Trackback specific URI for this entry

No Trackbacks

Comments
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.
#1 TheRock on 2008-09-02 18:16 (Reply)
I wrote some C code to read image data from this oscilloscope, based on the above code. It can be found on this page:

http://monsters.dontexist.net/projects/electronics
#2 Windsor Schmidt (Link) on 2008-11-15 19:39 (Reply)
I made a small Linux/GTK app to read from the GDS-820C. It and my original code can be found here:

http://monsters.dontexist.net/projects/scopeview/wiki
#2.1 Windsor Schmidt (Link) on 2008-11-17 20:09 (Reply)
I'm looking into reverse engineering a protocol as well, this has been very interesting background reading.

Thanks
#3 Matthew Rollings (Link) on 2009-09-04 10:09 (Reply)

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
BBCode format allowed
You can use [geshi lang=lang_name [,ln={y|n}]][/lang] tags to embed source code snippets
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA
 
 





Quicksearch

Categories



All categories

Syndicate This Blog

Site by Andrew Wilson. Copyright 1997-2006 All Rights Reserved unless otherwise noted.
Schematics in Schematics Depot were found on the internet and assumed to be in public domain. Contact webmaster if the copyright holder wants them pulled for any reason.