Hi all,
Really I’m looking for feedback, information and perhaps some example sketches of how people have successfully got data from the Air350Z via Python. I’ve looked through all the existing posts, slurped the Air530Z codes that one awesome user translated to English and seen the dead end that seems to be people getting very fragmented data from the chip.
I’m also getting that very fragmented data when trying to interface using the dextergps.py sketch as a starting point. There really doesn’t seem to be much information at all out there about the chip, its speeds, preferred baud rate, encryption etc etc and all I really need is to get the lat-lon from it but I don’t even get a $GPGGA readout. I’m somewhat familiar with NMEA codes from some previous work I’ve done with professional quality IMU units.
So any information from people with a Pi who’ve managed to get this thing talking clearly would be greatly appreciated, please!
Reading through the documentation there’s something that’ll be obvious to people more familiar with GPS interfacing but is handy info to me… The first two letters in a sentence refer to the sender identifier.
So in $BDGGA the BD refers to Beidou, for instance. The codes are as follows:
BD = Beidou
GP = GPS
GL = GLONASS
GN = GNSS
P = custom information from chip manufacturer, not standard NMEA
So it looks like the real issue here might be satellite visibility, hence the garbled lines of readout as they’re simply omitting unknown data… being most of it.
I have my antenna taped to a window pane for max visibility I can achieve indoors, I’ve downloaded GPSD and edited /etc/default/gpsd to point DEVICES directly to the unit. This has made the device visible using cgps in Terminal and it’s clear it’s picking up zero satellites…
Anyone had luck boosting the reception quality? I’m currently delving into whether or not to source a different antenna or whether I need to somehow deliberately point the device to use the external antenna that came with it…
This has been a background frustration while working on other parts of my project (and soooo nice to see no one from SeedStudios team is looking at these…).
Have just picked it up again, reading in raw data without decoding it gives this format:
Hi Cobra,
Yes while the general “packet” format is likely NMEA the encryption will be a data encryption. A single line reads out in UTF-8, a common encryption codec, but the rest looks like bytes in hex form however doesn’t translate to anything meaningful as far as I’ve managed to obtain so far.
GPSD as a result has been no help as it doesn’t understand the encryption of these bytes.
EDIT: I should say, GPSD reads out a bunch of random ASCII that aren’t alphanumeric. It looks like the garbled messages others have seen.
That’s what prompted me to just to a straight serial read which gave the “hex”. My hope was to find out what encoding that is and hopefully tell the program what to work with, but no luck so far.
I’ve given up. This problem is holding up my development and eventually I just got this USB GPS from DFRobot via PiHut. I plugged it in, directed GPSD to it and boom, works perfectly.
SOLUTION: Use a product from another brand, not SeeedStudio.
One of the most common issues with fragmented or incomplete data is incorrect baud rate settings. While the Air350Z’s default baud rate may not be well-documented, you can try the common rates like 9600, 4800, or 115200. Ensure your Python serial interface matches the baud rate configured on the GPS module.
PJ