Open svelmurugan92 opened 5 years ago
Vel, having been out for more than a week, I'm way behind and won't be able to look at this soon.
Can you please use the compliance app and git bisect
on the LMIC, to find the change that broke this?
Thanks, --Terry
For what it's worth, I noticed that JOIN had become more fragile and required that I widen the clock tolerances in order to make it robust. I thought it was beause of the new event reporting (particularly receive). However, I also notice that your log stops at datarate 2, can you please check that the first tx goes all the way to datarate 0 before going back to datarate 5. Also tell me what is happening at the gateway (which downlink window is being used, and what timing/channel/datarate).
Hello Terry,
I tried the same today, Now join working. Looks like its not a lmic code problem. Maybe a network issue. BTW, Checked the datarate, first Tx itself starting at datarate 5. Attached the success log below
Starting
Packet queued
313395: EV_JOINING
752319: EV_TXSTART: ch 1 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 88C
1060694: EV_RXSTART: freq=865.4 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 88C, txend 756222, delta ms 4871
1113177: EV_RXSTART: freq=866.5 rps=0x84 (SF10 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 88C, txend 756222, delta ms 5711
1153244: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80
1477698: EV_TXSTART: ch 2 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 88C
1786073: EV_RXSTART: freq=865.9 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 88C, txend 1481601, delta ms 4871
1838556: EV_RXSTART: freq=866.5 rps=0x84 (SF10 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 88C, txend 1481601, delta ms 5711
1878622: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80
2091308: EV_TXSTART: ch 0 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 88C
2399682: EV_RXSTART: freq=865.0 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 88C, txend 2095211, delta ms 4871
2452166: EV_RXSTART: freq=866.5 rps=0x84 (SF10 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 88C, txend 2095211, delta ms 5711
2492234: EV_JOIN_TXCOMPLETE: saveIrqFlags 0x80
3498319: EV_TXSTART: ch 1 rps=0x2 (SF8 BW125 CR 4/5 Crc IH=0), datarate 4, opmode 88C
3802386: EV_RXSTART: freq=865.4 rps=0x82 (SF8 BW125 CR 4/5 NoCrc IH=0), datarate 4, opmode 88C, txend 3505435, delta ms 4751
3823717: EV_JOINED: ch 1
netid: 19
devaddr: 2601255D
artKey: C9-DA-D6-B6-4A-0-77-9D-B6-9D-C0-F2-48-62-CB-E4
nwkKey: 53-E0-83-E6-83-A0-15-55-F7-EE-88-3A-B0-9D-67-2F
3823851: EV_TXSTART: ch 0 rps=0x2 (SF8 BW125 CR 4/5 Crc IH=0), datarate 4, opmode 888
3890463: EV_RXSTART: freq=865.0 rps=0x82 (SF8 BW125 CR 4/5 NoCrc IH=0), datarate 4, opmode 888, txend 3830967, delta ms 951
3950467: EV_RXSTART: freq=866.5 rps=0x84 (SF10 BW125 CR 4/5 NoCrc IH=0), datarate 4, opmode 888, txend 3830967, delta ms 1912
4234028: EV_TXCOMPLETE: ch 0 rps=0x84 (SF10 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x20
Packet queued
4546662: EV_TXSTART: ch 1 rps=0x2 (SF8 BW125 CR 4/5 Crc IH=0), datarate 4, opmode 888
4613276: EV_RXSTART: freq=865.4 rps=0x82 (SF8 BW125 CR 4/5 NoCrc IH=0), datarate 4, opmode 888, txend 4553780, delta ms 951
4673280: EV_RXSTART: freq=866.5 rps=0x84 (SF10 BW125 CR 4/5 NoCrc IH=0), datarate 4, opmode 888, txend 4553780, delta ms 1912
4982624: EV_TXCOMPLETE: ch 1 rps=0x84 (SF10 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x20
I will experiment more. We can close this ticket.
That's reassuring. Thanks.
@svelmurugan92 @terrillmoore I'm fighting the same symptom for a long time, including current LMIC (https://github.com/mcci-catena/arduino-lmic/commit/852f3489b6c9d016a1c9821833a595a9ca2aef71), testing on EU868 with TTNv2.
See my issue https://github.com/mcci-catena/arduino-lmic/issues/455
Some days no joins at all, last days smooth join, and these days "EV_JOIN_TXCOMPLETE" again.
No clue where to look at.
@cyberman54 Which board are you using? I normally use India band which is very similar to EU. I will try to setup the device in EU band and check.
Seems like we should reopen this for now
@svelmurugan92 i'm using ESP32, running my app on arduino-esp32 stack.
@terrillmoore meanwhile i managed to write logs
while the device repeatedly reports the "EV_JOIN_TXCOMPLETE" event.
I turned out, that in this situation there was no JOIN ACCEPT packet sent by both gateways, according to the gateway logs. While this is happening, TTN gateway console shows the yellow join request packet, but no green join accept packet.
So this seems a TTN network related issue. For some reason, sometimes (when?) or on certain conditions (which?) join accept packets seem not to be answered by the network. Thus, the behaviour of LMIC is correct.
I am hit by this same issue, it often takes days to successfully connect.
Weirdly enough I have some old code that does work using: https://github.com/matthijskooijman/arduino-lmic (on same hardware).
Any suggestions on what I can do to debug this issue?
I regrettably do not have my own gateway, so cannot grab logs from that.
HI @DaveDavenport. Sorry, this one is my fault. During cert testing I ran into a problem with data reliability. I looked into the code and found that the LMIC was using radically different timing parameters than Semtech. This is issue #442.
When I applied this change, I didn't realize that in fact RX for SF12 was adversely affected. I am planning to set up a test jig this weekend, and hope to finally characterize this. (I have test equipment, but nothing that will give me a GPIO signal at the start and end of the downlink TX, so I can match to my downlink RX.)
Unfortunately, joins in EU use SF12.
You can revert to an older LMIC, or try backing out the changes around #442. The changeset is 42da75b560c. This will reduce your overall RX quality, but will make SF12 (specifically) work beter.
Thanks, will try.
@DaveDavenport If you work out a patch, please let us know here. I am facing the same problem since weeks.
I reverted my checkout to the commit before: 42da75b. This worked-ish for me.
I reverted my checkout to the commit before: 42da75b. This worked-ish for me
@DaveDavenport Do you have a fork online which is in current HEAD level of MCCI LMIC, but has the above changeset/commit reverted?
why would you make a fork? its a single command to get the right checkout?
Any update on this issue?
@DaveDavenport I have committed a number of changes to head; they resolved the device-specific SF12 issues that I was seeing. I've had no feedback from testers (positive or negative). I ran the full EU868 pre-compliance test with the RWC5020, and everything worked well. But... others may have different experiences. I don't have resources to do commercial-scale testing. The problems were related to timing. I added features to https://github.com/mcci-catena/rwc_nst_test that allowed me to sweep the window, and I observed interesting reliability problems related to grounding; on a hunch, I moved the window opening earlier. It helped for me.
One thing that's clear: your platform must have access to a reasonably accurate time base. Some devices, like the Murata module, use an oscillator that's only 4000ppm accurate. The LoRaWAN spec practically requires 100ppm accuracy, and the Semtech and mbed sample code assume that accxuracy. The LMIC can accommodate 4000ppm for class A, but this appears to require using a different RX windowing scheme than Semtech uses.
See lengthy discussion starting at https://github.com/mcci-catena/arduino-lmic/issues/483#issuecomment-568632897.
thx.
I can confirm that that master allows me to connect and send a message..
@DaveDavenport excellent, thanks so much for testing. What radio/CPU, network, and region are you using?
RFM95W module.. uses SX1276 I think connected to a blue pill (stm32f108).
On EU network. 868 MHz. data rate: SF10BW125 coding rate: 4/5
Using the things network
Great, thanks very much. There's some test diversity, as I'm using (primarily) Murata modules. And I don't have a live EU network to test against, just the network simulator that's part of the RWC5020A.
I am completely new to this, I bought some units to play around.
Welcome to the party, have fun!
It seems to be running pretty reliable. Better then I had this/other libs running before.
Excellent, thanks for letting me know.
To be more precise on my testing results:
After devices join, stable transmissions, no issues. Joins delays seem still to be random:
Chance that devices join immediately when trying a bunch of joins is around 30%.
Hi Folks,
I just started moving up the stack from developing lora apps working at the physical layer over the last couple of years. Last couple of days I started using Lorawan and the MCCI LMIC library. As per the instructions which were really clear, I managed to get my TTGO TBeam board running the TTN-ABP example and sending data to The Things Network. So feeing happy I moved up to use the OTTA-TTN example as per the recommendations. I am using the latest libraries as of today and I am now getting the "EV_JOIN_TXCOMPLETE" event repeatedly. Has their been a regression n the OTTA code? I should also say I'm in the USA using the CFG_us915 configuration and the "bad" workaround of disabling all subbands and then enabling just one channel.. Working up the stack incrementally.
Any thoughts?
Hi Folks,
I just started moving up the stack from developing lora apps working at the physical layer over the last couple of years. Last couple of days I started using Lorawan and the MCCI LMIC library. As per the instructions which were really clear, I managed to get my TTGO TBeam board running the TTN-ABP example and sending data to The Things Network. So feeing happy I moved up to use the OTTA-TTN example as per the recommendations. I am using the latest libraries as of today and I am now getting the "EV_JOIN_TXCOMPLETE" event repeatedly. Has their been a regression n the OTTA code? I should also say I'm in the USA using the CFG_us915 configuration and the "bad" workaround of disabling all subbands and then enabling just one channel.. Working up the stack incrementally.
Any thoughts?
regrettable for me it has been pretty hit and miss. Once connected it works well, but it sometimes takes days to connect othertimes it is really quick. I kinda gave up for now and shelved my project.
With the current master changes, tried to build the example sketch in catena 4450 and catena 4612. While doing the step clear the FRAM and redo the provisioning. Then join not happening, EV_JOINING not success.
Tried the compliance test code in 4450. Still same problem, joining not happened.
Please share your views