CC2540: CC2540 BLE-STACK, Master missing response packets from Slave

Hello,

Have you tried disabling power savings and increasing the sleep clock accuracy to see if there is a change in when the RX windows occurs? I would try both first.

Best wishes

Power Savings is disabled on both sides (Master and Slave)

Setting a weaker Clock accuracy had no impact on the Rx_Active window.

Do you know if this RF window is hard-coded, or if it does have some adjustable feature withing the binary (library)?

From the scope, ideally the Transmit from the master should be more centered to the timing of the Slaves Rx_Active.

And like wise, the Transmit from the Slave should be more centered to the timing of the Master Rx_Active.

End Solution should be a setting to center the RF Tx/Rx, or increase the Rx_Active at a power cost.

Here is a sniffer snapshot of the connection, to provide you more information.

Hello,

I don't have exact details on BLE 1.2.1 since we no longer maintain this SDK version. As a data point, can you load BLE 1.4.2.2 on your module and check for the same condition? This will let us know if the issue is corrected on a supported SDK version.

Best wishes

Do you have a smaller footprint of the HostTest in the BLE 1.4.2.2 (which mine is based on) will fit the 128K CC2540?

Unfortunately, no, not with central. It may fit with peripheral role on BLE 1.4.0.

Best wishes

1.4.0 HostTestApp Compiles down to 158,737Bytes (const & Code), which is a lot of purging, but I will give it a try based on my options.

But in following with my main issue, is there an addressable variable that can control the timing of the Rx_Active active? again, from empirical observations, the alignment between each devices Tx package to Rx Active is so skewed to the end of the process. If this is controllable, then I can win in two ways, First I don't miss any packages, and second, I can significantly reduce the average power during the RX_active stage. If I can shift the RX_active stage by 74us to the right for the Slave and like wise for the Master, problem solved.

One thing to take into consideration is that my interval is set to 10ms. I am guessing that the algorithms that sets the timing of the RX_active is based on this value, as well as clock accuracy. my belief is that the end results works well for large intervals, but falls short when dealing with small ones. At 10ms interval, we have a Rx wnidow of 200us, and at 100ms, we have a Rx window of 233us.

Now, I have setup the slave peripheral to 1.4.0 and still have the same issue, the Tx lands in the ending process of the Rx_Active. IF you can find a solution within the 1.4.0 to provide a shift, then it would be worth the time and effort to purge 1.4.0 for the Central.

If there is no addressable variable, might I suggest a simple solution of providing me a derivative of the 1.4.0 library which shifts the start of the Rx_active by +100usec, and I will let you know my overall power decrease and zero package loss.

Hello RIRO,

Short answer: there is no user control of the T_IFS window since this is controlled by the PHY during the connection event.

According to BT Core Specification Version 4.0 [Vol 6], Part A, Sec 4 AIR INTERFACE PROTOCOL:
"The time interval between two consecutive packets on the same channel index
is called the Inter Frame Space. It is defined as the time from the end of the last
bit of the previous packet to the start of the first bit of the subsequent packet.
The Inter Frame Space is designated “T_IFS” and shall be 150 μs.
..
The average timing of packet transmission during a connection event is determined
using the active clock accuracy, with a drift less than or equal to ±50
ppm. All instantaneous timings shall not deviate more than 2 μs from the average
timing.
Note: This means that the start of a packet shall be transmitted 150±2 μs after
the end of the previous packet."

The active clock is driven by the 32 MHz crystal. This means if the slave starts its transmission such that the preamble is more than 152 μs after the master's packet, the master will close its RX an peg a missed event from the slave. It's not clear from the traces that you supply above whether the timing is being met by the master or slave as precise timing is not noted.

I agree that it's not worth pursuing a port of Host Test on the master side at this point. Can you run this same experiment on two TI development kits?

Best wishes

Here is a more detailed snapshot of the package timing at the interval.

First Snapshot is a proper communication, the second is where the Master missed the Slaves response package.

Setup information:  10ms Intervals

Observations:

1. if the Rx_Active phase based on T_IFS is 150uSec, the RX_Active wastes a lot of energy since it starts 208uSec before the start of the Master Transit Package. This in my opinion is something that can be address and reduce the overall power consumption of the system.

2. The measured T_IFS From when the Slave receives the Masters Package to when it sends is 176uSec.

3. As pointed out in (1.) the Master Rx Active Starts very early than it should, wasting power in the Rx Active stage.

4. On the package failure, the Master RX Active stage terminates after 200uSec and misses the the Slaves Transmit Package.

So my questions are:

A: how to I extend the Master Rx Active window? I tried setting the PPM to 500, but I am now questioning if I am doing it correctly.

B: Can we shift the Rx Active window over by 100uSec to save Rx Power, and bring the alignment of the Tx/Rx more centered and not skewed to the end.

Both A & B will provide a solution, but B would be best due to the direct power savings.

Timing.pdf

The RX Window by the Slave is based the sum of on 1) the Master's SCA that was specified during the connection request plus 2) the Slave's sleep clock accuracy which is specified to the stack at init time, and a margin of 16 us. This determines when the slave will activate its receiver to look for the start of the master's transmission (i.e., the preamble). The only way to shorten the RX window is to use sleep crystals on the master & slave that are as close to 0 ppm error as possible.

For the time between the end of the master's packet and the start of the slave's, this should be 150 us (T_IFS). I'm not sure why you show it drifting, either there is some measurement uncertainty or perhaps a crystal problem. Can you take a reference measurement on a TI EVM? Again, there is no user controllable setting for this as it's governed by the BT spec.

Best wishes

There is no clock issue, all other timing is correct relative to the two CC2540.
I don't see how me running out to buy a "TI" board will solve my issue since I have thousands of BLE112 out in the fields.
and if not mistaken, it has a 30 ppm. You seems to be running on guess work.

And from your response, I don't think you are reading my questions correctly form the start. I don't want to shorten the Rx Window, I want to move it away from the anchor point so it work properly. If this design on the Rx_Active timing is hardcoded, they you have a flaw in your binary that needs to be address. Why you would design a Rx Capture window to only be effecting in the last 10% of activity does not add up.

If you cannot help me or understand what I am asking, please pass me on to someone who can.

I have made a graphically clearer image of what we are looking for. See Yellow drawn in traces.

What is needed is a re-alignment of the Rx_Active stage of the connected intervals, relative to the anchorpoint.

By shifting the Rx Active stage 100uSec to the right, you get:

1. ~40% reduction in unused Rx_Active Power
2. Tx Transmission now landing in the middle of the Rx_Active Stage
3. Practically zero chance of missing a Tx package.

This appears to not affect the Core_V4.0 standard, since I could not see a clear statement which indicates that the Rx Active stage needs start where it does.

Again, it makes no sense to start it where it currently does, since we know that no Tx package is expected in that first have of the zone, relative to the anchor point.

So, can we build a new beta library(s) that allows us to shift the start of the RX_active stage to gain the benefits of points 1-3.

With my application, that does push the limits of the BLE due to overall thru-put, the accumulation of missed Tx Packages by the Rx Active window and normal RF interference is causing issues with my real-time application.

Timing2.pdf

Hello,

We are unable to provide custom libraries and the RX/TX parameters are based on calculations taking into account master and slave SCA values and timing parameters from the core spec. The window offsets are not "hard coded" and I think you are quite over-simplifying the LL scheduling process. Also note that if the previous packet was missed, the RX window will be further widened.

The request for a comparison on a TI EVM is required to demonstrate a suspected non-conformance since these kits use known layouts and crystals. The BLE112 module is not manufactured by TI. I'm not implying that it's at fault.

I suggest you move your setup to use BLE-Stack 1.4.0 at a minimum. There were adjustments to the CE timing calculations relative to BLE 1.2.1 which should reflect in better power consumption. I don't have an explanation as to why your capture shows the slave TX occurring more than 150uS after the master TX. I would need to see this on our EVM to provide a better understanding.

Best wishes

Hi, very interesting discussion.

Were you able to solve the issue? I am also very interested in the solution if so, I am are experiencing a lot of drops in connections and have debugged everything (hardware, firmware, used eval boards, etc.) up to the point that I am starting to think this is also a timing issue.

Thanks in advance!

Alejandro Veloz - are you using BLE 1.4.0 or later? I suggest opening a new thread to cover your issue - you can reference this post if needed.

In regards to the original problem and timing diagrams supplied by RRIO, after further investigation (I didn't give up), we have concluded that this behavior looks as what you would expect when you have a lost sync in the master (for instance due to interference). When sync is found, the RX time is extended to cover the whole packet, while when sync is not found, the receiver stops some time after sync would have been expected. If you look at the two plots, D9 in the second one goes low after D10 in the first one goes high. This means that the receiver was on long enough that it would have found sync if the sync word (access address) had been received without error.

The time between the high pulses in D8 and D5 is also as expected. The time from rising edge to rising edge is around 230 us. An empty BLE packet is 80 us (8 us preamble + 32 us access address + 16 us header + 24 us CRC), so this corresponds to T_IFS of 150 us. Keep in mind that the signal goes high after the access address, so the pulses are much shorter than the actual packet.

The timing in this case is not determined by the sleep clock accuracy (at least not for the master), since this is inside a connection interval. The timing in this case is done by the link layer engine. The RX_ACTIVE signal is a bit misleading for the master, as it goes high when transition has started, but the RX hardware is started a bit later. For the slave, the RX_ACTIVE signal also includes the synth calibration time, which has to happen before anything can be received. There is also some settling time in other parts of the receive chain. For the slave signal, the window widening also comes into account as previously mentioned, and increases when the previous connection event closed due to a missed event.

Also, as previously communicated, you are encouraged to migrate your application (both slave & master) to BLE 1.4.0 or later as there were improvements made to this release for RX window and handling of cases when the master actually missed the slave due to interference. If power consumption is critical to your products, then I recommend you explore moving your future designs to CC2640R2F.

Best wishes