WUR: BLE summary of useful features w.r.t. BLE

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.

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.

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.

This looks like a useful paper. Power Consumption Analysis of Bluetooth Low Energy, ZigBee

and this blog

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