OSTICKS and Timing question

[voodooatchi]

Hello,

I am currently trying to get the LMIC library to work with a SAMD21G18 and a RFM95W chip. I am using the Atmel Studio and so I wrote the necessary helper methods (SPI, micros, etc. ) myself. The communication with the chip and the interrupts works fine. The chip also sends the Join Request to the LoRa network (TheThingsNetwork), but it fails to receive the Join Accept from the Gateway. It is no reception problem, since the RSSI of the reception at the gateway is -60db. The problem seems to be in the timing of the library. And this is where I need some clarification how things work. The error is a "rxtimeout". That means, the radio chip does not receive the answer during the time window it is listening. And I do believe, that is because the systicks and speed of my chip do not work with the library.

My first question is about the "OSTICKS_PER_SEC" and following settings in the config file. All the timing calculations seem to depend on these settings. The config file documentation states the following : "LMIC requires ticks to be 15.5μs - 100 μs long". My SAMD21 is running with 24MHz and the Systick can only use the core clock. This means, my Systicks are only 0.04us long. Is this a problem? It seems that 24MHz is not such a high Frequency for a chip. Does LMIC not support this? Or is my understanding of this (hopefully) wrong?

Thank you all very much for your support! :-)

[terrillmoore]

I use the Adafruit Feather M0 LoRa board, which is a SAMD21G18 with an RFM95W.

OSTICKS_PER_SEC is an "abstract" LMIC concept, not related to any of the clocks the system uses; it is really an instruction to the HAL on how to convert whatever time source it has into units used by the LMIC. It is additionally an instruction to the LMIC, telling it what you've told the HAL. It is therefore not directly related to your sysclk value. There is a bunch of complicated stuff in the Hal that maps this onto the microseconds() API, which must return a correct value. microseconds() does not return a value that can be directly used; some complicated logic is used to generate the "most significant bits". All complicated by a desire to be portable.

However, there are some funny problems with the normal BSPs, having to do with interrupt enable and disable. Since MCCI uses the SAMD21G18, you can probably download our BSP, select the "Catena 4420" variant, and build. If that fixes your timing problem, we may have found the problem.

The other thing to cosider is what you're doing in your app. The LMIC runs sort of in the background while your app is running. Since there's no multi-tasking on the Arduino, you have to give it some CPU time periodically by calling os_runloop_once() or similar. This is particularly critical during the downlink windows. If the LMIC doesn't have control of the CPU when the window arrives, you'll miss the window and not hear the downlink.

There's also the possibility of clock error. Not likely on a SAMD21, but I see that on the Murata module when running at 2MHz - the clock just drifts badly with temperature changes, and if things end up slow, you'll miss the window. There's an API for dealing with this; what it means in practice is that the LMIC will open the receive window much earlier. Arguably, we should have an option that causes the LMIC to open the receive window right away after an uplink, and keep it open continually until it concludes that a downlink isn't coming. Many use cases of the LMIC are not battery powered; the current design is really a system power optimization. In practice, the power from having the rx window open is so much less than the TX power that this would have a second-order impact on battery life.

But that's not how it works now!

[voodooatchi]

Hi Terry,

thank you very much for your prompt reply and explanations. I do very much appreciate it!

So for the OSTICKS_PER_SEC part I understand not to temper with the settings, they do not depend on my clock settings or micros() implementation. Good.
As to the implementation of hal_ticks() and my version of micros(). I disabled the implementation of the hal_ticks() method and activated the immediate return micros(); statement. I did this because I read the description in the documentation and thought, the method exists, because the default micros() method does not deliver correct values or overflows very quickly. I have a version of micros(), that works very good and delivers correct values up to the full size of the 32bit integer it returns. However from what you explained, that is not the whole truth. The method is required no matter how well my micros() method works?

Could there be a problem with how my micros() method works? The initialization of the systick is done like this:

void SystickInit(uint8_t ticks){
  if (ticks > SysTick_LOAD_RELOAD_Msk)  return (1);            		/* Reload value impossible */
  SysTick->LOAD  = 24000-1; 						//1000 us per tick
  NVIC_SetPriority (SysTick_IRQn, (1<<__NVIC_PRIO_BITS) - 1);  		/* set Priority for Systick Interrupt */
  SysTick->VAL   = 0;                                          		/* Load the SysTick Counter Value */
  SysTick->CTRL  = SysTick_CTRL_CLKSOURCE_Msk |
  SysTick_CTRL_TICKINT_Msk   |
  SysTick_CTRL_ENABLE_Msk;                    				/* Enable SysTick IRQ and SysTick Timer */
  return (0);
}

and my micros() method looks like this:

// Interrupt-compatible version of micros
// Theory: repeatedly take readings of SysTick counter, millis counter and SysTick interrupt pending flag.
// When it appears that millis counter and pending is stable and SysTick hasn't rolled over, use these
// values to calculate micros. If there is a pending SysTick, add one to the millis counter in the calculation.
uint32_t micros( void )
{
	uint32_t ticks, ticks2;
	uint32_t pend, pend2;
	uint32_t count, count2;

	ticks2  = SysTick->VAL;
	pend2   = !!(SCB->ICSR & SCB_ICSR_PENDSTSET_Msk)  ;
	count2  = _ulTickCount ;

	do
	{
		ticks=ticks2;
		pend=pend2;
		count=count2;
		ticks2  = SysTick->VAL;
		pend2   = !!(SCB->ICSR & SCB_ICSR_PENDSTSET_Msk)  ;
		count2  = _ulTickCount ;
	} while ((pend != pend2) || (count != count2) || (ticks < ticks2));

	return ((count+pend) * 1000) + (((SysTick->LOAD  - ticks)*(1048576/(VARIANT_MCK/1000000)))>>20) ;
	// this is an optimization to turn a runtime division into two compile-time divisions and
	// a runtime multiplication and shift, saving a few cycles
}

The methods are derived from the default arduino ones and slightly changed to fit into my architecture. I do believe, I tested these methods well, but maybe there is a flaw here. Is there any more documentation about what LMIC expects from the micros() method and how the systick should be configured?

Regarding the Catena BSP, that is not really an option, since I am using the Atmel studio and the BSPs you are talking about are for the Arduino IDE I assume? But I will look into the IRQ enable disable methods.

Regarding CPU time for the LMIC, that should not be a problem, at least not right now. All I do in my main method is:

while (true) {
		os_runloop_once();
}

Regarding clock error, I remember, I had to set this up for my Feather32u4 and possibly also for the M0 to make it work. I will also experiment with that. For now I will try to find out if my systick and micros() are working correctly and try to understand the hal_ticks(). But any input from your side regarding my remarks would be great!

Cheers,
Arne

[terrillmoore]

Simply: micros() ranges from 0 to 2^32-1 microseconds, but the LMIC clock ranges from 0 to 2^32-1 ticks (and one tick is 16 microseconds). If you use micros() directly, you will get an LMIC clock that ranges from 0 to 2^28-1 ticks and then wraps around. At that point things will malfunction badly. That's only 268 seconds, if I calculate correctly; this really needs to be fixed. This really is documented (in the README and the source code), but you have to read carefully and study the code. The way the code works right now is to notice the 2^28 overflow and increment a higher-order counter. It might be more robust to use millis() to adjust, but that's not what it does.

If you're replacing hal.cpp, you have to be very careful about interrupt enable and disable, and you need to study how the hal is handling time. Also look at the git history for changes to hal.cpp; you'll see reference to bug numbers that you should look at.

The Radio driver can't be reentered by a radio interrupt, but it also can't disable interrupts (because time typically runs from systick). So the HAL must defer radio interrupts while the background is in the radio driver; and the radio driver has to notice that deferred interrupts have occurred when giving up control of the radio. I may have done this portably, but I've not ported it anywhere yet, so some of this may be in the hal. The pattern is simple and common in kernel-level work, but if you've not seen it before, it may not be clear. I don't at the moment remember, and have no time to check, whether the HAL works this way, or simply schedules a callback to the LMIC from the run loop that processes the ISR. (I'm on deadline for something else and dare not open up the code for fear of losing hours.)

Look at the logging scheme in the compliance example sketch, and port that into your environment; that will give you timestamped events that print out while the LMIC is not busy, thus not affecting timing.

Good luck!

[voodooatchi]

Instructing me to look into the README did the trick. Thanks for pointing that out. It's one of the most complete READMEs I've seen so far! After studying it thoroughly I stumbled over the LMIC_ENABLE_arbitrary_clock_error. If it is not set, the LMIC_setClockError() doesn't do very much. So all my tests regarding clock error were in vain. Coming from the original (old) LMIC library, I didn't expect to have to turn this on explicitly.

After activating it, it started working instantly (at 2% clock error). Now I have to figure out, why there is a clock error of 2%. Do you think using the internal High Accuracy Internal Oscillator (OSC32K) of the SAMD21G18 and multiplying it to 24 MHz using the Digital Frequency Locked Loop (DFLL48M) could introduce an error of this size?