Hi all,
I’m running a 328p and RFM95 on 2.2 V so I can use the excellent AEMLIC by Jasper Sikken for solar harvesting (GitHub - jrsikken/AEMLIC: Solar harvesting into Lithium Ion Capacitor). I’m using the internal oscillator set at 4 MHz and I can transmit just fine on ABP, but OTAA is proving a problem. I’ve tried fiddling with the MAX_CLOCK_ERROR setting but no joy.
Can anybody offer any tips to get this working or do I need to investigate other MCUs that will run at 2.2 V and 8MHz?
Thanks
Haven’t used RFM95 but I’m fairly sure the modem will be clocking out the bits based on the RF crystal, so wouldnt matter about the MCU clock speed. Unless it’s so far out that the serial port is way off
Test downlinks on ABP - if they don’t work then there is a timing issue with the Rx1 and subsequently the Rx2 window not hearing the gateway’s transmission.
At that point you can start tuning the delay. Toggle a pin when the device starts the Rx1 window and then see what the actual timing is.
At 2.2V you could up the speed to 6MHz as an alternative tactic.
There are a lot of pieces to the whole clock error idea - if you start listening earlier, you also have to listen longer, since error could be in either direction. And the setting for how long to listen is split across bits of 3 or more registers, and defined in terms of a symbol time.
With a slower processor, you also have to consider the operation setup time, which is not really an error per se, but a fixed offset.
I’d seriously look at a modern low voltage ARM Cortex MCU; fitting a full LMiC into an ATmega328p doesn’t leave much to spare.
You would also ideally want to use the newer generation lower power SX126x radios, but LMiC doesn’t support those yet.
If you want to debug things get a USB logic analyzer and put it on the DIO that flags the the end of the transmission, the SPI lines so you can see the activity setting up the receive attempt, and the other DIO so that you can see failure as well as success. If you can get at an SX1301 gateway’s hardware driven transmit LED, even better - but simply seeing that the RX setup SPI operations completely just before RX1 seconds after the TX done DIO, and that the failure DIO is firing more than a preamble time later, would be a key first step.
Thanks for your responses. I’ve managed to get it going fairly reliably on OTAA joins by using SF12 in the ‘EV_JOINING’ switch case then reverting to SF7 in the ‘EV_JOINED’ switch case.
In addition, within ‘\src\lmic\config.h’ I have changed the 0 to a 1 in ‘# define LMIC_ENABLE_arbitrary_clock_error 0’ to allow me to set a bigger clock error of 50% (massive I know). Will experiment further with trying to reduce this.
I have also set the Rx1 delay to 1 second in the TTN device network layer settings and I get fairly reliable receipt of downlinks.
I’m using MiniCore in the Arduino IDE so will investigate adding a 6MHz mode to see if I can fine tune things.
Resources that helped included:
https://www.thethingsnetwork.org/forum/t/adr-lmic/23167
https://github.com/RAKWireless/RAK811_LoRaWAN_Arduino/issues/2
https://www.thethingsnetwork.org/forum/t/using-lmic-setclockerror-on-mcci-lmic-howto/39776/1
It’s good that you’ve been having some luck, but it seems you’re more throwing huge clock error tolerances at it, than actually fixing the root issue.
The problem with a slower clock isn’t that it has more error, it’s that fixed setup tasks are going to take longer to achieve. If you want the radio to be actually receiving at time X, the time you need to start the SPI commands to get it into receive mode is going to need to be further in advance with a 4 MHz clock, than with an 8 MHz.
If you want to get this to work well and not kill your battery, get a logic analyzer on the DIO’s and SPI so you can see what timing is right and what is wrong.
Once you’re addressing the actual issue you should be able to readily make it work with TTN’s new longer receive windows.