cancel
Showing results for 
Search instead for 
Did you mean: 

I-CUBE-LRWAN V1.1.0 Why the -1 to Unsigned Cast?

ron239955_stm1_st
Associate II
Posted on May 18, 2017 at 22:10

In I-CUBE-LRWAN V1.1.0 RegionCommon.c there's a function that returns the next duty cycle delay as follows:

TimerTime_t RegionCommonUpdateBandTimeOff( bool dutyCycle, Band_t* bands, uint8_t nbBands )

{

   TimerTime_t nextTxDelay = ( TimerTime_t )( -1 );

   // Update bands Time OFF

   for( uint8_t i = 0; i < nbBands; i++ )

   {

      if( dutyCycle == true )

      {

         if( bands[i].TimeOff <= TimerGetElapsedTime( bands[i].LastTxDoneTime ) )

         {

            bands[i].TimeOff = 0;

         }

         if( bands[i].TimeOff != 0 )

         {   

            nextTxDelay = MIN( bands[i].TimeOff - TimerGetElapsedTime( bands[i].LastTxDoneTime ),

            nextTxDelay );

         }

      }

      else

      {

         nextTxDelay = 0;

         bands[i].TimeOff = 0;

      }

   }

      return nextTxDelay;

}

This compares the period between the last transmission for the band and now with the duty cycle timeoff period, returning the next transmission delay period to comply with the duty cycle.

TimerTime_t is a 32 bit unsigned integer

So the first line 

TimerTime_t nextTxDelay = ( TimerTime_t )( -1 );

casts a signed to an unsigned integer, effectively setting it to a very large number 0xFFFFFFFF i.e. a huge delay.

So my question is, is that intentional?  If so, for what purpose, how does it work?  I would like to understand this code better.

Many thanks in advance, Ron.

1 ACCEPTED SOLUTION

Accepted Solutions
Posted on May 21, 2017 at 03:57

Yes, so either there or in the original routine you should return 0 when the MIN() value is still 0xFFFFFFFF

Then the 100% duty case should schedule the transmission immediately.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

View solution in original post

8 REPLIES 8
Posted on May 18, 2017 at 22:38

Isn't it a way of indicating there are no usable entries in the table? Looks to be a purposeful setting of a maximal value (size agnostic)

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on May 18, 2017 at 23:01

Thanks Clive for responding so quickly.  Yes, I agree it doesn't look like a typo. What you suggest could make sense if the very large value was being conditionally checked downstream, which I haven't seen (in any case a horrible way to flag a table entry!).

Although I haven't been able to trace the behaviour right through properly, it looks like that value is being used to setup a transmission delay timer. When a 100% duty cycle is configured for band 0 (IN865 region, which has a single band), the MAC seems to get stuck forever in a transmission delayed state (16).

Posted on May 19, 2017 at 01:41

It's clearly constructed to allow for downstream code to catch the empty list, or no usable values, whether it does so is a whole other matter.

There's quite a lot of egregious code in I-CUBE-LRWAN, stuff that blocks, interrupt priorities backarseward, etc.

I'll browse this path later, I'm mainly building pingers and listeners at the moment, in the 902-928 MHz band.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on May 19, 2017 at 02:00

Hi Clive, thanks again. The stack is certainly convoluted to trace through.

The Aussie 915MHz band, regional code seems to work ok, pretty similar to the USA region and a lot less complex than EU868, which the IN865 region profile is based upon.  I was really hoping to use IN865 'out of the box', apart from some simple frequency changes to suit KotahiNet (kotahi.net) in New Zealand, which uses the 864 to 870 MHz ISM band (there's also a 915 MHz ISM band available, similar to Aus).  Typically though it doesn't seem to be panning out so easily! We've developed several LoRaWAN sensor monitoring end devices, with good success so far.  Do please let me know if you get a chance to work your way through more of the stack and find anything interesting. Cheers, Ron.

Posted on May 19, 2017 at 05:04

ScheduleTx() in LoRaMac.c needs to pick some default, it takes zero as 'now'. It needs to constrain the maximum by checking the (-1) value, and either pick some default delay or send immediately.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on May 20, 2017 at 08:07

Hi Clive.  So this is missing logic?  Currently in ScheduleTx there is no test for 0xFFFFFFFF (-1) then do something sensible, rather dutyCycleTimeOff is being set to 0xFFFFFFFF (as shown by a PRINTF %lu statement), so transmission is effectively delayed forever!  

Posted on May 21, 2017 at 03:57

Yes, so either there or in the original routine you should return 0 when the MIN() value is still 0xFFFFFFFF

Then the 100% duty case should schedule the transmission immediately.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on May 21, 2017 at 04:05

Right, so absence of that logic is effectively a bug.