First email from Mik about a Dewbly – 7/12/13
I wonder if a little device that combined DecaWave and BLE radios would be a popular thing.
DecaWave radio remains totally off unless a ranging request arrives from a BLE master.
I wonder about the time sync too. If they have not done it right it could suck more power than it saves. What worries me about that is that all the nodes have to form a network so they can all sync up. If they can’t because the extremes are out of range of one another then what? I’m guessing thay have implemented a controller-area network architecture which is yet another constraint on free-roaming.
Porting the software could be an issue. But I’m guessing that much more of the controller smarts are in the chip nowadays (compared with the Nanotron), so porting should at least be a lot easier. Porting the Nanotron code would have been a nightmare – and it might be a nightmare for DW of course – so good point.
Making a BLE/DW combo is probably not the simplest first step. Their eval kit will let us evaluate simple ranging over a bunch of different indoor conditions, and fortunately we have the NT ranging experience to lean on to guess how good the DW locating would be in practice. One possible way ahead would be to cobble on a DW wart to the TS hardware using the most pragmatic interface we can make work, and simply upgrade everything we have already built to use DW instead of NT. I have all that testbed software for evaluating a range of different locating strategies.
The other thing that (wearily) strikes me is that as soon as the DW chip hits the streets there will be hundreds of folks like us building StickNFind kind of things. This though bangs home the thought that we need to find a niche application – something that nobody else has thought about much that we can kill with clever software. You always need protoype hardware to develop the idea, but probably by the time the app is ready there’s lots of hardware and drivers that you can lean on, and the challenge is doing good ID.
If we were building a FDD(falling down detector) then the need to transmit is only critical (as opposed to desirable) when there is an alarm. The rest of the time we only require ranging when IMU activity stops, and perhaps the very occasional upload to train pattern recognition.
I think at this stage I want to know the following:
- How much space has to be allocated for the radio and ant?
- What are the on-body requirements.
- How are the transmissions impacted by walls, iron, tile, bodies etc.
- What’s the power requirement to maintain a location network? (One ranging check costs X mW?)
- How does it impact WiFi etc?
- How accurate is ranging/locating in practice.
- API: show us the interface spec. SHOW US the interface spec. When can we get the implementation code.
- Can we get a full definition of the chip interface?
- What is the data rate just for sending data.
- Are there any special requirements for FCC approvals? (not important but just crossed my mind)
What we do (have done int he past) is build proof-of-concept prototypes that scope out the field of problems and opportunities. Basically what we have to sell is knowhow. What is apparent to me is that our knowhow is not worth much until people start to see how hard it is – by which time they have momentum.
1 thought on “Mik muses about making a Dewbly or other combination in July, 2013”
Mik Lamming says:
Did I write that. It almost seems cogent.