confuses on TSCH use RADIO_DELAY_BEFORE_TX

[alexrayne]

Hallow! I`ve works with cc1350 launchpad now.

And breaks on use prefetching transmition by RADIO_DELAY_BEFORE_TX before tx_offset - this prefetching not corrects on receiving side. Receiver not takes to account, that sender starts transmition before tx_offset. Looks that it is rely on that radio realy starts transmit with some delay. And it is essential.

BUT for cc13/26 RADIO_DELAY_BEFORE_TX includes time for frame Sync - this is about 1ms on 50kbps/GPSK2. Since frame timestamps, evaluated by RFcore, are points to frame sync start, not after sync,

This sufficient time, affects tsch stack hadrly: Sender moves transmition point about 1ms before tx_offset, and receiver frame time follows it too. BUT receiver not compensates it!

More complex - it interferences with alternative tech for receving() - that rises after frameSync. It used by cc13 driver for TSCH_MAC.

What i do wrong? a) Is it a bug on RADIO_DELAY_BEFORE_TX - it should not include Sync len? b) Is it a bug of RF prop driver - it is should compensate Sync time, so that SFD time points to actual frame start? c) Is a bug of TSCH stack - it should compensate RADIO_DELAY_BEFORE_TX in receiver?

I prefer solution a) - since it is more adecvate to macro name

[alexrayne]

SWCU117I notes that

The timestamp is captured when SFD is found, but is adjusted to reflect the start of the frame (assuming 8 preamble bytes as per the standard), defined so that it corresponds to the time of the start trigger used on the transmit side. The adjustment is defined in the syncTimeAdjust firmware-defined parameter, and may be overridden.

so, looks a) - is right

[atiselsts]

The IEEE 802.15.4 standard does not go into details about things such as SFD and preambles. When choosing the behavior for TSCH implementation the goals are (1) interoperability (2) consistency.

That said, it would be good to have some interop tests with the TSCH sub-GHz mode. I'm not aware of any being done.

BUT receiver not compensates it!

This is incorrect, the RAT timestamp offset is corrected for approximately the PHY header size. The exact value is slightly different as the CC1310 has some additional offset on top of that offset. It may be different still on CC1350, as the implementation has not been tested with that chip.

SWCU117I notes that

syncTimeAdjust could be something to play with in order to avoid having the RAT timestamp offset added in software.

That said, the quote that you provide incorrectly talk about 8 byte preamble, but the IEEE 802.15.4 standard is clear that there are 4 bytes (8 symbols). The quote is also about the IEEE mode, while the 50 kbps rate is in the prop mode, so its not directly relevant to your question.

[alexrayne]

This is incorrect, the RAT timestamp offset is corrected for approximately the PHY header size

that was sayd about TSCH stack code - tx_slot have take it (RADIO_DELAY_BEFORE_TX) into account to prefetch transmition time, but rx_slot does not mention about it. Timestamp from rfcore takes without any compensation, and provdes to drift estimator as is.

the exact value is slightly different as the CC1310 has some additional offset on top of that offset. It may be different still on CC1350, as the implementation has not been tested with that chip.

Can you exlain more about this "additional offset"? i found that curent implementation not work at my launchpad. reason - big RADIO_DELAY_BEFORE_TX. such a big offset (1ms) cant be hiden into RX guard window. Old stack rely on that transmition start comes exactly at point that SFDtimestamp. This is was right for cc1310, and it is valid for cc1350 now - as i see by drift evaluation. It can adjusts to zero-drift. If there would be some significant radiodelay - drift compensation see it, and starts ringing aroud it, or consequence to some constant value. But i see that it can comes to zero.

you provide incorrectly talk about 8 byte preamble

documentation on cc26/13 say about it verypoor. Even cc13/26ware have no mention about syncTimeAdjust (only for ble).

So i prefer interprete this quote - that cc13 rf core evaluates timestamp to exact radio transmition request start for every modes of radio. Suppose that it even compensates delay for run request to transmition start.

[alexrayne]

here tsch_stack_prefetching_and_late_detect_patches i prepare some changeset - reworks technik for frame receive sensing at rx_slot, and some other improvements.

Can you inspect it? may be go wrong way?

[alexrayne]

Possibly i'm wrong about drift-compensator - it could manage transmition delay, on regular transmitions. i look for it's correction at monday

[alexrayne]

i measured RADIO_DELAY_BEFORE_TX on my launchpad cc1350 today - it's about 125-150us. with this value drift error on close rx-tx slots evaluates as 0.

[atiselsts]

1) How did you measure it? 2) Sending a single byte in the 50 kbps mode is 160 microseconds. There is no way the full PHY header (preamble + sync word) can be transmitted in this time. Are you sure you're not using the 250 kbps mode?

[alexrayne]

1) i adjusts RADIO_DELAY_BEFORE_TX , and look in tsch logs about drift compensation evaluated for sequences of close tx-rx, and rx-tx between node and boarder-router. first slot makes drift correction, and second one shows only error provided by radio-delay. with 125us (4 RT ticks) second transmition frequently shows 0 error.

2) imho, you mistakes about nature of RADIO_DELAY_BEFORE_TX - cc1350 evaluates it's timestamps right at PHY header start. at least for prop mode of cc1310/50.

autor of this change - including PHYheader in RADIO_DELAY_BEFORE_TX, not mention for with patform/mode it was done. maybe it works for BLE?

[alexrayne]

looks that autor of mentioned above change spoted at issue #565