Do you have recommendations for a better devolpment ecosystem?
If you really want to use Arduino, then pick exactly hardware that someone is actively supporting.
For example a Feather M0 and an sx1276 or RFM95 and MCCI LMiC - but beware even after tons of maintainer work, there are still issues, mostly with LMiC though the Arduino-ness is not making things any easier but rather harder in various ways.
Or the old TTN reference design with an ATmega for the sketch and the rn29x3 AT-command module encapsulating the LoRaWAN stack, not sure if there are still some issues but it generally works.
Or the similar idea from Arduino, not the MKWAN-1300 which has hardware design errors but the 2nd generation MKRWAN-1310 which allegedly fixes them. Note there are still software issues, but those are theoretically fixable as while the LoRaWAN firmware is not Arduino code it is open source and with an ST-LINK and sufficient effort user-replaceable
If itās looking like āthere are issuesā is common theme, that would be because pretty much everywhere you look, you will find some. Pick something not in common use (like the sx1262) and you end up with even more things to figure out, and fewer resources to help.
(And yes, if the actively maintained software support you found for a particular hardware platform was Arduino-based code, then you should initially stick with that or at least refer back to it from time to time while trying to get things to work)
1 Like
Having hardware that is supported is indeed very important, but for me not special for arduino.
Iāve seen very good support for the teensy ecosystem (not lorawan), which is based on arduino software.
Iām not as happy with the Arduino MKRWAN-1310 support. Thereās for example no library to store the needed join info in non volatile memory, which would be very handy for a maker/prototype board. Oh also no examples with sleep functionality.
Iāve also been not that happy about some āprofessionalā develop eco systems.
That is in part due to perspective.
The thing about an ecosystem is it tends to effectively say āif you want to use this technology, your program needs to look like this, target this processor, use these toolsā¦ā
In contrast a professional developer is often in a position of āif you want to sell your technology to us, it needs to fit into this software philosophy and methodology, be free of forbidden anti-patterns x, y, and z, be compatible with tool drivers that want to doā¦ā
Ecosystems make it easy to start projects, but they often make it very hard to finish them, or wrangle a project into the expectations of the organization commissioning it. What Iāve found is that when Iāve written production-destined code within a target-dictated ecosystem for the initial gain, months later Iāve regretted it (and that goes for mBed and even iOS storyboards as much as Arduinoā¦ and of course all of the old MCU vendor DOS and windows IDEs). Conversely, whenever Iāve invested the effort up front to set up the needed foundations to make an embedded project follow the same rules as expected of the organizationās other software projects, thatās paid off as the project moved along.
For many in the professional realm, an ecosystem lets you quickly see if something has promise - but if you decide to use it, you first sit down, understand the actual requirements of the technology, and then create a basis for achieving them compatible with your needs and ground rules of software practice.
Youāll find that true of many LoRaWAN starting points, in part because they are very hard problems that often get attention only after the basics are working. Join nonce (or frame count) storage is particularly thorny unless you assume battery backup, as you canāt just store the nonce with which you achieve success, but actually any youāve tried since the failure could be in receiving the accept. But as common NVM tetchnologies including EEPROM have limited cycle life, in theory an orphaned node that stores everything could burn itself out, so some intermediate strategy may be warranted. One board design Iām aware of goes to the extreme of adding a MRAM chip for thisā¦
Thereās an additional problem that the SAMD21 on the MKRWAN 1310 does not have an EEPROM, the best you can do there is emulation by walking through flash. It happens that the STM32L0 radio processor does have EEPROM, so incorporating solution into the LoRaWAN stack could make senseā¦ except that the strategy may need tuning by use.
One of the things often lacking in the LoRaWAN realm is good guidance on how to map the offerings of the network protocol to actual application needs - a lot of the discussion youāll see here is down in the weeds of mechanics of problems like running the receiving window at the correct time, as while those first-tier issues dominate thereās less attention spared for considering the actual ideal operating strategy.
2 Likes
Really enjoying this post, thank you so much for your opinions. My field is within hardware engineering and my project is about checking locations for Lora connectivity, using several chips from Semtech.
Initially LoraWAN appeared to be a convenient collecting point for my data 
I now wonder if it will be just as āeasyā to implement this test with the LoRaMac-node suggested by @kersing, My programming skills goes back to the Unix and assembler days (1980) so the NucleoLxxx boards might be just as āeasyā to start with?
What do you think?
Connectivity surveys tend to be almost purely uplink, and may not really need a network server responding. I have one I need to do this week where Iāll just be recording packets at the gateway (actually more an A/B comparison of two gateways than a survey, going for a walk with the node just creating the test conditions)
Anyway these tend to be fairly simple uplink programs that may not need to implement full LoRaWAN or even LoRaWAN at all.
You wouldnāt need some of the other things that have come up in this thread such as OTAA join retention. And you probably wouldnāt want ADR either, as the pacing of ADR assumes you sit in the same location for many hours or ideally days.
Unless of course your gateway is the TTIG, at which point youāre fairly locked in to using TTN to see your data. If this is a commercial project, do yourself a favor and buy an ordinary gateway card you can put in an embedded system (even initially a pi) and build and control the packet forwarder code.
If you have to stay with the TTIG and TTN then for a survey you probably want an uplink-only ABP type of test with a fixed SF, a short packet, and a courteous interval. Disable fcnt rollback. But also look at existing projects people have done, TTN mapper, etc.
I donāt love that code either, though may take a second look at it next time I need to start a project (current work veered from LMiC to an almost entirely custom stack tuned to specific needs)
Given your relatively simple needs I expect you could get it going fairly quickly, especially if you follow all of their toolchain recommendations. I think when I tried it a while back I spent a few hours getting it going as I wanted to do it in the context of our build system.
Ultimately the biggest difference between the node chips youāre likely to see is the reduced power consumption of the newer one.
1 Like
What would be your favourite go to card? within reasonable price range.
We mostly have RAK833ās though the RAK831 exposes some internal TX/RX signals on the connector which were useful to probe in comparison to node signals when receive window timing (had to tap the TX LED itself on the '833). The '831 also has its own 5v regulator.
The newer RAK2247 has an ill-chosen and entirely unnecessary SPI level shifter requiring slow clocking, but as those may be what are available going forward we now assume a slow clock everywhere. Still have to see if the factory heatsink is removable as we have been mounting the cards against a larger aluminum plate through a silicone pad.
In USB connected schemes the nFUSE implementation of the MCU-on-board idea seems to work though not always in internal mPCIe slots. Definitely avoid the old FT2232 based USB designs which are deprecated.
2 Likes
I would be surprised if more than 10% is in that position (lucky you). Quite often thereās only one choice and sometimes itās only a choice between systems.
If arduino offers a LORAWAN solution, I do expect most of those things to be solved. Itās not rocket science, but a lot of difficult work for a LORAWAN newby.
BTW. The Teensy LC uses EEPROM simulation in flash (256 words) and can be implemented for the SPI flash chip on de MKRWAN-1310.
BTW2. Not every frame count has to be stored. As far as I understand the protocol it possible to safe only the Xāth counter (for example every 1000) and add 1000 to the stored frame counters on a restart. If a restart is not happening every msg off course.
I would be surprised if more than 10% is in that position (lucky you). Quite often thereās only one choice and sometimes itās only a choice between systems.
You misunderstood the point. When you use technology at a lower level rather than expecting a turnkey āecosystemā you have the flexibility to achieve what your organization actually needs, because you arenāt bound by the unsuitable (for your purposes) decisions made by those who designed the fancy ecosystem.
I do expect most of those things to be solved.
Now who is insisting on something they may not realistically receive?
The things you expect to be solved are actually not solved (at least not soundly) by more than a small minority of current open-source LoRaWAN offerings of the sort that get used on TTN and discussed here.
If you think you know how to do it (the rest of your message seems to be such a claim and a proposal of a strategy that may be suitable in some cases and not in others) then go ahead and do it - with the added benefit that youāll end up with a solution that really meets your needs, instead of something designed around someone elseās needs and so a less ideal match for yours.
And if you think your solution is one that would be useful to others, then go ahead an publish that - all of the pieces involved are open source.
A very clear and not so āniceā message. I expect that companies that sell a LORAWAN device, even when using open source, to cover the most use cases. I do agree that not all āborder lineā cases need to be solved.
Unfortunally at the time I looked at it, it was not possible to readout the allowed frequencies. Those needed a āfirmwareā update on the murata chip.
Thanks for the useful info.
Indeed true for the uplink counter (see How much frame count deviation is allowed?), and it will also work for the downlink counter assuming thereās no replay attack between the restart and the first subsequent downlink. However, I guess you understand, some other changes in state might always need to be persisted between restarts, like updated network settings (including ADR) and pending confirmations.
Yes I do know, but like stated I stopped when I saw that for the arduino MKRWAN 1310 the āfirmwareā on the murata chip also needed additions.
For me it was not a save between msgās, but more a save and recall after a reset, new program version, battery change. Now it does a OTAA join, but thatās not nice and as I understand it limited in nr of joins. It could also be a problem with nodes that are farther from a gateway, my -limited- experience is that a OTAA join needs to be rather close to a gateway.
In the ideal world you have 64k joins, now the world is not ideal and random numbers will collide sooner with the set of used numbers. However, while not to be used for every transmission (also not ideal from airtime and battery usage) at least a couple of thousand joins are workable for a node. So no need to be overly concerned when it comes to battery changes and the like.
With regards to distance, that hugely depends on the antennas of the node and gateway, Iāve joined nodes > 5km from the nearest gateway.
As already explained, that firmware is open source, so you are free to take it in whatever direction you like.
As option for NVM, external I2C FRAM can be added to most existing LoRa development boards quite easily (e.g. just like a sensor). And while capacity is much more limited than flash, capacities up to 1 megabit are available. FRAM has practically limitless write cycles.
I found that I needed to be much closer to a gateway to do a OTAA join than to send data at sf10.
I know, but I do want to keep focus on the application side.
Yes, but thatās not realy needed if youāre not powering down completely every msg.
To ALL: Please stay on-topic.
If you feel need, you can create your own new topic.