I have added to TTN RS1XX Laird sensor
It send message. But no payload. See attached image.
Any hints?
I’m new with Lorawan. Thanks for patience
Luca
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.
1 Like
Dear Kersig
Thanks for Your support
Now it’s clear. We set the interval to 4000 second to avoid problem
1 Like
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.
Alex
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.
1 Like
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…
1 Like
Hi kersing,
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
Alex
CAs expected.
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)
1 Like
To UPDATE: something good coming as noted here:
Another UPDATE: here
Hello. I am having the same issue. Which interval should I change? Where from? I appreciate the support. Thanks.
Grab latest Sentrius Sensor app from the Google App Store & connect to the device over Bluetooth…push button on front panel…then follow your nose wrt settings in the app menus & info pages, esp look at doing device f/w update as old stocks may not be programmes with all the latest options & features. Suggest use Cayenne LPP payload profile (as Laird protocol expects to see a time stamp as part of Join exercise before it will send data…may require a Node Red set up…search forum!), unconfirmed data, select type of battery you have installed, sample update rate (in seconds). - use anything less than 5-10 mins (600) with caution due to duty cycles & fair use policies of the network your using (search!) as well a life of battery. I tend to go for 15 or 30 min updates (longer if none critical application), actual batt life & compliance may vary, not least with the SF you manage to join with.
1 Like
Thanks