Open GoogleCodeExporter opened 8 years ago
Original comment by nelso...@macpod.net
on 22 Feb 2009 at 3:59
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
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
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
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
Original issue reported on code.google.com by
nelso...@macpod.net
on 22 Feb 2009 at 3:58