Skip to main content
Andrew Neil
Super User
July 5, 2021
Question

I-CUBE-LRWAN v2.0.0 with B-L072Z-LRWAN1 ?

  • July 5, 2021
  • 2 replies
  • 899 views

Can anyone either confirm or deny that the End_Node project from I-CUBE-LRWAN v2.0.0 works with the B-L072Z-LRWAN1 (with Murata Type-ABZ module) ?

https://www.st.com/en/evaluation-tools/b-l072z-lrwan1.html

And any tutorials on getting it talking with The Things Network (TTN) ?

(tutorials I've seen previously were for v1.3.1 - and v2.0.0 looks rather different).

This topic has been closed for replies.

2 replies

Andrew Neil
Super User
July 6, 2021

Well, not a good start: building straight "out-of-the-box" - 57 Warnings:

0693W00000BcvXIQAZ.png 

Which would seem to summarise as 3 real issues, repeated:

0693W00000BcvfzQAB.png 

ADDENDUM

Sure enough, the REGION_EU868 and X_NUCLEO_IKS01A2 options are defined both in the Project setting and in source files:

0693W00000BcvuGQAR.png

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Andrew Neil
Super User
July 6, 2021

The warning that 'fBuffer' may be used uninitialized seems to be from GCC inlining 'static' functions - as the warning is reported in PrepareFrame(), but the definition of fBuffer is in LoRaMacMcpsRequest()

PrepareFrame() is called by Send() which is called from LoRaMacMcpsRequest():

LoRaMacStatus_t LoRaMacMcpsRequest( McpsReq_t* mcpsRequest, bool allowDelayedTx )
{
 GetPhyParams_t getPhy;
 PhyParam_t phyParam;
 LoRaMacStatus_t status = LORAMAC_STATUS_SERVICE_UNKNOWN;
 LoRaMacHeader_t macHdr;
 VerifyParams_t verify;
 uint8_t fPort = 0;
 void* fBuffer; // <=== *** Defined here
 uint16_t fBufferSize;
 int8_t datarate = DR_0;
 bool readyToSend = false;
 
 if( mcpsRequest == NULL )
 {
 return LORAMAC_STATUS_PARAMETER_INVALID;
 }
 if( LoRaMacIsBusy( ) == true )
 {
 return LORAMAC_STATUS_BUSY;
 }
 
 macHdr.Value = 0;
 memset1( ( uint8_t* ) &MacCtx.McpsConfirm, 0, sizeof( MacCtx.McpsConfirm ) );
 MacCtx.McpsConfirm.Status = LORAMAC_EVENT_INFO_STATUS_ERROR;
 
 // AckTimeoutRetriesCounter must be reset every time a new request (unconfirmed or confirmed) is performed.
 MacCtx.AckTimeoutRetriesCounter = 1;
 
 switch( mcpsRequest->Type )
 {
 case MCPS_UNCONFIRMED:
 {
 readyToSend = true;
 MacCtx.AckTimeoutRetries = 1;
 
 macHdr.Bits.MType = FRAME_TYPE_DATA_UNCONFIRMED_UP;
 fPort = mcpsRequest->Req.Unconfirmed.fPort;
 fBuffer = mcpsRequest->Req.Unconfirmed.fBuffer;
 fBufferSize = mcpsRequest->Req.Unconfirmed.fBufferSize;
 datarate = mcpsRequest->Req.Unconfirmed.Datarate;
 break;
 }
 case MCPS_CONFIRMED:
 {
 readyToSend = true;
 MacCtx.AckTimeoutRetries = MIN( mcpsRequest->Req.Confirmed.NbTrials, MAX_ACK_RETRIES );
 
 macHdr.Bits.MType = FRAME_TYPE_DATA_CONFIRMED_UP;
 fPort = mcpsRequest->Req.Confirmed.fPort;
 fBuffer = mcpsRequest->Req.Confirmed.fBuffer;
 fBufferSize = mcpsRequest->Req.Confirmed.fBufferSize;
 datarate = mcpsRequest->Req.Confirmed.Datarate;
 break;
 }
 case MCPS_PROPRIETARY:
 {
 readyToSend = true;
 MacCtx.AckTimeoutRetries = 1;
 
 macHdr.Bits.MType = FRAME_TYPE_PROPRIETARY;
 fBuffer = mcpsRequest->Req.Proprietary.fBuffer;
 fBufferSize = mcpsRequest->Req.Proprietary.fBufferSize;
 datarate = mcpsRequest->Req.Proprietary.Datarate;
 break;
 }
 default: // <=== *** this potentially leaves fBuffer uninitialised
 break;
 }
 
 // Get the minimum possible datarate
 getPhy.Attribute = PHY_MIN_TX_DR;
 getPhy.UplinkDwellTime = MacCtx.NvmCtx->MacParams.UplinkDwellTime;
 phyParam = RegionGetPhyParam( MacCtx.NvmCtx->Region, &getPhy );
 // Apply the minimum possible datarate.
 // Some regions have limitations for the minimum datarate.
 datarate = MAX( datarate, ( int8_t )phyParam.Value );
 
 if( readyToSend == true )
 {
 if( MacCtx.NvmCtx->AdrCtrlOn == false )
 {
 verify.DatarateParams.Datarate = datarate;
 verify.DatarateParams.UplinkDwellTime = MacCtx.NvmCtx->MacParams.UplinkDwellTime;
 
 if( RegionVerify( MacCtx.NvmCtx->Region, &verify, PHY_TX_DR ) == true )
 {
 MacCtx.NvmCtx->MacParams.ChannelsDatarate = verify.DatarateParams.Datarate;
 }
 else
 {
 return LORAMAC_STATUS_PARAMETER_INVALID;
 }
 }
 
 status = Send( &macHdr, fPort, fBuffer, fBufferSize, allowDelayedTx ); // <=== *** used here

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Andrew Neil
Super User
July 22, 2021

"Can anyone either confirm or deny that the End_Node project from I-CUBE-LRWAN v2.0.0 works"

currently unproven - due to lack of support on how to get it to work with the new TTN v3 ("The Things Stack")

It does seem to communicate with the gateway, but then the routing in TTN doesn't work.

https://community.st.com/s/question/0D53W00000wVhzTSAS/icubelrwan-the-things-stack-v3-replaces-the-things-network-v2

However, it is proven that the AT_Master project for I-NUCLEO-LRWAN1 + NUCLEO-L073RZ from I-CUBE-LRWAN v2.0.0 does not work:

https://community.st.com/s/question/0D53W00000uXu3ASAS/i-nucleo-lrwan-problem

https://community.st.com/s/question/0D53W00000vP1XtSAK/icubelrwan-v200-with-nucleol073rz-board-and-inucleolrwan1-shield

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.