Dragino TrackerD - Where can I find a working Payload Decoder?

End Devices (Nodes) Dragino
1

I connected my Dragino TrackerD successfully to TTN. Uplink works and I wanted to add a payload decoder. The decoder provided by Dragino for TTN does not seem to work correctly. I was following the instructions here: 2.4.7 Add Payload format in TTN V3, and tried all 3 versions of payload decoder from here

I am not a programmer and the payload decoder code is somewhat over my head.

For all 3 versions, I get this back:

Blockquote
“decoded_payload”: {
“ADDR”: “”,
“ALARM_status”: “FALSE”,
“BatV”: 4.196,
“Dvice_Information1”: 0,
“Dvice_Information2”: 0,
“Dvice_Information3”: 0,
“FIRMWARE_VERSION”: null,
“FREQUENCY_BAND”: null,
“Hum”: 0,
“LON”: “OFF”,
“Latitude”: 0,
“Location”: 0,
“Longitud”: 0,
“MAJOR”: 1,
“MD”: 64,
“MINOR”: 1,
“POWER”: 0,
“RSSI”: 0,
“SENSOR_MODEL”: null,
“SUB_BAND”: null,
“Tem”: 0,
“UUID”: null

Obviously, the decoder does not seem to work, since the location data is always 0.
Yet, if I look at the JSON data itself, in the section “rx_metadata”, “location”: ", I see the correct lat, long, etc…

Can anyone educate me what is wrong?

Thanks
Dan

1 Like
2

Same problem here… would love to see a solution.

3

Maybe mention the problem to Dragino.

4

It looks like you need to send several AT+ commands to the GPS tracker via Serial port.
It’s now working for me.

5

Can you share instructions, please…

6

I am not 100% sure what finally did it, as I have sent various commands to the tracker via the serial Connection.

In any case, I sent the below commands, not sure of the order and which one finally did it… :
AT+LON=1
AT+INTWK=1
AT+PDOP=2.5
AT+SMOD=1,0,0
AT+INTWK=00
AT+FTIME=180000

(all seperate commands)

At a certain point, the tracker will start beeping and the screen will show an “Alarm for GPS”. At that point I understand that it gives an alarm as it does not have a GPS signal. Leave it on the connection for a while (15-20 seconds) the led should start blinking blue (Which I understand to mean that it’s searching for a GPS signal) then remove the cable and place the tracker somewhere with a clear view to the sky, within range of the lorawan gateway that it’s supposed to connect with. Once it had GPS signal and was within range of a gateway, the payload decoder shows the correct gps position.

Hope this helps others…

7

Note: “rx_metadata” contains not the location of the tracker. It contains information regarding the gateway. Therefore this is the location of the gateway!
The payload decoder delivers “0” when there is no connection to GPS provider. IMHO this is not correct, as this is a valid location somewhere in Africa.
Valid range for longitude is +/- 180, for latitude is +/-90. In case of no connection, the payload decoder should deliver some value out of range e.g. 255 for longitude and 128 for latitude. Detection of invalid data would be much easier.

8

Fact is this is common behaviour with many trackers and GPS enabled sensors, not just Dragino - but perhaps you should flag this to Dragino for them to consider (via support or their forum) - no one here can fix it! IIRC even the original LoRaMOTE’s with original firmware supplied with the 1st Semtech reference design for LoRaWAN and the (now long obscolete) SMTC IOT Starter Kit had same issue. Until the GPS got a fix (typically up to 1st 3 samples/messages etc). the Lat/Long value would be 0,0 - just off the West coast of Africa - before starting their real tracks. Many applications were therefore adapted when using such trackers to basically reject the 1st 3 received locations received - until it could be assumed a ‘fix’ was likely real :wink: 2 of my own 'MOTE’s still behave that way! Cant tell you how many archived tracking sessions I have on file where start point is still 0,0!

Similar issues used to arise (occasionally still do) with GW’s where owner would not set GPS correctly manually or via automated message, and system provided value was 0,0 default - amazing how many GW’s could be crammed into such a small location in the Atlantic Ocean :rofl:

Absolutely, yes… as expected, then you know where the GW’s are (if data good as above) that received that particular message…can be used to build a coverage heatmap… :wink:

9

I am new to LoRaWAN and TTN and a little bit surprised about your answer.
Is this behavior common sense for ALL type of sensors? What about sensors for temperature, fuel level or electricity meters?
And what about the data sinks (e.g. TTNmapper.org, cayenne, you name it…)? Do they have any conventions for invalid readings from sensors? This should be basic (IMHO).

10

Cant speak for ALL sensors! You need to read any associated documentation. People often assume the same fix speed and accuracy as their mapping app on e.g. mobile phone which tends to set wrong expectation.

WRT end applications Cayenne will show what it is given (and given Cayenne GPS payload and rounding/truncation with a quantisation of presented location (eftectively points will map to a grid) - just off out mapping in Thames Valley shortly and will try to post pics of what you might expect later (no time to pull archive now). Sites such as TTNMapper have their own rules on what they expect to see and will accept wrt, yes quality of, GPS signals - atleast where presentation on Main site Map is concerned - they use e.g. the Hadoop value in metadata. If running private ‘experiments’ it may be different - not shown on main map to avoid data polution - again read the documentation.

Generally most generic sensors designed to not present info until they have a valid data point - in the case of temp remember 0 is valid! with start up values some form off out of range or extreme. WIth GPS also 0 or specifically 0,0 or anywhere on the equator or on Greenwich Meridian can have a 0 value…and the Sensor and hence the end presentation point may have no way of knowing/eliminating if ‘wrong’. I have seen situations where the longitude value was missing or wrong but latitude was correct and so a spurious point at right latitude jumps over to show on Greenwich meridian… YMMV! :slight_smile:

11

I am curious, which part of the chain of data, from node to end application, are you expecting to know what is valid data,or data that is outside limits, and what is not ?

12

@c64emu a bit late but as promised here are some pictures showing some of the weird (but usually explainable) presentations you see in end apps.

This is what happens with a LGT92 (v1.5+) presented in Cayenne when battery runs out! Not even a 0,0 value - seems to warp time and space…ok space!

image
image1920×1080 110 KB

And here showing essentially a static tracker on a window ledge for many hours with error induced by reflections, masked satellites etc,. Note the grid like structure of the location ‘dots’ which represents the quantisation and rounding of the cayenne payload wrt full lat:long data

image
image1920×1080 293 KB

And a tracking MOTE where 1st data point was 0,0 with rest fixed in Thames Valley area of UK (again in Cayenne)
image
image1920×1080 183 KB

A tracker in a vehicle parked outside a building for a few hours: (shows quantisation again)

image
image1920×1080 89.5 KB