Trying to get some sensible data from the ErleBrain3 GPS

[Richard]

I can't receive anything other than non-printing characters from the uBlox GPS that comes with a new ErleBrain3. I would like a very simple command-line query of the GPS coordinates.

There are several instances on this forum of similar effects in an ErleBrain2, e.g. http://forum.erlerobotics.com/t/solved-trying-to-get-some-sensible-data-from-the-gps/722/12 but none of those solutions has worked. Is there anything else I should try, that is specific to an ErleBrain3?

THE PROBLEM:
Immediately after re-flashing the CF card, and logging in via ssh, I get the following output

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Oct 13 20:22:47 2016 from 10.0.0.2
erle@erle-brain-3 ~ $ ls
APM  Documents  gtk-tests  ros2_ws  spider.launch  spider_ws
erle@erle-brain-3 ~ $ sudo stty -F /dev/ttyS0
speed 9600 baud; line = 0;
-brkint -imaxbel
erle@erle-brain-3 ~ $ sudo python
Python 2.7.9 (default, Mar  8 2015, 00:52:26) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial
>>> ser = serial.Serial('/dev/ttyS0',9600,timeout=1)
>>> print ser.readline()
%±%¥51e¬@
         µ%11M1
               !ñ%1
E¥

>>> print ser.readline()

±±Ü5¡¥Þ±1%@
           ¡Ã¥¥Æ±1%¬t!%¡G¡µ¡Ä¡Ö5
                               A¡%%w¡%±±%q¬;

±Ä!Äå%!%*

FAILED SOLUTIONS:
* apm.service is not installed, let alone running (when it was running on a previous flash, sudo stty -F /dev/ttyS0 was indeed returning random baud rates, consistent with a previous thread).
* I have tried different baud rates, but still get similar non-printing characters.
* I have tried forcing core_freq=250 in /boot/config.txt and rebooting to solve the known issue of the system clock in RPi3s ( https://frillip.com/raspberry-pi-3-uart-baud-rate-workaround/ )
* I have reflashed the CF card with Erle-Brain3-frambuesa-09-12-2016.img

Am I being stupid? I'm good with linux, but new to serial ports. Any ideas would be very gratefully received. Thank you!

[LanderU]

Hi @Richard,

can you see the GPS data in your GCS?

Regards,

@LanderU

[Richard]

Thanks @LanderU.

I'm not running a Ground Control Station. At the moment, I'm just trying to get the Pi to be able to talk to the GPS. Eventually, it will be doing various jobs as a companion computer, but this is a first feasibility test that the system will be able to do its required tasks... before I get the whole autopilot/GCS/APM working.

Can I do this without apm? If it would be easier for me to install apm now, please could you point me to an apm script that the pi could use to extract an NMEA string onto the local command prompt/file? (I'm never used apm before).

Cheers,
@Richard

[Richard]

Hmm, is the GPS unit somehow preconfigured to send its data in binary, for use with apm? Can I somehow (temporarily) un-configure that back to ASCII NMEA strings?

[celiasmith]

Did you ever figure this out @Richard?

[Richard]

No @celiasmith, @LanderU . I'd still love to be able to decode the binary messages from the GPS, but I haven't been able to - even by searching the mavproxy source code, which must contain a translation algorithm somewhere! If we could do that, unused cycles in the RPi would work great as a companion computer, being able to react to unexpected changes in the UAV's position, and (for example) override the next waypoint.

I got far enough to suspect that it is possible to send the GPS commands over the serial port, which will convert its output back to ASCII NMEA strings. However, that would stop APM from ever running, so I was reluctant to tinker.

My best workaround so far is to hack mavproxy.py in such a way that it interprets the binary data, then writes it to short logfiles rather than the continuous stream to which it defaults. I set up a daemon to start that on bootup, and leave it permanently running. I can then parse its short logfiles whenever I want, using mavlogdump.py (see https://pixhawk.org/dev/pymavlink ). This is inelegant, very slow, and uses a lot of disc space.