Strange behaviour with Feather M0 and Chirpstack

[TommasoGuiducci]

Hi, I'm writing because I'm experiencing a strange behaviour with my Feather M0 LoRa EU868 and the LMiC library (3.2.0).

I'm using it with a few sensors (DHT22, BMP388 and a contact sensor) and my sketch is basically a variation of the OTAA one included in the repository, except I added a 1 hour deep sleep cycle (using RocketScream's Low power library) between each transmission; the sleep is handled in the loop function using a flag that is set to true when the TX_COMPLETE event fires.

It works fine (I see the data received by the Network Server I'm using, ChirpStack) but there is a problem that keeps bugging me: except (sometimes) the first 2-3 transmissions, the period between each transmission is not 1 hour and a few seconds, which is what I expected, but it amounts to 2' 30" (+- 1"). Obviously this isn't a problem per se (I could just reduce the sleep period to 57' 30"), but the fact that the board stays on for much more than needed leads to a huge waste of power and this is indeed a big problem, since the board should run with only a small LiPo battery attached, hopefully for some weeks or even months.

I've done a few tests and it seems like the Feather completes its transmission in a few seconds after it wakes up from the sleep cycle, but the TX_COMPLETE event fires a lot later (approximately 2' 20"), thus postponing the start of the next sleep cycle.

I have already tried submitting this issue in other forums and it was pointed out that the problem is probably connected with the timer used by the LMiC library, which doesn't advance during this kind of deep sleep and therefore may introduce some bugs like this one, but since I'm not that good of a C developer I still haven't figured out how to fix this.

I also tried to modify the library as indicated in this issue but without any luck.

If someone could help me I would be really grateful!

Here is the code I'm using: Firmware_FeatherM0.zip

[terrillmoore]

Which network are you using?

[TommasoGuiducci]

What do you mean by network? If you mean network server, I'm using Chirpstack.

[terrillmoore]

Yes, Chirpstack is a network in the sense that I mean. (Or rather, you're running your own network, using Chripstack.)

Chirpstack configures your device in an odd way upon join. In particular, it programs your device to send three uplinks for each message. Because of regulations for EU regions, it is likely that your device is stalling trying to send one of the uplinks due to duty cycle restrictions. I strongly recommend that you investigate how to configure Chirpstack so that it doesn't do this.

The device is almost certainly functioning correctly (i.e., according to the instructions sent to it by your network).

For everyone starting with LoRaWAN device development, I also strongly recommend testing first with a commercial network (and The Things Network is a commercial network in this sense); a network administered by experts who are responsible for the success of the network. After you've confirmed that your device works properly, either with a known-good network or a known-good network simulator, you can then start learning how to run your own network. ChirpStack is a fine product, but it requires that you become a network administrator.

Best regards,
--Terry

[TommasoGuiducci]

Thanks for the detailed answer; I think I owe you some more context.

The device I'm building is part of a thesis project which I'm developing during a stage in a local company: the LoRa network (gateways, ChirpStack, etc.) were already configured when I began working at my project and i'm not an administrator. All the interaction I had with ChirpStack consisted in creating the device on the network, configuring the keys (also I disabled frame-counter validation - only to simplify testing, when the device will be ready I'll enable it) and setup the device profile (MAC version - 1.0.3, Regional parameters revision - A, Supports OTAA - yes, etc.).

So on the web based UI of ChirpStack I didn't find anything related to this triple uplink for each message thing, and the network admin doesn't know anything about it either; could you be more precise about this setting on ChirpStack and/or cite a link that explains how to modify it?

Lastly, I'm sorry if I insist but are you sure that this issue is not related to the sleep cycle implemented in my program? A while ago I also managed to make some tests in which I replaced it with a simple delay(sleepTime); and it seemed to adjust the transmission times to more acceptable values - but obviously this doesn't represent a viable option for me since I need a really low power consumption for my end-node.

Thanks again for the support,
Tommaso