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.
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.
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.
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?
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.
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.
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)
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.
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:
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!
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?
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.