Paper A Novel Indoor Localization Scheme for Autonomous Nodes in IEEE 802.15.4a Networks
S-TDoA – Sequential Time Difference of Arrival
Month: June 2016
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.
- In deep sleep with just a few essential registers retained the XL70550 consumes 10nA
- 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
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
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.
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 supplyI 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.
- 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?
- Barom and IMU are a single decision. Both or neither.
- PSU – Provisions for this BOVLB to measure power consumption with onboard/offboard instruments
- JTAG – great if easy to plug in and remove.
- Arduino compatible expansion port – makes experiments with off-the-shelf boards an option
- If there sufficient pins to have DW on SPI0, and IMU, etc on SPI1, and still pins for I2C… great.
- Spare pins get: LEDs, buttons (that are easy to press!). Reset button – minimal value
- 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.
——————-
- Make an nRF52 board anyway, and hope the ZL70550 software comes through
- Choose a different, less efficient WUP radio, and make a generic WUP API so it is easy to upgrade
- Continue using the 2 x Nordic nRF52 boards with wires jumpered to the TS06.2, and use BLE for WUP
- As (3) but make a TS shield for the Nordic nRF52 eval boards with DW etc
- Sleep
I should probably give them a few more days, and then bug Jean-Luc again.
//MikOn Wed, Jun 8, 2016 at 7:44 PM, David Carkeek <dcarkeek@gmail.com> 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 <mik@lamming.com> wrote:It’s not looking good.
//Mik
——– 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.
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).
… 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.
https://devzone.nordicsemi.com/question/63766/peer-manager-and-gcc/
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.
————-
MEMORY{ FLASH (rx) : ORIGIN = 0x1c000, LENGTH = 0x64000 RAM (rwx) : ORIGIN = 0x20002800, LENGTH = 0xd800}
//Check the ram settings against the used number of links
CHECK_RAM_START_ADDR(CENTRAL_LINK_COUNT,PERIPHERAL_LINK_COUNT);
// 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: app_ram_base should be adjusted to 0x20002A10
0> ram size should be adjusted to 0xD5F0
0>
0> Error: NRF_ERROR_NO_MEM file: // error returned from softdevice_enable(&ble_enable_params)
Change RAM START ADDR to 0x20002840 size 0xD7C0
Change app_ram_base to 0x20002A10 size 0xD5F0
MEMORY
{
FLASH (rx) : ORIGIN = 0x1c000, LENGTH = 0x64000
RAM (rwx) : ORIGIN = 0x20002a10, LENGTH = 0xd5f0
}
- A sends request to B at time T0
- B receives request and delays for time Db
- B sends response back to A
- 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
((Ta + Db* 0.1) – Db) / 2c = (Ta + Db*0.9) / 2c
(Ta * 0.9 – Db) / 2c
- A sends request to B at time T0
- B receives request and delays for time Db
- B sends response back to A
- 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