I notice in the recent git commits Gary has been doing some work supporting the new u-blox F9P chipset.
I've come across an interesting anomoly with it when recieving RAWX messages. For some reason it seems to not recognise it as a message, and it seems to confuse gpsd. Some times it switches to trimble mode, or NMEA mode, and occasionally jumps to 4800 baud and stops dead.
Running gpspipe -R it will pass through other raw messages, but not the RAWX ones.
I'm wondering if there is some sanity check on the length of the RAWX message, because they can get quite long now as the device will often pick up >60 sats, and have dual freq info too.
Below is an example debug - other binary messages come through fine but the RAWX isn't there (confirmed it is when I capture the serial port directly). Below you can see one of the anomolies where it jumps for some reason to 4800 baud - perhaps because it's interpreting the binary data in some unintended way?
Many thanks if anyone has any ideas. Happy to jump in myself to try to fix but wanted to see if anyone here has thoughts first.
gpsd:CLIENT: => client(0): =b56201075c00708bda10e307040a062014370c0000009a4500000301ea10a83ea0654ca2a7e4184e00001a47000000110000ae120000beffffffaeffffff77ffffff69000000aea28c017c010000dbff7c00b3000000dcca493200000000000000005e40
gpsd:CLIENT: => client(0): =b56201021c00708bda10a83ea0654ca2a7e4184e00001a47000000110000ae1200000032
gpsd:CLIENT: => client(0): =b56201221400708bda10a9fc0e00050300000c0000001a040000019c
gpsd:CLIENT: => client(0): $GNRMC,063220.00,A,4552.65593,S,17030.00370,E,0.205,,100419,,,A,V*0D\x0d\x0a
gpsd:CLIENT: => client(0): $GNVTG,,T,,M,0.205,N,0.380,K,A*31\x0d\x0a
gpsd:CLIENT: => client(0): $GNGGA,063220.00,4552.65593,S,17030.00370,E,1,12,1.06,18.2,M,1.8,M,,*57\x0d\x0a
gpsd:CLIENT: => client(0): $GNGLL,4552.65593,S,17030.00370,E,063220.00,A,A*64\x0d\x0a
gpsd:INFO: SER: speed 4800, 8N1