Month: February 2020

This week I confirmed that the design I will first be testing is just using the C calls for oscillators on the Decawave/RaspPi chips.

I found enough other people who were able to use this to enough accuracy for TWR/TDoA communication so it is important for us to give it a try.

I wrote a script in both C and python that calculated nanosecond clock ticks using the monotonic performance counter clock. Now we just need to focus on getting the UWB signals sent and received.

Our split up work is being severely hamstrung by that one component so it makes sense for all of us to work on that one part for now.

Also spent significant time this week reading through decawave documentation to start programming a tag software on the decawave chip. I am approaching the problem with Python while Shiva approaches it with C. We will take whichever one works first and run with it. And worked on the design presentation.

Roadblocks maintain programming the decawave chip (as, begrudgingly, Tamal was 100% right about).

There remain 2 major questions regarding our success for the project.

1. Can we program Decawave chips to receive signals and transmit them into a RaspPi?
2. Can we pull off nanosecond level time sync

The first question seems less problematic since there is a LOT of documentation and forum work on the matter. We are still digging through it to understand, but we feel confident we can get it to work. We are struggling a little bit to get the DW1004C blink code working with the DWM1001 so we may need to push forward the purchase of our DWM1004 tags for proof of concept. It won’t incur significant changes to cost since we just need to order something earlier than expected.

The second we have 2-3 different approaches are going to try. Understanding which approach is likely to work and how to implement them is going to need professor help. We look to try each of the methods as a contingency for the previous. (First clock based only, then TCXO + I2C analog interface (RaspPi or Particle board)).

Luckily, work on the anchor-server communication network is proceeding smoothly. There were some hiccups early on with nonfunctional equipment, but we secured replacements and the networking software has been tested successfully between one anchor and one server. The next step is to test with multiple anchors and one server, which is happening this week per the initial Gantt schedule.

I think we are about a week behind on 2 of the 3 parts than we expected to be. But this is still the design phase and we have a lot of slack so hopefully, we can quickly get back on track.

Our updated Gantt Chart is below:

Gantt Chart for 02/15

What was done this week:

The focus of this week was about doing enough preliminary work to validate our design decisions. For me, that meant doing enough research to feel confident about a timing solution that would work on paper.  I have extremely struggled with this goal. I feel like I do not have the technical expertise to understand many of the words I am reading.

Here is a summary of my research:

• We need <10 ns accuracy between anchors to have a semi-accurate localization
• There exist TDoA schemes that work without accurate time-sync but seemingly only in research papers and their accuracy results have been insufficient for our requirements
• I have found at least 2-3 other systems who claim their TDoA anchors use a 38.4MHz TCXO oscillator with a UWB receiver with time sync over UWB with syncs every 150ms
  • Problem is, I don’t understand how any of this works. How does a clock at that slow speed ensure the precision of nanoseconds?
  • Why doesn’t a RPi clock with GHz speed not give nanosecond accuracy with sync?

Frankly, much of this is confusing me and I think I need faculty help. Tamal told me that the RPi clock should theoretically suffice, so I have been trying to get a Rpi4 connected and write a time measuring sync.

The first RPi I got didn’t work and then setting up headless (without a display) took a while. I have not written time code but I have the RPi setup.

That will be the goal for the next week along with getting some help understanding TCXO setups for the next week.

I would say this part of the project is behind our original schedule. That said, the original schedule was mostly assuming the design was done. We want to have this finalized by design next week.