Europe 863 MHz frequency plan SF12 vs. SF9 for RX vs. OTAA devices

TTN Network and Services
21

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?

22

So I did 2 more experiments:

  1. 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)
  2. 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.

23

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.

24

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!

25

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.

26

Ok, just to clarify, 2 m away from the gateway is too close, but 5 m behind a brick wall should be fine, right?

27

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.

28

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
29

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
30

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.