Parsing data from pyserial

[Lone Wolf]

I'm trying to get data through my serial port from a CMUcam.
This gizmo tracks a color and returns a packet of data. The
packet has nine data points (well, really eight since the first
point is just a packet header) separated by spaces as follows: M
xxx xxx xxx xxx xxx xxx xxx xxx

Here is the code I am using (python v24):

import serial

ser=serial.Seri al('com1',baudr ate=115200, bytesize=8,
parity='N', stopbits=1,xonx off=0, timeout=1)

ser.write("PM 1") #This sets the CMUcam to poll mode

for i in range(0,100,1):
ser.write("TC 016 240 100 240 016 240\r\n")
reading = ser.read(40)
print reading
components = reading.split()
print components
ser.close

Here is an example output:

M 37 79 3 4 59 124 86 25
['59', '123', '87', '25', 'M', '37', '79', '3', '4', '59',
'124', '86', '25', 'M
']
M 38 77 3 2 59 124 86 25
['39', '85', '26', 'M', '38', '77', '3', '2', '59', '124', '86',
'25', 'M', '38'
, '7']

My problem is that I am trying to get each data point of the
packet into a separate variable. Ordinarily, this would be easy,
as I would just parse the packet, read the array and assign each
element to a variable eg. mx = components[1]. However, that
doesn't work here because the original packet and the array that
I got from using the split() method are different. If I were to
try read the array created in the first example output, mx would
be 123 instead of 37 like it is in the packet. In the second
example, the array is 85 while the packet is 38.

As near as I can figure out, pyserial is reading a stream of
data and helpfully rearranging it so that it fits the original
packet format M xxx xxx xxx xxx xxx xxx xxx xxx. I would have
thought the split() method that I used on original packet (ie
the "reading" variable) would have just returned an array with
nine elements like the packet has. This is not the case, and I
am at a loss about how to fix this.

I've searched the archive here and elsewhere with no luck. Any
help REALLY appreciated!

Wolf :)

_______________ _______________ _______________ ___
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

[Fredrik Lundh]

Si Ballenger wrote:

I would think a time delay would be needed between the below two
lines in the code if he expects to get a useable data string back
from the gizmo for the command sent to it.

ser.write("TC 016 240 100 240 016 240\r\n")
reading = ser.read(40)

why's that? if the gizmo is busy "doing its thing", read() will wait
for up to one second before giving up.

</F>

[Si Ballenger]

On Sun, 03 Dec 2006 18:44:07 -0000, Grant Edwards
<gr****@visi.co mwrote:

>On 2006-12-03, Si Ballenger <sh**********@c omporium.netwro te:

>>>In my dealing with serial gizmos I have to put a delay between
the request sent to the gizmo and the reading of the serial input
buffer for returned data. Serial ports and gizmos need some time
to do their thing.

I doubt that's the issue. He's reading with a 1-second timeout
value.

I would think a time delay would be needed between the below two
lines in the code if he expects to get a useable data string back
from the gizmo for the command sent to it.

ser.write("TC 016 240 100 240 016 240\r\n")
reading = ser.read(40)

No. A delay isn't needed as long as the device responds within
1 second. The read() call will wait up to 1 second for the
first byte of the response.

Per what was posted (below), it appears that the the appropriate
data is being received. It may be possible that the cam may be
sending in a mode that is not in alignment with the binary
transmission mode of the serial port. As a test I'd jumper
between the Tx and Rx pin on the serial port and then send out
the "M" line being received, then see if it will parse as
expected.

Here is an example output:

M 37 79 3 4 59 124 86 25
['59', '123', '87', '25', 'M', '37', '79', '3', '4', '59',
'124', '86', '25', 'M
']
M 38 77 3 2 59 124 86 25
['39', '85', '26', 'M', '38', '77', '3', '2', '59', '124', '86',
'25', 'M', '38'
, '7']

[John Machin]

Si Ballenger wrote:

>
Per what was posted (below), it appears that the the appropriate
data is being received.

[snip]

>
Here is an example output:

M 37 79 3 4 59 124 86 25
['59', '123', '87', '25', 'M', '37', '79', '3', '4', '59',
'124', '86', '25', 'M
']
M 38 77 3 2 59 124 86 25
['39', '85', '26', 'M', '38', '77', '3', '2', '59', '124', '86',
'25', 'M', '38'
, '7']

Based on the split() results (presumably much more reliable than the
"print reading" results) what appears to me is:
fragment '59', '123', '87', '25'
packet 'M', '37', '79', '3', '4', '59', '124', '86', '25'
fragment 'M', '39' [see note]
fragment '85', '26'
packet 'M', '38', '77', '3', '2', '59', '124', '86', '25',
fragment 'M', '38'

[note] the 39 obviously aligns with the 37 and 38s, not with the 123
and 124s. However the boundary of the 2 split() results lies before the
39, not after. Puzzling.

In any case, I wouldn't call that "the appropriate data is being
received" -- looks like chunks missing to me.

[Si Ballenger]

On 3 Dec 2006 17:33:59 -0800, "John Machin"
<sj******@lexic on.netwrote:

>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

[John Machin]

Si Ballenger wrote:

On 3 Dec 2006 17:33:59 -0800, "John Machin"
<sj******@lexic on.netwrote:

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_byte s). 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.

[Grant Edwards]

On 2006-12-04, John Machin <sj******@lexic on.netwrote:

Try reading previous posts. The OP reported that to be returned from
the cam, based on print forty_bytes, not print repr(forty_byte s). 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,

What lack of buffering?

--
Grant Edwards grante Yow! RELATIVES!!
at
visi.com