Indeed I haven’t mentioned Spreading Factors. I have been using 7 since according to the guides you shouldn’t program something to use SF12 as standard. I also believe the LoPy I’m using doesn’t support it. (And I’ve not been having luck re-programming my LoRa32u4 with constant arduino bootloader issues).
For now I’m going to continue mapping at SF7 which is also in line with TTN Map’s and then increase to SF12 once I finally get the Arduino sorted out to transmit on that and submit it as an experiment to TTN Mapper. Realistically my plan is to map it out at SF7 which covers most of the actual housing area and then experiment with higher SF Rates.
I think I’ve seen claims of 10KM on SF7 but I can’t remember.
As for it being LoRaWan Compliant most sources I find say that devices set to use hardcoded rates of SF11 & 12 or constantly transmit on them should be blocked. As of this LoPy doesn’t allow the SF to be set when in LoRaWan mode. Weather it changes dynamically or not I’m not sure. This could be because I’m using ABPP rather than OTA.
Where is it saying this? its not simply about the SF (look at the gateway console for the dramatic airtime difference between SF7 and SF12) but equally about frequency of usage over a period - lorawan specs are clear
Your making its sound like SF12 is not allowed to be used which is simply untrue, you could use ADR once your finished testing but seeing as your just testing at the moment there is nothing wrong with working across the SF levels to see what range you get.
I’ve found the cheap LoRa32u4 have better performance than other nodes.
13 km but that’s because LOS and my antenne (5 dbi) is @ 18 mtr and the receiving gateway @ 35 mtr
but with no LOS with a lot of buildings in between I have a confirmed 2.8 km @sf7
My SF7 testing this morning was terrible, I think this was because I changed to using OTAA instead of ABP and I don’t find it as reliable so I need to do this again.
I did some testing at SF10 and got peaks of ~ 5KM from the gateway with an average of 4KM. I’ll be doing some more mapping over the next few days.
Once joined, an OTAA device should behave like an ABP device. (The device should only join once and then keep using the very same DevAddr and secret keys just like an ABP device would, until it somehow loses them.)
Interesting. I’ll have to try that out as I do seem to get better range for whatever reason in ABP Mode. No idea why.
For reference so far I’ve plotted this map. The inner green circle so far has been a clear good signal zone, Orange and yellow are patchy. Red is the peak I’ve got at SF10.
Blue is the theoretical 10KM. Just rather interesting. I hope that by documenting it here & on my blog it’ll help some others out with realistic range expections.
OTA requires the node receives a downlink join accept sent by the gateway, if your node does not receive this then you wont get results - in terms of wardriving tests OTA tests your two way connection in effect, ADR will simply tests your node transmits only
Only when ‘starting’ the node. Once it has its keys it can use them as long as you don’t loose them (power down/reset).
You should never OTAA for each data transmission because you will a) use airtime of the gateway unnecessarily and b) you will run out of nonces resulting in OTAA failures. (B does not apply to LoRaWAN 1.2 compatible nodes on a LoRaWAN 1.2 network)
As for range of ABP vs OTAA I’ve not done any testing but ABP is slightly more reliable in my case.
I’ve been trying at different spreading factors and am getting a more acceptable range. I’m hoping I’ll be able to extend the pole which I have my antenna on for extra height and will be moving the gateway outside so the cable even though the antenna will be higher won’t be any longer as currently it goes indoors.
I just wanted to check, is RG8 Mini suitable cable? This is what I used as I believed I was buying RG8 which has a slightly different datasheet to RG8 Mini that actually arrived but I didn’t notice it until I put the antenna up as is.
If you check the specifications you’ll notice the attenuation is almost 37dB/100m for the frequencies involved. Compare that to for instance ant400 which has an attenuation of 4.04dB/100m at 900MHz.
In the first case you are loosing 0.37dB for every meter of cable. Does not sound a lot, but it equates to about 8% signal loss. I would look for something else…
@arjanvanb, All I can think is that because if I’m re-starting transmission from a distance further away which is out of signal it could be that when comparing it I get a better signal transmitting from further away this applies. But when starting close to away it’s the same.
@kersing, I’ll have a look around and see if I can return the RG8 Mini. As I said I was sold it as RG8 which a datasheet says 15dB/100M at 900Mhz. So while not as good as the ant400 but better than the mini… I’ll have to see what I can get at a reasonable price.
In my mapping tests I have encountered a strange glitch though. If I programmed my mapping node to do a new OTAA every time before sending a message (I know, I should be spanked for this, but it was for testing purposes ) and went from an area of no coverage to one with coverage, I found that my node was able to reach new gateways earlier than when it was activated only once. If I activated my node at home and moved to the gateway at work, crossing an area with no coverage, the gateway would only pick up (or forward?) the messages when I was already further into the area of coverage.
I didn’t have time (or willingness) to do more tests to rule out other factors though.
but that’s because LOS and my antenne (5 dbi) is @ 18 mtr and the receiving gateway @ 35 mtr
) and went from an area of no coverage to one with coverage, I found that my node was able to reach new gateways earlier than when it was activated only once. If I activated my node at home and moved to the gateway at work, crossing an area with no coverage, the gateway would only pick up (or forward?) the messages when I was already further into the area of coverage.
.