CC1352P: CC1352P: ETSI polite spectrum access Toff_min time and TI 15.4 frequency hopping (revisited)

hkr

Part Number: CC1352P

Hello,

we got the following information in an earlier thread (e2e.ti.com/.../3641736). The scope was

ETSI EN 300 220-1, specifically the "Minimum Toff_min on the same Operating Frequency" which is defined to be 100 ms,
TI 15.4 stack from CC1352P SDK v3.20, running at Frequency Hopping ETSI LBT mode.

"When LBT is enabled, stack automatically delays transmission by 100 ms if it occurs on the same channel. Note, no delay is needed when the next transmission occurs on a different channel."

While figuring out other problems in our application, we managed to measure the transmissions of our 2 devices with good resolution in the time domain, so that we now could actually see single packet transmissions on a scope.

Devices involved:

Link partner #1, is a 15.4 coordinator, transmits a packet each 50 ms.
Link partner #2, is a 15.4 device, replies to each packet of the coordinator with a packet.

What is visible on the following scope screen shots:

Channel 2, green line: Signal strength at the frequency of one channel (out of 14 configured 15.4 ETSI channels). Signal of coordinator is not attenuated, signal of device is attenuated, so they can be distinguished here.
Channel 3, orange line: RX_TX signal of link partner #1 (coordinator). High = TX, Low = RX.

A scope screen shot from the ASYNC phase (that maybe gets you familiar with our measurements): Orange line shows 14 transmissions in one row. Green line shows good signal strength for last channel.

Following scope screen shots were recorded during "link up" phase in our application with regular packet transmissions.

The one above shows two consecutive transmissions on the observed channel, from same device; transmissions distance is 50 ms.

The one above shows the case that the same channel is chosen again (DH1CF sequence...clarified also in previous post) after a 100 ms dwell time interval, which results in 4 transmissions on our observed channel within 200 ms.
Also, as above, the case that 2 transmissions take place on our observed channel within 100 ms, is included two more times.

Now, this does not exactly meet our expectation. From the related thread, we had understood that the stack takes care of keeping 100 ms TX Off time demanded by regulations in ETSI LBT mode. Can you clarify this please? We could also imagine that there is some misunderstanding of the TX Off time on our side, so we hope you can shed some light on this for us.

Thanks and best regards,

hkr

over 3 years ago

0 Nikolaj_G over 3 years ago

TI__Expert 4425 points

Hi,

Is the Link partner #2 a sleepy or a non-sleepy device?

Thanks,
Nikolaj

0 hkr over 3 years ago in reply to Nikolaj_G

Intellectual 950 points

Both are non-sleepy devices.

Best regards, hkr

0 Nikolaj_G over 3 years ago in reply to hkr

TI__Expert 4425 points

Thanks for the reply.

Can you please share the contents of the ApiMac_mcpsDataReq_t struct (please expand the txOptions field) passed to the ApiMac_mcpsDataReq function for the regular packet transmissions?
If your code is based on the collector example from the SDK, then it should be `dataReq` in collector.c::sendMsg()

Thanks,
Nikolaj

0 hkr over 3 years ago in reply to Nikolaj_G

Intellectual 950 points

Hi, this is our code:

    ApiMac_mcpsDataReq_t dataReq;

    /* Fill the data request field */
    memset(&dataReq, 0, sizeof(ApiMac_mcpsDataReq_t));

    /* Switch to the long address */
    dataReq.dstAddr.addrMode = ApiMac_addrType_extended;
    memcpy(&dataReq.dstAddr.addr.extAddr, rf_ti154stack_deviceExtAddr,
           (APIMAC_SADDR_EXT_LEN));
    dataReq.srcAddrMode = ApiMac_addrType_extended;

    dataReq.dstPanId = CONFIG_PAN_ID;

    dataReq.txOptions.noRetransmits = true;
    dataReq.txOptions.ack = false;
    dataReq.txOptions.noConfirm = false; /* calls dataCnfCb() */
    dataReq.msdu.len = len;
    dataReq.msdu.p = pData;

    /* Send the message */
    ApiMac_mcpsDataReq(&dataReq);

Thanks,

hkr

0 Nikolaj_G over 3 years ago in reply to hkr

TI__Expert 4425 points

Hi hkr,

Thanks for your code. This helps me rule out a few possible causes for the issue you are seeing.

I will forward this to R&D.

Regards,
Nikolaj

0 Nikolaj_G over 3 years ago in reply to Nikolaj_G

TI__Expert 4425 points

Hi hkr,

It has been determined that this issue is due to a problem in the stack, and we plan to fix it in a future SDK release.

Thank you for notifying us about this issue!

Regards,
Nikolaj

0 hkr over 3 years ago in reply to Nikolaj_G

Intellectual 950 points

Hi Nikolaj,

thanks for your answer, though we did not expect such one! As far as we interpret it, this completely blocks all frequency hopping use in Europe??

As this is a quite urgent matter (not only) for us, we are very interested in the DATE when the updated SDK will be released?
Will there be a backport to SDK v3.20 available?

Regarding Europe mode, more generally, as we understand it currently (please correct me if I am wrong):

- TI 15.4 stack on the CC1352P uses the LBT/Listen Before Talk Mode for Europe

- The LBT mode (as compared to the CSMA/CA) does CCA/Clear Channel Access also for ASYNC messages

- The LBT mode's listen time is - according to ETSI LBT regulations - quite long, 5 milliseconds.

Since regulations EN 300 220-1, V3.1.1, dated 2017-02, the LBT mode is not required anymore, but instead a PSA/Polite Spectrum Access, which allows for a minimum CCA interval of 160 us (as opposed to 5 ms with LBT). Are there plans on your side to update the mode for Europe from LBT to PSA (which could possibly be fulfilled by CSMA/CA, with CCA for ASYNC messages, and Toff_min compliance)?

Thanks,
hkr

0 Nikolaj_G over 3 years ago in reply to hkr

TI__Expert 4425 points

Hi,

I understand your frustration, the problem with the TX off time was determined too late for a fix to be included in the next Q2 release. We are planning to have it fixed in the subsequent Q3 release.

Also, thanks for updating us on the new regulatory requirements, we will also take these into consideration, but we have not yet made any plans for if, how or when we will update the stack for these requirements.

I will contact you in a private message regarding actions we can take, to help you with you current issue.

Regards,
Nikolaj

Sub-1 GHz

Sub-1 GHz forum

CC1352P: CC1352P: ETSI polite spectrum access Toff_min time and TI 15.4 frequency hopping (revisited)