Video freezes after other commands are quickly sent to the SRV1 Unit

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Connect to an SRV1 unit
2. Send multiple SRV1 commands very quickly to the unit.
3. Stop sending commands and see if video resumes ok.

What is the expected output? What do you see instead?
Video may freeze and remain frozen

Please use labels and text to provide additional information.
It is expected sending commands can slow down video, but it should not
freeze it as it is currently doing. 

Original issue reported on code.google.com by nelso...@macpod.net on 22 Feb 2009 at 3:58

[GoogleCodeExporter]

Original comment by nelso...@macpod.net on 22 Feb 2009 at 3:59

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The freeze isn't in the SRV-1 firmware.  If you stop and restart the console, 
video
will resume.  

The SRV-1 firmware does not buffer requests.  In fact, it flushes its input 
buffer
after completing a command.  If srv1console is expecting acknowledgement of 
every
command, it might be stuck waiting because the command got flushed.

Original comment by surveyorcorp@gmail.com on 22 Feb 2009 at 4:53

[GoogleCodeExporter]

Yea, it definitely isn't an SRV1 unit issue, it's the way images are 
requested/read
in the app. That is very helpful to hear that the flushing occurs.. and also 
explains
why one of my fix attempts did not work :)

FYI: I have my surfaceviews working so once this bug is fixed, video should be 
pretty
close to as good as it will get.

Original comment by nelso...@macpod.net on 22 Feb 2009 at 5:28

[GoogleCodeExporter]

The changes made in r13 may help fix the never-ending freeze issue after 
multiple
commands are sent. In the video command, when data on the socket is > 0 bytes, 
it
tried to read in 6 bytes to see if the data represented the start of a valid 
image.
The problem came in that the data available on the socket could have been the 
output
of another command such as #b, since this is less than 6 characters long, it sat
forever waiting for 4 more bytes. The video command now checks that there are at
least 6 bytes available to read in.

Original comment by nelso...@macpod.net on 25 Feb 2009 at 5:24

[GoogleCodeExporter]

r16/r17 changed the code from continuously requesting frames from the SRV1 unit 
to
only requesting one frame. If the header cannot be read in after 1/2 a second.. 
the
attempt to read the video frame fails and the next command is executed in the 
queue.

Earlier approaches most likely allowed more than one frame to be sent back to 
the
android console, but since only one frame is read.. the other frame(s) data sat 
on
the socket. If this data was not completely cleared at the start of other 
functions,
the verification portion of commands would fail (and be called over and over 
again
until the verifications passed). In the case of motor/servo command this would 
make
the unit seem really sluggish to respond to commands and in the case of video, 
a new
frame may never be drawn on the display.

I'm keeping this open for a little while longer.. but hopefully it is really 
solved
this time :)

Original comment by nelso...@macpod.net on 13 Mar 2009 at 3:08