Not finding GPS device on Linaro / Dragonboard 410c

Products Support DragonBoard410c
#1

Hi all,

We’re currently running into some problems with the onboard GPS of the Dragonboard 410c.

uname -a
Linux linaro-alip 4.14.0-qcomlt-arm64 #1 SMP PREEMPT Wed Jan 30 04:14:16 UTC 2019 aarch64 GNU/Linux

Followed the steps over here:
https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/latest/

But the result is that no GPS devices are found, gpsmon says:

tcp://localhost:2947 JSON slave driver
(82) {“class”:“VERSION”,“release”:“3.17”,“rev”:“3.17”,“proto_major”:3,“proto_minor”:12}
(32) {“class”:“DEVICES”,“devices”:[]}
(122) {“class”:“WATCH”,“enable”:true,“json”:false,“nmea”:false,“raw”:2,“scaled”:false,“timing”:false,“split24”:false,“pps”:true}

We got this working (with an extra passive antenna) on a Geniatech DB4 (also 96boards) without any problem and without modifying kernels etc.

Are we missing something?
Thank you in advance,

Chris

#2

Geniatech db4 is neither 96boards compliant, nor in any way related to or endorsed by Linaro.

How did you start gpsd?

#3

This was discussed less than two weeks ago. See:

#4

It was not a signal problem, the device itself was not found.

Seemed a fault in the distro versions, I believe the Geniatech DB4 had 17.04 (on which it seemed to work), the Dragonboard had 18.04 on which it was disabled. I’ve now installed the 19.04 version of august in which it seems re-enabled.

The DB4 already has a passive antenna (did not help very much) and we’re going to install an active GPS antenna on the Dragonboard tomorrow, hope that will improve the signal itself.

Although not officially supported the Geniatech DB4 seems to work quite nice with Linaro (also the GPS). Only problem we had is it didn’t recognize any of our sensors over I2C.

We needed a little bit more power due to navigation on the system (DB4 has 2GB RAM and 16GB eMMC). But I think we’ll have to figure out a way to get it to work with the Dragonboard for now.

Thank you for your time!

#5

I usually don’t find it all that useful to muck around with the onboard GPS. Especially considering the poor antenna that it comes with. Yes, you can modify the board to add an external antenna, but for LESS cost than all the parts it takes to add an external antenna (counting the antenna, the connector, etc.), you can get a u-blox 8 that connects by USB and just plugs straight in.

#6

@doitright, will take that in consideration. Adding these components by hand is also almost undoable.

We do have it working now with an active GPS. However, the location is close but off by about 50km.
Does this have to do anything with definitions (satellite position data) that needs to be updated? And how do you do that in Linaro?

#7

50 km off? That is unheard of. Sounds like some serious kind of driver bug. Like it’s claiming to have a lock when it doesn’t, and is sending bogus data to you.

#8

I agree, the distance he’s off also always seems to be the same wherever you are: +/- 50km off to the south-west.

We’re building our own carrierboard at the moment, so maybe we need to take the Ublox 8 in consideration if this is the onboard alternative :grimacing:

#9

What do you mean by carrierboard? Home brew sd410 board? Or a mezzanine that the dragonboard snaps into? If the former, then there’s nothing holding you to their choice of bt+wifi+gps chip, you can pick something else that is more modern and works better.

#10

@doitright Sorry for the late response. Have been trying several things lately (besides other projects ;)). But we haven’t found a solution for the 50km offset in the onboard GPS of the Dragonboard 410c.

We’re actually building our own carrierboard. We’re integrating Canbus over SPI and integrating a Bosch BNO055, with touch screen and a few other things.

I’m not an electronics specialist though (programmer)… to come back to your option of the external U-Blox 8, we found this one at Reichelt: NAVILOCK 62575: GNSS GPS Engine module - u-blox 8 - USB bei reichelt elektronik

This would be a no-brainer plug and play solution over USB (high speed connector)? Or will we run in the same kind of problems regarding the drivers on Linaro?

#11

If you plug in a usb ublox receiver and run “cat /dev/ttyUSB0”, it will start spewing out nmea with accurate coordinates (after the time it takes to lock on, of course). Gpsd will, of course, be able to handle the receiver much more sensibly than that. The only dependency is to have the proper usb-to-uart driver built into the kernel, which is a pretty standard default.

#12

The receiver in your link is ridiculously over priced. Check Amazon, you should be able to find these things for about $15.

#13

@doitright We’ve purchased and connected the u-blox 8.
Standard Linaro installation does not show /dev/TTYUSB0, correct?

We get an error in dmesg currently:

new low-speed USB device number 28 using ci_hdrc
device descriptor read/64, error -32
device descriptor read/64, error -32

After connecting (USB wiring seems fine and we added the 3.3v power).
Could the -32 error mean it draws to much current?

The USB hub is externaly powered however.

#14

@doitright Sorry we got it, the data + and data - of the USB had wrong wiring colors. When switched it seems to work, at /dev/ttyACM0 though.

When we interprete the latitude/longitude however (right from the data we read with CAT) we once again end up +/- 50km southwest of the correct position. Exactly the same problem we had with the Dragonboard 410C onboard GPS :frowning:

#15

If 2 different GPS devices are reporting the same position that does not concur with your expectation, then it seems like either your expectation is incorrect, or your interpretation of their results is incorrect.

I’ll go out on a limb and guess that you are interpreting it as decimal degrees, when it should be interpreted as degrees and minutes.

From the NMEA, you will have a number such as 7234.5678. It means 72 degrees and 34.5678 minutes. There are 60 minutes in a degree, so that converts to 72+34.5678/60 = 72.57613 degrees.

#16

@doitright We came to the same conclusion that the data must be correct and that there was some conversion we were doing wrong. I’m not totally certain about the type of data we’re receiving etc. but your calculation indeed gave us the 100% correct coordinates we were looking for.

We were already certain that the first two digits (minutes) should be devided by 60 (so we came close) but were uncertain about the numbers after that. Thank you for exlaining that to us :slight_smile:

Seems like the onboard GPS was also correct, but this u-blox 8 seems to get a much quicker fix so we’ll likely stick to that.

Thank you once more for your time, it was a big, big help for us.

1 Like