SlimLoRa library for arduino - EU863 basic functionality - testers wanted

End Devices (Nodes)
1

Hello there, after two years of absence the last month I think I resurrected the SlimLoRa library.

ADR works and other MAC commands like RX1 delay.

You have a featrher32u4? I would like verification of what works or better try some stuff I didn’t tested.

The device always connects to my TTN gateway (nfuse-sx1308 via usb1 on a server) with RX1 delay of 5 secs SF7 and 0 power of dBm. It is a nice surprise to me, that if I try to join with SF9 in different room TTN server immediately requests SF7* and the SlimLoRa adapts.

* I was expecting after many uplinks for the server to request lower SF.

Details of what I tested and what help I need you can see on the github.

Ironically I have not tested ABP. I think it’s very easy to add support for other boards and regions. Currently only EU863 is supported, although I copied from TinyLoRa the frequencies for other regions, some work needs to be done to be usable in other regions and I don’t have access to other region.

Also I only tested KEEP_SESSION. I don’t find a meaning to test to not keep MAC session.

The examples also use Deep Sleep so you can easily build your low power node if you remove the Voltage Regulator of Feather.

Full credits must go to novag since I did little things (but it took me time):

  1. Modified the code to arduino environment.
  2. Added SetPower function (I need to change to LoRaWAN style. novag already did the work.
  3. Added battery report (but not tested)
  4. And testing of ADR, ACK_LIMIT and joins.
  5. I also did many silly stuff to be deleted :stuck_out_tongue:

SlimLoRa currently uses 12240 bytes (42% of ‘disk space’) and 218 bytes of RAM with battery reporting and Deep Sleep sketch.

With DEBUG Serial.prints 17912 bytes (62% of space) and 357 bytes of RAM.

Also thanks to the TTN guys for the valuable knowledge.

I think I created the device like that.

ttn-lw-cli d create APPID DEVID --dev-eui EUI --frequency-plan-id EU_863_870_TTN --lorawan-version 1.0.3 --lorawan-phy-version 1.0.3-a --root-keys.app-key.key APPKEY --join-eui JOINEUI --mac-settings.rx1-delay RX_DELAY_5 --mac-settings.status-count-periodicity 0 --mac-settings.status-time-periodicity 0s --join-server-address eu1.cloud.thethings.network

I just realized that I need to re-do everything for a complete test. Phew!

1 Like
2

Added a helper function to report Transmission duration. The application after every transmission have to issue the GetTXms() function to get the duration of transmission.

Small fix. Now it joins on 3 frequencies instead of 2.

Just re-tested today. It joins from the first join message on 1st window in different room at SF7 at 0 dBm power.

3

Latest SlimLoRa release now can revive 32Kb AVR’s. It needs 14Kbytes of flash. Tested only with Adafruit Feather 32u4 on EU868. Other regions still unsupported.

Finally downlinks for application are supported*, MAC ChMask and NbTrans.

Major TODO is dynamic creation of channels to obey CFlist. I hope to write some documentation and examples.

* Assuming you load SlimLoRa with SlimLoRa lora = SlimLoRa(8); You can check if you have downlink if lora.downlinkSize is greater than zero. Downlink data are accessible via array lora.downlinkData and port via lora.downPort.

4

Some user experience comments …

Called EU863 - yes, I know it starts at 863 but I see 868 far more often.

Not sure it’s a good vibe to post a link to a repro that’s preset to, cough, the ‘other’ network.

Is Nbtrans that important? The CFlist, hmmm, for a cut down stack against a know channel plan, why process it as long as we know it matches? Or even stop any such downlinks as being redundant.

Perhaps ask the TTN community what would be useful / essential and make it compliant to be a good radio citizen - I for one can work around DevStatus & DeviceTimeReq - the RXParam, RXTiming, NewChannel, etc seem to me to be a function of the network that’s being used and so are known. I’ve not yet figured out how to stop the LNS being anally-retentive about sending settings - I can only dream of a Shut-The-F-Up checkbox. Or perhaps more detail on the console about what else is being said with the Rx1 5s message - or some feedback on why it thinks it hasn’t been acknowledge or the reason for sending it again (and again and again).

I’ve a variety of devices available and have some competency with getting LMIC working on a 328 even now, so happy to help. That said, Digikey will sell you a Wio-E5 (STM32WLE5JC) for less than a combo of an older AVR + power hungry SX1276 and you can run RadioLib on STMduino (aka Arduino) on it. And RadioLib has passed compliance tests for all bar the FSK modes so is pretty compliant.

5

Thank you for you comments. I always remember 868, don’t know why.

I use both networks but I admire the knowledgeable TTN people.

NbTrans, not important for me. I didn’t managed to think a use-case for that. I implemented it because it was simple and part of ADR command. I don’t wanted the LNS to send constant ADR commands if the device ignores the NbTrans variable.

Olivier Seller proposes NbTrans 4 for static devices at latest TTN conference in Amsterdam, although I don’t see a benefit. If you loose data you have the latest data. I don’t see a problem. LoRaWAN is not blockchain :stuck_out_tongue:

Well, that’s the reason I try to develop SlimLoRa. With TinyLoRa I had constant downlinks so I abandoned it.

DevStatus it’s ok for battery status. Margin I think is reported wrong. I have to evaluate. DeviceTimeReq is optional, not mandatory, but I think i’ts easy to implement. RXParam yes it’s omitted together with NewChannel. I am not happy for that. RXtiming is working.

Yes, I know about the better solutions. To my surprise the price of hope RF quadrupled. For half the price you get LR1110 which also has GPS. But I have some AVR’s hanging around and my brain has difficultly to jump on another platform like STM32WL. But yes, you have right. STM32WL seems better option. It’s my next step.

I remember many people here using 328p in the past, I thought that maybe they want a library to stop having abandonware.

Excuse me, I have language barrier here. I don’t start downlinks. ChMask is on ADR MAC command. I didn’t have never received a CFlist command yet.

I think more serious problem is the absence of confirmed uplinks.

6

Even if it’s using the very same Arduino framework???

Er, not really, I think the serious problem is people using confirm uplinks.

1 Like
7

Oh, you give me hope with the STM32WL, thanks. I had the impression you need their IDE for the LoRaWAN stack. I also tried platformio but to my surprise I had many errors to fix. So yes, I am afraid to jump on another platform.

For confirmed uplinks I wrote about the opposite. I imagine if someone is using SlimLoRa and issued a confirmed DOWNlink, then I don’t know what will happen since SlimLoRa will not respond with confirmed uplink. Constant downlinks from the LNS till the node responds with confirmed uplink?

I think it’s easy to implement that. Maybe this week will do it.

8

There is nothing more disruptive than a confirmed downlink - just don’t do it. You can end up with a perpetual loop if the user code goes wrong.

And confirmed uplinks are disruptive as well - for a lightweight stack both can be emulated with user code.

9

But I want to be managed from the library, so user can’t do any wrong except that choose confirmed downlink which already can. Unless the user tampers the library. Right?

You mean it’s better to not implement confirmed up/downlinks?

10

There will always be someone who wants to shoot themselves in the foot.

If flash space is a consideration, I’d make sure ADR works wonderfully and leave the rest out.

All the 1-Wire libraries seem to have grown considerably so getting a couple of I2C sensors + DS18B20 on to a Nano needs all the space we can get.

11

I think ADR is working flawlessly. You mean I don’t need to further develop SlimLoRa? It’s better to add features with #define’s? No need for dynamic TX/RX channels or CFlist? Just checked that CFlist is only for US and AU. I had the wrong impression that it was applicable to EU.

My full blown feature-rich GPS tracker is using 28164 bytes (98%) - 500 bytes left with 20 gateways mapped for my version of blind ADR. I transmit with SF7 and 6dB when I am close to GW. I wanted to add FSK support and also CAD for listen before talk. Those are overkill?

Bloatware in the embedded!

12

Always better to turn optional items on/off.

I think you’ll find that this will be the Flash killer - so be very careful about spending time on it and then finding that you don’t have any flash left - or indeed no-one from the US or AU is going to use it.

Flash is static so that’s fine - not sure how gateways make any difference as they aren’t in flash.

It’s the RAM remaining that’s the “other” problem for LMIC - I can make it fit but then I run out of RAM!

FSK doesn’t seem to be in much use.

CAD potentially saves on battery if a device is in a busy environment but if it’s not, you burn battery on doing the CAD every time that’s wasted - it’s all about the stats. The only way to find out is to implement it and see how often it detects activity.

1 Like
13

Here 1360 RAM bytes free. I think 1440 bytes RAM free without devices and only battery level report.

Forgot to write. downlinkData are hardcoded to 12 bytes. Just now I figured I have to check for overflow and added #define to semi-hard code the payload size.

1 Like
14

Some additions and bug fixes.

  1. Added to platformio - not tested.
  2. Downlink had major flaw*, I think it’s fine now.
  3. Margin for device status MAC I think it’s working now. Previously only battery level was working.
  4. I updated the example of battery report “complicated” version. It has downlink support. You can change the interval of uplinks with one byte payload on port 1. Other examples probably broken. They need update.
  5. If user sends a downlink with ACK - confirmed - SlimLoRa sends the ACK.

* random port if it was null

15

FYI, this is the most dangerous activity in the world, not even base jumping compares!

I code firmware with a reboot command via downlink - customer sent confirmed downlink - device cycled for hours until I got him to clear the downlink queue!

1 Like
16

Nice input as always, thanks. A downlink with ACK to reboot a device is indeed a nice never ending loop - disaster. So, if we save the ACK demand to EEPROM and after reboot the device sends the ACK you are fine for this edge case? One more byte to EEPROM, but more to program flash.

I think we discussed this. I think it’s worse to not support ACK for downlinks. In that case downlink queue will be full EVERY time a user asks for ACK. Not only after a re-boot command.

I am feeling strange now. I try to conform with LoRaWAN spec and now you don’t want me to conform. TinyLoRa vibes in reverse :grimacing:

To make things better I will not implement confirmed uplinks. We are fine with that?

17

I didn’t say not to conform, I’m just remembering how badly it can go wrong if the user doesn’t follow the instructions!

From my perspective, as long as the device does the core stuff without any issue or impact on the local ISM band or the LNS - join, uplinks, ADR (so downlinks by implication) - the rest I guess is all nice to haves. I’d even go as far as ABP + uplinks + ADR + downlinks.

I’ve got a box of ProMini + RFM95 boards so I’ll take this for a spin over the break to see if they can be put to better use than being technical paperweights.

1 Like