[Bob Doiron]

Has anyone seen documentation for this process?

admin@mtcdt:~# ps -eaf |grep watchdog
admin 3437 1 0 Feb01 ? 00:00:10 watchdog –device /dev/watchdog –ppp
admin 18138 13069 0 12:08 pts/0 00:00:00 grep watchdog

admin@mtcdt:~# which watchdog
/sbin/watchdog

admin@mtcdt:~# watchdog –help
Usage: watchdog
–api (a) : watches and restarts api process
–ddns (i) : watches and restarts ddns process
–ppp (p) : watches and restarts ppp process
–lora (l) : watches and restarts lora process
–node-red (n) : watches and restarts node-red process
–device (d) : path to hardware watchdog device
–help (h) : prints this message

[Bob Doiron]

Yes, our servers send a response code. I already have a watchdog of sorts built in to my node-red flow that will reboot the box if the node-red flow is unable to deliver messages for 4 hours. It also delivers lora stats every 5 minutes as a heartbeat.

Unfortunately, on several occasions we’ve found that the conduit continued to update devicehq, but was no longer delivering data to our api and my node-red watchdog didn’t activate. Nothing was written to the node-red logs either, so I concluded that node-red itself either hung up or crashed.

We’re using 1.6.2 which does have log rotation for node-red. I haven’t tried 1.6.4 yet, but I hope they didn’t un-fix the node-red log rotation. We had previous issues with the node-red log getting too big.

[Bob Doiron]

Thanks! That looks promising.

[Bob Doiron]

It works most of the time – it’s an intermittent thing that didn’t seem to exist with 1.4.16.

New problem – downgrading from 1.6.2 back to 1.4.16 seems to prevent all xdots/mdots from being able to join the lora conduit. Seems like this is a one way upgrade and I’m going to have to implement retries to our api in the node-red flow. Nasty.

• This reply was modified 5 years, 7 months ago by Bob Doiron.

[Bob Doiron]

I think I may have answered my own question:
https://www.multitech.com/support/resolutionid/5084138

And in the developer guide: https://www.multitech.com/documents/publications/manuals/s000612_DB9.pdf

SPI Flash
Note: Using the SPI Flash, Micron M25P16 Family.

I’m surprised this isn’t mentioned in the data sheet.

[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”
}

[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.

[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.

[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

[Bob Doiron]

It looks like this might have corrected itself. I must not have waiting long enough to see it.

[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

[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”
}

[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

[Author]

Posts