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