Error (lora-packet verify) (Dragino Hat + T-Beam)

End Devices (Nodes)
1

Hi.
I’m running a small test, on knowledge level, and I would appreciate your help.
I’m using a Dragino Hat v1.0 on my raspberry pi, configured as a single channel “gateway”, and a TTGO T-Beam as a end node, configured to send GPS data to TTN through the hat. I’ve got dio1 connected to pin 33 on T-Beam.

It took one hour for the first and only package arrive at TTN. And a good time later, other packets started to show up on raspbian terminal from time to time (±30 minutes), I decoded it and they say:

Error (lora-packet verify): expecting pktBufs packet.DevAddr to be a Buffer length=4

I believe there may be a wrong parameter somewhere but I’m having a hard time to find anything about this error.

//Code setup

The codes I’m using are based on the following projects, with minor configurations:
Project used for gateway: GitHub - tftelkamp/single_chan_pkt_fwd: Single Channel LoRaWAN Gateway
Project for T-BEAM: GitHub - DeuxVis/Lora-TTNMapper-T-Beam: TTNMapper on the TTGO T-Beam

Main gateway setup ( Dragino LoRa GPS HAT for Raspberry Pi v1.0 http://www.dragino.com/products/module/item/106-lora-gps-hat.html)

int ssPin = 6;
int dio0 = 7;
int RST = 0;
sf_t sf = SF7;
uint32_t freq = 915000000;
#define SERVER1 “13.66.213.36”
#define PORT 1700

Main TTGO T-Beam setup
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN, // was “14,”
.dio = {26, 33, 32},
};
LMIC.dn2Dr = DR_SF9;
LMIC_setDrTxpow(DR_SF7,14);

//Arduino monitor output

T-Beam (ignore No gps Fix, I’m indoors right now):
Valid gps Fix.
01:28:15.240 → Lat: -10.315424
01:28:15.240 → Lng: -20.253535
01:28:15.240 → Packet queued
EV_TXCOMPLETE (includes waiting for RX windows)
No gps Fix.
No gps Fix.

//Gateway output

Packet that successfully made it to TTN
rxpk update: {“rxpk”:[{“tmst”:604646536,“chan”:0,“rfch”:0,“freq”:915.000000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:0,“rssi”:-103,“size”:22,“data”:“eUUXDyaALwABpFqEsdGWLwb9+9XjGQ==”}]}

Packet that returned error
rxpk update: {“rxpk”:[{“tmst”:273833083,“chan”:0,“rfch”:0,“freq”:915.000000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:-12,“rssi”:-109,“size”:55,“data”:“2RznVZdWDIRCis+Kfnu3+tpoaFEWP+GIfBmXh0NYJ1PUsIUJ52EcWC1CtUI5D7PBbbamzcYRKw==”}]}

Listening status (runs every 30 seconds)
stat update: {“stat”:{“time”:“2018-10-30 13:52:48 GMT”,“lati”:43.29942,“long”:-74.21793,“alti”:376,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single Channel Gateway”,“mail”: “hilarioemail@gmail.com”,“desc”:“test LoRa Hat Raspberry”}}

If there’s anything else I need to inform, please let me now. Thank you very much for your attention so far.

2

compliments for your topic start :+1:

1 Like
3

I think this could be your problem :

You are using a single channel gateway and a multichannel node.
The node changes channel every transmission So not all transmissions are received by your gateway.
Solution could be to edit the channels in your node So that they are all the same and equal to the channel on your gateway.

also it looks like you are using EU frequencies for the node

1 Like
4

When decoding the Base64 messages in the logs into a hexadecimal representation, you’re seeing the following 22 and 55 bytes packets:

7945170F26802F0001A45A84B1D1962F06FDFBD5E319

…and:

D91CE75597560C84428ACF8A7E7BB7FADA686851163FE1887C19978743582753D4B08509E7611C582D42B542390FB3C16DB6A6CDC6112B

The first byte 0x79 is binary %01111001, where the first 011 denotes an unconfirmed downlink, not an uplink. And 0xD9 is %11011001, where 110 tells you it’s reserved for future use. I guess that the error about the DevAddr is just caused by your decoder not knowing what to do.

image

Maybe these are random LoRa (not LoRaWAN) packets not sent by your node at all; do you see the packets at the same time your node is sending? If yes, then maybe check the antenna, and increase the distance between node and gateway to avoid distortions. If there’s any other gateway around then it would be good to see what that one receives. Also, what length of the packet do you expect?

Did the first packet even decode into something you expected? The 4 bytes after the header byte, 0x45170F26, seem to indicate it’s a TTN DevAddr, 0x260F1745, but it’s still a downlink… Due to “inverted IQ” a downlink from one gateway should not be received by other gateways, so if this is a downlink sent by another gateway, then maybe the IQ is wrong on yours?

1 Like
5

Assuming the problem could be the single channel gateway and multichannel node, I’ve tried to install bokse001/dual_chan_pkt_fwd/tree/dual_chan_pkt_fwd_up_down .Which is a fork of the single channel version for the raspberry pi LoRa Hat which turns the gateway into a dual channel gateway. But I’m confused about the frequencies and spreading factors I should use.

Trying to detect module CE0 with NSS=6 DIO0=7 Reset=3 Led1=unused
SX1276 detected on CE0, starting.
Trying to detect module CE1 with NSS=6 DIO0=7 Reset=3 Led1=unused
SX1276 detected on CE1, starting.
Gateway ID: b8:27:eb:ff:ff:9b:7f:90
Listening at SF7 on 903.900000 Mhz.
Listening at SF7 on 905.300000 Mhz.

I’m not sure about the value of the frequencies. Here in Brazil we support 902-928 MHz. Does that mean I could use 902 for channel 1, and 928 for channel 2, for example? I’m having trouble to understand this, I’ve only found examples using 868.1MHz frequencies.

Anyway, I tried this method and the gateway received three 22bytes packets in about 30 minutes, the packets arrived through channel using 903.9 Mhz.

pkt

I’m not sure this is a good result, I understand LoRa is limited, and that I’m using the cheapest gateway method, so maybe it is.

6

without changing the frequencies of your node ?

7

Yes, I haven’t changed. I also forgot to say I’m using ABP, if it is of any relevance on this scenario.

image

Example of successful packet:

image

It takes nearly 30 minutes uptime to receive the packet.

It is also strange how from the moment I turn off the node, the gateway completely stops receiving any kind of packets. Not just the packets destined to 26031745. The packets also seems they’re being sent in pairs (time field below) with different addresses. Which makes me believe these Device Addresses are being somehow “generated”(?). The dual channel code required mapping the same pins for both channels, this may be related.

image

8

so you use EU frequencies on the node ? line 146-154

2 Likes
9

Please don’t post images for terminal output: that makes it hard to copy details.

Anyway, the QAMmAAE4Kv1C1q1FF4AfMeChD17yoA== now nicely decodes into an uplink. However, it shows a huge counter value of 64,810. Given the different timestamps I also assume the terminal output and the screenshot of TTN Console are unrelated?

Seeing data in TTN Console’s Traffic page doesn’t tell you much; that could even be plain LoRa (not LoRaWAN) from other sources. But if TTN Console shows the packet in the Application Data, then it used the secret NwkSKey to validate the Message Integrity Code, so chances are low that the packet was somehow distorted then. When you also see the expected decoded application data (like shown in the screenshot) then you can also assume that the secret AppSKey is okay. So, the packet for the screenshot seems very fine, but the packet from the terminal output (seeing the huge counter) might be erroneous after all.

So, it’s safe to assume that all packets you see are indeed generated by your node. You should also be able to tell as you know when the node is sending?

Did you meanwhile try to increase the distance between node and gateway? A few meters at least, to avoid distortions/crosstalk. (Certainly along with the possibility you’re using EU868 frequencies in the node, like BoRRoZ suggested.)

That by itself is not a problem. Yes, if you don’t make the node only use the frequency that the gateway is listening to, then you’ll not receive all packets. But when a packet is sent on the expected frequency and SF, then it should be received just fine.

2 Likes
10

I’ve changed the following parameters on LMIC library config.h to attend the device specs:

#define CFG_us915 1
#define CFG_sx1276_radio 1

Then, back on the project file, I removed the block of code from line 146 to 154, and included the following line:

LMIC_selectSubBand(1);

11

I’ve increased the distance between them, and the result was positive, that surely was an issue before.
Analyzing the packet logs on gateway, I’ve realized the packets had a fixed 4 minutes interval, and from the node perspective, I can see packets via serial monitor.

This is the code so far: https://pastebin.com/geS9JEn0

13

see Can LMIC 1.6 be set up to use a single channel and SF?

14

Hey, I’m also doing a project similiar to this, using the raspberry, the Pi Hat and the TTGO t-beam, but in my case this is the only package received by the Pi Hat

Packet RSSI: -102, RSSI: -102, SNR: -11, Length: 124

rxpk update: {“rxpk”:[{“tmst”:2126325270,“chan”:0,“rfch”:0,“freq”:915.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:-11,“rssi”:-102,“size”:124,“data”:“qg0cSkgOyr2e9l0tsrq4Efhg3Ri75vbV68mPBUguacX3RNRW7Ta6F9dsoiY/Z2j+n53cdaxN82J1rg8oRc2WeTqgWjPkxezyviLwnjoKKWyf793Ny3UR3w7MIxJCWYvgjC2N37Ln/ut45lj91e/7M1Y60cgTAXudBaeOig==”}]}

I’m unable to understand it, and also the TTGO T-beam is not showing activity in the TTN, only the gateway (Pi Hat) is connected. Could someone help me figure this out? Code is the same as @kryogen kryogen

15

So your using a Pi Hat, but what are you using the Pi hat for, and with what hardware ?

How often are the packets the Pi Hat is apparently receiving, being received ?

What is the distance between the TTGO and the Gateway ?

16

Your problem is no doubt the same as OP >4 years ago:

Search for SCPF & DCPF on the forum, to understand further. These were barely tolerated back then and were deprecated, today with better understanding of behaviour and massive reductions in the cost of GWs they are no longer tolerated and supported (not LoRaWAN spec) due to the impact on other users and challenges of working effectively. Please disconnect it from TTN or move to a private instance and/or get a LoRaWAN gateway….

17

Thanks for all answers, but in the meaning of test purposes what do you think is the best option to build a Geofence using a LoraWan Low cost technology? I’ve also looking for a Heltec v2 LoRa to use.

18

Hi, I’m using a Dragino Pi Hat Lora/gps_hat da versão v1.0 do chapéu de lorgps é um módulo da despesa para lorawan e gps para ues com o pi da framboesa|Circuitos integrados| - AliExpress

19

Ah a Single channel packet forwarder, not supported on TTN even for test purposes. Please remove it as it causes disruption to the rest of the network.

Try a Things Network Indoor Gateway for a compliant but low cost Gateway.

20

Perhaps describe the application in more detail.

As a general rule because of the limited number of packets you can send for free per day using TTN, maybe only 25 packets a day, TTN may not be suitable for your application.