Bad data causes parse errors. Fix the parse error by checking the number of parsed tokens before trying to unpack into an array - but this is a workaround to the root cause. The email below sums up the question:
Hi John (Banner Communications) and Steve (our other SAR techie) - SAR is experiencing some crazy data coming over the com port from our kenwood mobile radios (5310), received and decoded from a KPG-47GPS gps mic attached to a kenwood handheld. We have not (knowingly) changed anything about our radio programs any time recently. The data leads me to think it's a dying battery in the GPS mic. Have you seen anything like this? Here's the radiolog (our program) transcript of the data that comes in over the com port (the first four digits and colon on each line are just a relative timestamp, in seconds):
First, here's a valid caller-id-only data packet:
1656: DATA IS WAITING!!!
1656: VALID FLEETSYNC DATA!!!
1656:PARSING
1656: I110020071002007
1656: line: I110020071002007
1656:CID detected (not in $PKLSH): fleet=100 dev=2007 callsign=Radio 7
Here's a 'valid' GPS packet - this one came in with the warning character ('V' - found this in some NMEA docs online) and some dummy (probably default) coordinates, 36deg N by 136deg E:
1658: $PKLDS,084740,V,3600.0000,N,13600.0000,E,,,,,00,100,2007,80,00,1F
$PKLSH,3600.0000,N,13600.0000,E,084740,V,100,2007,37
$GPRMC,084740,V,3600.0000,N,13600.0000,E,,,,,04
$GPGGA,084740,3600.0000,N,13600.0000,E,0,,,,,,,,53
I110020071002007 $PKLDS,084740,V,3600.0000,N,13600.0000,E,,,,,00,100,2007,80,00,1F
$PKLSH,3600.0000,N,13600.0000,E,084740,V,100,2007,37
$GPRMC,084740,V,3600.0000,N,13600.0000,E,,,,,04
$GPGGA,084740,3600.0000,N,13600.0000,E,0,,,,,,,,53
I110020071002007
...
1658:WARNING status character parsed from $PKLSH; check the GPS mic attached to that radio
...
1658:CID detected (not in $PKLSH): fleet=100 dev=2007 callsign=Radio 7
And finally, this one also has the warning character, but the line stops mid-sentence which causes errors in our radiolog program - I'm recoding o gracefully handle those errors but we should figure out the root cause - can you help?
Uncaught exception
Traceback (most recent call last):
File "radiolog.py", line 1274, in fsCheck
self.fsParse()
File "radiolog.py", line 1289, in fsParse
[pklsh,nval,nstr,wval,wstr,utc,valid,fleet,dev,chksum]=line.split(',')
ValueError: too many values to unpack (expected 10)
(I also have a picture, but not the log file, of a packet where the entire line it is trying to parse is "$PKLSH,3920.2564" (end of line) and the ValueError is 'need more than 2 values to unpack' but the GPS status character in that packet is 'A' for 'working' - though we may as well assume this is an artifact from earlier 'too many values to unpack' errors which probably left some data in the parse buffer of the radiolog program)
Bad data causes parse errors. Fix the parse error by checking the number of parsed tokens before trying to unpack into an array - but this is a workaround to the root cause. The email below sums up the question:
Hi John (Banner Communications) and Steve (our other SAR techie) - SAR is experiencing some crazy data coming over the com port from our kenwood mobile radios (5310), received and decoded from a KPG-47GPS gps mic attached to a kenwood handheld. We have not (knowingly) changed anything about our radio programs any time recently. The data leads me to think it's a dying battery in the GPS mic. Have you seen anything like this? Here's the radiolog (our program) transcript of the data that comes in over the com port (the first four digits and colon on each line are just a relative timestamp, in seconds):
First, here's a valid caller-id-only data packet:
1656: DATA IS WAITING!!! 1656: VALID FLEETSYNC DATA!!! 1656:PARSING 1656: I110020071002007 1656: line: I110020071002007 1656:CID detected (not in $PKLSH): fleet=100 dev=2007 callsign=Radio 7
Here's a 'valid' GPS packet - this one came in with the warning character ('V' - found this in some NMEA docs online) and some dummy (probably default) coordinates, 36deg N by 136deg E:
1658: $PKLDS,084740,V,3600.0000,N,13600.0000,E,,,,,00,100,2007,80,00,1F $PKLSH,3600.0000,N,13600.0000,E,084740,V,100,2007,37 $GPRMC,084740,V,3600.0000,N,13600.0000,E,,,,,04 $GPGGA,084740,3600.0000,N,13600.0000,E,0,,,,,,,,53 I110020071002007 $PKLDS,084740,V,3600.0000,N,13600.0000,E,,,,,00,100,2007,80,00,1F $PKLSH,3600.0000,N,13600.0000,E,084740,V,100,2007,37 $GPRMC,084740,V,3600.0000,N,13600.0000,E,,,,,04 $GPGGA,084740,3600.0000,N,13600.0000,E,0,,,,,,,,53 I110020071002007 ... 1658:WARNING status character parsed from $PKLSH; check the GPS mic attached to that radio ... 1658:CID detected (not in $PKLSH): fleet=100 dev=2007 callsign=Radio 7
And finally, this one also has the warning character, but the line stops mid-sentence which causes errors in our radiolog program - I'm recoding o gracefully handle those errors but we should figure out the root cause - can you help?
1684: I010020071002007 $PKLDS,084805,V,3600.0000,N,13600.0000,E,,,,,00,100,2007,80,00,11 $PKLSH,3600.0000, I010020071002007 $PKLDS,084805,V,3600.0000,N,13600.0000,E,,,,,00,100,2007,80,00,11 $PKLSH,3600.0000,N,13600.0000,E,084805,V,100,2007,39 $GPRMC,084805,V,3600.0000,N,13600.0000,E,,,,,0A $GPGGA,084805,3600.0000,N,13600.0000,E,0,,,,,,,,5D N,13600.0000,E,084805,V,100,2007,39 $GPRMC,084805,V,3600.0000,N,13600.0000,E,,,,,0A $GPGGA,084805,3600.0000,N,13600.0000,E,0,,,,,,,,5D 1684: line: I010020071002007 $PKLDS,084805,V,3600.0000,N,13600.0000,E,,,,,00,100,2007,80,00,11 1684:CID detected (not in $PKLSH): fleet=100 dev=2007 callsign=Radio 7 1684: line:$PKLSH,3600.0000, I010020071002007 $PKLDS,084805,V,3600.0000,N,13600.0000,E,,,,,00,100,2007,80,00,11
Uncaught exception Traceback (most recent call last): File "radiolog.py", line 1274, in fsCheck self.fsParse() File "radiolog.py", line 1289, in fsParse [pklsh,nval,nstr,wval,wstr,utc,valid,fleet,dev,chksum]=line.split(',') ValueError: too many values to unpack (expected 10)
(I also have a picture, but not the log file, of a packet where the entire line it is trying to parse is "$PKLSH,3920.2564" (end of line) and the ValueError is 'need more than 2 values to unpack' but the GPS status character in that packet is 'A' for 'working' - though we may as well assume this is an artifact from earlier 'too many values to unpack' errors which probably left some data in the parse buffer of the radiolog program)