TTIG and SX1261 not connecting + LoRaWAN design considerations

[arjanvanb (Arjan)]

@AlainD

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.

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.

[AlainD]

@arjanvanb

@AlainD

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.

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.

[kersing (Jac Kersing)]

@AlainD

C
Now it does a OTAA join, but that’s not nice and as I understand it limited in nr of joins.

…

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.

[cslorabox]

@AlainD

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.

As already explained, that firmware is open source, so you are free to take it in whatever direction you like.

[bluejedi]

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.

[AlainD]

@kersing

With regards to distance, that hugely depends on the antennas of the node and gateway, I’ve joined nodes > 5km from the nearest gateway.

I found that I needed to be much closer to a gateway to do a OTAA join than to send data at sf10.

[AlainD]

@cslorabox

@AlainD

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.

As already explained, that firmware is open source, so you are free to take it in whatever direction you like.

I know, but I do want to keep focus on the application side.

[AlainD]

@bluejedi

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.

Yes, but that’s not realy needed if you’re not powering down completely every msg.

[bluejedi]

To ALL: Please stay on-topic.

If you feel need, you can create your own new topic.

[micronetwork]

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.

[bluejedi]

So maybe it’s time to update the topic title?

[micronetwork]

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

[cslorabox]

@AlainD

I found that I needed to be much closer to a gateway to do a OTAA join than to send data at sf10.

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.

[kersing (Jac Kersing)]

@AlainD

I found that I needed to be much closer to a gateway to do a OTAA join than to send data at sf10.

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.

[AlainD]

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.

[cslorabox]

@AlainD

One reason could be that the antenna is a combined 868 MHz and 915 MHz, this could give more noise when receiving.

Not really, no.

[syrfhm]

hello i want to ask, i bought the same ebyte module like you, E22900M30S the spi version, and im going to use it with esp32, but the supplier told be that there is no firmware flash into the lora module and i need to flash it first before i can use the module with esp32, how do you solve this problem? thank u in advance

[LoRaTracker]

There is no ‘firmware flash’ for or needed for a SX1262 LoRa device. It is an SPI device that will work as is with a microcontroller that supports SPI, which an ESP32 does.

Is this device for connection to TTN, if so which library are you using ?

[syrfhm]

Thank u so much for ur reply, for now im using it for point to point communication only, and im using your library GitHub - StuartsProjects/SX12XX-LoRa: Library for SX12XX LoRa devices, but after i run the code, it shows no device responding, i have checked the wiring and coding but it still shows no device responding

[LoRaTracker]

This is a forum for the discussion of TTN projects only.