Just taking a break from porting the DW code over to the nRF51822. I’m finding it a steep learning curve, but mostly it makes sense. There seems to be a lot of flexibility, which in turn means that there is a lot to configure, which in turn means there’s a lot to understand about the configuration: channels, packet sizes, speeds, preambles and so forth. And it all has to be perfect to work. Of course the example code provides one set of parameters that clearly work, so that’s a comfort.
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.
low-power osc calibration 1555; blink time 5s; blinktime counter 3.012500
low-power osc calibration 1552; blink time 5s; blinktime counter 2.989700
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.
//Mik