Parsing data from pyserial, an (inefficient) solution

[John Machin]

Lone Wolf wrote:

Your code has a problem when the first character of reading is 'M': you
will miss the full packet and pick up a fragment. The length test that
you are doing to reject the fragment is a kludge. If the average length
of a packet is say 25, then you are throwing away 4% of all packets on
average. Try this [untested]:

        reading = ser.read(40)
        # components = reading.split("M")
        # components = components[1]
        # if len(components) > 23:  # If shorter than 24 it won't have
enough data for a full packet
         # subcomponents = components.split()
         pos_past_m = reading.index('M') + 1
         subcomponents = reading[pos_past_m:].split()
         mx = int(subcomponents[0])
         my = int(subcomponents[1])
         confidence = int(subcomponents[7])
         print mx, my, confidence

>
> The really sad thing is that I get a perfectly constructed
> packet from the reading variable,

What we tell you three times is true, you are *NOT* getting a perfectly
formed packet from the reading variable; you are getting 40 bytes of
guff which will be long enough to contain a packet with possible stray
fragments at either end.

Do this:
    print len(reading)
    print repr(reading)
and see for yourself.

>  and that gets butchered when I
> try to slice it up to pick out individual elements. Since
> pyserial doesn't do anything to rearrange the data, then the
> CMUcam must do the heavy lifting of extracting a perfect packet
> from the data stream.

Huh? I thought the CMUcam was *creating* the data stream -- how could
it be *extracting* a "perfect packet" from it?

> It's a real shame I couldn't use it
> because the program would be more efficient.

Somebody else gave you a clue: use the readline method instead of the
read method; have you tried that? It's more likely to stop on a packet
boundary that what you are doing.

As far as starting on a packet boundary is concerned, have you explored
your options with buffering and flow control?

> FWIW, this code
> will analyze 2-3 frames per second on my computer, which is
> enough for my purposes.
>
> In case you couldn't tell from the questions/code, I am a total
> beginner, and I really appreciate this list. All I needed was a
> hand, not a handout. Wolves are willing to hunt for their
> supper.

Independence is one thing. Ignoring plausible truth told to you by
multiple independent people with no axe to grind is another :-)

HTH,
John