Si Ballenger wrote: > On 3 Dec 2006 17:33:59 -0800, "John Machin" > <[EMAIL PROTECTED]> wrote: > > >In any case, I wouldn't call that "the appropriate data is being > >received" -- looks like chunks missing to me. > > Well, below is the posted expected return data format from the > cam and below that is what has been reported to be returned from > the cam when it is polled, which appears to be a fairly > reasonable match. I assume that each xxx is a decimal number > repersenting a single byte. In the binary mode each x in the > string might be considered a byte in itelf and possibly evaluated > as such. Anyhow it should be easy to see if the received string > can be parsed on it own correctly when not being received via the > serial port. That would start to narrow down where something not > understood is comming into play. > > M xxx xxx xxx xxx xxx xxx xxx xxx > M 37 79 3 4 59 124 86 25
Try reading previous posts. The OP reported that to be returned from the cam, based on print forty_bytes, not print repr(forty_bytes). I think everybody (including possibly even the OP) is willing to believe that the cam is *generating* correct parseable stuff, followed by '\r' -- the problem now is how to get as many samples per second as is reasonable in the face of problems like lack of buffering, flow control, etc. -- http://mail.python.org/mailman/listinfo/python-list
