I can't explain this in one line just click me...

Discussion in 'OT Technology' started by CodeX, Jul 21, 2009.

  1. CodeX

    CodeX Guest

    Okay so at work I have been working on providing a communication protocol for communicating between the PC software bundled with our hardware and the hardware itself.

    Basically it is a handheld fiber optic tester, displaying a graph of signal level in db versus distance, but thats not important. I have developed a virtual instrument for the PC so that when you have the two connected via the supplied USB cable they can communicate and transfer files and such, and now you can also have direct control of the instrument from the PC, and can see its exact screen on the PC.

    To do this I am transferring the screen data to the PC every time user input occurs that changes something. It is in the format of 320x240x8bpp. This is working, I am not asking how to implement it, but it is SLOW... The real problem is our "USB" cable is not really USB at all it uses an RS232 bridge chip to piggyback normal UART communication over USB interfaces. The fastest this chip supports is 920k. Considering I am transferring 76,800 bytes of data this should occur in less than a tenth of a second, but it takes closer to a half second per screen update for some reason.

    Furthermore, in an attempt to improve this I implemented real time compression using lossless RLE which I observed to shrink the 76,800 bytes to as little as 18,000 (varies with the complexity of the screen data). The puzzling thing is... this had NO impact on speed... it still takes roughly half a second for the display to update, and I have confirmed this is in waiting for the data to be received by the PC, not in drawing the screen or anything stupid like that.

    So... I am grasping at straws I know but does anyone have any idea what might be going on? Particularly why reducing the amount of data being sent by 75% had no impact on performance? I am at a loss and this needs to be done this week.
     
  2. White Stormy

    White Stormy Take that, subspace!

    Joined:
    Sep 17, 2002
    Messages:
    85,489
    Likes Received:
    70
    Location:
    Sparkopolis
    USB blows. however little you're using it, I'd blame that
     
  3. avctechsupp

    avctechsupp New Member

    Joined:
    May 12, 2009
    Messages:
    69
    Likes Received:
    0
    DHCP? DNS? Eliminate as much as possible (the network!) and work from there...
     
  4. CodeX

    CodeX Guest

    Thanks but its not a network issue, it is not a part of a network it is direct serial communication over USB interfaces... unless I am wrong and that is time-sliced with other network communication in windows or something...?
     
  5. retorq

    retorq What up bitch??

    Joined:
    Dec 14, 2006
    Messages:
    6,061
    Likes Received:
    0
    Location:
    Mohave Desert
    :rofl:
     
  6. Fase

    Fase Your Face, In A Pickle Jar.

    Joined:
    Apr 6, 2004
    Messages:
    29,540
    Likes Received:
    0
    Location:
    Windsor, Ont, Canada.
    Wait so you are using RS232?

    USB > RS232 > PC?

    If this is the case and if you haven't already, adjust the baud rate on the COM Port.

    What language is this programmed in?
     
  7. CodeX

    CodeX Guest

    No, its more like RS232 internal from the processor (TMS320C2812) to a "USB bridge chip" which converts it to USB data, to a USB cable and through USB interfaces, to the PC where a driver converts it back to RS232, which is accessed in a VB.Net program using a common serial port interface.

    I have already increased the baud rate to the maximum that the bridge chip can handle, 920k. With some simple math the transfer should take 5x less time than it is actually taking, and this is what I am trying to figure out. A major clue (I think) is that the time it took was the same after reducing the amount of data transfered by 75% through compression.
     
  8. 5Gen_Prelude

    5Gen_Prelude There might not be an "I" in the word "Team", but

    Joined:
    Mar 14, 2000
    Messages:
    14,519
    Likes Received:
    1
    Location:
    Vancouver, BC, CANADA
    What happens when you set it something much lower? Ie is the setting having any impact on the speed?
     
  9. CodeX

    CodeX Guest

    I'll have to check that tomorrow, good thinking though I naturally put it at the highest speed that worked :mamoru:
     
  10. binary01

    binary01 New Member

    Joined:
    Apr 6, 2007
    Messages:
    3
    Likes Received:
    0
    Maybe I'm misunderstanding but If your baud rate is 920,000 then there is no way you are going to be transferring 76,800 bytes in 0.1 seconds. The baud rate is the raw number of bits that travel over the serial line. That includes each bit in the data (8 per byte usually) as well as start/stop/parity bits.
     
  11. johan

    johan Active Member

    Joined:
    Nov 4, 2003
    Messages:
    5,123
    Likes Received:
    0
    Location:
    Sahasrara; magnetic violet infinite
    prob not a 'bandwidth' problem per se, since the xfer time remains roughly the same even when you shrink the data to 20%

    how much handshaking is going on? I assume you're doing this async with your uart. Can you try a usart and do it synchronous.

    Although .... I'm guessing you're stuck with the hardware, so check to see if there's a delay in between each frame. Try reducing the delay time, to zero if possible. If not, play around to find the minimum delay necessary to allow reliable resync. Inserting a delay in between frames is pretty common on async comms.
     
  12. CodeX

    CodeX Guest

    Ah you are right, should be 10x what I thought, slightly less then 1 second... but that just raises further questions, it is only taking about a half second, and the time seems constant with the amount of data I am sending...
     
  13. GOGZILLA

    GOGZILLA Double-Uranium Member

    Joined:
    Jan 16, 2003
    Messages:
    10,760
    Likes Received:
    3
    Location:
    Plantation, FL
    i dunno if you have a USB comm analyzer but at work we've got one made by CATC called a USB Chief. I'd probably start out there by sending your data package and then sending some other packet immediately after and measuring to figure out whether the timing is messed up coming out of your unit or if it's the driver on the pc or pc program causing the timing issue. There's really too many possibilities at this point you have to isolate it somehow.
     
  14. mobbarley

    mobbarley Active Member

    Joined:
    Mar 4, 2005
    Messages:
    9,256
    Likes Received:
    2
    Location:
    Sydney
    Wouldn't it be more efficient to transfer data and have the PC software process it, rather than transfer a screen? Are you using something similar to the FTDI chips with CDC?
     
  15. mobbarley

    mobbarley Active Member

    Joined:
    Mar 4, 2005
    Messages:
    9,256
    Likes Received:
    2
    Location:
    Sydney
    Further to this:
    what chip are you using for the 232->usb?
    are you using a serial module on the mcu or software on gpios?
    could parity errors etc be a problem? do you have a way of dumping data / using a protocol analyser?
     
  16. CodeX

    CodeX Guest

    FTDI chip indeed. And yes, it would be much more efficient to transfer only the data needed to reconstruct the screen unfortunately the logic needed to draw the screen based on that data will require far more development time than simply sending the screen pixel by pixel over the cable. If I had (or am given the time later) to do that it would be the preferred method.

    I don't know what the RS232->USB chip is, it may be FTDI, we use an FTDI chip for actual USB communication to MSD class devices (flash disks) and this may be handled by the same chip I dont know. The serial hardware is part of the DSP we are using, it is not software controlled GPIO. I am not sure about parity errors, we use 8 data bits, no parity bit, and one stop bit because as far as I know that is all the chip supports, there is no option to change it anywhere (I mean, I can change it on the serial hardware in the processor through registers, and I can set it on the PC in device manager... but as far as I know there is no way to configure the bridge chip, which would seem to be necessary if I made changes to the data format)

    As far as I know we don't have any kind of analyzer, and you mentioned dumping the data? I am not sure I know what you mean the data is getting across alright, it is not corrupt, I do get all data sent and in the right order lol.

    In any case today I did figured something out that was interesting and helped with some of the issues I was having. Apparently calling SerialPort.Write() does not actually send any data.... :ugh:
    Instead it puts the data on the write buffer and only when the buffer is full does it actually transfer the entire set of data. That kind of fucks you up when you the receiving device goes into a wait loop expecting to get a single byte, lol. I had "fixed" the problems that this caused with ridiculously complex timing schemes, which I am glad to be able to get rid of now after figuring out I need to call SerialPort.BaseStream.Flush after every byte I want to send to force it to transfer immediately. Still have the same problem with it being slower than it should be though... ~25kb of compressed data at 921k baud should not almost 2 seconds.
     
  17. CodeX

    CodeX Guest

    I solved this if anyone is interested. I am not going to go into into it but suffice to say it had to do with the ambiguous built-in serial port interface in VB being designed by a 5 year old apparently... or at least not documented well at all on the MSDN.
     

Share This Page