The Things Network – thescobber

TTN Downlink Problems

October 11, 2020December 3, 2020thescobberLeave a comment

Configuring the gateway parameters in console.thethingsnetwork.org is not as important as it appears. Here in Australia the ‘thethings.meshed.com.au’ appears to apply arbitrary filtering on our gateways. It is the only router in this region (AU_915). so from time to time when this filtering is an issue we will swap to another router. We also don’t use thethings.meshed.com.au for applications much. because integrations are not as configurable, and we have to use a ‘special’ dashboard.

So the issue here is the “frequency plan” setting seems to only be for statistics. As is the “Router” configuration. It can be set to anything, it does not appear to mean much. When set to anything you can forward packets in anywhere. and by the Things Networks own documentation. A unregistered gateway will still work. but the packets it received will be stamped untrusted.

So back to the problem. When you use ttn.opennetworkinfrastructure.org as your router. All downlink packets are enqueued against the channel plan for EU_868. When this happens the gateways here in Australia to discards the transmission. Even though the gateways frequency plan is defined correctly in the dashboard. This lets me to believe that value is only for statistics.

_{^{60c5a8fffe74d372 >< 172.20.1.55 PUSH 207 :: {"rxpk":[{"tmst":1623936916,"chan":2,"rfch":0,"freq":917.200000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":8.5,"rssi":-70,"size":23,"data":"AETpAdB+1bNwEQFVAAAAAAGu+9RhEKQ="}]} ::}}
_{^{thethingsnetwork <> 52.169.76.203 PULL_RESP 213 :: {"imme":false,"tmst":1622032348,"freq":869.525,"rfch":0,"powe":27,"modu":"LORA","datr":"SF12BW125","codr":"4/5","ipol":true,"size":33,"ncrc":true,"data":"IAzxv/1dO/oMXS5B/Ke4zhfnBTYMQDboBpq0FuO2fphB"}} ::}}

The only way to overcome this problem appears to use the correct router for the region. Which for AU_915 is the infrastructure hosted by Meshed. And I guess we will have to put up with the arbitrary filtering.

Working OTAA compatible TTN Routers

au915.thethings.meshed.com.au
router.au.thethings.network
router.us.thethings.network	Make sure the gateway has min/max TX freq set. Does work-around meshed for OTAA

Working routers for AU_915

Router DNS Address	Region	Region
thethings.meshed.com.au		AUS
router.au.thethings.network		AUS
au915.thethings.meshed.com.au	AU915 915-298	AUS/NZ
as923.thethings.meshed.com.au	AS923 – “AS1” 922-923	AUS

https://www.thethingsnetwork.org/docs/gateways/packet-forwarder/semtech-udp.html
https://www.thethingsnetwork.org/country/australia/

Router DNS Address	Region	Country
router.eu.thethings.network	EU433 and EU863-870	EU
router.us.thethings.network	US902-928	US
router.cn.thethings.network	CN470-510 and CN779-787	China
router.as.thethings.network	AS923	Southeast Asia
router.as1.thethings.network	AS920-923 “AS1”	Southeast Asia
router.as2.thethings.network	AS923-925 “AS2”	Southeast Asia
router.kr.thethings.network	KR920-923	Korea
router.jp.thethings.network	AS923-925	Japan
router.au.thethings.network	AU915-928	Australia
ttn.opennetworkinfrastructure.org	EU433 and EU863-870	Swizerland

https://www.thethingsnetwork.org/docs/gateways/packet-forwarder/semtech-udp.html

So ensure you set your router DNS entry to one that corresponds to the table above. Otherwise the things network appears to tell the gateway to TX on an out-of-band channel. and a misconfiguration on the end of the operator could mean transmitting on licensed spectrum. and potentially prosecution. Despite every other effort being made to be compliant.

I expect the only reason why the US router works is because the downlink channels match both AU_915 and US_915

Proxying GWP Packets

October 7, 2020thescobberLeave a comment

GWP is the first protocol widely used by LoraWAN. It started out as a proposal from Semtech to prove the concept. Essentially GWP is just JSON wrapped in UDP.

It has become apparent that there is a need for a GWP proxy, not only to provide access for multiple gateways. but also to provide debugging. Using this GWP proxy it was possible to discover a design flaw in interoperability between the RAK2287 software and The Things Network. In the protocol specification it makes use of a ‘temp’ variable in the ‘stat’ data structure. Which RAK Wireless implemented.

The Things Network silently discarded the entire packet and reset the last seen counter. The result from this was the gateways current GPS position was also discarded, and incoming packets from devices would not be stamped with the GPS co-ordinates.

The GWP proxy can be found on GitHub. https://github.com/Scobber/GWP-Proxy

Because this was a quick implementation, it lacks some features. It will provide bi-directional communications. and all output is visible on STDOUT.

The RAK2287 Gateway can be found:
https://store.rakwireless.com/products/rak-discover-kit-2

Packet Forwarder Protocol
https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT

Github Issue https://github.com/RAKWireless/rak_common_for_gateway/issues/19

Netvox and The Things Network

April 18, 2020thescobberLeave a comment

In order to connect a Netvox sensor to The Things Network. First, you have to connect the device somewhere, then you can send it a downlink message over the air. that will reconfigure its parameters. Fortunately, most gateways can be put into a local operation mode to facilitate over the air programming. The documentation that is distributed with the Netvox R311W wireless Water detector on this topic is very vague. To connect it into your LoraWAN infrastructure. Use the AppKey, AppEui from the box.

For the RAK7258 in built LoRa Network Server.
Create a new application and enter the AppKey and AppEui provided on the box. For the simplicity of configuration turn on Auto Add LoRa Device.
Startup the R311W and all going well the device should auto register to the gateway.

The next step is to create a device in The Things Network console. Once the device is created, edit its settings. Make sure it is set to OTAA. and overwrite the DevEui and AppKey with the parameters found on the devices box. The AppEui will not be able to be modified. and this is why we needed to connect it earlier to our gateway.

Back in the RAK7258 open up the application you created. In the downlink area, this is where we create the packet and queue it to transmit. In the specifications for these particular commands, they require high bandwidth. So you need to be fairly close relatively speaking.
To prepare the AppEui change.

Turn on confirmed
FPort 8
HEX Bytes 03 00 01 02 03 04 05 06 07 00 00 00 00 00 00 00 00 SEND
HEX Bytes 83 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SEND
This will change the AppEui to 0001020304050607. So substitute this for the AppEui from The Things Network.
To complete the command either wait for the next transmit window, or press a button on the side.
After the device connects and the downlink packets are delivered. Connecting to The Things Network can be completed by power cycling the device by removing the batteries. If there is no Things Network gateway available the device will not activate.

Once you have the device connected to The Things Network. It is possible to downlink messages there to configure other aspects of the device. This process is also device agnostic and should work for all Netvox devices.

Buy Netvox Wireless Water Detector