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.
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.
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.
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 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.
As the tread starter I highly appreciate this discussion and find all topics relevant for my project. As long as there is no rule against it, please continue.
Long time due I have already tried but I’m not allowed to, I think.
BTW: I have newer been at a meeting with engineers where we didn’t end up in the same scenario.
I always ended up with more to think about than I had before the meeting.
For me I find this form of multitasking very refreshing
OTAA places no special requirements on signal quality distinct from any other sort of traffic.
It does however require downlink to work. Perhaps if your node is bad at receiving (has a very noisy power supply?) then receive in general is short range while transmit range might be normal.
Or perhaps some aspect of your code causes it to only attempt joins at fast spreading factors. Or causes the receive window timing to come out wrong at certain spreading factors.
Different people, different experiences. A general rule of thumb: there is no need to be close to a gateway for OTAA as long as you can receive downlink packets.
I have already tried but I’m not allowed to, I think.