What does error no_free_channel mean and when does it happen?

ndarkness · September 16, 2016, 2:27pm

Hello all,

Recently I open a post regarding some issues I was facing with Libelium and its LoraWAN stack implementation while connecting to my TTN backend.

After quite a lot of debuging, I have been able to point out that the issue lies on the fact that apparently the device runs into a lack of free channel to upload its payload. The bihaviour is quite weird since it happens after having sent the 8th packet, then I get the error _no_free_channel and it stalls there forever ( as shown below in the debug). Just mention that I register my motes as ABP.

My question is then, could someone explain me how could a device run out of free channels?

Thanks again,

Kind regards!

[debug] cmd:mac tx uncnf 3 0100000000C3

[debug] ans1:ok
[debug] ans2:invalid_param
[debug] ans3:not_joined
[debug] ans4:no_free_ch
[debug] ans:ok
::sendUnconfirmed: command->mac tx uncnf 3 0100000000C3
::sendUnconfirmed: status->[debug] found:mac_tx_ok
[debug] cmd:mac save

[debug] ans1:ok
[debug] ans2:invalid_param
[debug] ans:ok
Sent properly data: 0100000000C3
3. Send Unconfirmed packet OK
[debug] cmd:mac get upctr

[debug] ans1:

[debug] ans2:invalid_param
[debug] ans:

parseValue::The buffer is this ->7
[debug] cmd:mac get dnctr

[debug] ans1:

[debug] ans2:invalid_param
[debug] ans:

parseValue::The buffer is this ->1
Up Counter is:7
Down Counter is:1

[debug] cmd:mac tx uncnf 3 0100000000C3

[debug] ans1:ok
[debug] ans2:invalid_param
[debug] ans3:not_joined
[debug] ans4:no_free_ch
[debug] ans:ok
::sendUnconfirmed: command->mac tx uncnf 3 0100000000C3
::sendUnconfirmed: status->[debug] found:mac_tx_ok
[debug] cmd:mac save

[debug] ans1:ok
[debug] ans2:invalid_param
[debug] ans:ok
Sent properly data: 0100000000C3
3. Send Unconfirmed packet OK
[debug] cmd:mac get upctr

[debug] ans1:

[debug] ans2:invalid_param
[debug] ans:

parseValue::The buffer is this ->8
[debug] cmd:mac get dnctr

[debug] ans1:

[debug] ans2:invalid_param
[debug] ans:

parseValue::The buffer is this ->1
Up Counter is:8
Down Counter is:1

[debug] cmd:mac tx uncnf 3 0100000000C3

[debug] ans1:ok
[debug] ans2:invalid_param
[debug] ans3:not_joined
[debug] ans4:no_free_ch
[debug] ans:no_free_ch
::sendUnconfirmed: command->mac tx uncnf 3 0100000000C3
::sendUnconfirmed: status->[debug] cmd:mac save

[debug] ans1:ok
[debug] ans2:invalid_param
[debug] ans:ok
3. Send Unconfirmed packet error = 10
[debug] cmd:mac get upctr

[debug] ans1:

[debug] ans2:invalid_param
[debug] ans:

parseValue::The buffer is this ->8

[debug] cmd:mac get dnctr

[debug] ans1:

[debug] ans2:invalid_param
[debug] ans:

parseValue::The buffer is this ->1
Up Counter is:8
Down Counter is:1

[debug] cmd:mac tx uncnf 3 0100000000C3F5BE418022804200053FB7

[debug] ans1:ok
[debug] ans2:invalid_param
[debug] ans3:not_joined
[debug] ans4:no_free_ch
[debug] ans:no_free_ch
::sendUnconfirmed: command->mac tx uncnf 3 0100000000C3F5BE418022804200053FB7
::sendUnconfirmed: status->[debug] cmd:mac save

htdvisser · September 16, 2016, 2:49pm

This means there is no channel available for a transmission due to the duty cycle of the channel. There are 8 channels, so after the 8th message, the device has to wait until it’s allowed to send on the first channel again.

Solutions:

Sending less frequently will not give you this error
Sending at a faster data rate will decrease the time you have to wait

Also, keep in mind that TTN has the Fair Use Policy, so if you reach the hardware-enforced limit, you’re way over the TTN Fair Use limit.

ndarkness · September 19, 2016, 8:13am

Hi @htdvisser

Thank for you explanation! I have taken as approach your first solution. Thus, in order to try to avoid the error, I have increased the time between transmission depending on the duty cycle that the example has.

So, I see that in the waspmote example the duty cycle (dC) is set to 100/40000=0.0025 thus according to Lora Standard(section 7.1.2) I should wait a time of Toff = TimeOnAir/dC - TimeOnAir, for a Tx power of 18dBm the TimeOnAir is around 0.21811s. Using that equation I should have a Toff = 87.03s.

Setting this time should grant that I can use again the same channel, however this is not like this, and I still face the same problem, is it something I am doing wrong? I think that a minute and a half is quite a time…

On the other hand, I wonder why I do face this issue with the Libelium stack and not with the TTUno for instance, is it due to the fact that in the TTUno the duty cycle is not set and therefore I am not compliant with the standard?

Thanks !

regards

htdvisser · September 19, 2016, 8:55am

I personally don’t have experience with the Libelium stack, but its LoRa module is based on the RN2483 chip (same as The Things Uno). Therefore, the duty cycle enforced by the hardware/firmware in the RN2483 should be the same for both devices.

If you use SF7 you should be able to send every ~30 seconds without problems.

ndarkness · September 22, 2016, 8:35am

Thanks @htdvisser for replying!

That is the weirdest thing, I am currently using such as SF ( I haven’t set it in the firmware it is apparently set by default ) according to what I see from TTN log coming from my Lora GW. So I cannot understand why I get no free channel even having set the tx time till 88s

> [90m DEBUGe[0m Inject Metadata e[90mDevAddre[0m=41473034 e[90mGatewayIDe[0m=xxxxxxxx e[90mMetadatae[0m=Frequency:867.7 DataRate:"**SF7BW125**" CodingRate:"4/5" Timestamp:643257660 Rssi:-81 Lsnr:9.5 PayloadSize:30 Time:"2016-09-22T08:29:19.695528Z" CRCStatus:1 Modulation:"LORA" Channel:6 GatewayEUI:"xxxxxxxxxxx" Altitude:33 Longitude:xxxxxxx Latitude:xxxxxxxx ServerTime:"2016-09-22T08:29:22.709754713Z"

JDP · September 22, 2016, 3:33pm

Maybe the Libelium software has set up a very very low duty cycle.
You can find the explanation & commands to change the duty cycle here: http://www.microchip.com/forums/FindPost/947922

I’d recommend bumping it up high to see if it resolves the problem, then work backwards from there.

ndarkness · September 29, 2016, 9:23am

Hi @JDP

Thanks for your reply, checking their code comments I can see that they are setting a real duty cycle of X[%] = 100/(dcycle +1) so if dcycle = 333333 => X[%] = 0.0002999994
dcycle = 40000 => X[%] = 0.0024999375

Which are really low right?

UPDATE: I have increased the dutycycle as @JDP suggested till 0.1% for all the channels, and it does seem to resolve the problem that I have been facing for so long, even people at Libelium didn’t know!!

Thank you very much @JDP

/*!
 * @brief   This function sets the duty cycle on the given channel ID
 * 
 * @param   uint16_t dcycle: frequency to be set [0..65535]
 *          uint8_t channel: channel to be set [0..15]
 * 
 * @remarks The "dcycle" value that needs to be configured can be obtained 
 *          from the actual duty cycle X (in percentage) using the following formula:
 *          dcycle = (100/X) - 1
 * 
 * @return  
 *  @arg    '0' if OK
 *  @arg    '1' if error 
 *  @arg    '2' if no answer
 *      @arg    '7' if input channel parameter error
 *  @arg    '8' module does not support function
 */
uint8_t arduinoLoRaWAN::setChannelDutyCycle(uint8_t channel, uint16_t dcycle)

How they configure it

//  //////////////////////////////////////////////
//  // 10. Set Duty Cycle for specific channel. (Recomemnded)
//  // Consult your Network Operator and Backend Provider
//  //////////////////////////////////////////////
//
//  for (int ch = 0; ch <= 2; ch++)
//  {
//    error |= LoRaWAN.setChannelDutyCycle(ch, 33333);
//  }
//  
//  for (int ch = 3; ch <= 7; ch++)
//  {
//    error |= LoRaWAN.setChannelDutyCycle(ch, 40000);
//  }
//
//  // Check status
//  if( error == 0 ) 
//  {
//    USB.println(F("10. Duty cycle channel set OK"));     
//  }
//  else 
//  {
//    USB.print(F("10. Duty cycle channel set error = ")); 
//    USB.println(error, DEC);
//  }

//

ndarkness · September 29, 2016, 12:41pm

Another question, if I do connect to the network using OTAA procedure, should I set as well the duty cycles or it is aggreed between mote and GW?

Thanks!

JDP · September 29, 2016, 9:11pm

There is an optional feature within OTAA called CF-List. It can set up the channel plan, so must set duty cycle as well. But I don’t know if TTN has implemented CF-List.

htdvisser · September 30, 2016, 6:16am

TTN’s backend implements the CFList for the EU-868 band. However, the CFList does not include duty cycle information (see the spec) so you have to make sure that your device is configured for the European duty cycles. As far as I know, the default firmware and configuration do this correctly.

telkamp · September 30, 2016, 7:10am

Unfortunately, after TTN provides the CFList in the join accept message, still manual action is required.

From the RN2483 documentation:

“The default settings consider only the three default channels (0-2), and their default duty cycle is 0.33%. If a new channel is created either by the server or by the user, all the channels (including the default ones) must be updated by the user in terms of duty cycle to comply with the ETSI regulations.”

@JDP: it would be nice of the RN2483 module would be able to automatically take care of this.

JDP · September 30, 2016, 7:47am

Admittedly I should have checked this but I was rushing yesterday. I’m surprised - to me it seems like the intention of the CF-List function is to allow the network to configure a default node to the networks local preferences. If application intervention is needed, it seems like a bit of a fail in the spec.

arjanvanb · October 7, 2017, 9:56am

As an aside, when wondering why the error might only show after sending a few messages quickly after one another, see the Duty Cycle Wiki page. This explains how some modules (such as the RN2483) implement a per-channel duty cycle rather than an overall duty cycle.