[Sergio Valiente]

Hello,
I have the same problem. I resolved it as you say, but two years after the device didn’t communicate. (downlink counter > 16bit I think). I remobed the xdot on the Conduit and create again, then… I have one year to fix it…
The 16bit transmited, I understand that they aren’t only the las 16bit of 32bit counter ¿correct?
Is there any possibility to read and reset the gateway counter to control that it don`t be major to 16bit? ¿Is there any other possibility?
thanks

[Sergio Valiente]

OK,thanks

[Sergio Valiente]

OK. I have a problem to reset the downlink counter. I can not detect this error in my program. In the example (dot_util.h). the menssage “MIC_FAIL” is not written. I only see the internal debug messages:

[TRACE] Check rollover of downlink counter 00020008
[WARNING] Not valid MIC Addr: 00000001 FCnt: 00000008

But I do not know how to detect them
Why not detect the error event MIC_FAIL in the Multitech example dot_util.h?:

public:
RadioEvent() {}

virtual ~RadioEvent() {}
char rx_string[128];
int i;
/*!
* MAC layer event callback prototype.
*
* \param [IN] flags Bit field indicating the MAC events occurred
* \param [IN] info Details about MAC events occurred
*/
virtual void MacEvent(LoRaMacEventFlags* flags, LoRaMacEventInfo* info) {

if (mts::MTSLog::getLogLevel() == mts::MTSLog::TRACE_LEVEL) {
std::string msg = “OK”;
switch (info->Status) {
case LORAMAC_EVENT_INFO_STATUS_ERROR:
msg = “ERROR”;
break;
case LORAMAC_EVENT_INFO_STATUS_TX_TIMEOUT:
msg = “TX_TIMEOUT”;
break;
case LORAMAC_EVENT_INFO_STATUS_RX_TIMEOUT:
msg = “RX_TIMEOUT”;
break;
case LORAMAC_EVENT_INFO_STATUS_RX_ERROR:
msg = “RX_ERROR”;
break;
case LORAMAC_EVENT_INFO_STATUS_JOIN_FAIL:
msg = “JOIN_FAIL”;
break;
case LORAMAC_EVENT_INFO_STATUS_DOWNLINK_FAIL:
msg = “DOWNLINK_FAIL”;
break;
case LORAMAC_EVENT_INFO_STATUS_ADDRESS_FAIL:
msg = “ADDRESS_FAIL”;
break;
case LORAMAC_EVENT_INFO_STATUS_MIC_FAIL:
msg = “MIC_FAIL”;
break;
default:
break;
}
logTrace(“Event: %s”, msg.c_str());

logTrace(“Flags Tx: %d Rx: %d RxData: %d RxSlot: %d LinkCheck: %d JoinAccept: %d”,
flags->Bits.Tx, flags->Bits.Rx, flags->Bits.RxData, flags->Bits.RxSlot, flags->Bits.LinkCheck, flags->Bits.JoinAccept);
logTrace(“Info: Status: %d ACK: %d Retries: %d TxDR: %d RxPort: %d RxSize: %d RSSI: %d SNR: %d Energy: %d Margin: %d Gateways: %d”,
info->Status, info->TxAckReceived, info->TxNbRetries, info->TxDatarate, info->RxPort, info->RxBufferSize,
info->RxRssi, info->RxSnr, info->Energy, info->DemodMargin, info->NbGateways);
}
….

[Sergio Valiente]

Hi Jason,
Is this not a good practice for safety or for other reasons?
Thanks

[Sergio Valiente]

Ok, thank you
regards

[Sergio Valiente]

Hello,
I had this problem. It was resolved. thanks

But now, I have similar problem if the conduit power off, and the mdot is on.
when the conduit power up, I send a packet to the mdot from the conduit but the mdot trace shows:

[TRACE] Check downlink counter rollover 00020008
[WARNING] Invalid MIC Addr: 00000001 FCnt: 00000008

the packets from the mdot to de conduit are received withon problems.
if I reset the mdot all go well.
have I to disable some check in the mdot too?
thanks

[Sergio Valiente]

Ok! thanks

[Sergio Valiente]

Hello Mike,
So I can’t use the USB with mbed platform? How do I should program this interface?
If I use mbed online compiler, only can I use pin 8 and 9 like GPIOs?
thanks

[Author]

Posts