I’m going to see if I can connect the Nordic Eval board to the EVK eval board.

The first thing to do is to make sure that I have all the switch settings, and jlink connections recorded.

I was thinking of connecting the Nordic EVK to the DW EVK1000 board.  The EVK user manual (attached) has some words of wisdom on p12, and a diagram.

If I connect the Nordic to USB for power, flashing and debugs, and connect one of our batteries to DW1000 J7, what will go wrong?

 DC:

Do you know what the I/O voltage is on the Nordic eval board? It can anything from 1.8V to 3.6V. I think it must be 3.3V. That would be good, because the EVK1000 is running at 3.3V. Then the I/O voltages will be compatible. If the Nordic is running at 1.8V then there would be a problem because 1.8V wouldn’t drive the EVK1000 reliably and 3.3V from the EVK1000 to the Nordic board would overdrive it. Even if they aren’t the same the Nordic seems to be quite robust since we already did things to it that should have destroyed it but didn’t. On the other hand you don’t want to take unnecessary chances. Is there a schematic of the Nordic board or other documentation? If you think the Nordic board is 3.3V then go for it.

ML:

Here some stuff I uncovered.

HOWEVER I Fluked Vcc to ground on the Nordic when connected to USB and it was 2.978 which is weird.

GO or NO GO mission control? 

DC:

Go, because the reason there would be any damage is if the ESD diodes become forward biased.

Since the drop across a diode is about 0.6V, as long as the voltage on the input is less than 0.6V higher than Vdd / V+ (or more than 0.6V lower than GND / V-) it will be OK.
2.9V is pretty low but maybe the errors are adding up. Or maybe the regulator is set to 3.0V instead of 3.3V. It doesn’t matter; go ahead and try it, as long as the pins are connected correctly.

ML:

OooooKaaaaay   🙂 

<later>

ML:

So I’m out of my depth again.  The EVK1000 manual p21 shows the connections for SPI.  There is no chip-select pin.
 

Am I supposed to know what these SS1..3 pins are?  

DC:

These are the TotalPhase Cheetah pin descriptions.
2.1.4 SPI Pins
SCLK (Pin 7):
Serial Clock – control line that is driven by the master and regulates the flow of the data bits.
MOSI (Pin 8):
Master Out Slave In – this data line supplies output data from the master which is shifted into the slave.
MISO (Pin 5):
Master In Slave Out – this data line supplies the output data from the slave to the input of the master.
SS1 (Pin 9):
Primary Slave Select – the primary control line that allows slaves to be turned on and off via hardware control. (This SS is in the same location as the SS line of the Aardvark and Beagle products.)
SS2 (Pin 1):
Second Slave Select – an additional control line that allows slaves to be turned on and off via hardware control.
SS2 (Pin 3):
Third Slave Select – an additional control line that allows slaves to be turned on and off via hardware control.

So let’s find the SPI pins in Nordic’s  pca10001.h header file.

#define SPIM0_SCK_PIN     23u   /**< SPI clock GPIO pin number. */
#define SPIM0_MOSI_PIN    20u   /**< SPI Master Out Slave In GPIO pin number. */
#define SPIM0_MISO_PIN    22u   /**< SPI Master In Slave Out GPIO pin number. */
#define SPIM0_SS_PIN      21u   /**< SPI Slave Select GPIO pin number. */ 

Sig_Name  nRF51822_Pin  PCA10001_Pin EVB1000_Pin EVB_Sig_Name
SPIM0_SCK         23            P5.8             J6.7       EVB.SCK
SPIM0_MOSI        20            P5.5             J6.5       EVB.MISO
SPIM0_MISO        22            P5.7             J6.8       EVB.MOSI
SPIM0_SS                  21            P5.6             J6.9       EVB.SS1
GND                             P5.9             J6.10      EVB.GND
GPIO?                                            J6.4       EVB.IRQ

DC:

Do you have a schematic of the Nordic eval board? Then I can see what regulator they are using to see if it can supply the extra current. However, I”m almost certain that it can. Neither board draws a lot of average current.

ML:

I looked around for a Nordic schematic myself, and couldn’t find one.  I googled “scematic”  and “BOM” both on the web, and our shared documents.  Nada.

Maybe a AP7333-33SAG-7   It looks like an LDO 

DC:

The part number is for a 3.3V regulator so I think you’re correct. It can supply 300mA, which isn’t a lot, but probably enough. You won’t hurt anything by trying because it has current limit protection, so go ahead and hook it up.

I wondered what this “Smart Power” code was all about, so I did a bit of research.

In the process I tripped over a really interesting article dated May 15th, 2014 by Bob Cringely, called “Did the NSA help kill UWB?“.

The UWB startup that got the most press back then was called Time Domain and the name says a lot about how the technology worked. Rather than using specific frequencies UWB transmitted on all frequencies at the same time. The key was knowing when and where in the frequency band to expect a bit to appear. Two parties with synchronized clocks and codebooks could agree that at 10 nanoseconds after the hour at a certain frequency or range of frequencies a bit would appear if one was intended. The presence of that signal at that time and place was a 1 and the absence was a 0. But if you didn’t know when to listen where — if you weren’t a part of the conversation — it all looked just like noise.

There was a San Diego startup called PulseLINK that came up with the idea to try UWB not only through the air but also over wires. They reasoned that RF travelled through copper as well as it travelled through air. So they injected their UWB signal into the local cable TV system (without permission of course) just to see what would happen. Could they establish point-to-point and point-to-multipoint communications as an Over-The-Top network on the local cable plant? It worked. They created a gigabit network atop established cable infrastructure without the cable company even noticing it was happening.

One fascinating aspect of the PulseLINK test was that UWB, which is an electrical signal, was able to propagate throughout the Cox cable plant even though sections of the Cox network used optical signaling. They went from electrons to photons back to electrons again and the fact that was even possible came down to the fact that it was CATV, not IP. Had the cable system been IP-based every electrical to optical conversion point would have involved capturing packets, fixing them as needed, then retransmitting them, which would have foiled UWB. But in the rotgut world of cable there were no packets — just an analog signal carrying digital and analog data alike which was block converted from one medium to another and back. So the UWB data was converted and retransmitted throughout the cable plant as noise.

Since it costs almost nothing to run another test while I’m in bed…
I found another Tenergy battery that had never been used as far as I could tell.  It had the solder tags on the ends.  I charged it up and ran another test.

The fresh battery measured at 4.2V.  The battery measured 1.42V when the test finished after 14465 seconds/ranges.   Towards the end of the test (around 14300) the ranges started getting progressively longer, ending up in the 1.7m region by death.  But that’s just during the final 3 minutes, or almost 4 hours.

Results

14300 decent ranges.
3575 3D location fixes.
Assuming each range is the median of four samples, then we get 894 fixes.

Thoughts from David

Conclusions from Mik

Today I thought I’d do a rough and ready experiment to see how long it takes for one of the TS05b rechargeable batteries to run down.  I’m hoping this will give me some clue about how many new-style range events I can perform on one battery.

I have set the program to range once/sec, and I’m going to count how many seconds it is until the battery powered unit stops responding.

I put it into the TS05b to charge and measure it with the gas guage.  It measured 4.2V and 22157 Coulombs in the tank, when I transferred it to the DW EVK, at 6.18pm.

I don’t have an on-board RTC to print out the time when it stops, so I’m simply incrementing a 1Hz counter each time there is a successful range operation.

Results

The 900mAh battery pooped out at 3h 41m.  I put it back into the TS05b to measure it rather than using the Fluke(Doh).  It showed 3.5V.  The gas gauge said it had 10610C left in it.  That’s 1 Coulombe/range – an easy, but probably meaningless statistic?

Just as interestingly, about 20 minutes beforehand the range estimates increased by 20 cms.  So clearly I have to keep an eye on that detail.  Why does it increase though?  Clock slow?

So bottom line is that we can get about 12000 good range estimates.  That’s 3000 3D fixes at 4 ranges per fix.

But let’s assume we need to take the median of 4 ranges to get a good fix.  Then it falls to 750 fixes/battery.  That’s about 1 good fix per 1mAh!  Oh jeez, I have a problem 🙁

N.B. In the following, the first number is the number of times the software polls the DW between ranges, not particularly important.  The last two numbers are <elapsed seconds>: <range>

136733 Me:0 Other:100999205E37F8FD 11253: 1.02
136784 Me:0 Other:100999205E37F8FD 11254: 1.10
136717 Me:0 Other:100999205E37F8FD 11255: 1.05
136844 Me:0 Other:100999205E37F8FD 11256: 1.05
…
136714 Me:0 Other:100999205E37F8FD 12007: 0.96
136735 Me:0 Other:100999205E37F8FD 12008: 1.04
136754 Me:0 Other:100999205E37F8FD 12009: 1.00
136726 Me:0 Other:100999205E37F8FD 12010: 1.05
136802 Me:0 Other:100999205E37F8FD 12011: 1.08
136884 Me:0 Other:100999205E37F8FD 12012: 1.09
136830 Me:0 Other:100999205E37F8FD 12013: 1.07
136798 Me:0 Other:100999205E37F8FD 12014: 1.04
136748 Me:0 Other:100999205E37F8FD 12015: 1.03
136791 Me:0 Other:100999205E37F8FD 12016: 1.01
136810 Me:0 Other:100999205E37F8FD 12017: 1.02
136708 Me:0 Other:100999205E37F8FD 12018: 0.99
136705 Me:0 Other:100999205E37F8FD 12019: 1.08
136843 Me:0 Other:100999205E37F8FD 12020: 1.08
136808 Me:0 Other:100999205E37F8FD 12021: 1.05
136876 Me:0 Other:100999205E37F8FD 12022: 1.10
136824 Me:0 Other:100999205E37F8FD 12023: 1.08
136747 Me:0 Other:100999205E37F8FD 12024: 1.08
136714 Me:0 Other:100999205E37F8FD 12025: 1.08
136881 Me:0 Other:100999205E37F8FD 12026: 1.05
136778 Me:0 Other:100999205E37F8FD 12027: 1.04
136726 Me:0 Other:100999205E37F8FD 12028: 1.11
136720 Me:0 Other:100999205E37F8FD 12029: 1.03
136879 Me:0 Other:100999205E37F8FD 12030: 1.07
136737 Me:0 Other:100999205E37F8FD 12031: 1.11
136829 Me:0 Other:100999205E37F8FD 12032: 0.99
136820 Me:0 Other:100999205E37F8FD 12033: 1.03
251146 Me:0 Other:100999205E37F8FD 12034: 1.28  Something happens around here…
136881 Me:0 Other:100999205E37F8FD 12035: 1.25
136799 Me:0 Other:100999205E37F8FD 12036: 1.16
136795 Me:0 Other:100999205E37F8FD 12037: 1.21
136746 Me:0 Other:100999205E37F8FD 12038: 1.13
136814 Me:0 Other:100999205E37F8FD 12039: 1.09
136880 Me:0 Other:100999205E37F8FD 12040: 1.19
136707 Me:0 Other:100999205E37F8FD 12041: 1.10
136778 Me:0 Other:100999205E37F8FD 12042: 1.22
136886 Me:0 Other:100999205E37F8FD 12043: 1.18
136709 Me:0 Other:100999205E37F8FD 12044: 1.17
136828 Me:0 Other:100999205E37F8FD 12045: 1.11
136823 Me:0 Other:100999205E37F8FD 12046: 1.20
136868 Me:0 Other:100999205E37F8FD 12047: 1.24
136783 Me:0 Other:100999205E37F8FD 12048: 1.22
136737 Me:0 Other:100999205E37F8FD 12049: 1.26

136800 Me:0 Other:100999205E37F8FD 12050: 1.18
…
136756 Me:0 Other:100999205E37F8FD 13253: 1.54
136821 Me:0 Other:100999205E37F8FD 13254: 1.43
136715 Me:0 Other:100999205E37F8FD 13255: 1.46

As delivered the ranging system operates at 100kbps.  Presumably that’s the symbol rate.  At the other end of the scale it works at 6.8Mbps.  I tried both speeds and it seems like the effective range is a little longer at the slower data rate.

The ranging protocol relies upon the peers taking a known, and fixed amount of time to respond to a ranging request.  The code indicates that this is 150ms!   Unless the peers can sleep, that’s a long time to have to remain awake every range event.  When the EVB1000 is connected to a PC, the turnaround time is set to 750ms!  Yup 3/4 second.  Since there are two fixed period turnarounds, the total ranging time is in excess of 1.5s.

Fortunately, a feature of the DW chip is it’s ability to schedule transmissions, and receptions for some time in the future, and to sleep while waiting (or is it to let the processor sleep while it waits?) Without that, I reckon the power budget would be horrendous.  Nevertheless, it means that to perform the four one-shot range operations required to locate yourself in 3D, it would take  150*2*4 ms = 1.2 seconds.  A moving person could travel 6-10 feet in that time, so there would be a much higher probability of trying to do trilateration (is it really quadlateration) with a degenerate set of coordinates. (i.e. the ranges don’t intersect, so can’t specify an area, let alone a single point).  My experiments so far, show that one-shot ranges are way off, and that it isn’t until the second try that it get’s reasonable.

The DW code claims to have some options to allow “fast ranging”.  I think they are assuming that the two peers are using identical processors and software, and that the turnaround delay is proportional to the time it takes to transmit the ranging packet.

The question they are trying to answer is, “If radio A sends a ranging packet to radio B, how briefly can radio A sleep for before expecting to hear back from radio B”.   This is puzzling.  Radio A must stay awake until the last bit of the packet is sent.  Assuming that the processor attached to radio B takes minimal time to turn the packet round and have the radio send it out, then why would radio A need to sleep for more than a trice before it has to wake up to catch the first bits of the return packet.  This doesn’t seem like a big win.

Of course they might be trying to let processor A sleep as soon as it has handed over it’s packet to the DW, and not be awoken until the return packet has been received.  In that case the delay until being awoken should be about the time it takes to send two ranging packets.

Looking through the code it appears they try to calculate the minimum fixed delay time based on the time it takes transmit a range packet.   I don’t understand the calculations, but they have parameters that measure the length of the fixed, and variable parts of a ranging packet under different transmission modes.  At 110Kbps the delay appears to be much longer than at 6.8Mbps, but doing their math in my head doesn’t produce the result I expect.  There are a bunch of fudge factors, and these seem to be significant.

Anyhow, the final calculation seems to result in a number that is less than 600us which is more appetizing.  With that you could quadlaterate in < 5ms (200Hz) which is very respectable.  Of course there are actual legal restrictions on how much UWB traffic you put into the ether, so there may be other limitations.

However, and much more importantly, I can’t get the “fast ranging” to work.   Comments in the code indicate that it only works at 6.8Mb, but all my attempts to configure it as suggested fail, and the two nodes can’t find each other.

I’m looking to put the DW1000 into a deep sleep, and then to wake it up and start ranging operations. Here’s the output from the text program, which is actually DW’s program that I have hacked a bit.

Semihosting operational                    trace messages via semi-hosting   
DW1000 now in (deep?) sleep mode           put  DW1000 to sleep

For some reason the first range is always about 20 cms too large.  I’ve tried this perhaps 20 times, and it is consistently too big.

I’m inserting trace message into the DW code so that I can try to understand what it does.

I’d like to figure the simplest sequences to do the following:

1. Power-up from off, or very, deep sleep;
2. Power down, or enter very, deep sleep;
3. Get ready to receive and respond to a ranging request;
4. Issue a ranging request, and capture the result.