Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Extended time between received bytes causing misreads?

I am communicating with a frame grabber that stores an image and can send bytes of intensity data through the serial port. The bytes are arranged so that each row of pixels is expressed as 1440 bytes. Typically, a command is sent to the frame grabber to send every Xth Pixel Y times at a Z compression level (the compression is irrelevent) in the syntax SEND X Y Z\r\n.

When I command a horizontal line to be returned over the serial port (SEND 2 720 1), I get the expected string of intensity values for a given test pattern.



However, when I want a vertical line to be returned (SEND 1440 240 1), every 8th or 9th byte is incorrect.

 Since incrementing the data pointer 1440 places takes longer than two places, the time between received bytes is longer. Could this be the cause of this problem? I have communicated with the frame grabber manufacturer and a vertical scan is a doable operation. Thanks for the input..
Kevin
UTHSC-Houston
0 Kudos
Message 1 of 3
(3,147 Views)
Hi Kevin,

I don't think that a delay or increased time would cause incorrect or bad data.  What are you expecting to see in the second graph?  How do you know which bytes are bad? 

Do you have to use that specific combination (1440 240 1) to get a vertical line returned? 

Regards,

Adam W
Applications Engineering

0 Kudos
Message 2 of 3
(3,128 Views)
I expected the same stepwise pattern, since I rotated the test pattern 90 degrees to get a vertical orientation. In any case, I changed the method in which I requested pixels, and that seemed to solve, or at least bypass, the problem. Instead of the command SEND 1440 240 1, I send SEND 1 1 1, and then increment the pointer in another step all within a for loop.

Those peaks were definately junk bytes since I analyzed the image with my IMAQ card previously.
Kevin
UTHSC-Houston
0 Kudos
Message 3 of 3
(3,117 Views)