Library Error Message

End Devices (Nodes) LMIC
41

Version 2 is fine - but the zip download is now neatly hidden inside the oval blue-is Code button a bit down on the right.

42

Just found it - as you say hiding under another button!

43

It’s working! Because it was quick to do I just compiled the bike tracker code with the new library and it is now transmitting on 868MHz and, wonder of wonders, my new gateway (8 channels no fruit involved) is picking up packets. No low memory warnings either 767 bytes left.

1 Like
44

I need to do some work on decoding the packets now. I found an example but it doesn’t quite align with the way these packets are put together but it is a start.

But not before tomorrow I think. Time for a break. Very many thanks yet again and no doubt I will have more questions later. :slight_smile:

45

Just an update. I’ve added the altitude improvement (altitudeGPS>>16) in the code which also required the third line down to be changed from int16 to int32:

 int32_t lat = flat * 10000;
 int32_t lon = flon * 10000;
 int32_t altitudeGPS = faltitudeGPS * 100;
 int8_t hdopGPS = fhdopGPS;

channel = 0x01;
coords[0] = channel; 
coords[1] = LPP_GPS; 
coords[2] = lat >> 16;
coords[3] = lat >> 8;
coords[4] = lat;
coords[5] = lon >> 16; 
coords[6] = lon >> 8;
coords[7] = lon;
coords[8] = altitudeGPS >> 16;
coords[9] = altitudeGPS >> 8;
coords[10] = altitudeGPS;
}

Then I found a simple decoder which I amended to include altitude:

function Decoder(b, port) {
 
  var lat = (b[2]<<16 | b[3]<<8 | b[4]| (b[2] & 0x80 ? 0xFF<<24 : 0)) / 10000;
  var lng = (b[5]<<16 | b[6]<<8 | b[7]| (b[5] & 0x80 ? 0xFF<<24 : 0)) / 10000;
  var alt = (b[8]<<16 | b[9]<<8 | b[10]| (b[8] & 0x80 ? 0xFF<<24 : 0)) / 100;
  return {
    location: {
      lat: lat,
      lng: lng,
      alt: alt 
    },
  };
}

This seems to work although the altitude figure varies a lot between 95 and 155 (should be 70) but that might be just as a result of a poor view of the sky as it is raining so it is looking through a window.

Curiously, I don’t seem to be able to alter the order they appear, alt is always first, then lat then lng. It seems to want to work in alphabetical order. :slight_smile:

What I’m not sure of is should I be doing something with bytes [0] & [1] because the decoder is currently ignoring them?

46

Where is this LPP_GPS defined? If defined in some library then I’d assume it would also provide functions such as, say, addGPS? Also, if properly encoded using Cayenne LPP then TTN Console can decode for you out of the box, if you select the proper payload format:

TTN Console

That said, assuming coords is some 8 bits data type, then it seems your code looks okay. You don’t need to use the channel in bytes[0] if your device only has a single GPS receiver. Also, you don’t need to validate bytes[1] if you know what you’re sending… In fact, you could also not use Cayenne LPP and not send those 2 bytes, and use a decoder like you did. Altitude could then maybe use fewer bytes too. In all, that would only limit the total payload from 13 + 11 = 24 bytes to about 13 + 7 or 8 = 20 or 21 bytes. (A LoRaWAN packet always needs at least 13 bytes of overhead.)

Aside: please see How do I format my forum post? [HowTo]

47

Thank you, I’ll have another look later, walking the dog at the moment. :slight_smile:

And I’d forgotten there is a format for pasting code. Oops!

EDIT: Just formatted it. :slight_smile:

48

That Cayenne LPP payload format works perfectly, many thanks. :slight_smile: This probably explains why in the original article in my first post (OP) there is no mention of decoding.