I feel that is part of the answer given the need to service potentially many nodes - if responsing on SF12 there is a greater chance of exhausting GW’s ability to Tx on what is a community network, also related to that responding at SF12 takes ~8 times longer than SF9 (assuming ~2x air time for each SF step) so one users downlink/RX2 ack has potentially MUCH greater impact on GW’s ability to hear other community nodes (simplex TX/Rx) hence geometrically much higher impact on GW’s ability to service a local community. Private networks may take a difference view/value judgement…
The node settings, not the gateway settings (SF9 or SF12 for RX2) determine what RX2 spreading factor the back end instructs the gateway to use for the RX2 downlink.
My guess is that gateways are getting an RX2 setting simply because the RX2 setting that is an actual choice for end devices is being treated as part of the “frequency plan” settings, and gateways are selecting from the same set of such “plans” as offered for end devices, rather than from “pure” frequency plans that give only channel coverage along with LoRa standard channel and FSK data rates.
But as others have pointed out, the RX2 setting is irrelevant as a gateway parameter, since gateways merely do whatever the server commands to match the setting of the end device being responded to.
This was in response to your statement that sending a message every 5 seconds being illegal in the EU. So I was wondering: if that is illegal in the EU how can it be that the device in the reference installation is sending every 5 seconds (according to the data preview there). So perhaps the reference installation is running outside the EU, where that would be fine. Thus, I was looking into the event details and noticed the frequency information which reduces the number of possible jurisdictions the reference installation is running in.
This is very useful. And it shows that no frequency plan allows a device sending a message every 5 seconds. Especially under the fair use rules. So I’m really wondering why the data preview in the reference installation (i.e. https://www.thethingsnetwork.org/device-repository/devices/browan/tbhv110/) is displaying events every 5 seconds. How is that possible?
Well, I wasn’t implying that somebody said that. And I wouldn’t call it conclusion leaping. I just wanted to verify my understanding that was based on the (little) information I could gather at that point.
So I reconnected the Browan IAQ device at a greater distance (i.e. > 5 m, brick wall in between) and the join happened in a similar way as before. After that I don’t see any recent activity anymore on the ttn application page (i.e. no uplink message received in > 1h).
For comparison, I added another application and added another device, i.e. a Dragino LHT65 (temperature/humidity/misc sensor device). This device is definitely better documented. For example, a real manual is available and it clearly states that the device transmits every 20 minutes, by default.
And this is also what I’m seeing in the live data view now. And no decoding errors. So joining that Dragino device did work without any issus and I’m seeing its periodically transmitted sensor payload, just fine.
Manufacturers creating broken examples is sadly not unheard of. LoRaWAN and the air allocations on which it depends are more restrictive than many imagine, no small number of people have through lack of checking assumed they can do things which formally or legally speaking, they must not.
So I reconnected the Browan IAQ device at a greater distance (i.e. > 5 m, brick wall in between) and the join happened in a similar way as before. After that I don’t see any recent activity anymore on the ttn application page (i.e. no uplink message received in > 1h).
You should look in the gateway traffic page rather than the application page, to see if there is any activity at all.
Better yet, you should look for debug output (serial, etc) from the node itself.
The benefit of a “canned” node firmware is that it’s supposed to work.
The detriment of a “canned” node firmware is that when it doesn’t work, it may not be clear where to start debug.
You shouldn’t have to. For gateways, both plans are equivalent. The difference in the RX2 data rate is only relevant for end devices.
I just filed Indicate whether plan is applicable to gateways / end devices · Issue #41 · TheThingsNetwork/lorawan-frequency-plans · GitHub to add an indicator in the frequency plans that tells the Console if a frequency plan applies to only end devices, only gateways or both.
3 Likes
Ok, I did another test with the Browan IAQ sensor: I changed the frequency plan to SF12 for RX2 (in the end device settings) and placed it behind another brick wall (similar distance) - and now the transmission works!
(i.e. a new OTAA join was triggered by re-inserting the battery after it was removed for 16 h or so)
So the device is now sending sensor data every 5 minutes. Example payload:
"frm_payload": "AAs2OPQBAAAZADU=",
"decoded_payload": {
"battery": 3.6,
"eco2": 500,
"humidity": 56,
"iaq": 25,
"iaqChanged": 0,
"status": 0,
"tempHumidChanged": 0,
"temperature": 21,
"temperatureBoard": 22,
"voc": 0
},
This time right after the join, again, 2 Unknown FPort message appeared, as before. And the first sensor measurement was transmitted exactly 5 minutes after the last Unknown FPort one.
A curious detail perhaps is that the first sensor measurement included a low battery value, i.e. 2.5 V.
Since I basically changed two things (sensor location and frequency plan variant) I need to do another test in order to really determine which of these two things made the difference!
FWIW, I moved the sensor to the previous location and I’m still receiving sensor measurements every 5 minutes.
Chances are these are network level housekeeping messages transmitted on FPort 0.
Your decoder shouldn’t be trying to process those, since application traffic begins only from FPort 1.
If the device needs SF12 whilst it’s within only a few tens of meters of the gateway, then one or both antennas would need looking at.
Whilst doing the analysis, bear in mind almost all of the other users get by with the recommended channel plan - so if you have to use SF12 then there is something up with some part of the kit.
Ok, since the gateway works fine with the Dagino LHT65 under the RX2/SF9 plan this should be a sign that the gateway’s antenna is fine.
I don’t know how popular these Browan IAQ devices are.
Besides hardware defects of the device, could the device be shipped with a buggy firmware that simply isn’t prepared to deal with the RX2/SF12 variant?
So I did 2 more experiments:
- frequency plan set to RX2/SF12, placed at old location (few meters + brick wall) and triggered an OTAA join → result: no measurements are received after the initial data messages; blue led blinks 7 times (short), followed by 2 double blinks (i.e. after inserting the battery)
- frequency plan set to RX2/SF9, placed at second location (also few meters + a brick wall) and triggered another OTAA join → result: measurements are received every 5 minutes; blue led
blinks 7 times (short) followed by 3 double blinks (i.e. after inserting the battery)
That means that the frequency plan variant doesn’t make a difference, but the initial location of the OTAA join is crucial. After the join is completed, the location doesn’t matter anymore.
PS: FWIW, Browan hasn’t processed my account request for days. Thus, I can’t access the TBHV110 reference manual on their site. However, I found a copy at https://docs.microshare.io/assets/pdf/TBHV110.pdf It contains some details, but isn’t comprehensive. Especially, it doesn’t describe the LED blink codes, at all.
PPS: After removing the battery the last time I shorted the +/- contacts using a small resistor in order to empty any built-in capacitor. Before inserting the battery again I measured the voltage as 2.65 V (instead of the previous 3.6 V). The drop was sufficient for the OTAA join to be initiated. Previously, I just let the device sit for a few hours without the battery inserted. Again, the reference manual doesn’t mention anything about how the device is supposed to be reset, how the OTAA join can be initiated, etc.
No, that’s coincidence.
Being too close to a gateway can be problematic in any case, but won’t always be so in every trial.
It’s possible that it’s a coincidence since the number of observations is low:
- 2 to 3 meters from gateway without a brick wall: 2 out of 2 times no sensor readings after each join attempt → always failed so far
- old location, i.e. 5m or so behind a brick wall: 2 out of 2 times no sensor readings after each join attempt → always failed so far
- new location, i.e. 5m or so behind another brick wall: 2 out of 2 times sensor readings are transmitted at a 5 minute interval after each join attempt → always succeeded so far
After a successful join I receive sensor readings everywhere at a 5 minute interval. Even when I place the device 2 m away from the gateway without a brick wall in between!
All I can tell you - If you have the node and the gateway that close, the RF is shouting at each other, sooner or later you are going to damaged one of the receivers.
You can’t go to the club and stand next to the bands speakers, sooner or late you are going to lose your hearing.
Ok, just to clarify, 2 m away from the gateway is too close, but 5 m behind a brick wall should be fine, right?
Yes 5m and brick wall, just check the RSSI as well, you need rssi as low as you can get.
Remember you are going to deploy your nodes typically a few 100m or km away so you can expect a significant drop in rssi and snr, which is where you want to test.
This shows that the receiver of the node is overloaded. The receiver of the gateway seems to be more tolerant against strong signals.
1 Like
A summary of this thread:
- For the gateway, both Europe 863 MHz frequency plan variants SF12 for RX2 and SF9 for RX2 are equivalent. A future version of the UI might replace both options with a single entry to avoid confusion, when configuring a gateway.
- it’s very unlikely that OTAA devices can’t deal with the recommended SF9 for RX2 frequency plan variant
- likely causes for an OTAA device not completing a join/proper transmission is a) device is too far away from a gateway (obvious, i.e. signal quality insufficient) or b) device is too close to a gateway (less obvious, i.e. receiver overload)
- if a device is too close to its gateway the receiver overload doesn’t have to be symmetric, leading to asymmetric failures (e.g. join fails, but later sensor transmissions succeed)
- for evaluating the quality of transmissions it makes sense to look at SNR and RSSI values, cf. LoRa — LoRa documentation
- Browan goes to some length to hide its reference manuals from their customers, but direct links for the TBHV110 reference manual are available
- Resetting the Browan TBHV110 IAQ to trigger a fresh OTAA join is quite involved since it buffers electric energy, i.e. there is no reset button and thus the battery has to be removed for 6h or so for the internal buffer to be discharged enough
- the example data in the TTN device repository doesn’t necessarily contain realistic timestamps, cf. online airtime calculator
Thanks to everyone who participated in this thread. My questions were answered and I learned a lot.
3 Likes
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.