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?