search

manuelbl / ttn-esp32

The Things Network device library for ESP32 (ESP-IDF) and SX127x based devices
MIT License
303 stars 64 forks source link

Issue handling multiple downlinks #10

Closed Jochim closed 4 years ago

Jochim commented 5 years ago

I'm working on a project at the moment that requires a number of downlink packets to be sent and was wondering if you might have any insight into an issue I've been having.

The device works as expected for the first downlink message, waiting until TTN.transmitMessage() is called and triggering the onMessage callback function correctly.

After handling this however, I see a series of EV_TXSTART / SPI RX buffer / EV_TXCOMPLETE events that are not triggered by transmitMessage(). These don't seem to be triggering the callback function either. transmitMessage continues to be called on a timer, but will fail should an EV_TXSTART event be in progress.

Any help/advice on this would be appreciated, do let me know if this problem isn't related to this library.

I've attached some logs which may or may not be helpful: tx_start_issues_2 tx_start_issues_1

manuelbl commented 5 years ago

Your description doesn't ring a bell. Can you provide the code, both for the device and the part that feeds the downlink messages? With the code, I might be able to reproduce it. I could also monitor it on my local gateway.

Jochim commented 5 years ago

I've moved the device code onto Github and added you as a collaborator.

I've been using LoRaServer rather than TTN for the backend side of things as I already had a gateway set up for it. From looking at the LoRaServer logs, it's receiving an uplink transmission before each downlink, which leads me to believe that it isn't the problem. The backend code just pushes some base64 encoded data onto a queue which is consumed by the gateway bridge. I do understand that this muddies the waters a bit though.

manuelbl commented 5 years ago

Thanks for sharing the code. However, I think the code cannot have produced the above output. Have a look at https://github.com/Jochim/lora-esp-update-project/blob/c786092218cce6b3603942fc0a76b17211f93411/main/main.cpp#L75: it's an empty function that is registered as a callback.

Jochim commented 5 years ago

Ah, apologies, I was doing some testing and mistakenly deleted the function call when testing with a simpler callback. I've pushed the correct code.

I had the same issues when testing with a callback function defined in main.cpp that just prints a fixed "Message Received" string.

Jochim commented 5 years ago

I did a little more digging today and made some progress! It appears that the callback is not being triggered correctly when LMIC tries to poll for new downlink messages. I've attached another log file with debug mode on.

log file

Lines 1-22 cover code that was executed by ttn.transmitMessage() and Lines 16-22 are the product of the callback function.

We can see on Line 24 that the opmode is set to 0x10 which from here I believe indicates that polling will occur.

This then starts a transmission which is responded to with the next downlink; but for some reason, at least in my application, the downlink does not trigger the callback function registered in main.

I commented out The line responsible for polling in lmic.c and from my current tests it seems to prevent the issue occurring. Obviously this isn't an overall solution, as much as an indication of where my problem stems from.

Do you think this an issue with how I've registered the callback, or might it be indicative of a more general problem?

manuelbl commented 5 years ago

I will probably have time on the weekend to look into it.

On Wed, Apr 17, 2019 at 11:00 PM Jochim notifications@github.com wrote:

I did a little more digging today and made some progress! It appears that the callback is not being triggered correctly when LMIC tries to poll for new downlink messages. I've attached another log file with debug mode on.

log file https://gist.github.com/Jochim/c3dc974db8704f32694f5a6f3820cb49#file-ttn-esp32-polling-issue-log

Lines 1-22 cover code that was executed by ttn.transmitMessage() and Lines 16-22 are the product of the callback function.

We can see on Line 24 that the opmode is set to 0x10 which from here https://github.com/manuelbl/ttn-esp32/blob/267e04c833b1b7e43b255b728c48b65bdbf84aad/src/lmic/lmic.h#L213 I believe indicates that polling will occur.

This then starts a transmission which is responded to with the next downlink; but for some reason, at least in my application, the downlink does not trigger the callback function registered in main.

I commented out The line responsible for polling https://github.com/manuelbl/ttn-esp32/blob/267e04c833b1b7e43b255b728c48b65bdbf84aad/src/lmic/lmic.c#L825 in lmic.c and from my current tests it seems to prevent the issue occurring. Obviously this isn't an overall solution, as much as an indication of where my problem stems from.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/manuelbl/ttn-esp32/issues/10#issuecomment-484259440, or mute the thread https://github.com/notifications/unsubscribe-auth/ACTSOHFVMTEJ3DIIXJQW4J3PQ6FVTANCNFSM4HGIGS5A .

manuelbl commented 5 years ago

I've run a few tests today with downlink messages and had no problems whatsoever.

However, I have not used your code. It seems to require special messages and I don't understand the details. It looks as if it would require a first message that sets the size. If the message is too long however, there seams to be no safeguard against it and memory will likely be corrupted.

To further investigate the problem I propose you create a more minimal example. In particular, temporarily remove the LoraUpdater and MessageDecoder. They are not really needed for the TTN communication but make the analysis harder.

If you need my help for the analysis, then I would require the code or instructions for generating the downlink messages.

If I'm not mistaken, your code tries to do an OTA update via TTN. TTN Fair Access Policy mandates no more than 10 downlink messages a day and messages are between 51 and 222 bytes long, depending on the data rate. So if I'm not mistaken, the OTA update will take between 3 and 12 months...

manuelbl commented 5 years ago

You have mentioned that you are using LoRaServer rather than TTN. That could also explain the problem. I'm not really familiar with the LoraWAN protocol but it's different from TTN. The ttn-esp32 specifically configures the LMIC code for TTN use; the other option would be LoraWAN.

So you might want to test it with TTN to rule out that the protocol differences are causing the problem.

Jochim commented 5 years ago

I'll do some tests with TTN to see what the differences are when I am able, I'm interested in finding the source of the problem!

I was under the impression that TTN and LoRaServer both implement the LoraWAN protocol, with TTN having some additional fair access policies in place? That's what seems to be the case from looking at the TTN homepage.

Other than the issue with polling not triggering the callback I haven't noticed any other compatibility issues when using the library with LoraServer. Thank you for your work on it!