Processing of downlink packets

[novag]

I think I mentioned it often enough but this evolved from the LoRa-ATtiny-Node project and thus has a few unusual design choices.

One of them is the blocking nature of the SendPacket method. SlimLoRa blocks until the reception of a packet in one of the windows or until RX2 timed out. This is because SlimLoRa has no interrupt support for the radio chip. The ATtiny85 had only 5 usable data ports with none left to be used as an interrupt receiver. Thus SlimLoRa times the start of the RX windows and polls the radio chip to know if a packet was received or if the window timed out.

I am not sure if it's wise to stick with this behavior but it's one of the simplifications made to be able to run it on an underpowered uc without interrupts. This wasn't that much of a problem with V2. However now with V3 and the 5 second RX1 window it might matter. Other than that it's possible to change the RX1 delay with V3:

• Dynamic temporary change (uses a MAC command in the current session): ttn-lw-cli d set --mac-state.desired-parameters.rx1-delay RX_DELAY_2
• Permanent change (valid from the next Join): ttn-lw-cli d set --mac-settings.desired-rx1-delay RX_DELAY_2

[clavisound]

I will evaluate the energy cost with downlinks (MCCI LMIC) vs TinyLoRa without downlinks.

I will test with a 100mah battery and a feather 32u4 (8Mhz)

I think it’s better to add the option for INT either way.

[novag]

SlimLoRa puts the radio chip to sleep until a few milliseconds before the start of the corresponding RX window. So during the waiting time only the uc itself is active. We could probably improve this by letting the uc itself sleep in between, but this depends on which uc is used and is not trivial.

I am not so sure yet about implementing interrupts and a small callback system. If it's kept simple it may be worth it but I don't really want to create a LMIC competitor. There's no reason and the whole structure of SlimLoRa is not made to be a LMIC competitor. It's more like a drop-in replacement for TinyLoRa to get you started very quickly with a small interface.

[clavisound]

If understood correctly: MCU will be active and only radio is sleeping during the ~5 seconds before RX1. Is it possible to sleep the MCU and wake before the RX1 window? It's 4-5 seconds of uptime 😄 every time.

1200 (uplinks) * 5 (seconds waiting MCU)
6000 (secs)
6000 / 60 = 100 (minutes of wasted uptime)

I mentioned LMIC not for competition, but because I didn't tried another library for downlinks (even with LMIC still trying). I agree keep it simple please 👍🏼 .