GPS

[Bob Doiron]

I’m just getting started with an AEP conduit. I hooked it up to DeviceHQ, but the GPS information is not showing up.

GPS appears to be working according to the API, so how do I get DeviceHQ to show it?

Thanks,
–Bob

curl -s -X GET -H ‘Content-Type: application/json’ http://127.0.0.1/api/stats/gps
{
“code” : 200,
“result” : {
“alt” : “61.5 M”,
“data” : [
“$GNGGA,132237.00,4440.77403,N,06334.78383,W,1,12,0.80,61.5,M,-24.1,M,,*43\r”,
“$GNGSA,A,3,80,71,73,72,81,82,83,,,,,,1.33,0.80,1.06*15\r”,
“$GPGSV,4,1,15,03,08,243,25,04,,,33,08,00,198,,09,22,315,21*40\r”,
“$GPGSV,4,2,15,14,15,160,17,16,77,269,33,21,10,093,17,22,00,224,*7B\r”,
“$GPGSV,4,3,15,23,50,286,19,26,68,048,36,27,30,179,14,29,15,038,23*70\r”,
“$GNGLL,4440.77403,N,06334.78383,W,132237.00,A,A*65\r”,
“$GNRMC,132237.00,A,4440.77403,N,06334.78383,W,0.194,,290518,,,A*77\r”,
“$GNVTG,,T,,M,0.194,N,0.359,K,A*3E\r”
],
“fix” : “1”,
“lat” : “4440.77403 N”,
“lng” : “06334.78383 W”,
“sats” : “12”,
“time” : “132237.00”
},
“status” : “success”
}

[Steve Kovarik]

Hi Bob

There was fix for this in the latest Conduit AEP firmware version 1.4.16,
what version of firmware is your Conduit at, and if a previous version,
could you upgrade to the latest firmware version and retest.

[Bob Doiron]

I upgraded to 1.4.16 shortly after I got it. Is there something I need to (re)configure?

ProductMTCDT-LAT1-247A

Firmware1.4.16
Radio Firmware17.01.502
Radio ModelLE910-NAG

[Bob Doiron]

Do I need to enable something here?

admin@mtcdt:~# curl -s -X GET -H ‘Content-Type: application/json’ http://127.0.0.1/api/gps
{
“code” : 200,
“result” : {
“client” : {
“enabled” : false,
“password” : “”,
“port” : 5445,
“protocol” : “TCP”,
“remoteHost” : “”
},
“nmea” : {
“gga” : true,
“gll” : true,
“gsa” : true,
“gsv” : true,
“id” : “”,
“idPrefix” : “”,
“interval” : 10,
“rmc” : true,
“vtg” : true
},
“server” : {
“dumpSerialPort” : false,
“enabled” : false,
“password” : “”,
“port” : 5445
}
},
“status” : “success”
}

[Jeff Hatch]

Bob,

Have you given the Conduit at least 12 hours to check in once it has a lock? Due to the way Device HQ behaves, it will not allow Conduit to send up GPS coordinates in any shorter than 4-8 hour intervals. The Conduit doesn’t get a GPS lock in time after reboot for it to send the coordinates up on check-in after boot. What that means is that you have to wait for it to send up coordinates on the next check-in after the one that happens at reboot.

When you tell it to check in through the Web UI, it will check in, however, it will not send up the GPS coordinates. I have verified that even though you can configure the GPS interval to an interval as small as 5 minutes, Device HQ responds on check-in and tells the Conduit that it has to increase the interval to something like four or eight hours.

Jeff

[Bob Doiron]

Ok – It’s been running overnight and still no GPS updates. Is there any configuration or logs I can check to figure out what is happening?

Thanks,
–Bob

[Jeff Hatch]

Bob,

In /var/log/messages on the device there will be messages from annexcd. That is the daemon that is responsible for sending up GPS data. Also, verify that the file /var/run/gps_dump. That is a file that is shared by different processes and contains the gps NMEA strings. If the strings are in the gps_dump file, then something may be going wrong with the annexcd process.

Jeff

[Bob Doiron]

/var/log/messages:

May 30 10:40:51 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3343: sending GPS data
May 30 10:40:51 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3346: gpgaa:
May 30 10:40:51 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3347: gpgll:

I don’t see a /var/run/gps_dump file:
admin@mtcdt:/var/run# ls -l /var/run/gps*
ls: /var/run/gps*: No such file or directory

[Jeff Hatch]

Bob,

Is the GPS server or client enabled in your GPS configuration? If not, try enabling one of those. If that works, then I think I know what may be happening. If that does not work try sending a SIGHUP to the mtsgps process.

The mtsgps process creates the /var/run/gps_dump file, however it has to get a SIGHUP to do that. Without the server or client enabled in GPS, I don’t think that mtsgps ever gets HUP’ed. This would be an enhancement that needs to be made so that it is not required to enable the GPS server/client programs for streaming data just to get the GPS data sent up to Device HQ.

Jeff

[Bob Doiron]

ok – GPS server enabled and now I have a gps_dump file:

admin@mtcdt:~# cat /var/run/gps_dump
$GNGGA,164925.00,4440.77168,N,06334.78468,W,1,12,0.95,56.8,M,-24.2,M,,*4C
$GNGSA,A,3,75,76,85,86,,,,,,,,,1.82,0.95,1.55*1A
$GPGSV,4,1,15,01,23,175,20,07,65,266,34,08,79,035,33,09,08,225,*7C
$GPGSV,4,2,15,10,04,068,,11,45,191,32,13,04,335,,16,15,097,06*71
$GPGSV,4,3,15,18,42,157,22,20,01,032,,27,39,054,34,28,19,290,25*73
$GNGLL,4440.77168,N,06334.78468,W,164925.00,A,A*64
$GNRMC,164926.00,A,4440.77167,N,06334.78465,W,0.064,,300518,,,A*71
$GNVTG,,T,,M,0.057,N,0.105,K,A*3B

It didn’t update DeviceHQ with GPS info when it rebooted, but I’ll wait to see if it pulls it on the next check in.

[Jeff Hatch]

Bob,

I am going to file an enhancement request. I don’t think that this functionality is working the way it is supposed to. Let me know if what’s been done so far fixes your issue.

Jeff

[Bob Doiron]

Nope – still not updating position on the DeviceHQ site.

Strange, since the change it seems to be checking in twice in a row:

Connected Duration (min:sec)
SSL

May 30 17:56 00:58.56 true
May 30 17:49 00:30.59 true

May 30 13:55 00:49.22 true
May 30 13:47 01:6.38 true

May 30 12:27 01:8.44 true
May 30 11:42 01:14.36 true
May 30 07:40 01:15.96 true

From the log, it looks like it does GPS in one session and the rest in another?

May 30 20:49:14 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3343: sending GPS data
May 30 20:49:14 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3346: gpgaa:
May 30 20:49:14 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3347: gpgll:
May 30 20:49:46 mtcdt daemon.info annexcd: [INFO] courier.cc:RunnableCore:1387: timing out socket connection due to inactivity

May 30 20:56:45 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3322: sending cell stats
May 30 20:56:45 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3332: sending network stats
May 30 20:56:50 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3359: sending active apps
May 30 20:56:50 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3368: sending lora
May 30 20:56:53 mtcdt daemon.info annexcd: [INFO] delivery_agent.cc:RunnableCore:3307: requesting package delivery

I also see these errors in there about every 2 minutes:

May 30 21:00:14 mtcdt user.notice ntp_sync:
May 30 21:00:54 mtcdt user.err admin: Is GPSD running?
May 30 21:00:54 mtcdt user.err admin: FIX OK field should be single hex digit: gpsmon data: gpsmon:ERROR: TCP device open error can’t connect to host/port pair.
May 30 21:00:54 mtcdt user.warn admin: GPS does not have a fix yet. Try again later.

[Jeff Hatch]

Bob,

It may be that the GPS interval is not in sync with the regular check-in interval. That can happen with the way the intervals are designed and would explain the separate check-ins.

It looks like the GPS is having trouble keeping a lock/fix. The only thing I can think of right now is that the interval that there isn’t a fix is large enough that annex client is not getting coordinates from mtsgps.

The annex client connects to mtsgps over a socket and does not read the gps_dump. The gps_dump file is used by other things including the Web API. What that means is that I think that annex client has a “more real-time” access to the current GNSS data from the ublox chip. Unfortunately it seems to be querying the chip when the lock/fix has been lost.

I’m not ruling out another issue, but with the devices I have, once I see a lock, the GPS coordinates get sent to Device HQ.

All that said, have you tried putting the conduit somewhere where the GPS reception would be better?

Jeff

[Bob Doiron]

I have yet to run this command and not see it updating the data. It’s always tracking 11-12 satellites. I think something else is broken.

admin@mtcdt:~# curl -s -X GET -H ‘Content-Type: application/json’ -l http://127.0.0.1/api/stats/gps

{
“code” : 200,
“result” : {
“alt” : “60.3 M”,
“data” : [
“$GNGGA,145857.00,4440.77119,N,06334.78398,W,1,11,0.94,60.3,M,-24.2,M,,*49\r”,
“$GNGSA,A,3,67,85,76,,,,,,,,,,1.77,0.94,1.50*19\r”,
“$GPGSV,3,1,12,07,28,308,35,08,48,206,25,09,39,268,26,11,00,193,*7F\r”,
“$GPGSV,3,2,12,16,52,060,34,21,19,051,25,23,32,222,22,26,26,077,27*75\r”,
“$GPGSV,3,3,12,27,78,124,33,30,02,308,,48,06,255,,51,23,234,*75\r”,
“$GNGLL,4440.77120,N,06334.78402,W,145856.00,A,A*62\r”,
“$GNRMC,145857.00,A,4440.77119,N,06334.78398,W,0.070,,310518,,,A*7D\r”,
“$GNVTG,,T,,M,0.070,N,0.130,K,A*38\r”
],
“fix” : “1”,
“lat” : “4440.77119 N”,
“lng” : “06334.78398 W”,
“sats” : “11”,
“time” : “145857.00”
},
“status” : “success”
}

[Jeff Hatch]

Bob,

Please create a Multitech Support Portal case at: https://support.multitech.com/

I am not sure what is going on, but a person that can dedicate more time to reproducing and tracking down this issue will be assigned to the case.

Sorry we couldn’t get this resolved in the forum.

Jeff

[Author]

Posts