This is not a general review of BLE! I have collected the following facts in the context of trying to establish the practicality of our proposed WUR idea.
Some important facts about BLE Phy
BLE uses Gaussian frequency key shifting (FSK)
BLE uses 40 channels from 2402MHz, 2404… 2480MHz
If 2402MHz was the center frequency (CF) then ‘0’ would be CF-180kHz, and ‘1’ would be CF+180kHz
Maximum xmit power is +10dBm (10mW)
Receiver sensitivity must be better than -70dBm
Path loss is 40+25log(meters)
The longest packet possible lasts 376uS (Pmax)
Packets have a 37-byte payload and 10-bytes of decoration = 47B
Bytes are sent least-sig-bit first.
Whitening
FSK receivers are unable to receive very long sequences of bits of the same value because they assume that the center frequency of the transmitter has wandered off in the direction of the ‘0’ frequency. To protect against this a whitener function is used. The whitener is a pseudo-random sequence of bits that both sides of the connection know (it’s kinda like encryption). The whitener is XORed with the packet at sender and receiver. So the packet payload will always look like it contains white noise.
Broadcasting Modes
Nodes broadcast for two reasons: to say they are ready for a connection (advertising), to broadcast some data (like temperature). They can do both at the same time. Payload data has to conform to a protocol that enables anyone to understand it. e.g. It’s a temperature. The list of BLE-allowable data objects is large.
General advertising is for nodes that will accept a connection request from anyone. Direct advertising is for nodes who are prepared to be connected to by specific peers. They are required to advertise every 3.75 milliseconds. So a scanning device only has to listen for 3.75 ms.
Sending packets this fast clogs up the advertising channel, so it is only allowed to go on for a maximum of 1.28 seconds (341 packets).
So ordinary advertising is one way to generate a WUR signal to a node that’s asleep. The downside is that lots of devices may be trying to do this in their normal course of operations, so some level of packet analysis would be required to avoid waking up for all of them.
Connection modes
Master is the name given to the node initiating the connection. The node that broadcast its preparedness to accept a connection will become the slave. Counter intuitivity warning: Since the broadcaster started the ball rolling you would think it would be the master, but nay!
After a connection is established there is a mandatory 1.25ms delay before the first data packet is sent to allow batteries to recover after a possibly exhausting advertising procedure.
When in connection, the master is required to send a packet at regular intervals on the same frequency or the slave considers the connection is terminated after N traffic-free periods. N is called the slave latency (SL). And there must be a 150us gap between packets.
The interval between connection packets called the connection interval (CI), can be as short as 7.5ms to 4s. (The internal clock has to be recalibrated every 4s!!) The maximum time a slave is prepared to wait for a packet, called the supervision timeout (ST), is 32s.
This seems complicated but the basic idea is that ST = CI*(SL+1) < 32s. So with a CI or 100ms and SL=9 then ST = 1 sec.
Put another way, the slave has to wake up and listen for a connection packet every 32 seconds. If CI = 100ms then SL has to be 319 or less.
FACTOID: The slave has to wake up every 32s to maintain a connection. It has to listen for a minimum of the CI interval = 7.5ms. But then the master has to transmit a packet every 7.5ms!
However BLE folks say giving the slave just one opportunity is a bad strategy (page 97). They recommend six attempts. So when CI=100ms & SL=9, the ST should be set to 6 seconds, rather than 1 second, giving the slave 6 opportunities, instead of just 1. So in the example above the ST should be 6 times larger – i.e. 6s. If the ST is 32, and you want 6 opportunities, then the CI is 32/6=5.3s which exceed the 4s max allowed.
A typical scenario for transmitting data on a button press is to have BLE connection with relatively low connection interval but with high slave latency. Low connection interval will enable your device to send packets frequently, i.e. to have a good response on a button press. High slave latency will allow your device to not send packets on every connection event, thereby saving current.
and this blog
Sleep Clock Accuracy
Having more accurate clocks would save power. The clock accuracy is used to determine the uncertainty window of the slave device at a connection event, when the clocks are re-synchronized.
A crystal that is 20ppm at room temp, might be 50ppm at 0C or 85C. The protocols have to assume the worst.
To be extreme, if master and slave have clocks that are 500ppm, then their total drift from one another could be 1000ppm. In a second, they could have drifted 1 millisecond apart. So the slave has to wake up 1 millisecond early, and stay on for an extra millisecond.
If the device is waking up at the maximum connection interval of 4s, then the extra “on” time could be 8ms.
- External crystal: Using an external 32.768 kHz crystal is the option that gives the lowest current consumption. If you have this on your board, you should use it. You have to choose the appropriate accuracy for your crystal, so that the softdevice can take the accuracy into consideration to know how much the clock may drift over a certain period. It will use this information to make sure it compensates correctly and wakes up the chip just when needed.
The Nordic code (nrh.sdm.h) contains these options for crystals. Presumably we could add our own to the list.
NB. The best is 20ppm.
enum NRF_CLOCK_LFCLKSRCS{ NRF_CLOCK_LFCLKSRC_SYNTH_250_PPM, /**< LFCLK Synthesized from HFCLK. */ NRF_CLOCK_LFCLKSRC_XTAL_500_PPM, /**< LFCLK crystal oscillator 500 PPM accuracy. */ NRF_CLOCK_LFCLKSRC_XTAL_250_PPM, /**< LFCLK crystal oscillator 250 PPM accuracy. */ NRF_CLOCK_LFCLKSRC_XTAL_150_PPM, /**< LFCLK crystal oscillator 150 PPM accuracy. */ NRF_CLOCK_LFCLKSRC_XTAL_100_PPM, /**< LFCLK crystal oscillator 100 PPM accuracy. */ NRF_CLOCK_LFCLKSRC_XTAL_75_PPM, /**< LFCLK crystal oscillator 75 PPM accuracy. */ NRF_CLOCK_LFCLKSRC_XTAL_50_PPM, /**< LFCLK crystal oscillator 50 PPM accuracy. */ NRF_CLOCK_LFCLKSRC_XTAL_30_PPM, /**< LFCLK crystal oscillator 30 PPM accuracy. */ NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, /**< LFCLK crystal oscillator 20 PPM accuracy. */ NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION, /**< LFCLK RC oscillator, 250ms calibration interval.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_500MS_CALIBRATION, /**< LFCLK RC oscillator, 500ms calibration interval.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_1000MS_CALIBRATION, /**< LFCLK RC oscillator, 1000ms calibration interval.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_2000MS_CALIBRATION, /**< LFCLK RC oscillator, 2000ms calibration interval.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_4000MS_CALIBRATION, /**< LFCLK RC oscillator, 4000ms calibration interval.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_8000MS_CALIBRATION, /**< LFCLK RC oscillator, 8000ms calibration interval.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_1000MS_CALIBRATION, /**< LFCLK RC oscillator. Temperature checked every 1000ms, if changed above a threshold, a calibration is done.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_2000MS_CALIBRATION, /**< LFCLK RC oscillator. Temperature checked every 2000ms, if changed above a threshold, a calibration is done.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_4000MS_CALIBRATION, /**< LFCLK RC oscillator. Temperature checked every 4000ms, if changed above a threshold, a calibration is done.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_8000MS_CALIBRATION, /**< LFCLK RC oscillator. Temperature checked every 8000ms, if changed above a threshold, a calibration is done.*/ NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_16000MS_CALIBRATION, /**< LFCLK RC oscillator. Temperature checked every 16000ms, if changed above a threshold, a calibration is done.*/};
Direct Test Mode
The following seems potentially useful in some way (possibly illegal) way.
There is this “Direct Test Mode” in which a transmitter can be asked to transmit packets repeatedly for a length of time determined by the test person.
For testing, whitening is turned off (which simplifies things for us). So the data will be exactly as we specify. Most packets used in real life are whitened to look like random white noise.
A test packet can be configured using the following parameters
- channel number
- payload length (0-37 bytes)
- byte pattern (9 bit pseduo randm bit seq / 0xF0 / 0xAA / 0x0F / 0x55 / 15bit PRBS
So even if the WUR could detect alternating patterns in a single packet’s payload, the packet decorations would not conform.
