Arduino 1MHz

[Samuel-ZDM]

Hello!

• Version of LMIC being used: 3.2.0
• PlatformIO
• Network provider The Things Network
• Region US915
• Board Atmega328 standalone
• Radio HopeRF RFM95W (Sx1276)

I'm using an Atmega328 with internal oscillator of 1MHz with RFM95, but I can't send a message to the gateway.
My device sends the first message and then no longer sends it.
I am using the ABP example to send to TTN.

I've been researching and answering questions in other repositories and I found something about the ticks that are in the oslmic.h file, that they depend on the frequency of the microcontroller. Maybe my problem is there, but I would like to know if it is possible to change these values without changing the operation of the library? And any tips on how I can do this?

I also saw that the library has two parameters that can be changed, the US_PER_OSTICK_EXPONENT and the LMIC_SPI_FREQ, can the default values be influencing the non-operation with 1MHz?

Can the LMIC_setClockError () function help in this case?

[Samuel-ZDM]

I already tried to change the SPI frequency, as the clock is 1 MHz, I thought what this could be.
I put 500k and lower, 125k MHz, and the device only sent 1 or 2 messages.
In addition, I tried to add LMIC_setClockError (MAX_CLOCK_ERROR * 20/100) with 500k and 125k MHz SPI.
Also, I tried to change the US_PER_OSTICK_EXPONENT value and it didn't work.

I don't know what I can change for it to work.

Thank you very much in advance

[terrillmoore]

Unfortunately, I don't have any experience looking at this kind of problem on an Atmega328. Perhaps someone else here has more experience. However, i always recommend starting with two devices and the raw sketch, so you can confirm that the radio is working. If SPI were not working, the LMIC will fail (or assert) during initialization. Also, it's important to include the debug serial output, and the exact details of your gateway and (if possible) gateway logs showing whether your device was heard by the network.

[JohnOH]

Review the packet transmission triggers you are using for the radio. You may be filling the FIFO buffer too slowly to keep up with the transmission rate. If this is happening the FIFO goes empty and the transmission must then stop before a complete packet has been transmitted.

[Samuel-ZDM]

@terrillmoore Thank you so much for your answer!
Yes, I will start with point-to-point communication and see if I can exchange messages. Then I test the communication with the TTN.

[Samuel-ZDM]

Thank you so much @JohnOH !

How can I check the stack? Because I'm finding it very strange that he sends a message or two and stops. Maybe that could be it.

[JohnOH]

I was thinking about the RegFifoThresh (0x35) used in FSK mode. The closest I have found in LoRa mode is RegTxCfg (0x16) which isn't well documented. You could hold the radio in sleep until the FIFO was had the whole packet I guess.

[terrillmoore]

@JohnOH I don't think it matters how fast you load the fifo in LoRa mode; the transmit doesn't happen until you hit "start" (line 531 of radio.c where we say opmode(OPMODE_TX)). However, if timing is really slow (generally), some of the hard-coded assumptions about delays will not work, breaking class A downlink.

My recommendation is to start with the LMIC with a close-to-known-good platform, and only then make changes, one change at a time. In this case, get the LMIC working with an AVR at normal speed. Then try slowing things down.

[JohnOH]

Good thoughts @terrillmoore, my experience comes from FSK mode. Thanks for your insight.