Very interesting situation with RAK811

Hi, guys!
I have a very interesting situation with RAK811. I created a very simple program: RAK811 should send data to the base station and should fall asleep for 1 minute, then it should wake up, send the data to the base station and so on …
In fact, RAK811 does this …
First, RAK811 sends data every minute!


after some time, RAK811 sends data every 2 minutes!))

a few hours later RAK811 sends data every 19 minutes!!!))))

Who can explain where I got lost???))))

 I make the module fall asleep like this:
///////////////////////////////////////////////////////////////////////////////////////////////////////////////
SX1276SetSleep();
SX1276Write(REG_OPMODE,SX1276Read(REG_OPMODE)& 0xF8);     
//__HAL_RCC_RTC_DISABLE();    
//__HAL_RCC_LSE_CONFIG(RCC_LSE_OFF);      
BoardDeInitMcu();			 
SysEnterUltraPowerStopMode();
BoardInitMcu();   
//__HAL_RCC_LSE_CONFIG(RCC_LSE_ON);  
//__HAL_RCC_RTC_ENABLE();
SX127X_INIT();			
GPIOIRQ_Enable();    
rw_LoadUsrConfig();        
UartFlush(&Uart1);
///////////////////////////////////////////////////////////////////////////////////////////////////

before going to bed I set up the RTС for 1 minute:
RtcSetTimeout(60000);

Full firmware version: https://yadi.sk/d/gcVlMKSFV41Q2g

RAK811 send data to the base station every minute for exactly 1 hour, then started sending every 2 minutes…there is clearly something wrong with the RTC

Hi @andbene
I think this is the duty cycle limitation. It is not an RTC issue. Perhaps @Fomi, can confirm my suspicion.

Good idea, @Hobo!!! Thanks!!! I’ll think about it.

Turned off the duty cycle and everything was as it should

So now it is ok, what did you do exactly. Just remove the timeout, or decrease it?

By the way, guys, I see a lot of people complaining because of duty cycle limitations. Those are there for a reason. You might get away with it for testing, but when you go into production, please consider that the duty cycle is there to manage the channel usage so we have a fair policy. :slight_smile:

I did so in “RegionEU868.h”:
///////////////////////////////////////////////////////////////////////////////////////////
/*!

  • Enabled or disabled the duty cycle
    */
    #define EU868_DUTY_CYCLE_ENABLED 0
    ///////////////////////////////////////////////////////////////////////////////////////////

Aha so total freedom :grin:

If the duty cycle is disabled, then with a large number of end-devices on some channel there will be many collisions?

Precisely, in order to scale at least for about a 100 devices you need to ha e some kind of governing mechanic to deal with collisions. As LoRa is ALOHA based there is no detection or avoidance of collisions, so only way to make it work up to a point is not to transmit too often for too long. Hopefully this way you do not clock the channel time wise. This is a poor bandaid though in my opinion and there will eventually have to be some kind of scheduling to enable collision detection and avoidance. Kind of happened with wifi over time.
That is what I think, I tend to be wrong most of the time :slight_smile:

The 868MHz EU band is free to use but subjected to duty cycle.
The firmware enforces the duty cycle but if you disable the duty cycle limitation, you might violate it.

This is against the regulations, please avoid to do that.
If we all do that, we will not be able to send anything on this frequency band.

If you want to send data every minutes, you should lower the SF and send at SF7
If you need to get higher distance and needs to send at SF12 then try to send data every 5 or 10 minutes

2 Likes

yes, I will! You right, @kastayou