On plane down to Sayulita I carefully read DecaWave device driver API.
Porting has been considered with some care.  For new hardware one has to implement ~5 native architecture specific functions to talk to chip.
SPI read and write; an ISR;  DW-SPI mutex operations: enter and leave.
Rest of the API should just need recompiling.
Sadly that’s not going to be the end of it.  The API is low-level, and there’s a lot of work to do to initialize, calibrate, and configure, before even starting to think about ranging. 
Accurate ranging demands calibration to trim crystal, and estimate antenna delay, and other questionable fudge factors.  Multiple refs in document to consult DW to learn how to do calibration!
No range functions in API.  Have to roll your own from basic time stamping functions.’
Complex-domain temporal signal sample data available to assess the quality of the signal.  Looks like for accurate results have to detect first “edge” yourself!  Hoping standard examples are in some demo code somewhere.
All looks daunting and I wonder if DW has higher level stuff avail now. 
BeSpoon apparent approach of having all this stuff canned seems very attractive
Intersting article in the Economist this week
IWatch: Battery life 18hours.
Independ company projects sales: 8-16M units in 12 months.
2-3% revenue will come from watch
No killer app
C.f. Disney magic band has better idea of things to do with wrist worn device.  
No simple way to revoke personal sensing data if device lost/stolen
I have really tried hard to get this BeSpoon phone code compiled so that I can tinker with it.  BeSpoon have not been helpful, and not even responded to my latest whine for assistance.   I'm not a top-notch programmer, but neither am I a complete novice, or a novice at eclipse.  I think I have been extraordinarily persistent.  Indeed one of my failings is not knowing when to quit! Clearly I could use a good deal more expertise, and experience in either Android Studio, or eclipse to overcome all the issues I'm facing.  Maybe another day, or week, or month would crack it.  Maybe if I come back to it when I have had some successes with eclipse in another context, then the problems and solutions will be more obvious to me.  At present I'm down, wounded, but not out.

It's also important to consider that the code they have provided simply does not compile and run under any windows IDE that it is currently possible to download and configure.  My previous message clearly revealed that they were over-selling on the "it works for everyone else" argument.  I wonder what other shortfalls they have forgotten.  Until they actually install an up-to-date Windows IDE and bring their code up to rev., I don't think it makes sense to have much confidence in their code.
Lastly, their code has other problems I reported earlier.  Clearly it is a lot more fancy than it should be for the purpose.  Instead of a bare-bones simple program that just demonstrates a single "wake-up, discover, range, sleep" operation, this program fiddles with the phone IMU, and pressure sensor, and registers itself with google-play so that new versions can be automatically downloaded – and all that good stuff.  They also seem to have used this demo as an opportunity to show how clever they are at Android programming, using unnecessarily obscure abstractions, and almost zero comment, to impress us with how clever and sophisticated they are.  All this unnecessary stuff complicates getting a trivial program working.  
I'm also not confident that they understand what they are doing anyway.  An unused portion of code seems to think it can figure out the bearing from phone to the anchor, which it clearly does not have enough data to do.  But it is a common fallacy that requires some careful thought to reject.  I guess they discovered the problem and abandoned that pursuit, but left the fossil code around to complicate things.
So what are my options?
1) Use one on my old laptops to setup an Ubuntu environment, learn all about developing code under Ubuntu, and then try to see if I can understand their code well enough to start tinkering.  
2) Start developing Nordic code to interface to the BeSpoon module.
Re 1:  Given my advanced age, and lack of experience I expect that will take a month.  The question I need to ask is what is all this BeSpoon phone tinkering in aid of anyway?   I was thinking that it would be trivial to install their code and trace through it to understand the workings of the software on their chip.  I thought this would also prepare me for the arrival of the new TS06 hardware, by familiarizing me with the protocols, performance and trade-offs.  I was going to modify their code to generate some range data with known characteristics – measuring the start-up time, the number of ranges required to get a stable fix.  I could also save the data in a format that makes it all easier to analyze.  If the ranging was poor, then this would allow us to abandon building BeSpoon hardware and return to DecaWave evaluation.  
The other reason was that the BeSpoon phone could act as a bridge, and a mobile UI for experiments.   That may still turn out to be a win, but right now it is a second-tier requirement.
Re 2: Well I don't have hardware yet but it will take a while to get all the tools chains set up again anyway.  I could easily use the current TS06.2 hardware to re-establish my eclipse tool chain and start to write code that will talk SPI/I2C or serial to the chip when it arrives.  I could talk to some easy SPI device to start with.  And of course I could try to talk to the DecaWave chip which was plan A anyway.
The downside of this approach is that I have no code working as a base camp.  Sure there are BeSpoon demo programs and so forth, but I don't have that code running on hardware.  So an early challenge is to figure out how to compile their code for the Nordic.  Does this start to sound familiar?  Why would their code port to a foreign platfrom any more easily than it ports to their own platform the Spoon phone.
So both paths look like a lot of work with a truckload of unknowns ahead.  Maybe it makes sense for me to futz with Ubuntu just a little to see if it seduces me?  


Another two full days trying to figure out how to compile the BeSpoon code.

The program is way more complicated than it needs to be, and I’m willing to bet that it’s level of sophistication is getting in the way of many people understanding how to drive the chip.

The code uses android-play-store, and accesses the IMU and a bunch of other stuff instead of simply demonstrating the very simplest interface to their ranging module.  As a result there is a huge amount of code that has to be upgraded before the program will run.

The code they have supplied needs updating for the current development tools, and that’s clearly way too hard for me.

I spent two days very carefully exploring all the options I could enumerate, and made some progress, but came to another dead end.

I have trawled through their code to try and find exactly where they talk to the module.  It looks like they may use USB to talk to it, but I can’t find any point where they read/write data.  I’m guessing that there is some subtle inheritance structure in the code that I just don’t understand.

I’m out of ideas for now.  Maybe it would be easier to build our own hardware first!

Eclipse installation issues

Summary

  • Eclipse has some documented bugs that have workarounds, which it makes it all more tedious to work through the IDE installation.
  • BeSpoon are several revs bhind the latest API, and I’m not sure even they can compile their code.
  • Their code seems unnecessarily complex for a demo.

Problem:  A TOF ranger sucks power.  To get an accurate 2D fix you have to range 3 anchors.  When you have no idea where you are in the filed of interest, it’s not possible to select the three best anchors to get a new fix.  There are two pathological cases: (In mathematics, a pathological phenomenon is one whose properties are considered atypically bad or counterintuitive; the opposite iswell-behaved)

Mathematically, the most stable fix will be produced when the ranges are precise, and the anchors form an equilateral triangle.

  1. Obviously the worst case is that there are insufficient anchors in range, so ranging is simply a waste of time and power.  It’s important to note that getting a fix is not the only reason for ranging – proximity detection requires just one anchor – but in this case zero anchors nearby would still be a waste of time.
  2. Anchors positions are degenerate, and the trilateration cannot produce a single result, or any result.  An example is when all three anchors appear coincident, or maybe in a straight line.

Given there are more than three anchors available then choosing the three that most closely approximate an equilateral triangle would be good.  But how do we know which three are the best without trying to range them first?

One solution is to use a less expensive radio to produce some range estimates.  With a BLE radio we can use RSSI to determine which anchors are actually in range.  In there are insufficient then there is no point carrying on, unless the ranging radios have greater range.  With more than three approximate range estimates we make some informed guesses about the best three to choose.

The problem here is that RSSI-based ranging is notoriously bad.  Obstructions, both man, and man-made can cause huge discrepancies.

My idea uses an incremental technique to build an RSSI fingerprint map of the field of interest.  The premise is the same eroneous premise as for all fingerprinting techniques – that the RSSI fingerprint will be the same every time the mobile is at the same position.  I would extend that using the IMU to include oritentation parameters to take into account which way the user was facing!

My idea is not to rely on RSSI range measurements to get an approximate position.  Instead I propose to store an RSSI fingerprint after each successful range operation.  The fingerprint will include the anchor identity and TOF-range of the three anchors that contributed to a successful ranging event, and their BLE RSSI values.  So each stored fix looks like this.

Fix-n:  (a#, ble-rssi), (a#, ble-rssi), (a#, ble-rssi)

where a# is the UID of the anchor, ble-rssi is the rssi value measured on the BLE radio, and tofR is the time-of-flight range.

I assume that each time there is a successful range operation a new record is stored, and at this stage I assume that there is plenty of memory.

So having decided that we need to get an accurate position, we obtain RSSI measurements from the regular BLE broadcasts and use them to locate the best matching RSSI fingerprint, and use that record to select the best three stations for accurate trilateration.

Improvement

An improved version relies on the anchors building a graph of their relative positions.  The world-orientation of this graph is not known.  The graph shows the distances between anchor pairs.  As the mobile device wanders around the field of interest it overlays fingerprint information over the graph.   Each time it gets a successful range, it simply records all the most recent RSSI data it has.

I wanted to make a new backup system that didn’t chew up all the Internet bandwidth.   I decided to make a stat-alone NIS for backups.   If the house burns down then my laptops, and the NIS will go, but my plan is to shadow the NIS up to Glacier for safety.

Of course that was great in theory but then I discovered that W7 has it’s own challenges.

In theory Windows has all this covered with the Backup facility in the control panel.  I have used it before with no issue.

However whenever I tried to backup I got some sort of credentials failure.
Displaying image.png
After literally days of scouring the web I finally uncovered the two gotchas that were causing the problem.  It’s hard to believe that so few people have encountered this problem.

The two issues

  1. The windows backup service was not setup correctly, even though it was a fresh install on a new machine.  W7 Pro had left the backup service uninitialized.  In the following image it shows that it is in “Manual” mode, but by default it is initialized – i.e. the “Startup Type” field was blank.  As soon as I set it to “Manual” the credentials issues went away, and my password was acceptable.
    Inline image 2
  2. Now the backup would start, but it failed after about 20 seconds with this message:
    This makes it sound like there is insufficient room on the NAS to hold the backup, but that is clearly not the case.  It was caused by their being insufficient disk space on the local recovery partition.   The backup process uses local disk space to buffer results before sending them to the NAS.   I extended the partition to about 5GB and the problem went away.

Backups are now being sent to the NAS correctly. Two at the same time even!




I spent today figuring out how to setup the development environment for the SpoonPhone.  It was pretty straightforward with a few funnies from BeSpoon, and there was a lot to learn.  For example, Eclipse is OUT, and Android Studio is IN.

As usual I wrote down the complete installation process in detail so there is some chance I can do it again.

Setting up Android Studio for the BeSpoon Android Phone

I couldn’t find any Android code that would import into Android studio, or Eclipse.

I wrote to BeSpoon, and got a “it all works” answer, which is less than I was hoping for.  Obviously I have to try and track down the cache of working code on the BeSpoon site.

———

So David and I see different things on the BeSpoon Forum Site.  Why is that?

David downloaded the latest stuff from the site.
Now I can load it into Android Studio, but I get this message:

Gradle ‘UWBLogger’ project refresh failed
Error:The project is using an unsupported version of Gradle.

Clearly you have to be a lot more clever than me to make this work.

So I swapped to Eclipse and was able to download UWBlogger, but it would not build either.

Errors occurred during the build.
Errors running builder ‘Android Pre Compiler’ on project ‘MainActivity’.
java.lang.NullPointerException