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

[schnitzlein]

How far in advance (in ticks if possible) should we schedule new Operations to have TX after TX Operation with 2 Slots usage and directly after this the next TX Operation?
You can put this to private if you want, because it sounds not to be mentioned yet for the public and is mostly related with a scheduled access transmission.

[schnitzlein]

I am not allowed to mention the name here. We have the same questions related with being in ACTIVE Mode and schedule time in for cast.

[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

[schnitzlein]

Hello again,

to add more insights:
With the idle_to_active and other timings is the question how should it be calculated.

Sorry to hide my Codebase but it is highly confidential, internal and have a copyright and I am not allowed to share the codebase.

There exist some public codebases but they dont allow sharing there codebase as well.

Anyway

We achive something similiar but this is somekind of waste of a slot or a blind-slot for each op, right?

I want to stay in Radio ACTIVE for some Slots, is that possible? With different TX Ops ? or RX Ops

Scenario (with sycnd devices)

Assuming I have a stream of data, which should be addressed scheduled to others. One device will schedule different slots pre-allocated / scheduled.
But the delay is important here, it should be keep low as possible.

Radio is in low latency mode and the ops_transsion delay and other I am aware of.
But why that many delay?

Cant I just stay in ACTIVE State wait for new data or new data is arrived (assuming dma + acklowged isr), checking for next timeslot to schedule and use that data for that timeslot.

After the frame is over remove it, or keep in softbuffer if necessary, is that so?

I am basically searching for the lowest latency with high output of data I could achieve.

Just the idea in reducing the idle_to_active, active_to_idle delays just haveing a small operation_transistion delay or wait_for_dma + IPC sth. ?

Thanks in advance
Have a great day :) 

bye