There are two weird things though:

I kept getting 0 for the calibration data.  So I ran the register dump to find out if I was read any registers, and sure enough it all looked kosher, and indeed the temp. calibration was 0x7A.  After some fiddling around I discovered that I couldn't read that register unless a read a whole bunch of others.  I have stopped digging into it, because I suspect it's some kind of weird timing bug.  Maybe the DW has to be in some special state to read the OTP.  It can wait.

The other thing is that if I plugged in the calibration value it didn't make much difference, which I suppose makes some kind of sense.  But the temp went up!  And the T is measured in C, not F, so I'm pretty confused.

Temp = 88.14(uncalibrated) 86.84(using calibration).  Volts =  2.99 

I think the code was originally written to run on a PC, because it is been written to drive multiple EVK1000s from a single processor – I suspect via multiple Cheetah boxes they talk about in one of the manuals. It looks like it has been hacked, and hacked because there is a lot of redundant code, and comments that clearly don’t make sense (well to me anyway).  I guess after the PC they ported it to the ARM m3 without cleaning it up, so there is a lot of extra complexity that we don’t need, and also buffers for the data for multiple devices, each of which is huge, so I don’t think we’d have enough RAM.

the good news is that the documentation is better than the code.  I read the documentation and didn’t understand it all.  Now I am looking at the code and not understanding it all, but the documentation starts to make more sense 😀

Of course they also run the demo nodes in either anchor, or tag mode exclusively, and we need to run it in either mode on demand, so the code is going to be quite a bit different anyway.  But right now I’m simply trying to get a one-byte packet from one TS to other, and I have not even got all the code ported yet.

I notice that a bunch of config parameters are allegedly set up in the factory and stored in the OTP memory of the chip.  I sure hope that they setup some decent default parameters in each module. 

As I get bits of code running I print out diagnostics to see if it makes sense. 

I notice that our two modules have LF clocks that tick at slightly different rates as you might expect (see below).  I guess a difference of 3/1555ths is < 0.2%. But that’s ~3 mins/ day – is that respectable?   Of course it’s calibrated against the high speed crystal which may be wrong too I guess.  Why is a HF crystal more trustworthy?  It wanders around too. 1555 became 1559 very quickly.

I think it will take another day or so to laboriously work through the code and understand what needs to be ported, clean it up, and port it over.  then I can start to debug it.

The good news is that so far the code is about 72K, and the data is about 4K, so we are still well above water.  But of course I have not linked in all the DW library yet, so it could suddenly mushroom.

Onwards…  need to sharpen my pickaxe.

I had a few minutes of uninterrupted time to begin to scrutinize the DW code.   The code base is pretty big.  The actual demo “application” code, (not even the libraries) are extensive.  See ->

I printed out just the demo part of the code so that I could start to understand how they set up the radios for TOF calculations.  Now it got depressing.

The following code translates TOF to a distance.  It appears that the hardware can produce TOF results that are negative!  OK, I can see how that can happen, but simply turning it into a positive number seems like a odd solution.  I wonder why that is the right thing to do?

Then I notice that the code assumes two complete round trips, i.e. 4 transmissions, and averages them.

Then if the result is less than -50cms discard it – which is odd because the previous line of code should have guaranteed that the TOF is positive.

And then if the distance is still negative then the sign is inverted –  after all the previous work, how can it be negative anyway?

Finally, just to be sure, they generate a moving average of the last 8 estimates.

So each report is actually the average of 32 TOF estimates.   That can’t be good for our power budget!

This is my first program that actually needed to know the speed of light.

Glorious fudge factors (pulled out of rectal orifice) require floating point.  N.B. No FP hardware on the Nordic.

//assume PHR length is 172308us for 110k and 21539us for 850k/6.81M
if(instance_data[instance].configData.dataRate == DWT_BR_110K)
{
msgdatalen *= 8205.13f;
msgdatalen += 172308;

}
else if(instance_data[instance].configData.dataRate == DWT_BR_850K)
{
msgdatalen *= 1025.64f;
msgdatalen += 21539;
}
else
{
msgdatalen *= 128.21f;
msgdatalen += 21539;

}

Antenna delay

My two conclusions were:

• RELIABLE zero/low-power person detection is required to avoid annoying operational behaviors.
• the value of various animation effects is subjective, and probably minimal

I have the basic comms for a mesh working (no actual packet forwarding, but the basic IO is working, i.e. a TS can be in listen, and broadcast mode.

I have rigged up push-buttons to simulate some IMU event.   So when a node senses it has moved  it would fire off a ranging sequence to recompute the revised topology of the mesh.   

So now I can press a button on either node and the other node get's told about it – that's the big breakthroug.  It provides the basic transport mechanism for propagating topology changes throughout the mesh.

So far so good, but of course…

Obviously a node will not advertise changes unless it has some to share, so that side of things should not consume much power.

On the other hand, listening out for advertisements is something you have to do all the time.  After some experimentation I begin to see that the listen overhead is kind of fixed.

If an advert occurs once every 10 ms, then you have to listen out for 10 ms to be sure of hearing a packet go by.  Of course you don't have to listen every 10ms (i.e. continuously) because you could just decide that you are not going to try and catch every advert, and will just listen for one in ten. So you listen for 10ms every 100ms.  On the other hand it requires that the advertiser sends the same packet 10 times at regular intervals.

The consequence of this that you get to choose the trade off between time spent listening, and time spent advertising.   You can advertise once an hour if the receiver listens continuously for an hour. You can listen for just ten minutes continuously if the advertiser sends the same packet 6 times an hour.  What that split should be is determined by the anticipated frequency of transmissions, and the power-budgets.  I'd like to measure thos values.  Maybe we are in the toilet already.

The other consequence of the choice is latency.  If you only design to hear one out of 10 advertising packets, then that means on average you will miss 5 before you hear the first.

So the important thing to decide for our application is how long the application can tolerate to wait before it should hear updates.   

I have paramterised my code so that I can choose any average latency from a few milliseconds out to 5 seconds (i.e. a worst case wait of 10s naively assuming no packet losses).   The longer the latency, the less time spent listening, and that's going to be the battery killer.

It should also be noted that the latency is for one hop.  If it takes 3 hops to get to the edge of the network and thus to the cloud then there could be a 30s wait.

But I have also discovered a snag with BLE.  It's too popular!  I have a bunch of Apple devices within wireless earshot (apartment below), all of which implement Apple's iBeacon protocol (based on BLE).  They are issuing unwanted advertising packets that wake me up many times a minutes, just so that I can ignore them and go back to sleep.