DECT-NR+ Scheduling Latency issues

[schnitzlein]

Hi

I am quite well familiar with DECT-NR+ and the Nordic Boards, as well as nrf91xx, we use a nrf9151.

Also some kind of involved at this opener initiative, but I cannot say here any more about this.

We using the latest (shared with us) mfw version at PHY and haveing our "own" MAC Implementation.

But my we going down to radio, so ignore the MAC.

My question is related according to TX - TX Latency, basically I have two different TX Operations and want them to schedule.

One Operation starts at Slot 16 and goes two Slots, so it ends at Slot 18.

2nd Operation starts at Slot 18 and my assumption was that when I schedule quite the same Operation and staying in the same mode (TX Operation, only)

than there is no delay in between.

But it looks lilke that at least the Latency for TX Transmission "idle_to_active" with 29030 ticks is needed to schedule another Operation within this time.

It feels odd and strange together, because why? is there any delay for TX - TX necessary? just for IPC communication and transfer data from nrf to Radio ? or?
And why is a whole slot needed ? the 29030 - 28800 = 230 which is a Slot plus 230 ticks. 

Is there a magic switch or function pointer I can use to have a schedule_tx_after_tx operation ? similiar question with schedule_rx_after_rx operation ? with delays

From AI answer: "If your two TX operations are logically one burst, consider whether they can be combined into a single longer TX operation rather than two separate scheduled ones."

good point, but the Receiver is different etc.

Kind regards

thanks

[Amanda Hsieh]

Hi, 

What NCS and MFW versions are you using?

schnitzlein said:

You can also address this question with from a company you might well know

Sorry, I cannot find the information regarding the name you mentioned. 

Regards,
Amanda H.

[schnitzlein]

All fine, they do internally somehow.

I am the just the tech guy, not in the management world.

ncs is: v3.2.4

mfw: mfw-nr+-phy_nrf91x1_2.0.0.zip

Regards,
Christoph

[Amanda Hsieh]

Our experts are on vacation. I will check with them and update the case when they are back. I am sorry about any inconvenience this might cause. 

[schnitzlein]

thanks for quick reply :) 


Sure it can wait,

next two weeks I am in vacation.


Hope to hear from you.

[Amanda Hsieh]

Currently each modem command is atomic thus modem goes after the operation to “idle/stand-by” state and next operation needs to get back “up” from idle state to “active” state. Fast, back-to-back tx-tx, rx-rx, tx-rx or rx-tx operations require some work from our side and new FW release.

The delays in state transitions is inherent to modem RF resources ramping down and ramping up for next transmission/reception. Currently the gap you have to have is approximately single slot. The exact value is reported in API. This value in microseconds you can convert to ticks by multiplying the duration with 69.12MHz clock.

Please also see the FW / NCS compatibility matrix.

[schnitzlein]

Thanks a lot for the answer! :) 

Most of this is we figured already out.
The we rely currently on the "scheduled_operation_transition"

Is this the correct delay to be used than or 

idle_to_active + <operation_startup_time + duration> + active_to_idle ?
It feels like that with low_latency mode we are already scheduling massive staying in ACTIVE  somekind of and only the <operation_startup_time + duration> + scheduled_operation_transition + <operation_time>  is necessary.

Can you put some light into this darkness for me? 

kind regards
Christoph

[Amanda Hsieh]

This is explained in the documentation DECT NR+ physical layer — nrfxlib 3.3.1 documentation, I hope well enough.

Thus, if you schedule operations the first operation you need to take the t_{standby_to_idle} and t_{idle_to_active} into account depending on radio mode. The second operation needs only t_{min_sched_opr_trans_dly} also noted as t_m in the figures.

The modem packet scheduler handles automatically whether it has time to go to IDLE or STANDBY between consecutively scheduled operations. If you have scheduled multiple operations in advance.

If it goes to IDLE or STANDBY then the next operation always pays the t_{standby_to_idle} and t_{idle_to_active} delays.

So if the modem knows what is going to happen after current radio command it is executing the delay between radio operations is < 1 slot. But if it does not know, or the command comes too late, i.e. modem is already transitioning to IDLE or to STANDBY, then you pay additional latency.

[schnitzlein]

Thanks!

I was in the intern meeting about this topic. :) 

Have a great day!

[BillyBobJoe]

I'm the author and am suspicious of people who need to remain anonymous using copyright and licensed code.

[schnitzlein]

Dont get me wrong @BiilyBobJoe or WilliamGFish, this Question has nothing todo with the github repo Opener Repo ... I used this as a reference here for compare in research topics.
It is related to the Nordic Radio specially for DECT-2020, Nr+ on a 91xx SoC.

There is also a opener initiative ongoing https://github.com/Opener-Initiative but this is open source initiave of many different stakeholders.

The MAC stack I or we are wrote and using is completly different from your code, completly invisible from public and closed source only. That is why I cannot simply use a link to our code pieces, but to those which is public in github as a reference.
Some parts are in discussion to open in public place, since we are on DECT-2020 NR+ Topic since the beginning, and we are in the meetings which are going on.

If you still find something suspicious write me an E-Mail and we could create an appointment with a meeting, mr. BillyBobJoe or WilliamGFish

kind regards.

[BillyBobJoe]

I am part of the Opener initiative and they are hosting a copy of my repo. I suggest you look at the very prominent README.md

[schnitzlein]

Okay, i did this month ago and checked it again now.
Thanks a lot for the clarification.
To make my point clear (maybe it is because I am not a native English speaker), sorry for mentioning your open public GitHub repository to explain my research situation.

I am sorry that this post might upset you, I removed the link to your public github repository source code.

I used it just as a reference, because our code is hidden, and not public and I am not allowed to share any insights of this.

And only this one line of calculation i just take out for a point to create a picture for the situation in this topic, but I guess now it is clear for everyone, right?

There is a lot of research, knowlegde created and done by us, but I am also not allowed to share this. And yes we are also in the Opener initiative, last week was a meeting here in our company, maybe we meet already? :) 

I am giving you my hand and say please apologies my post of your public internet code and the link to it here.

Have a great day.