LMIC Node, dropped packets?

brandonbyrne · December 10, 2016, 6:21pm

I have an Adafruit Feather M0 running the LMIC LoraWAN stack.
The device is correctly configured for OTAA with the correct keys.
The device is registered as online on staging.thethingsnetwork.com
At the moment for testing, I have it set up to send a “Hello World” packet once a minute via the ttn-otaa example.
The gateway we have for testing is the Multitech Conduit AEP running ttn poly_pkt_forward script.

Only about 10% of my packets make it through to ttn - the rest of them don’t seem to hit the gateway.

I’m guessing it’s probably on the gateway side that it is losing packets as monitoring the /var/log/lora-pkt-forward log on the gateway reflects that. When the gateway picks up a packet, it correctly forwards it to ttn, and it shows up as a payload.

I’m trying to troubleshoot why the gateway is only seeing about 10% of the packets that my node is sending. I don’t have ssh access to the gateway at the moment so this is from memory. These are my guesses at this point, as well as some things I noticed:

The lora-pkt-forward log seems to update every 30 seconds; every update there is 1 failed CRC check, and an indicated datagram of 252 bytes is attached. Is this the gateway picking up noise or spurious signals and thinking they are possible lora packets, doing a CRC check, and failing? My guess would be that the buffer to hold a packet is ~255 bytes before it gets full and dumps it.

When a successful packet from my node is detected, the log reports one successful CRC check, one failed CRC check, and indicates the correct size of the forwarded packet of “Hello World” along with the 252 byte datagram that failed the CRC check.

So my first guess, there is noise that is preempting my packet or overpowering it and keeping it from being detected.

The second guess is that maybe my node is not transmitting on the correct frequencies. My config.h file in LMIC is set to US915, as well as my gateway. Every packet that was successful in making it to ttn was all on the same frequency: 904.xxx (the xxx precludes me). Is it possible that the LMIC library transmits on different frequencies in a sub band, and my gateway only sees when the node transmits on 904.xxx?

And lastly, this is more of a gateway issue, but the installed poly_pkt_fwd script creates a ton of errors in dmesg and /var/log/message. Again, no access so don’t have the exact error message, but it constantly reports that “usbfs: PID xxxx of poly_pkt_forward failed to claim interface before accessing it.” The poly_pkt_fwd script still seems to work when the gateway receives a packet and forwards it to ttn, but these error messages are spamming my logs as well as hogging close to 90% of the CPU time on the gateway.

What would be the best course of action for me to troubleshoot my node only getting about 10% of its packets detected by the gateway, and to ttn? When I explicitly specify LMIC.setSubband(2) (which I am pretty sure is the default for ttn) the node fails to join at all. Again, my hunch is that there is either noise on some of the frequencies keeping my packets from being detected at the gateway level, but for now I’m trying to find information regarding ttn US frequencies used and if LMIC needs to be configured in a specific way to deal with this.

douglarue · December 10, 2016, 7:07pm

I would first make sure the frequency ranges are the same on both gateway and node. Also check the signal strength to see if there is an antenna issue. You can verify antenna by putting in your base frequency into any number of wire antenna length calculators and then measure the actual wire part of the antenna’s used.

brandonbyrne · December 10, 2016, 7:09pm

The RSSI shows -50 on received packets, which seems pretty realistic.

The gateway is set on FSB 1 (ttn is using FSB 2?). But when I switch to FSB 2 on the gateway, all join requests fail.

Is there any overlap in the frequency sub bands? Is there any reason the node should even be able to connect to the gateway if it’s set on FSB 1?

kersing · December 10, 2016, 7:37pm

@brandonbyrne
Did you install poly_pkt_fwd using the installer.sh script? That should download the TTN channel setup for your region which in the USA uses band 2.
If you are using the poly_pkt_fwd you should not use the MultiTech Conduit configuration tools to change any LoRa settings as the MultiTech configuation software is not compatible with poly_pkt_fwd.
If you try to start the LoRa software using the conduit configuration interface you might end up with two programs trying to access the same hardware, that will cause issues for sure.

brandonbyrne · December 10, 2016, 8:12pm

@kersing
I used the installer.sh script to install initially. After the packet loss problem was happening is when I started messing around with the conduits settings specifically, but after it didn’t work at all (which sounds to be expected), I reran the installer.sh to update back to the ttn settings.

The packet loss happens even with a fresh install on the conduit and only loading the installer.sh script, so I’m at a bit of a loss why it only sees ~10% of my packets.

kersing · December 12, 2016, 8:56pm

@brandonbyrne
A couple of questions:

running only poly_pkt_fwd are you seeing the usbfs errors in dmesg? Can you check the PID mentioned is actually poly_pkt_fwd? (I am not seeing any of those messages on my gateways but this might be version related)
what version of the conduit software is installed on the device?
what Linux kernel version are you running? (output of ‘uname -a’)
what frequencies is the node using?
what is the distance between the gateway and the node during tests?

brandonbyrne · December 12, 2016, 9:09pm

I’ll be out of work until Friday, I’ll get back to you then (and be able to copy paste error messages).

timmyhadwen · December 21, 2016, 11:44pm

Having the same issue in Australia (albeit on the AU915 spectrum). Ive deduced it down to being that LMIC appears to not stay on a single frequency subband however the conduit bases only listen on 1 (in your case FSB 2). Im unable to find anything in LMIC that lets us restrict that but I could be wrong.

brandonbyrne · December 22, 2016, 12:44am

I worked through most of my problems; the gateway dmesg errors were from the Multitech built in network server and poly_pkt_fwd fighting over control of the MTAC card.

LMIC library had to have channels pretty explicitly forced, these are the settings I ended up with that have it receiving every packet.

LMIC_selectSubBand(1);
//Disable FSB1, channels 0-7
for (int i = 0; i < 7; i++) {
    if (i != 10)
    LMIC_disableChannel(i);
  
}
//Disable FSB2-8, channels 16-72
for (int i = 16; i < 73; i++) {
    if (i != 10)
    LMIC_disableChannel(i);
  
}

LMIC_setAdrMode(0);
LMIC.dn2Dr = DR_SF10;

// Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
LMIC_setDrTxpow(DR_SF10,23);

// Start job
do_send(&sendjob);

selectSubBand(1) wasn’t enough to make it stay on ttn’s default of FSB 2; it would transmit on channel 8,9,10,11,12,13,14 then jump to channel 64,65,66,67,68,69,70,71 and repeat 64,65,66,67,68,69,70,71. I had to manually disable every channel but 8 through 15, as well as disable ADR(ADR was causing it to jump to 64,65,66,67,68,69,70,71 as well and get stuck there).

timmyhadwen · December 22, 2016, 4:29am

Awesome! Oddly the channel randomiser still doesn’t work properly for me, so I’ve rewritten it to be much more simple (and super specific to my implementation).

Thanks for the insight!

christopherdro · March 9, 2017, 3:10am

Looking at the source, using LMIC_selectSubBand is suppose to disabled the rest of the sub bands by calling LMIC_disableSubBand which does exactly what @brandonbyrne logic of disabling the channels does.

However, I was still coming across issues with packet loss.
Seems like force disabled the other sub bands by using LMIC_disableSubBand works for now.

tweil · July 6, 2018, 9:51pm

brandonbyrne:

I worked through most of my problems; the gateway dmesg errors were from the Multitech built in network server and poly_pkt_fwd fighting over control of the MTAC card.

LMIC library had to have channels pretty explicitly forced, these are the settings I ended up with that have it receiving every packet.
LMIC_selectSubBand(1);
//Disable FSB1, channels 0-7
for (int i = 0; i < 7; i++) {
    if (i != 10)
    LMIC_disableChannel(i);
  
}
//Disable FSB2-8, channels 16-72
for (int i = 16; i < 73; i++) {
    if (i != 10)
    LMIC_disableChannel(i);
  
}

LMIC_setAdrMode(0);
LMIC.dn2Dr = DR_SF10;

// Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
LMIC_setDrTxpow(DR_SF10,23);

// Start job
do_send(&sendjob);
selectSubBand(1) wasn’t enough to make it stay on ttn’s default of FSB 2; it would transmit on channel 8,9,10,11,12,13,14 then jump to channel 64,65,66,67,68,69,70,71 and repeat 64,65,66,67,68,69,70,71. I had to manually disable every channel but 8 through 15, as well as disable ADR(ADR was causing it to jump to 64,65,66,67,68,69,70,71 as well and get stuck there).

Getting much closer…
I tried implementing something similar to this. Before I update the code on the node, I noticed that the 9 Uplink frequencies listed in the TTN US Frequency Plan https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928 translated to channels 8-15 and 65 using the following table which may or may not be correct. I could not find a reference to it elsewhere.
https://forum.pycom.io/topic/393/lorawan-915mhz-in-the-us/3

I used the following code to enable only channels 8-15 and 65 and had better, but not perfect results. During the JOIN process, the node continued to try frequencies that had been disabled by the code and not in the TTN US Frequency Plan (See the Serial Monitor Logs). When the node eventually tried to JOIN with a frequency in the TTN US Frequency Plan, it was successful right away. From that point on, all Uplinks sucessfully used only the frequencies in the TTN US Frequency Plan that I had specified in the code. The Uplink packets started to populate the Gateway Traffic and Application Data logs immediately, and there were no missed frames. In the Gateway Traffic log, you can see the Uplink packets start immediatley after the JOIN.

I need to try this a few more times and see if it consistently works this way. Are there other changes I should make to the code?

See logs and code below:

// LMIC init
os_init();

// Reset the MAC state. Session and pending data transfers will be discarded.
LMIC_reset();

// relaxed the timing
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);

LMIC_selectSubBand(1);

//Disable FSB1, channels 0-7
for (int i = 0; i <= 7; i++) 
{
LMIC_disableChannel(i); 
} 

//Disable channels 16-64
for (int i = 16; i <= 64; i++) 
{
LMIC_disableChannel(i);
}

//Disable channels 66-72
for (int i = 66; i <= 72; i++) 
{
LMIC_disableChannel(i);
}

LMIC_setAdrMode(0);
LMIC.dn2Dr = DR_SF10;

// Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
LMIC_setDrTxpow(DR_SF10,23);

// Start job
do_send(&sendjob);

Click to see Serial Monitor logs with frequencies used

> Starting
> 15492: engineUpdate, opmode=0x8
> Packet queued
> 18547: engineUpdate, opmode=0xc
> 20899: TXMODE, freq=902300000, len=23, SF=7, BW=125, CR=4/5, IH=0
> Packet queued
> 331346: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 393007: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 402644: engineUpdate, opmode=0xc
> 444577: engineUpdate, opmode=0xc
> 444877: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 755341: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 817001: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 826639: engineUpdate, opmode=0xc
> 1000727: engineUpdate, opmode=0xc
> 1001029: TXMODE, freq=914100000, len=23, SF=8, BW=125, CR=4/5, IH=0
> 1315366: RXMODE_SINGLE, freq=925100000, SF=8, BW=500, CR=4/5, IH=0
> 1378122: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 1387695: engineUpdate, opmode=0xc
> 1388380: engineUpdate, opmode=0xc
> 1388683: TXMODE, freq=907800000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 1699197: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0
> 1760856: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 1770429: engineUpdate, opmode=0xc
> 2261287: engineUpdate, opmode=0xc
> 2261589: TXMODE, freq=907100000, len=23, SF=9, BW=125, CR=4/5, IH=0
> 2581783: RXMODE_SINGLE, freq=923300000, SF=9, BW=500, CR=4/5, IH=0
> 2644475: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 2653984: engineUpdate, opmode=0xc
> 2661842: engineUpdate, opmode=0xc
> 2662144: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 2972610: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 3034270: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 3043918: engineUpdate, opmode=0xc
> 3876355: engineUpdate, opmode=0xc
> 3876657: TXMODE, freq=902300000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 4207284: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 4269849: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 4279422: engineUpdate, opmode=0xc
> 4321010: engineUpdate, opmode=0xc
> 4321311: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 4631777: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 4693437: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 4702946: EV_JOIN_FAILED
> 4702975: engineUpdate, opmode=0xc
> 4725137: engineUpdate, opmode=0xc
> 4725438: TXMODE, freq=911300000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 5056002: RXMODE_SINGLE, freq=926300000, SF=10, BW=500, CR=4/5, IH=0
> 5118566: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 5128139: engineUpdate, opmode=0xc
> 5150168: engineUpdate, opmode=0xc
> 5150470: TXMODE, freq=911000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 5460937: RXMODE_SINGLE, freq=926300000, SF=7, BW=500, CR=4/5, IH=0
> 5522596: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 5532170: EV_JOIN_FAILED
> 5532199: engineUpdate, opmode=0xc
> 5676291: engineUpdate, opmode=0xc
> 5676592: TXMODE, freq=911900000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 6007220: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 6015601: EV_JOINED
> 6015629: engineUpdate, opmode=0x808
> 6016094: TXMODE, freq=903900000, len=26, SF=10, BW=125, CR=4/5, IH=0
> 6100433: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 6163061: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 6167434: EV_TXCOMPLETE (includes waiting for RX windows)
> 6167478: engineUpdate, opmode=0x900
> 7417478: engineUpdate, opmode=0x908
> 7417937: TXMODE, freq=904100000, len=26, SF=10, BW=125, CR=4/5, IH=0
> 1699197: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0
> 1760856: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 1770429: engineUpdate, opmode=0xc
> 2261287: engineUpdate, opmode=0xc
> 2261589: TXMODE, freq=907100000, len=23, SF=9, BW=125, CR=4/5, IH=0
> 2581783: RXMODE_SINGLE, freq=923300000, SF=9, BW=500, CR=4/5, IH=0
> 2644475: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 2653984: engineUpdate, opmode=0xc
> 2661842: engineUpdate, opmode=0xc
> 2662144: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 2972610: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 3034270: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 3043918: engineUpdate, opmode=0xc
> 3876355: engineUpdate, opmode=0xc
> 3876657: TXMODE, freq=902300000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 4207284: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 4269849: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 4279422: engineUpdate, opmode=0xc
> 4321010: engineUpdate, opmode=0xc
> 4321311: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 4631777: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 4693437: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 4702946: EV_JOIN_FAILED
> 4702975: engineUpdate, opmode=0xc
> 4725137: engineUpdate, opmode=0xc
> 4725438: TXMODE, freq=911300000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 5056002: RXMODE_SINGLE, freq=926300000, SF=10, BW=500, CR=4/5, IH=0
> 5118566: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 5128139: engineUpdate, opmode=0xc
> 5150168: engineUpdate, opmode=0xc
> 5150470: TXMODE, freq=911000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 5460937: RXMODE_SINGLE, freq=926300000, SF=7, BW=500, CR=4/5, IH=0
> 5522596: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 5532170: EV_JOIN_FAILED
> 5532199: engineUpdate, opmode=0xc
> 5676291: engineUpdate, opmode=0xc
> 5676592: TXMODE, freq=911900000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 6007220: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 6015601: EV_JOINED
> 6015629: engineUpdate, opmode=0x808
> 6016094: TXMODE, freq=903900000, len=26, SF=10, BW=125, CR=4/5, IH=0
> 6100433: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 6163061: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 6167434: EV_TXCOMPLETE (includes waiting for RX windows)
> 6167478: engineUpdate, opmode=0x900
> 7417478: engineUpdate, opmode=0x908
> 7417937: TXMODE, freq=904100000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 7503620: RXMODE_SINGLE, freq=923900000, SF=10, BW=500, CR=4/5, IH=0
> 7566249: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 7570685: EV_TXCOMPLETE (includes waiting for RX windows)
> 7570730: engineUpdate, opmode=0x900
> 8820729: engineUpdate, opmode=0x908
> 8821188: TXMODE, freq=904300000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 8906872: RXMODE_SINGLE, freq=924500000, SF=10, BW=500, CR=4/5, IH=0
> 8969501: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 8974012: EV_TXCOMPLETE (includes waiting for RX windows)
> 8974057: engineUpdate, opmode=0x900
> 10224057: engineUpdate, opmode=0x908
> 10224517: TXMODE, freq=904500000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 10310073: RXMODE_SINGLE, freq=925100000, SF=10, BW=500, CR=4/5, IH=0
> 10372701: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 10377074: EV_TXCOMPLETE (includes waiting for RX windows)
> 10377122: engineUpdate, opmode=0x900
> 11627121: engineUpdate, opmode=0x908
> 11627581: TXMODE, freq=904700000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 11713139: RXMODE_SINGLE, freq=925700000, SF=10, BW=500, CR=4/5, IH=0
> 11775766: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 11780138: EV_TXCOMPLETE (includes waiting for RX windows)
> 11780186: engineUpdate, opmode=0x900
> 13030187: engineUpdate, opmode=0x908
> 13030647: TXMODE, freq=904900000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 13116204: RXMODE_SINGLE, freq=926300000, SF=10, BW=500, CR=4/5, IH=0
> 13178831: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 13183203: EV_TXCOMPLETE (includes waiting for RX windows)
> 13183251: engineUpdate, opmode=0x900
> 14433252: engineUpdate, opmode=0x908
> 14433712: TXMODE, freq=905100000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 14519269: RXMODE_SINGLE, freq=926900000, SF=10, BW=500, CR=4/5, IH=0
> 14581896: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 14586268: EV_TXCOMPLETE (includes waiting for RX windows)
> 14586316: engineUpdate, opmode=0x900
> 15836317: engineUpdate, opmode=0x908
> 15836777: TXMODE, freq=905300000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 15922333: RXMODE_SINGLE, freq=927500000, SF=10, BW=500, CR=4/5, IH=0
> 15984961: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 15989333: EV_TXCOMPLETE (includes waiting for RX windows)
> 15989381: engineUpdate, opmode=0x900
> 17239381: engineUpdate, opmode=0x908
> 17239856: TXMODE, freq=903900000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 17325412: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 17388041: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 17392413: EV_TXCOMPLETE (includes waiting for RX windows)
> 17392461: engineUpdate, opmode=0x900
> 18642462: engineUpdate, opmode=0x908
> 18642922: TXMODE, freq=904100000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued

Here is another test using the same code that has the odd behavior of mulitple successful JOINs before the Uplink packets.

Click to see Serial Monitor logs with frequencies used

> Starting
> 230: engineUpdate, opmode=0x8
> Packet queued
> 2311: engineUpdate, opmode=0xc
> 4599: TXMODE, freq=902300000, len=23, SF=7, BW=125, CR=4/5, IH=0
> Packet queued
> 315109: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 376769: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 386407: engineUpdate, opmode=0xc
> 422264: engineUpdate, opmode=0xc
> 422565: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 733028: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
> 794688: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 804326: engineUpdate, opmode=0xc
> 855060: engineUpdate, opmode=0xc
> 855361: TXMODE, freq=914300000, len=23, SF=8, BW=125, CR=4/5, IH=0
> 1169826: RXMODE_SINGLE, freq=925700000, SF=8, BW=500, CR=4/5, IH=0
> 1232582: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 1242155: engineUpdate, opmode=0xc
> 1303846: engineUpdate, opmode=0xc
> 1304147: TXMODE, freq=909400000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 1614613: RXMODE_SINGLE, freq=925700000, SF=7, BW=500, CR=4/5, IH=0
> 1676274: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 1685847: engineUpdate, opmode=0xc
> 2080700: engineUpdate, opmode=0xc
> 2081003: TXMODE, freq=903100000, len=23, SF=9, BW=125, CR=4/5, IH=0
> 2401261: RXMODE_SINGLE, freq=925700000, SF=9, BW=500, CR=4/5, IH=0
> 2463953: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 2473525: engineUpdate, opmode=0xc
> 2478667: engineUpdate, opmode=0xc
> 2478969: TXMODE, freq=909400000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 2789499: RXMODE_SINGLE, freq=925700000, SF=7, BW=500, CR=4/5, IH=0
> 2851159: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 2860807: engineUpdate, opmode=0xc
> 3849846: engineUpdate, opmode=0xc
> 3850148: TXMODE, freq=909300000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 4180712: RXMODE_SINGLE, freq=925100000, SF=10, BW=500, CR=4/5, IH=0
> 4243276: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 4252849: engineUpdate, opmode=0xc
> 4268387: engineUpdate, opmode=0xc
> 4268689: TXMODE, freq=907800000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 4579155: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0
> 4640815: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 4650388: EV_JOIN_FAILED
> 4650417: engineUpdate, opmode=0xc
> 4714564: engineUpdate, opmode=0xc
> 4714865: TXMODE, freq=911700000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 5045493: RXMODE_SINGLE, freq=927500000, SF=10, BW=500, CR=4/5, IH=0
> 5108058: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 5117631: engineUpdate, opmode=0xc
> 5171754: engineUpdate, opmode=0xc
> 5172055: TXMODE, freq=914200000, len=23, SF=8, BW=500, CR=4/5, IH=0
> 5482521: RXMODE_SINGLE, freq=927500000, SF=7, BW=500, CR=4/5, IH=0
> 5544181: RXMODE_SINGLE, freq=923300000, SF=10, BW=125, CR=4/5, IH=0
> 5553690: EV_JOIN_FAILED
> 5553719: engineUpdate, opmode=0xc
> 6181324: engineUpdate, opmode=0xc
> 6181626: TXMODE, freq=913300000, len=23, SF=10, BW=125, CR=4/5, IH=0
> 6512254: RXMODE_SINGLE, freq=927500000, SF=10, BW=500, CR=4/5, IH=0
> 6520571: EV_JOINED
> 6520598: engineUpdate, opmode=0x808
> 6521071: TXMODE, freq=903900000, len=26, SF=10, BW=125, CR=4/5, IH=0
> 6605475: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
> 6668103: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 6672539: EV_TXCOMPLETE (includes waiting for RX windows)
> 6672585: engineUpdate, opmode=0x900
> 7922584: engineUpdate, opmode=0x908
> 7923042: TXMODE, freq=904100000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 8008662: RXMODE_SINGLE, freq=923900000, SF=10, BW=500, CR=4/5, IH=0
> 8071291: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 8075663: EV_TXCOMPLETE (includes waiting for RX windows)
> 8075707: engineUpdate, opmode=0x900
> 9325708: engineUpdate, opmode=0x908
> 9326166: TXMODE, freq=904300000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 9411850: RXMODE_SINGLE, freq=924500000, SF=10, BW=500, CR=4/5, IH=0
> 9474479: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 9478990: EV_TXCOMPLETE (includes waiting for RX windows)
> 9479035: engineUpdate, opmode=0x900
> 10729034: engineUpdate, opmode=0x908
> 10729493: TXMODE, freq=904500000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 10815050: RXMODE_SINGLE, freq=925100000, SF=10, BW=500, CR=4/5, IH=0
> 10877678: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 10882051: EV_TXCOMPLETE (includes waiting for RX windows)
> 10882098: engineUpdate, opmode=0x900
> 12132098: engineUpdate, opmode=0x908
> 12132558: TXMODE, freq=904700000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 12218114: RXMODE_SINGLE, freq=925700000, SF=10, BW=500, CR=4/5, IH=0
> 12280742: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 12285114: EV_TXCOMPLETE (includes waiting for RX windows)
> 12285162: engineUpdate, opmode=0x900
> 13535163: engineUpdate, opmode=0x908
> 13535623: TXMODE, freq=904900000, len=26, SF=10, BW=125, CR=4/5, IH=0
> Packet queued
> 13621178: RXMODE_SINGLE, freq=926300000, SF=10, BW=500, CR=4/5, IH=0
> 13683806: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
> 13688179: EV_TXCOMPLETE (includes waiting for RX windows)
> 13688227: engineUpdate, opmode=0x900

kalp97 · March 8, 2020, 6:04am

Thank you so much for you input! Solved alot of my problems also.