Timing issues

[HeadBoffin]

If you can point the way, I'm happy to figure out the timing issues that are causing issue.

[clavisound]

@HeadBoffin since novag seems inactive, can we try together to solve the timing issues?

I have a experimental branch with DEBUG_SLIM and DEBUG_TIMING options and functions SetPower, SetDataRate. Useful for ABP only: ForceTxFrameCounter, ForceRxFrameCounter.

SetPower is useful for testing without to cause problem to GW and TTN. Because -80 'disables' transmission. It works only close (centimeters) to GW. I think to make a real test you need to SetPower(0) and move the node away from GW to avoid overloading.

Also a I have wrote an example https://github.com/clavisound/SlimLoRa/tree/full-throttle/examples/simpleLoRa-clv

To my understanding timing related code is in those places.

Start time. https://github.com/clavisound/SlimLoRa/blob/725a38d653d7fa5f745d96f450211fbfa9c8f467/SlimLoRa.cpp#L302

Set RFM wait time to generate interrupt. https://github.com/clavisound/SlimLoRa/blob/725a38d653d7fa5f745d96f450211fbfa9c8f467/SlimLoRa.cpp#L328

Wait time before RX https://github.com/clavisound/SlimLoRa/blob/725a38d653d7fa5f745d96f450211fbfa9c8f467/SlimLoRa.cpp#L355

DEBUG_SLIM 1 for sure breaks RX2 timing, I hope not RX1 timing. https://github.com/clavisound/SlimLoRa/blob/725a38d653d7fa5f745d96f450211fbfa9c8f467/SlimLoRa.cpp#L391

Things that I don't understand - again related to timing. CalculateDriftAdjustment() https://github.com/clavisound/SlimLoRa/blob/725a38d653d7fa5f745d96f450211fbfa9c8f467/SlimLoRa.cpp#L536

CalculateRxWindowOffset() https://github.com/clavisound/SlimLoRa/blob/725a38d653d7fa5f745d96f450211fbfa9c8f467/SlimLoRa.cpp#L551

CalculateRxDelay() https://github.com/clavisound/SlimLoRa/blob/725a38d653d7fa5f745d96f450211fbfa9c8f467/SlimLoRa.cpp#L570

SlimLoRa.h VALUES https://github.com/clavisound/SlimLoRa/blob/725a38d653d7fa5f745d96f450211fbfa9c8f467/SlimLoRa.h#L121

[novag]

Hi, very cool that you want to contirbute! I did not abandon the project and will fix the remaining problems, but it will probably not be possible before April 10. I am happy to help where I can. For debugging the timing issues you can look into the original implementation for the ATtiny. I sent a short debug string right after the JoinRequest was sent and another short debug string when the receiver is activated. You can measure the time between the two messages from the serial console. According to the lorawan spec the JoinRequest RX1 is always 5 seconds. The RX1 window for normal messages is set by the network server through the JoinAccept. SlimLoRa respects this.

Since I did not use the ABP mode since a long time ago there might be problems with it. The RX1 window for ABP currently defaults to 1 second with no config option to set it.

CalculateDriftAdjustment is for compensating the internal clock drift since I did not use an external clock on the ATtiny project. You might be able to save some power but I would leave it for now.

CalculateRxWindowOffset is for compensating clock drift at the gateway. We need at least 5 out of 8 symbols to synchronize on the preamble so this depends on the spreading factor.

[clavisound]

Nothing cool from me. You are very cool and your work :-)

Sorry I don't wanted to imply that you abandoned the project. I remember that it's a fun project for you. I suppose for your spare time. That's the reason I wrote 'inactive'. Thank you for the forecast.

I checked the original code in hurry before posting. But I don't understand this debugging style. I will use your style it to understand it.

I am confused with the delay ABP 1 sec. The previous line is uint8_t value = eeprom_read_byte(&eeprom_lw_rx1_delay); so if value is != 0x00 || 0xFF then we have a value! And since you have SetRx1Delay(packet[12] & 0xF); I don't understand why is not supported. The SetRx1Delay(packet[12] & 0xF); is executed only on OTAA?

Thanks for the explanations. The name of the functions are self-explanatory, I just don't get the voodoo magic with the numbers. More to study. :p

Thanks!

I also have questions about EEPROM, but I will leave you in peace.