tech comparisons - general discussion - any comments?

[bmarkus]

Don't take it serious. Lora part is messy and it says LoRa Linklabs, not LoRaWAN as specified by Lora Alliance. In LoRaWAN encryption is 128 bit AES and not 32 bit, for number of nodes, bettery liftime, distance simply you can not provide a single number even for a Linklabs device. Also, in LoRaWAN other vendors offer GW with sector antennas.

My advice is to look for better comparison and do not use it.

[livius]

@bmarkus said in tech comparisons - general discussion - any comments?:

My advice is to look for better comparison and do not use it.

Yes, and i need better comarision
Can you point to one - i look previous for better in my assumption revision about lora itself:
https://www.thethingsnetwork.org/forum/t/universal-lora-wan-gateway-limitations-because-physics/1749

But as always - i really need better overview from real users/developer - they use it and see lost messages or not, can connect 500 nodes or not and more...

Will be good to see what you got already e.g. distance, nodes connected - i am really interested
Because my knowledge about this quite new tech is really limited :(

[bmarkus]

Just as a random example it is a real statistics for a Kerlink IoT station GW on a hilltop. It contains only GPS packets not ordinary sensor volume which is much higher:

As you see there are packets from rather high distance but most of them are in cca. 10 km range.

[jmarcelino]

@livius
In my experience those "spec comparison tables" are almost always wrong - in everything! - and WavIOT wins the prize for going well into the BS territory.

What I can say from my admittedly small scale deployment of about 100 nodes, inc ~ 50 on one gateway is that LoRaWAN has two major critical points: the environment and the network usage pattern of applications running on top of it.

This is compounded by limitations in implementations (the firmware running on nodes implementing the protocol) and the current protocol itself.

In fact with just 100 nodes we're already struggling, including having had to patch the network server to reduce some security aspects (disabling Nonce collision checks on OTAA joins) and accepting that we can't use public networks due to the way our application works.

On the environment side, with access to antenna locations at around 8m above sea level we've managed about 5Km range (near line of sight) using both RisingHF and IMST ic880A gateway boards. I'm told Kerlink does manage to pull some extra range, but at a cost of €1400 or so per gateway ( vs ~ €200 for RisingHF ) it's just not an option.

Without line of sight, in an urban like environment we usually get 1-2Km (mostly thanks to signal making it's way out via building windows). The upper range is only available if we go up to SF12, but once you get a few nodes using SF12 you'll start having problems - gateway airtime restrictions, free radio channels for transmissions - which is why going SF12 all the time is not allowed on public networks, the number of nodes served by the gateway drops considerably.

Finally it's somewhat hilarious but we've found that all certified LoRaWAN we tested have serious limitations be it design factors (temperature, current, protocol bugs) or application ones . Microchip, Laird, yes LoPy :-) you name it. For any serious deployment I think we need to change part of the LoRaWAN stack code, which means losing the certification.

This said all of this is evolving almost daily and many issues are being addressed.

[bmarkus]

@jmarcelino

I'm working a lot with RN2483. There is an issue how 1% transmit duty cycle is interpreted on a channel base or on the set of 8 channels. In my view it for a physical channel which means if you are choosing channels randomly it means 8%. You can disable the TX restriction and let your application to meet legal requirements. The other point is to use ADR in your end devices to have the optimal RF settings which allows devices to go to higher bitrate when it is possible, do not use fix datarate settings for fix installations. Mobile device is a different case.

Also, be careful using ACK's. You can significantly reduce payload length also with proper coding. I see Libelium devices in our network sending plain ASCII measurement data, field names, etc. where real content is only 10% in size with proper coding. Also I see data sent at high rate where it is not necessary and so on. All together you can do a lot to improve your network performance.

BTW, a new Kerlink IoT station is on the way to the market for cca. 200 EUR which is the same price (or less) of an RPi + IMST GW card + housing + power supply + cables + SD card.

[jmarcelino]

@bmarkus
You're probably aware that there are some deeper problems with the RN2483 - at least the current revision - in fact most distributors no longer stock it and those who still do like Mouser have marked it as "End of Life"

http://www.mouser.co.uk/ProductDetail/Microchip-Technology/RN2483-I-RM101/

I've started using ADR now (it was still broken in the network server for our first deployment) but it doesn't change the fact that some nodes can only reach the gateway with SF12. Also ADR needs more downlinks (at SF12), which is kind of what we try to avoid in the first place.

It's early days I think and hopefully the NB-IoT train quickly approaching will push LoRaWAN manufacturers to get better and more creative more quickly.

[bmarkus]

@jmarcelino said in tech comparisons - general discussion - any comments?:

@bmarkus
You're probably aware that there are some deeper problems with the RN2483 - at least the current revision - in fact most distributors no longer stock it and those who still do like Mouser have marked it as "End of Life"

Can you tell exactly which issue(s) are and which fw version referring to?

[jmarcelino]

@bmarkus
It's the /101 (latest revision) as I linked to Mouser below.

I don't know the whole story and seems there's more to this iceberg under NDA but incorrect datasheet specs (operating temperature, current and sleep mode specs) comes to mind...

Marking this revision as end of life without a replacement in place also signals something's wrong - at the least a firmware update will be needed and soon-ish.

[livius]

@bmarkus said in tech comparisons - general discussion - any comments?:

here is an issue how 1% transmit duty cycle is interpreted on a channel base or on the set of 8 channels. In my view it for a physical channel which means if you are choosing channels randomly it means 8%

This is really interesting point :)

Thank you both @jmarcelino and @bmarkus for short overview - as you can see we have many themes to discuss.
I know that this topic can going to offtopic but for me really interesting one :)

[bmarkus]

@jmarcelino

Microchip is replacing the current RN2483 with a new version, RN2483A-I/RM103 which will come with fw v1.03 It means that RN2483 still alive.

Also please note, that the new Microchip 8-bit development environment has a LoRaWAN stack which means, that you can develop your own application, link the LoRaWAN stack and download to an RN2483/2903 internal PIC controller. Without an additional MCU you can have a low sized, low power consumption LoRaWAN solution.

But it is offtopic here as it is not related to LoPy. OpenLORA Forum would be a better place for such discussion.

Sorry for spamming.

[jmarcelino]

@bmarkus said in tech comparisons - general discussion - any comments?:

Microchip is replacing the current RN2483 with a new version, RN2483A-I/RM103 which will come with fw v1.03 It means that RN2483 still alive.

Thanks for letting me know, I had not doubt the RN2483 was still alive and issues were being addressed... Actually just one year ago I was going through a similar ordeal of updating my (some already soldered) modules from 0.9.5 to 1.0.1 to get OTAA join working... Let's just say it should be a lot easier than it is.

Also please note, that the new Microchip 8-bit development environment has a LoRaWAN stack which means, that you can develop your own application, link the LoRaWAN stack and download to an RN2483/2903 internal PIC controller

Indeed but then you lose the LoRaWAN certification. Much like if you change the LoRaWAN stack on the LoPy (though on the LoPy you can customise a lot more). Of course one question would be is the LoRaWAN certification really worth anything...

[bmarkus]

@jmarcelino

Certification is an interesting point. First of all it is available only for 868MHz end devices, but nor for gateways, network servers, etc. Also even if you have a certified product you can reconfigure without hacking to be out of compliance. In the Microchip stack you can do nearly the same config changes as in RN2483 but you can not fully blow it up.