STAT packet is dropped by TheThingsNetwork

[Scobber]

there is an issue with the way the stat packet is built. the "temp" parameter is not part of the protocol specification and the connection is ignored on transmit

dca6ffffffffffff >< 172.20.1.248    UNCLASS   168 :: {"stat":{"time":"2020-06-23 03:19:40 UTC","lati":-10.05907,"long":10.89303,"alti":5,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"temp":30.0}} ::
Socket Timeout timed out

when the temp param of this data structure is filtered. then the stat packet is accepted.

this applies to Raspberry Pi 4 Model B Rev 1.2, OS "10 (buster)", 4.19.97-v7l+. RAKWireless gateway RAK2287 version 4.2.1R install from firmware.

[kalon33]

Confirmed on my side. I recompiled the packet forwarder with the temp variable removed, and it works properly.

[kalon33]

@Scobber did you also have issues with the GPS, or is it working as expected?

[Scobber]

The GPS was an issue until the stat packets were being accepted. GPS location stamping was working a minute or two afterwards.

In the logs, I am getting invalid timestamping errors. to be specific, /var/log/daemon.log.

Earlier I also had Daemon and Syslog fill the disk. 6GB each.

[kalon33]

@Scobber Could you please describe how you fixed all these problems? I deleted temp variable from packet forwarder sources that I recompiled, but I have no GPS data, neither in packet forwarder, nor in cat /dev/ttyAMA0... Was that your situation too?

[Scobber]

I haven't recompiled the source for the packet forwarder, I'm adding the other channels to the install scripts at the moment How I worked around the temp issue was with a python GWP proxy, which I used to strip out the temp var. I'll put the src for it on my Github. because it's pretty useful for hiding multiple gateways behind one IP as well as manipulating the data stream.

[kalon33]

@Scobber Thanks for your answer.

I'm adding the other channels to the install scripts at the moment

What are you doing exactly please? I will try to do the same thing on my side

[Taki-B]

@RAKWireless with the last commits you dropped all temperature monitoring but you could have left the one that was written in the logfiles for monitoring purposes...

[kalon33]

@RAKWireless with the last commits you dropped all temperature monitoring but you could have left the one that was written in the logfiles for monitoring purposes...

That's exactly what I thought when I saw the commit...

[Scobber]

I noticed that tonight as well, although its hard to confirm it when the install scripts are fundamentally broken in the dev branch. Also good to see the usage of the issue tracker from @RAKWireless 's side. Particularly when the software of the product seems to be in a pre-release state.

[Scobber]

Looks like the master branch is working properly, although the dev branch whos installers at first glance appears to be the same. @kalon33 the GPS did not work at first. ttyAMA0 was empty on cat, after a reboot, it appeared ok. and is relaying to TTN. Were you using a clean Raspbian? all I can think of is disabling login shell and enabling serial in raspi-config.

[Scobber]

did you guys even notice the temperature value, mine never budged from 30 so I'm wondering if it was even a real sample?

[Taki-B]

@Scobber : a quick grep over the log entries since 2020-06-21 did not show any other temperature than 30° C. I think you could be right with your suspicion. On the other hand the original file was created by Semtech (https://github.com/Lora-net/sx1302_hal/tree/master/packet_forwarder/src) and they should know how to read their sensors on their chips...

[cstratton]

There's no temperature sensor in an SX1302, unfortunately.

Rather the Semtech reference design has an additional I2C temperature chip, but the RAK2287 lacks that.

Since the temperature reading will never be anything but fake, completely dropping it is probably the right thing.

Though it's a pity the very inexpensive sensor was not included.