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.
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.
So maybe it’s time to update the topic title?
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
1 Like
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.
2 Likes
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.
One reason could be that the antenna is a combined 868 MHz and 915 MHz, this could give more noise when receiving. If possible I’ll do a test with downlinks on a “difficult” location.