Lora-net / LoRaMac-node

Reference implementation and documentation of a LoRa network node.
Other
1.87k stars 1.09k forks source link

ACK for confirmed msg #298

Closed artuguy closed 7 years ago

artuguy commented 7 years ago

Hi: I'm debugging the confirmed msg, when i USE_BAND_470 , seems like class A node can't recieve ACK, it re-sent packet for 8 times, but from base station web page ack was sent. when i USE_BAND_433, class A node sent packet once only. How can I test if node recieved the ACK? some detail is

define LORAMAC_FIRST_RX1_CHANNEL ( (uint32_t) 500.3e6 )

define RX_WND_2_CHANNEL { 505300000, DR_0 }

base station global_conf.json:

{ "SX1301_conf": { "lorawan_public": true, "clksrc": 1, "antenna_gain": 0, "radio_0": { "enable": true, "type": "SX1255", "freq": 471800000, "rssi_offset": -176.0, "tx_enable": true, "tx_freq_min": 470000000, "tx_freq_max": 510000000 }, "radio_1": { "enable": true, "type": "SX1255", "freq": 472600000, "rssi_offset": -176.0, "tx_enable": false },

    // SX1301 MultiSF, standard LoRa and FSK channels
    "chan_multiSF_0": { "enable": true, "radio": 1, "if": -300000 },
    "chan_multiSF_1": { "enable": true, "radio": 1, "if": -100000 },
    "chan_multiSF_2": { "enable": true, "radio": 1, "if": 100000 },
    "chan_multiSF_3": { "enable": true, "radio": 1, "if": 300000 },
    "chan_multiSF_4": { "enable": true, "radio": 0, "if": -300000 },
    "chan_multiSF_5": { "enable": true, "radio": 0, "if": -100000 },
    "chan_multiSF_6": { "enable": true, "radio": 0, "if": 100000 },
    "chan_multiSF_7": { "enable": true, "radio": 0, "if": 300000 },
    "chan_Lora_std":  { "enable": true, "radio": 1, "if": -200000, "bandwidth": 250000, "spread_factor": 7 },
    "chan_FSK":       { "enable": true, "radio": 1, "if": 300000,  "bandwidth": 125000, "datarate": 50000 },

    // RHF0M301-470
    "tx_lut_0":  { "rf_power": -2, "dig_gain": 3, "mix_gain": 8,  "pa_gain": 0 },
    "tx_lut_1":  { "rf_power": 1,  "dig_gain": 3, "mix_gain": 10, "pa_gain": 0 },
    "tx_lut_2":  { "rf_power": 3,  "dig_gain": 3, "mix_gain": 12, "pa_gain": 0 },
    "tx_lut_3":  { "rf_power": 4,  "dig_gain": 3, "mix_gain": 15, "pa_gain": 0 },
    "tx_lut_4":  { "rf_power": 5,  "dig_gain": 0, "mix_gain": 15, "pa_gain": 0 },
    "tx_lut_5":  { "rf_power": 8,  "dig_gain": 3, "mix_gain": 8,  "pa_gain": 1 },
    "tx_lut_6":  { "rf_power": 10, "dig_gain": 0, "mix_gain": 8,  "pa_gain": 1 },
    "tx_lut_7":  { "rf_power": 14, "dig_gain": 0, "mix_gain": 13, "pa_gain": 1 },
    "tx_lut_8":  { "rf_power": 15, "dig_gain": 3, "mix_gain": 8,  "pa_gain": 2 },
    "tx_lut_9":  { "rf_power": 17, "dig_gain": 3, "mix_gain": 9,  "pa_gain": 2 },
    "tx_lut_10": { "rf_power": 19, "dig_gain": 0, "mix_gain": 8,  "pa_gain": 2 },
    "tx_lut_11": { "rf_power": 20, "dig_gain": 0, "mix_gain": 9,  "pa_gain": 2 },
    "tx_lut_12": { "rf_power": 21, "dig_gain": 0, "mix_gain": 10, "pa_gain": 2 },
    "tx_lut_13": { "rf_power": 23, "dig_gain": 0, "mix_gain": 14, "pa_gain": 2 },
    "tx_lut_14": { "rf_power": 24, "dig_gain": 3, "mix_gain": 10, "pa_gain": 3 },
    "tx_lut_15": { "rf_power": 25, "dig_gain": 0, "mix_gain": 9,  "pa_gain": 3 }

},
"gateway_conf": {
    "gateway_ID": "AA555A0000000000",
    /* change with default server address/ports, or overwrite in local_conf.json */
    "server_address": "localhost",
    "serv_port_up": 1680,
    "serv_port_down": 1680,
    /* adjust the following parameters for your network */
    "keepalive_interval": 10,
    "stat_interval": 30,
    "push_timeout_ms": 100,
    /* forward only valid packets */
    "forward_crc_valid": true,
    "forward_crc_error": false,
    "forward_crc_disabled": false
}

}

thanks

artuguy commented 7 years ago

A few minutes ago , I discover on unconfirm mode node can get mcpsconfirm primitives, but on confirmed mode, node can not get mcpsconfirm primitives.

djaeckle commented 7 years ago

Hi artuguy,

thanks for your report. Which version are you using?

artuguy commented 7 years ago

djaeckle: In case USE_BAND_433, on confirmed msg mode, McpsConfirm primitives can be got, ACK can be recieved, but USE_BAND_470, on confirmed msg mode, McpsConfirm primitives can not be got, ACK can not be recieved. I'm using V4.3.2 thanks

djaeckle commented 7 years ago

Hi artuguy,

so the LoRaMAC does not provide the McpsConfirm primitive at all in your case for confirmed uplinks?

artuguy commented 7 years ago

djaeckle: it is, in USE_BAND_470 case , unconfirmed uplinks, McpsConfirm primitive can be got. if I use confirmed uplinks, McpsConfirm primitive can't be got . I'm using stm32l053 discovery board, with SX1278 . BR/Artuguy

djaeckle commented 7 years ago

Hi artuguy,

whats the value of the parameter Req.Confirmed.NbTrials in your McpsReq_t data structure?

artuguy commented 7 years ago

djaeckle: Req.Confirmed.NbTrials = 8; as below: static bool SendFrame( void ) { McpsReq_t mcpsReq; LoRaMacTxInfo_t txInfo;

if( LoRaMacQueryTxPossible( AppDataSize, &txInfo ) != LORAMAC_STATUS_OK )
{
    // Send empty frame in order to flush MAC commands
    mcpsReq.Type = MCPS_UNCONFIRMED;
    mcpsReq.Req.Unconfirmed.fBuffer = NULL;
    mcpsReq.Req.Unconfirmed.fBufferSize = 0;
    mcpsReq.Req.Unconfirmed.Datarate = LORAWAN_DEFAULT_DATARATE;
}
else
{
    if( IsTxConfirmed == false )
    {
        mcpsReq.Type = MCPS_UNCONFIRMED;
        mcpsReq.Req.Unconfirmed.fPort = AppPort;
        mcpsReq.Req.Unconfirmed.fBuffer = AppData;
        mcpsReq.Req.Unconfirmed.fBufferSize = AppDataSize;
        mcpsReq.Req.Unconfirmed.Datarate = LORAWAN_DEFAULT_DATARATE;
    }
    else
    {
        mcpsReq.Type = MCPS_CONFIRMED;
        mcpsReq.Req.Confirmed.fPort = AppPort;
        mcpsReq.Req.Confirmed.fBuffer = AppData;
        mcpsReq.Req.Confirmed.fBufferSize = AppDataSize;
        mcpsReq.Req.Confirmed.NbTrials = 8;
        mcpsReq.Req.Confirmed.Datarate = LORAWAN_DEFAULT_DATARATE;
    }
}

if( LoRaMacMcpsRequest( &mcpsReq ) == LORAMAC_STATUS_OK )
{
    return false;
}
return true;

}

djaeckle commented 7 years ago

Hi artuguy,

does the MAC perform the frame repetitions for confirmed uplinks correctly?

artuguy commented 7 years ago

djaeckle: Yes, MAC send packet repeatly for 8 times, it is correct , looking from base station web page .

artuguy commented 7 years ago

djaeckle: On USE_BAND_470, I have mask some channels for the base station has not them. as bellow: LoRaMacParamsDefaults.ChannelsMask[0] = 0x3FC0; LoRaMacParamsDefaults.ChannelsMask[1] = 0x0000; LoRaMacParamsDefaults.ChannelsMask[2] = 0x0000; LoRaMacParamsDefaults.ChannelsMask[3] = 0x0000; LoRaMacParamsDefaults.ChannelsMask[4] = 0x0000; LoRaMacParamsDefaults.ChannelsMask[5] = 0x0000;

Does it matter?

djaeckle commented 7 years ago

Hi artuguy,

what happens after the 8 uplinks? Is the node running? Could you please provide some details about the software state?

artuguy commented 7 years ago

djaeckle: On USE_BAND_470, I recover the LoRaMacParamsDefaults.ChannelsMask[] to 0xFFFF this morning , Same as before. After the 8 uplinks, node is running, fCnt ++. log data from base station as below:

"txInfo":{"frequency":471500000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":0, "fPort":2,"data":"yw=="}

"txInfo":{"frequency":472100000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":0, "fPort":2,"data":"yw=="}

"txInfo":{"frequency":472700000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":0, "fPort":2,"data":"yw=="}

"txInfo":{"frequency":472700000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":0,"fPort":2,"data":"yw=="}

"txInfo":{"frequency":471700000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":0,"fPort":2,"data":"yw=="}

"txInfo":{"frequency":472900000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":0,"fPort":2,"data":"yw=="}

"txInfo":{"frequency":472100000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":0,"fPort":2,"data":"yw=="}

"txInfo":{"frequency":471900000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":0,"fPort":2,"data":"yw=="}

"txInfo":{"frequency":472300000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":1,"fPort":2,"data":"yw=="}

"txInfo":{"frequency":471700000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":1,"fPort":2,"data":"yw=="}

BR/Artuguy

djaeckle commented 7 years ago

Thanks for the input. Based on your log information, the node works correctly - it starts the repetitions since it don't receives an ACK and increases the fCnt after 8 frames.

To get a bigger picture of your issue, I would like to request some more information from you:

  1. Could you please provide some more details on your implementation? Did you change the implementation of some drivers? If so, which ones?
  2. What I don't understand is that the MAC doesn't provide the McpsConfirm primitive in case of confirmed uplinks. Especially, when it is working properly according to your log. If the node has not received an ACK to a confirmed uplink, the MAC should still call the McpsConfirm primitive providing a mcpsConfirm->Status unequal to LORAMAC_EVENT_INFO_STATUS_OK.
  3. Is the node able to receive other downlinks or is this issue related to an ACK only?
  4. Have you verified that your 1st and 2nd window timing is correct?
artuguy commented 7 years ago

djaeckle:

  1. I use LSI as RTC clock source instead of LSE. RTC config as below:

          #define N_PREDIV_S                11
          #define PREDIV_S                  ( ( 1 << N_PREDIV_S ) - 1 )
          #define PREDIV_A                  17               //( 1 << ( 15 - N_PREDIV_S ) ) - 1
          #define RTC_ALARM_TIME_BASE       (18000/37)       //( USEC_NUMBER >> N_PREDIV_S )
          #define CONV_NUMER                                18
          #define CONV_DENOM                                37
  2. MAC doesn't provide the McpsConfirm primitive, on USE_BAND_433, MAC can provide McpsConfirm primitive
  3. node has not yet receive other downlinks, because my AS did not send downlink data.
  4. Reguard 1st and 2nd window timing, I have not modified it. in gpio-board.c, I commented 257 line as below: void EXTI4_15_IRQHandler( void ) { // RtcRecoverMcuStatus( ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_4 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_5 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_6 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_7 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_8 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_9 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_10 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_11 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_12 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_13 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_14 ); HAL_GPIO_EXTI_IRQHandler( GPIO_PIN_15 ); }
artuguy commented 7 years ago

djaeckle: On Region_CN470, I find MAC provide a McpsConfirm after 8 times uplink. it seems like node has not recieved a ACK, base station should apply ACK with the same RF.

JSON up: {"rxpk":[{"tmst":1776882308,"chan":7,"rfch":0,"freq":472.100000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":5.2,"rssi":-28,"size":14,"data":"gAEQCBeADwACO/mvAIc="}]} INFO: [up] PUSH_ACK received in 1 ms INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"imme":false,"tmst":1777882308,"freq":472.1,"rfch":0,"powe":14,"modu":"LORA","datr":"SF12BW125","codr":"4/5","ipol":true,"size":12,"data":"YAEQCBcgUgWLx8hB"}} INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000) INFO: [down] PULL_ACK received in 0 ms

How do I adjust the recieve frequency to the correct one?

thanks

artuguy commented 7 years ago

djaeckle: Got it, change RegionCN470.h as below:

//#define CN470_FIRST_RX1_CHANNEL ( (uint32_t) 500300000 )

define CN470_FIRST_RX1_CHANNEL ( (uint32_t) 470300000 )

//#define CN470_LAST_RX1_CHANNEL ( (uint32_t) 509700000 )

define CN470_LAST_RX1_CHANNEL ( (uint32_t) 479700000 )

You can close this issue. Thanks BR/Artuguy

djaeckle commented 7 years ago

Hi artuguy,

nice to hear that it works now. Thanks for the feedback.