I’m sorry for coming back again on this issue, but, maybe, I was able to find a more general problem.
As far as I can see, I put my code in the right place of LMIC, so I do not think that the problem lies in my code. To be able to test this, I just downloaded a new version of LMIC-node and just specified the Feather M0 board and tried to run the demo program, in which a counter value is sent to a Gateway. I obtained exactly the same behaviour (without any line of code from my side).
Here I include the output of serial port:
Device-id: feather-m0
LMIC library: MCCI
Activation: OTAA
Interval: 60 seconds
000000633158: doWork job started
000000633193: Event: EV_JOINING
000000799107: Event: EV_TXSTART
000001120220: Event: EV_JOINED
Network Id: 19
Device Address: 260BE5EE
Application Session Key: 62-0D-A7-B0-9D-9F-C4-59-33-9B-E6-57-29-FD-FD-8C
Network Session Key: 43-30-7A-A6-23-B7-BA-F1-27-75-A8-56-71-10-02-90
000001120767: doWork job started
000001123924: Input data collected
COUNTER value: 1
000001124030: Packet queued
000001124085: Event: EV_TXSTART
000004870767: doWork job started
000004873970: Input data collected
COUNTER value: 2
000004873970: Uplink not scheduled because TxRx pending
000008620768: doWork job started
000008623965: Input data collected
COUNTER value: 3
000008623965: Uplink not scheduled because TxRx pending
The first payload is transmitted correctly, all other are ignored because TxRx is pending.
Thanks a lot for any help. I hope that answering you privately was the right idea.
Cheers.
It’s not breaking the FUP (even if it intends to) because it’s not actually transmitting more than once after join.
And it’s doesn’t really look like a hardware problem, because the TX complete event is never happening, it looks more like a software issue.
Where can we see the exactallegedly uncustomized sketch used, including its commit history?
Though: did you add the required jumper wire to the Feather M0 as specified in the LMIC documentation? Without that I guess it’s theoretically possible that it could work in one of the receive / no receive cases, but not the other. Still if that were the case I’d expect it to get permanently stuck in the receive routine and never run any more code, rather than keep doing other things without ever running the receive code, which makes it look more like somebody has messed with the LMIC jobs or scheduler.
I hope that answering you privately was the right idea.
What you actually did was create another public thread disconnected from the history of your issue, hopefully one of the mods can move this onto that.
DIO1 indicates the RX timeout. If the join accept comes in the first RX window of the first attempt, it wouldn’t have been needed, provided that the unconnected state wasn’t false-firing it. It’s only needed to detect timeouts, give up, and move on to try the next RX window or transmit another request. DIO0 handles successful receive, and transmit completion (which is probably why the Adafruit designers only hooked that one up to get basic radio functionality - they didn’t really have any practical familiarity with LoRaWAN)
But getting the join accept in the first RX window of the first join request would be luckier than many experiments are, so yes, a missing DIO1 will often cause failure.
The problem could possibly be caused by incorrect settings for the end device (in TTS console).
It’s hard to rule anything out yet, but to me it looks like the firmware is never executing or at least never finishing the RX windows following from the first post-join uplink (though it did do at least one of the ones for the join), and since LMIC considers the RX windows to be necessary steps on the path to transmit completion, it believes itself to still be busy and unable to send anything else.
It’s not just RX1 vs RX2 though, it’s that the first join request would have to be received, accepted, and the join accept successfully received - if DIO1 is missing, then the device would literally have to get a response before it ever go the no rx case that would get it stuck.
But that’s kind of moot anyway, because it’s not stuck in the receive routine, it’s as if it never even entered the receive routine after transmitting the first post-join uplink - the job scheduling seems mixed up.
Perhaps there’s an issue with both launching a self-perpetuating chain of events in startup() and also seemingly launching the same chain in the join success code.
To repeat the explanation that was already here, the issue is NOT DIO1. Although a join accept transmitted at the absolute first possibility can succeed without DIO1, the failure mode for any subsequent operation would be that the code would get stuck in receive mode. Instead what we’re seeing is that post-join the code neglected to try to receive after transmit at all!
Yes, I confirm that the wiring connection was missing. Now it works properly.
Thank you so much for your help. Sorry for any musinderstanding and happy Easter to you all
Many Thanks