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.
I installed Ubuntu on my SSD as a dual boot. Now Windows won’t boot. So now I have to restore my SSD and re-install a bunch of other stuff.
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!
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.
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.
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.
Backups are now being sent to the NAS correctly. Two at the same time even!
I bought a $20 laser rangefinder. My, it does it make things easier!
The laser gets confused below about 50cms. The UWB seems to under-read by about 25cms.
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.
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’.