I’ve been having some trouble sending and receiving packets using the DW chip’s automatic response facilities.

Automatic-response:  It is possible (and probably necessary for ranging) for the DW chip to quickly enter listen mode after it has transmitted a beacon packet.  There is a special mode that can be set up so that no intervention is required by the host processor.  There is a symmetrical capability to set up the DW chip to respond automatically to inbound beacon packets.

When transmitting a packet, and automatically listening for a response, I was receiving a “timeout” response as if the other end has taken too long to respond.  I simplified all the code down to the bare essentials, but still kept getting the timeout.  This is weird because clearly a response had been received, but by the time I polled the status of the response, the chip had decided it was too late arriving.

The cause turned out to be the SPI baudrate.  I was driving the SPI at 110K which is the slowest data rate that the DW can handle, but it is the speed they suggest for initializing the DW.  Deep in their demo code, the STM32 raises the SPI speed to something a lot higher (a rate that is difficult to decipher from the code).

I scanned the DW manual and couldn’t find any hints about legal  higher SPI speeds. My versions of the datasheet, and user manual are pdfs and for some reason I can’t search for keywords, the way I usually can.  Moreover, I couldn’t find any indication how to tell the DW I was going to talk to it at a higher speed.

Short of any better ideas… I simply cranked up the speed at the Nordic side to 8Mb/s, and let it rip.

Not only did the DW figure out the data rate automatically, but it also fixed my timing bug.  Clearly the Nordic software was not testing the status of the radio fast enough using the slow SPI speeds.

I don’t recall ever reading anything about this issue, but perhaps the new manuals mention it.  I suppose this explains why they crank the SPI speed up.   Doh!

—
1/21/16   I just read that the maximum possible baudrate for the SPI is 20MHz.

We were a little concerned about the antennae on TS06.3 boards.  Recall that the ground plane had extended under the DW module which was against their rules, so David had scraped it off.  The good news is that the TS06.3 antenna seem only to be about 50% as effective as the TS06.2 boards.  Given the packet loss is quite small, we can live with that I think.

I did some rough-and-ready tests to see how many packets get lost.

TS06.2 packet loss test

I left the simplest transceiver programs running on TS06.2 all last night.  The transmitter logs more packets than the receiver.  Sending packets all night at 1Hz 13.58% got lost, which is both dreadful, and strange.  I’ll run that again, and see if it is consistent.   I would expect close to perfection, but sure less than 1% for transceivers  8″ apart, transmitting one packet every second.  Note that my later tests send packets a lot faster.

1s intervals, overnight = 13.58%

This morning I moved the transceivers 12″ apart and sent packets at 10ms intervals, and got 0.12% packet loss.

10ms intervals – 0.12% packet loss.

Moving the tranceivers back to 6″ separation I now get 0.11%

Repeating for TS06.2 -> TS06.3

10ms intervals TS06.3 -> TS06.2 – 0.3% packet loss

Repeating for TS06.3 -> TS06.3

Here are the exacting test conditions,  The DW antenna are about 6″ apart. The results are about the same.

10ms intervals TS06.3 -> TS06.3 – 0.6% packet loss

Sleep time

While the test is running the listener code in the Nordic is awake an impreceptibly small amount of time.  (I am not sleeping the DW yet.)

The transmitter is sending stuff as fast as it can and rarely get’s to sleep.  That doesn’t seem quite right, because sending packets shouldn’t be a big overhead.

I was having trouble waking up the DW if it had gone to sleep without setting the wakeup condition bits: DWT_WAKE_WK or DWT_SLP_EN. Under these conditions, the correct way to wake the chip up is to force RSTn low for a short time, and then let it float again.  There are strong exhortations in the manual never to drive RSTn high, so my code had been ultra-conservative. 

#define RESET_DELAY 1  // 1 msnrf_gpio_cfg(          // set the pin up as an output DW_RSTN, NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_DISCONNECT,  // input buffer disconnected NRF_GPIO_PIN_NOPULL, // no internal pullups – high impedence I guess NRF_GPIO_PIN_S0D1, // ‘0’ drives it low with 0.5mA max sink;                                        // a ‘1’ disconnects it NRF_GPIO_PIN_NOSENSE   // not an input so not relevant );
nrf_gpio_pin_clear(DW_RSTN); // drive the pin lowdeca_sleep(RESET_DELAY); // wait a very long timenrf_gpio_pin_set(DW_RSTN); // disconnect the pindeca_sleep(RESET_DELAY); // wait a very long timenrf_gpio_pin_clear(DW_RSTN); // drive the pin lowdeca_sleep(RESET_DELAY); // wait a very long time
nrf_gpio_cfg( // sets the pin up as an input DW_RSTN, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_CONNECT, // connect the input buffer NRF_GPIO_PIN_NOPULL,         // no pullups ??? NRF_GPIO_PIN_S0S1,  NRF_GPIO_PIN_NOSENSE           // not using GPIOTE, so no used );
nrf_gpio_input_disconnect(DW_RSTN); // disconnect itdeca_sleep(2);

Leo has let us joint he DW google group.  That could be useful

https://groups.google.com/forum/#!forum/decawave_group

Resupinus – No Battery