CC1312R: RE: Sensor send message algorithm

Hi,

Apologize for the delayed response. Thanks for the data plot. I have set up a similar network and will look into recreating the problem to get a better understanding. I will try and provide an answer early next week.

Regards,

Marvin

Hi,

There is a mistake in description. Both tests were conducted with BO = 10.

Regards,

Lukas

Hi Lukas,

Which sniffer firmware did you use?

Regards,

Marvin

Hi Marvin,

I used the firmware from cc1312lp folder, inside SmartRF Packet Sniffer 2 directory.

Regards,

Lukas

Hi again Lucas,

I am having trouble being able to read viable data with the sniffer when I specifically use the 200kbps GFSK 868Mhz configuration. Could I ask you what type of version of smart RF sniffer you are using and which PHY you have specified in the sniffer settings?

Regards,

Marvin 

Hi Marvin,

I used SmartRF Packet Sniffer 2, version: 1.10.0. As this version does not have predefined PHY settings for 200kbps GFSK 868MHz, I did this ->

I selected 915MHz 200kbps GFSK PHY from predefined configurations and edited its the base frequency to be of 0 channel frequency from SysConfig tool ->

Regards,

Lukas

Hi Lukas,

Apologize again for the delayed response. You say that the sensor either does LBT and drops the message, or does not do LBT and retransmits 1-2 beacons later. This makes me think that when the sensor drops doing LBT it has no message to send. I did some tests and saw that the sensors only do LBT when there is data to send. The only time it drops doing LBT is when there is no data to send. The first test involved only having one of the sensors send data and the other test involved both sensors sending data. 

Both sensors sending data:

One sensor sending data:

As can be seen in the first test, both sensors are doing LBT and only one is sending data. On the second test the second sensor does not do LBT, because it has no data to send.

Here is the capture of both tests:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/156/Session-0.sal

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/156/Session-1.sal

Regards,

Marvin

Hi Marvin,

Could You please tell me, which SDK version did you use in those tests?

Regards,

Lukas

I am using 7.10.01.24

Regards,

Marvin

Hi Marvin,

Thank You for your insights.

I've updated the SDK on my application to 7.10.01.24 and the problem is still there. As for your comment -

Marvin Ademi said:

This makes me think that when the sensor drops doing LBT it has no message to send

I did additional tests with updated SDK, modified our application to enable GPIO right before calling ApiMac_mcpsDataReq() in Sensor_sendMsg() and disable it right after.

In the following oscillograms, sensor 0x0002 events were captured.

CH1 - RX, CH2 - TX, CH3 - call to ApiMac_mcpsDataReq() (packed message transmission to the stack's TX queue).

Sniffer log -

1st case -

Sniffer log shows that sensor 0x0001 successfully sent the message to coordinator. Oscillogram shows, that sensor 0x0002 indeed sent formed message to the stack, but LBT was not performed.

2nd case -

Unwanted retransmission can be seen here. Stack decided somehow that it needs to send the message on this beacon, even though the packed request was received on the queue 1 beacon earlier. CH3 is low the whole time, so it proves that our application behaves as it should.

3rd case -

Oscillogram above shows expected behaviour. Sensor 0x0002 did LBT, channel was free so the message was sent.

4th case -

Oscillogram above shows expected behaviour. Similar case to 3rd, but according to sniffer, both sensors succeeded sending their messages, certainly because LBT was initiated at different times between them.

I've also managed to capture the case, when sensor 0x0002 actually does LBT and does not retransmit -

This case is expected behaviour. Stack should initiate LBT if it receives data sending request, and drop the message if channel is occupied at the time. It can be seen in the sniffer log, that sensor 0x0001 was sending the message at that time.

I've also added traces in the application to track responses from beaconNotifyIndCb(), calls to ApiMac_mcpsDataReq(), and the MAC_MCPS_DATA_CNF event status response from the stack -

Log shows that on every 4th beacon indication callback, sensor sends message to coordinator by calling ApiMac_mcpsDataReq(). On every single one of the occasions, ApiMac_mcpsDataReq() respond with 0 (ApiMac_status_success), therefore data is certainly sent to the stack successfully. If the stack even tries to do something with that popped message from the queue, MAC_MCPS_DATA_CNF event is raised, and dataCnf callback is called with status 0 (ApiMac_status_success) - that explains the dataCnf traces.

Unwanted retransmission can be seen in line 23, earlier line 19 shows that stack accepted the message, but for some unknown reason decided to transmit it 2 beacons later. If LBT had even tried to be performed there, MAC_MCPS_DATA_CNF event would had been raised with status 0xE1 (ApiMac_status_channelAccessFailure).

So the question regarding retransmission problem at ETSI regulation 200kbps bandwidth stands.

One additional question - it seems that stack's CSMA-CA algorithm does not go with the IEEE 802.15.4 standard. In the attached oscillograms in this comment and issue description, it can be seen that time interval is random before LBT is initiated, even though we have configured minimum backoff exponent to 0, and maximum backoff exponent to 1. Standard's specified CSMA-CA algorithm includes this formula for random time calculation before CCA stage -

In our case, it should be 2^0 - 1 = 0s. So what is the formula for random time calculation and how min/max backoff exponents influences this time?

Also, attaching all debug files for Your convenience.

Regards,

Lukas

new_sdk_tests.zip

Hi Lucas,

Could you try and change MAC_CFG_TX_DATA_MAX found in mac_cfg.c file from 2 to 1 and see if you get the same issues?

Regards,

Marvin

Hi Marvin,

Thank You for last suggestion. I can see that it's better, but retransmissions are still seen. Attaching sniffer log.

Regards,

Lukas

MAC_CFG_TX_DATA_MAX=1_2sensors.zip

Hi Lucas,

I see. Could you try and set dataReq.txOptions.noRetransmits to true in the sendMsg function in the sensor.c file, and then see if you get the same results.

Regards,

Marvin

Hi Marvin,

Unfortunately, I get the same results.

Regards,

Lukas

dataReq.txOptions.noRetransmits=true_2sensors.zip

Hi Lucas,

Back to the transmit queue then. I had hoped that setting MAC_CFG_TX_DATA_MAX to 1 would work, due to the possibility of the mac only deleting one of the messages in the transmit queue. Can you try and set  MAC_CFG_TX_MAX to 1 also. This is for all type of frames, not just data. For example ack frames.

Regards,

Marvin

Hi Marvin,

I get the same results. I don't think that this problem has much to do with TX queue length, as tests showed that the stack does not even try to do LBT - it must have something to do with the processes between receiving the message from the TX queue and stack deciding to do LBT.

Regards,

Lukas

MAC_CFG_TX_MAX=1_2sensors.zip

Hi Lucas,

I will discuss this with R&D and see what the issue could be.

Regards,

Marvin

Hi Marvin,

Could You give the status of this issue from R&D standpoint?

Regards,

Lukas

Hi Lucas,

Yes, I had a meeting with them this past friday. R&D was not quite sure either what the issue that caused this behavior was. However, we have some ideas that we would like to test. I will get back to you when I have some answers. Thanks for your patience.

Regards,

Marvin

Hi Marvin,

What's the status of this issue?

Regards,

Lukas

Hi Lucas,

Unfortunately, still no updates. We are quite limited on resources at the moment. Coming to a solution could therefore take some time. I will update if I have a found an answer.

Regards,

Marvin