I have added to TTN RS1XX Laird sensor
It send message. But no payload. See attached image.
I’m new with Lorawan. Thanks for patience
I have added to TTN RS1XX Laird sensor
that’s not enough information
Please indicate me which info I must give.
Selected OTAA activation method
Thanks for help
Yes I have studied all manuals and applied configuration to sensor by BLE connection.
The gateways are intalled around in the town.
I see from that at least 3 different gateways see my device in the same time.
The documentation states you need to deploy a ‘server’ that sends a downlink to the device when the first (empty) uplink packet is received. (Downlink should contain time stamp in a certain format)
The node-red example provided in the documentation will provide the required functionality.
However the firmware for these devices uses confirmed uplink for every transmission, if you do not set the interval to very infrequent uplinks you will be breaching the TTN fair access policy which allows for maximum of 10 confirmed uplinks per day. (Equals ten transmissions a day)
The confirmed uplinks are an issue anyway (even when ignoring the TTN fair access policy) because of scalability issues, it drastically reduces the number of nodes a gateway can support.
Cannot read payload Laird LoRa Gateway
Thanks for Your support
Now it’s clear. We set the interval to 4000 second to avoid problem
I asked Laird why they done this choice, here the official response:
The LoRaWAN specification does not have a fair use policy but instead is constrained by the ETSI 868MHz duty cycle regulations which apply to all licence free radios used on that band across Europe.
However, some networks such as The Things Network (TTN) do impose a fair use policy (FUP). With the Things Network there is a fair use policy on their free to use community account. TTN will happily sign you up to a paid for account if you need more messages.
You could also implement the whole network yourself and run your own network server to get around TTNs FUP /paid for accounts but of course you still have to comply with the ETSI regulations, or rather the device/gateway has to comply with those regulations.
From Lairds point of view the RS1xx is a hardware product and we use TTN purely to demonstrate its usage.
ZI got the same reply. Given that their documentation is based on how to get it working with TTN I would have appreciated a bit more consideration for the community network.
Something else to consider, space in the frequency band is limited so everyone implementing private networks will only lead to congestion.
I agree Jac
The fact they expect ack for each payload Tx is wasteful of precious spectrum irrespective of any fair use policy any given back-end (e.g. TTN) seeks to impose - seems to have been spec’d/dev’d for a private use case (via a US based team?) and where some sort of audit or verification needed (I suspect). I expressed a view that (IMHO) a device like this should never have got out into the wild, without option to eliminate/reduce need for acks, and didn’t get much push back from contacts. What were the engineers/product guys thinking?!
Hopefully something is coming that may make these devices more user, network and socially (from spectrum use POV) friendly. see my comments on another thread here
There are also hints of some variant with expansion of (external) sensor capabilities…if/when they get it ‘right’ it looks promising…
I forwarded your considerations to Laird support and this is the reply:
The documentation we provide is purely for demonstration purposes, so that customers can try/test out the hardware easily, we do not sell the RSxxx specifically as a solution for use with TTN. We are working on updating the RSxxx code to be demonstrated out of the box with other networks/data visualization portals and we will be including the option to enable/disable confirmed packets as part of that release. We are hoping to release this later this summer.
The ETSI 868MHz duty cycle will ultimately limit usage by any device on the band but LoRaWAN is best used for event driven or low reporting frequency applications, this way you have duty cycle available when you need it most. As a hardware manufacturer we enforce the duty cycle restrictions in our hardware
Months ago I suggested the option to switch of acks as a few commercial providers I checked do not allow anywhere near the downlinks required with the current firmware. These devices with the current firmware are only usable for private LoRaWAN deployments, a shame as this limitation means I had to pass on a project where a couple of hundred could have been deployed. (Huge area so would require the use of an existing network, deploying a private network is not viable)
To UPDATE: something good coming as noted here:
Another UPDATE: here