According to my dubious expectations the major current drain is going to be the WUP radio which has to listen, or duty-cycle listen, continuously and thus consumes most of the energy.

I read through the Datasheet.  One interesting bit I discovered is that it is possible to transmit raw bits.  This means that the exact contents of TX buffer are transmitted without preamble, frame sync pattern, FEC, CRC or anything.  Now this makes the TX times short, but it doesn’t really help much.

Also, all of these extra bits serve an important purpose in reliability, but if I just wanted to transmit a 32-bit WUP packet, then it ought to be possible.

  • In RX mode it consumes 2.4(sniff) – 3.2 mA(rx).  “typical” rather than worst case values.

So with the simplest protocol the listener would consume 3.2mA @ 3.6V = 8.64mW.

For reference a CR2032 can produce a constant 55mW and has a capactity of 240mAh.  With a nice constant drain rate of 2.9V at 0.19mA it would last for about 800 hours = ~1 month.
But even ignoring the different voltages, buck-boost inefficiencies, smoothing capacitors etc., that seems to mean that the radio would have to duty-cycle listening at 3.2/0.19 = ~20
Duty-cycling is a mixed blessing because it simply moves the load from the listener to the transmitter.  e.g Duty cycling the listener at a ratio of 20:1 requires the transmitter to TX 20 times more often.
If the transmitter consumes more than the receiver (2.7 – 5.3mA) then the transmitter can’t use a CR2032.
This calculation assumes that the listener can sleep with approximately zero current drawer.
  1. In deep sleep with just a few essential registers retained the XL70550 consumes 10nA
  2. Crystal oscillator takes 1ms to start up and then it consumes 200µA

So what kinds of battery can produce a steady 8,64mW, last an eon, but occupy no space.


LiPo has an energy density of 250–730 WattHours/L. So worst case, the WUP would run for 250/0.00864 = 28935 hours, or ~1200 days, or ~40 months ,or ~3 years on a 1 liter LiPo.

Bottom Line

Doing the math the other way, to last a month the battery would have to be 1000/40 cc = 25cc 

which is ~3x3x3 cms!

—- David
A small battery powered tag that doesn’t need frequent charging and that listens constantly can’t be made using currently-available radios. It will need either to duty cycle or an ultra-low power wake-up radio has to emerge. So your analysis is correct.

Maybe it’s time to talk to BlinkSight?
—- Mik
The alternative is to use a more chance-based discovery method.   Peers listen and/or transmit at random intervals around some mean.  The chance that A hears B = Pb receiving.  If B listens for 5s every 100s the probability that it is listening when A transmits is 5%.  On average A will have to randomly 20 times at ~5s intervals, so the average latency is 100s.
The alternative is to rely on always-on base-stations, that have access to more power and can stay on all the time.
On Sat, Jun 4, 2016 at 7:30 AM, David Carkeek <> wrote:

We talked about this but I forgot the conclusion. Is the next board going to be a TS07?

– Decawave module
– nRF52 module from RayTac
– Microsemi ZL70550
– Maybe an IMU footprint. Could be Invensense, ST or Bosch 
– Maybe a barometer footprint, probably Bosch
– Expansion port
– No memory card socket
– JTAG connector
– New power supply

I made a TS07 design directory in Google Drive but it is under the TS06 shared directory. That doesn’t make much sense unless it’s going to be called TS06.4. Should there be a new TS07 shared directory?

Yup.  “TS07” (codenamed “Pining” <for the fjords?>) seems right,  This will be TS07.1 aka “Pining.1”

You already had access to the directory above Touchstone, but I created the new directory TS07, and moved your new stuff into it.

You might want to bookmark the root Touchstone directory so you can get to all the antique stuff?
I think your list is good.  Some thoughts…
  1. We need to think about the IMU choice.  I hear the Bosch IMU is functionally rather good, but perhaps it sucks power.  What do you think?  
  2. Barom and IMU are a single decision.  Both or neither.
  3. PSU – Provisions for this BOVLB to measure power consumption with onboard/offboard instruments
  4. JTAG – great if easy to plug in and remove.
  5. Arduino compatible expansion port – makes experiments with off-the-shelf boards an option
  6. If there sufficient pins to have DW on SPI0, and IMU, etc on SPI1, and still pins for I2C… great.
  7. Spare pins get: LEDs, buttons (that are easy to press!).  Reset button – minimal value
  8. UART – I am living without (using SEGGER), but if, and only if, we are using USB to charge, may as well hook it up if pins avail.


    Using the SEGGER for trace output is a bit inconvenient because it keeps hanging up, and it uses a lot of buffer space.  So I’m in greater favor of putting a FTDI serial to USB chip on – at least for the next rev.

    Nothing from MS again.  
    I looked at the schematic for the ZL70550 and it looked like it required a lot of extra parts that had to be placed just right.  
    I assume that the ZL70550 has a lot of overlap with the ZL70251 which they seem less paranoid about.  I looked at the programmer documentation and I have waves of Nanotron nausea sweeping over me.   The setup and calibration process goes on for 22(sic) pages. The chances that I can get the ‘550 to work using just the ‘251 documentation seems remote.  Indeed the chance that I can get the ‘251 to work without working firmware to which I can refer is even less.  Unless they provide documentation and sources, I think trying to mount these chips on our board is almost a waste of time.
    I can see that the eval kit would be quite valuable for debugging, but I don’t think you actually get sources with that either.
    The radio is such a bleeding prima donna to set up and use that MicroSemi are going to have a lot of trouble selling any until they make it shitload easier – like providing a module with a much simpler interface.
    So what to do?
    1. Make an nRF52 board anyway, and hope the ZL70550 software comes through
    2. Choose a different, less efficient WUP radio, and make a generic WUP API so it is easy to upgrade
    3. Continue using the 2 x Nordic nRF52 boards with wires jumpered to the TS06.2, and use BLE for WUP
    4. As (3) but make a TS shield for the Nordic nRF52 eval boards with DW etc
    5. Sleep


    On Wed, Jun 8, 2016 at 9:36 PM, Mik Lamming <> wrote:

    I should probably give them a few more days, and then bug Jean-Luc again.


    On Wed, Jun 8, 2016 at 7:44 PM, David Carkeek <> wrote:

    They probably feel like they can’t be bothered supporting a hobbyist who just going to ask for free parts and suck up resources. Therefore you’ll have to make yourself such a pest they’ll give you what you want just to make the whine go away. Do you want to introduce me to them so I can start being a pest?

    On Wed, Jun 8, 2016 at 8:35 AM, Mik Lamming <> wrote:

    It’s not looking good.


    ——– DAVID
    If one of the requirements for the next board is to accept a standard Arduino shield then it can’t be a “small” board, such as TS05/6. Therefore TS07.1 could have footprints for everything on it we are considering; each section can have jumpers for connecting to UART/SPI/I2C. So we can put on both the ZL70550 and ZL70251, plus all the IMU components, and the uSD card socket.

    Perhaps it’s not important to have the ZL70550 to validate the concept of using an ISM 800MHz radio. Maybe one of the TI solutions is worth looking at. Or what about the Nordic nRF905? After it is proven to be a win then the ZL70550 can be used to reduce power. Or is there something special about the ZL70550 implementation? 

    But it would suck to have to rewrite a bunch of code. On the other hand using a mature product will probably be easier so in the end the total effort might not be more.

    ——— MIK
    IMO accepting an Arduino shield isn’t a requirement – it’s more a possible short-cut to avoid having to layout a full board.   I keep suggesting it in the probably mistaken hope that it might be less work than doing a full board, PSU and all that stuff.
    I don’t think there is anything special about the MicroSemi chips other than their very low listen power.  Any 800MHz radio will have better range than the 2.4GHz BLE for the same power level if Friis is to be believed.  I don’t need any of the clever stuff – just the ability to send a peer address, and checksum.
    The nRF52 listen current is 5.5mA, but the packets are 256 bytes + preamble 
    The nRF905 is an 8085 chip (assembler progamming) darws 12.4mA in RX
    Using the ZL70550 offers 2.4mA, but the range may be better, and I can use very short packets.  But there is always a substantial preamble, and the packet length savings might not add much.  So I see the power win not being worse than 2x, and not better than 5x compared to BLE.  It certainly isn’t worth toughing it out to get the ZL chip working with no help from MicroSemi.
    I should just plow on and try to make the BLE version work well enough to figure out if it is a dead dog.  If it works then we can revisit an ISM radio.

    Last year David went to an expo where he won a free nRF52 eval board.  Some while afterwards he gave it to me.  On or about 12/7/15 I started playing with it, because I wrote a note about it.

    Recently I ran out of steam with the old software and nRF51 hardware.  So I have been trying to program the rRF52, and have been having some success.  But I have encountered a bunch of weird problems that have sucked me into the bog for a week.

    It has this funny situation where is appears to run out of RAM at about the 32K mark, but it has 64K. I have been poking around and talking to Nordic who were not much help so far – probably because the problems I describe are so weird.  I’m homing in on the “.ld” file (used to say where bits of the code get placed in memory during loading).

    I’m grasping at random ideas now.  I’ve just googled  “nrf52 .ld file” and hit this gem.

    @Kirkus: The nRF52 preview chip has some anomaly from the production that we are going to release. You can have a look at the errata here. Issue #33 and #34 are related to your question. There are still 64kB of RAM on the nRF52 preview version, but they are located at 2 locations, each has 32kB. Please follow the information in the errata to declare correct IRAM1 and IRAM2 block.

    … this was dated Jun 20th, 2015

    I think David got our freebie eval board around this time!

    I have no idea if this is the issue but a lot of the symptoms fit.

    I checked the chip markings, and we have a QFAABA chip. Even if this isn’t the issue,   I looked at the chip revision errata and it all post-dates Feb 17, 2016 – so I smell a ratty odour.

    I was caught by the nRF51 freebies, and now perhaps the nRF52 freebie. I kind of think that using freebies has to be treated with a lot more circumspection from now on.

    The lead time here on a replacement from
    DigiKey is 18 weeks
    Mouser 5 weeks
    Arrow “on order”

    Now it Istart to see why I am having so much trouble.

    So it seems like you might be able to address 64K or RAM but not necessarily in the order that you might assume 🙂


    Pls refer this to Håkon!

    I think all my arcane problems I reported above are now clear. I have a “preview” system, and most of the problems I am encountering, others have described too. I’d get new hardware, but delivery on the current rev. of the DK seems to be 5-16 weeks!

    For reference: I’m using GCC, Eclipse, nrf52 QFAABA1536AA silicon. nRF5_SDK_11.0.0_89a8197

    Håkon: Can you confirm that there is a working suite of “.ld” scripts for the nRF52 example ble_app_hrs_rscs_relay/pca10036, or could you consolidate the advice at the following post into one less confusing set of instructions please. The currently posted “.ld” script only specifies 32K RAM.


    Hi Michael,
    I can confirm that the initial RAM calculation has a bug, and it is the second one reported back that shall be applied:
    sd_ble_enable: app_ram_base should be adjusted to 0xsomevalue
    The bug lies in macro softdevice_handler.h::CHECK_RAM_START_ADDR_INTERN:
    This one is hard to read, I know.
    It shall match a corresponding macro in app_ram_base.h, in your case it will incorrectly match:
    However; the macro does not consider the security (crypto) being used in your peripheral link.
    For the ble_app_hrs_rscs_relay it shall point to:
    I’ll of course report this bug internally!
    I appreciate the time and effort you’ve also put into catching this bug and helping us continuously improving our delivery.
    As an official thank you from me, I can send you one of my nRF52-DKs which has the latest chip revision. 
    Just send me your address and phone number (DHL requirement), then I’ll ship this ASAP.

    Context:  SDKV11 s132 nrf52 Eclipse
    Two inter-related problems:
    RAM START ADDR 0x20002BD8 should be adjusted to 0x20002840
    RAM SIZE should be adjusted to 0xD7C0
    on the next line
    softdevice_enable outputs
    sd_ble_enable: RAM START at 0x20002BD8
    sd_ble_enable: app_ram_base should be adjusted to 0x20002A1
    ram size should be adjusted to 0xD5F0
    I am happy to read the documentation, but seem unable to find the right stuff.  What do these apparently conflicting error messages mean?
    2/  probably related
    If I include this line:  
    err_code = pm_init()  // initialize the peer manager

    then I get no output on the SEGGER RTT channel.
    Even if I simply link in the pm module, but don’t call, or  reference it. (i.e. I don’t remove unused modules in linker) RTT still goes quiet.
    It seems likely that there is some conflict in the memory layout that I don’t yet understand. Again, could you refer me to the appropriate documentation.


    Hi Michael,
    1)  You should change the ram base address in your project setttings.  For KEIL it will be in the Project_settings->Target->IRAM1 settings. For GCC it will be .ld file in your project.
    The softdevice migration guide (comes with softdevice zip file) explains you how softdevice reserves RAM for its use when it is enable and disabled. Application should make sure that it does use the RAM that is used by the softdevice. From your output it seems that you have not changed your application project settings to change the IRAM1 start address and size. You should do that. With softdevice version change only its usage of ROM and RAM is affected. The settings of the application is done in application project to make sure that it reflects the new start address and size.
    2)  I am not sure if I get what you mean. What does peer manager (pm_init) have to do with RAM settings? Maybe pm_init failed and your application is not checking the error?
    Susheel,   First, I want to thank you for your swift and apposite response.  I much appreciate you guys at Nordic!
    Ah…  the migration document.  I feel embarrassed.  I skimmed it when I upgraded and was looking in documents with more specific titles.  I will wear “sackcloth and ashes” while I re-read it more carefully, and get back if there is something I don’t understand, or close out the query.  Thank you.
    The pm_init appears indirectly to set up persistent memory in flash, and I wondered if perhaps there was some flash-layout issue relating to the first message.  I plan to see if my homework fixes problem #1, and then maybe #2 will evaporate.
    Again, thank you so much for your PROMPT help.  You did good!
    OK I read the document.
    I’m using Eclipse/GCC.  I changed my .ld file, blindly using the R/W memory numbers in the migration document, and ran it again.

    MEMORY{  FLASH (rx) : ORIGIN = 0x1c000, LENGTH = 0x64000  RAM (rwx) :  ORIGIN = 0x20002800, LENGTH = 0xd800}

    Here is some output from the following code fragment:

        //Check the ram settings against the used number of links
        // Enable BLE stack.
        err_code = softdevice_enable(&ble_enable_params);

    0> RAM START ADDR 0x20002800 should be adjusted to 0x20002840
    0> RAM SIZE should be adjusted to 0xD7C0 

    0> sd_ble_enable: RAM START at 0x20002800
    0> sd_ble_enable: app_ram_base should be adjusted to 0x20002A10
    0> ram size should be adjusted to 0xD5F0
    0> Error: NRF_ERROR_NO_MEM file:  // error returned from softdevice_enable(&ble_enable_params)

    Notice the conflicting suggestions again.  

    Change RAM START ADDR   to 0x20002840 size 0xD7C0
    Change app_ram_base     to 0x20002A10 size 0xD5F0

    But I changed to the values suggested by “sd_ble_enable”

      FLASH (rx) : ORIGIN = 0x1c000, LENGTH = 0x64000
      RAM (rwx) :  ORIGIN = 0x20002a10, LENGTH = 0xd5f0

    Now the program runs correctly, but outputs these conflicting messages:

    0> RAM START ADDR 0x20002A10 should be adjusted to 0x20002840
    0> RAM SIZE should be adjusted to 0xD7C0 
    0> sd_ble_enable: RAM START at 0x20002A10
    So which call is the one to believe?

    I noticed a comment in the DW blog mentioning a technique I had neither thought, or heard of, and I wonder what the advantage is.  I can’t get the paper because I’m not a member of the ACM, but I think I can guess what it is from the synopsis.  More interestingly, the paper is from Samsung!
    A leading factor leading to inaccuracy in the DW ranging system is that the respondents clocks may be running at different rates.

    1. A sends request to B at time T0
    2. B receives request and delays for time Db
    3. B sends response back to A
    4. Distance = the round trip time measured by A (Ta), minus the B’s delay time (Db) divided by 2, divided by c (speed of light) is the distance. 

    (Ta – Db)/2c

    But A’s clock may be running at a different speed from B’s clock, and so all timing measurements are suspect.  
    If clock A is accurate, and clock B runs 10% more slowly than true time, the round trip time measured by A would appear to be Db*10% longer, but A would still subtract the alleged turnaround time

     ((Ta + Db* 0.1) – Db) / 2c = (Ta + Db*0.9) / 2c

    If B’s clock is 10% faster the converse would be true.
    If on the other hand, clock B is accurate, and clock A is 10% slow, then the total round-trip time would appear shorter when measured by A’s slower clock.

    (T* 0.9 – Db) / 2c

    Of course, clocks A and B are both inaccurate!  Decawave compensates a bit for this by making two round trips, the so-called double-sided two-way ranging.  The advantage of this is that there are two delays, Da and Db and the clock error of both peers is factored into the time measurement.  The assumption is that, on average, the clock errors cancel out, which is of course a bogus assumption.  DW send the results back to the originator which makes a total of 4 transmissions, instead of the 2 used for single-sided ranging.
    I think this new idea tries to estimate the relative clock error.   

    1. A sends request to B at time T0
    2. B receives request and delays for time Db
    3. B sends response back to A
    4. then B waits a fixed time Db2 and sends a replicated response packet back to A.
      or A waits a fixed time Da and sends a packet containing timing data to B
    Assume the first.  The difference between the first, and second response packets is agreed by both sides, so A can measure the difference in arrival times of both of B’s packets. A knows how far apart they ought to be, and the difference between the expected, and observed times accounts for the relative clock drift.
    The problem I have is that even when A knows how slow or fast Bs clock is relative to it’s own clock, it doesn’t know which is right, and so averaging the two clocks out still seems like the best approach for generating a range.  
    The win is that it seems to be as good a double-sided two-way, but only three transmissions are needed for A to average out the clock drift.  On the down-side, B knows nothing unless A tells B.
    So this scheme saves 25% power for “selfish” rangers who just want to know a range, and don’t want to share it using DW packets.  I’m thinking TS07 will use a selfish ranging protocol because it will use a low-power radio to distribute the range data, eschewing (I love that word) the relatively expensive DW packets.