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

TTN Network and Services
1

So I recently created a TTN community account and registered a gateway (MikroTik wAP LoRa8) and an end device (Browan IAQ temperature/humidity/etc sensor). In both cases I had to select the frequency plan. Since I’m located in Europe I knew that I have to select 863-870 Mhz - thus, the two available variants confused me:

  • Europe 863-870 MHz (SF12 for RX2)
  • Europe 863-870 MHz (SF9 for RX2 - recommended)

Searching the web didn’t turn up much pro/cons with respect to certain devices/use cases. Thus, I selected the recommended one for both the gateway and the end device.

Does one plan has better compatibility with real-world devices and the OTAA join method than the other?

Registering the gateway seems to have worked fine, i.e. I see periodic updates in the live view.

However, the OTAA join process for the sensor failed, i.e. I see the following error in the live view after that no more activity:

Decode uplink data message failure:
Unknown FPort

So I suspect that the device isn’t compatible with the SF12-for-RX2 variant. Could that cause such errors?

Does the frequency plan has to be set to the same value for the gateway and all the devices that connect to gateway? Or is it fine if - say - the gateway is set to Europe 863 Mhz/SF9 for RX while a connected device is set to Europe 863 Mhz/SF12 for RX2?

2

This issue is completely unrelated to the RX2 Spreading Factor(SF). You are receiving uplinks. But your javascript packet decoder is throwing this error. It appears to be expecting the end-node to be sending on one particular port, but its not.

3

Ok. So what is the expectation here when the packet decoder throws an error - should the live data view still receive updates with the error repeated or should it stop updating?

I mean I just saw this sequence of events:

  • 09:33:57 Accept join-request
  • 09:33:59 Forward join-accept message
  • 09:34:03 Decode uplink data message failure Unknown FPort
  • 09:34:03 Forward uplink data message MAC Payload …
  • 09:34:03 Update end device “activated_at”
  • 09:34:10 Decode uplink data message failure Unknown FPort
  • 09:34:10 Forward uplink data message FPort 222 Data rate SF7BW125 SNR 10.25 RSSI -45
  • no more messages after that

FWIW, I added the device from the database, and the model number in the description matches what’s printed on the device.

4

hmm. I normally would not expect the end-node to simply stop transmitting. Most of these devices are meant to transmit until the battery runs out.

Do you know how often your device transmits by design? every minute, 10 minutes or hour? It could be that the next transmission is scheduled for some time later.

5

According to the reference installation at https://www.thethingsnetwork.org/device-repository/devices/browan/tbhv110/ it should transmit every 5 seconds.

In that data preview I also see a few ‘unkown FPort’ messages, but there are also enough messages where the payload is successfully decoded.

6

That would be illegal in pretty much any European jurisdiction - like court appearance illegal. And is also grossly in breach of the TTN Fair Use Policy.

As for dropped packets, how far apart is your gateway and your sensor? Too close and you will overload the receivers which will be unable to process the LoRa chirps successfully. Preferably 5m and a brick wall between them. Or a dummy load / 50Ω resistor on the device antenna.

For frequency plans, mostly people will use the recommended plan unless they know what the impact would be on reception & coverage for the RX2 window at SF12 instead of SF9.

7

ok, the reference installation is then special in some way? The event details there include "frequency": "868300000" - which is the base frequency of EU/Russia/India frequency plans. So it run in either of those jurisdictions, it seems.

Browan’s product page isn’t that helpful, i.e. I couldn’t find a real manual and the data sheet doesn’t say what the default measure/transmit interval is for their devices. And whether/how it can be changed. I’ve signed up at their ‘member’ page to get an additional pdf, but the sign-in process takes some days.

The TTN fair use policy says something about 30 s airtime per day. However, I don’t know how much time a single transmit really takes, usually.

Ok, then it was probably too close. Since I’m doing my first steps with LoRa the device was just located in 2 - 3 m distance to the gateway. I’ll retry it and put the sensor at greater distance with some brick wall/s in between.

Ok. Is my understanding correct that you can’t mix RX2/SF9 devices/gateways witih RX2/SF12 ones? IOW, that a RX2/SF9 configured device needs a RX2/SF9 configured gateway?

8

Not sure how this relates to the setup that Browan sends its devices out - but there is generally some similar band plans for those that share borders as radio waves don’t have passports. So nothing to read in to this fact really.

This will enlighten:

https://avbentem.github.io/airtime-calculator/ttn/eu868/15

No, no one said that. Try to slow down the conclusion leaping, there’s so much going on in LoRaWAN you’ll get tired very quickly.

No. The gateway is a dumb box that does what it’s told, it’s all driven by the Network Server based on the settings you’ve made. SF12 provides some benefit for contacting a far away devices if coverage is an issue.

I’d really suggest you get the kit working before looking at the esoteric options.

9

No it is not correct. I’ve been wondering about the two plans for gateways for some time now because the gateway should listen on all frequencies anyway and the back-end decides what frequency and spreading factor a transmission should use, not the gateway. So specifying a spreading factor for RX2 for a gateway does not make sense (to me). Perhaps @htdvisser can explain why we have to choose between the two?

So feel free to mix. However keep in mind you really should be using nodes with SF9 in RX2 to minimize gateway airtime. A gateway needs to service multiple nodes but has the same legal transmission restrictions a node has so should not have to spend time transmitting using SF12. (Transmissions on SF12 take 8 times as long as on SF9)

1 Like
10

No, doesn’t to me either. But for a device in a marginal coverage area, it gives you a chance to contact it in really need be.

11

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…

12

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.

13

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.

14

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.

15

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.

16

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
17

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!

18

FWIW, I moved the sensor to the previous location and I’m still receiving sensor measurements every 5 minutes.

19

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.

20

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.