Month: April 2014

Mik muses about making a Dewbly or other combination in July, 2013

Posted on by crackingcontraptions_3voi0v
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. 

7/16/13
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:
  1. How much space has to be allocated for the radio and ant?
  2. What are the on-body requirements. 
  3. How are the transmissions impacted by walls, iron, tile, bodies etc.
  4. What’s the power requirement to maintain a location network?  (One ranging check costs X mW?)
  5. How does it impact WiFi etc?
  6. How accurate is ranging/locating in practice.
  7. API:  show us the interface spec.  SHOW US the interface spec.  When can we get  the implementation code.
  8. Can we get a full definition of the chip interface?
  9. What is the data rate just for sending data.  
  10. 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. 

Development environment

Posted on by crackingcontraptions_3voi0v
TS05 taught me how easy it is to get all the various programming tools out of step with each other.  I’d often end up running around looking for bugs that were caused by inconsistent definitions of the same object, but expressed in different languages.  So it would be cool to find an easy way to share that information in common definition files.
As the code got more complicated I also found it was easy to make an update that broke something, and I didn’t know it was broken until weeks later when eventually I tripped over it and managed to track it down.  I want to try and use a dev. system that has facilities to write test code and have it run every time the code is changed to make sure that the old stuff hasn’t stopped working.
Lastly I’d like to find some way to print out debug statements without clogging the uC with USB drivers, and two tons of print statements that fill up the memory.

These are now all standard techniques in the industry, but it all passed me by, and yet it would be good to try and drag myself into at least the 20th century.

I’m trying to figure out how to set up a general purpose development environment using Eclipse, that has at least some of these twiddles in it.  It makes sense to get them in place early, rather than after the fact.  It is really, really complicated to figure out what all the component sub-systems are, and how they fit together, but it is very cool.  If I can get it to work then I can imaging making a small change to a header file and having all the firmware, Java PC code, Ruby web server code, and Python hardware test code (and maybe the hardware definition too) automatically recompile so it’s all consistent.  Well it’s a goal 🙂
Today I managed to compile, run and debug a C program for the STM32F4.  In the same tool I can have elements written in C, Java, Ruby, and Python for the PC, and cross-compile C for an ARM.  Now I have to figure out how to cross-compile for the Nordic.  I might try to cross-compile for the Atmel too, just so we can get all our old and smelly eggs into the one basket!

Wearables, Drones Scare Americans

Posted on by crackingcontraptions_3voi0v
http://www.informationweek.com/strategic-cio/executive-insights-and-innovation/wearables-drones-scare-americans-/d/d-id/1204591

Respondents exhibited worry about technologies that have attracted significant recent investment in Silicon Valley. Fifty three percent of Americans believe society will suffer if “most people wear implants or other devices that constantly show them information about the world around them.” About 37% disagree and see wearable and implantable devices as a change for the better. Asked whether they would be interested in riding in driverless cars, only 48% would do so given the option.

David’s first Dewbly email

Posted on by crackingcontraptions_3voi0v

I am trying to figure out the power consumption of the DW1000. There are 3.3V supplies and 1.8V supplies. The Rx and TX supplies are separate. However, there is only one number given for current consumption for Rx and Tx. There are on-board linear regulators for making 1.8V, but there are options for using an external switching regulator. There also seems to be an on-board switching power supply. It will take me a while longer to figure it out.

The spec provides a recommended PCB stackup and routing for part of the RF section. They specify a chip antenna: http://www.digikey.com/product-detail/en/AH086M555003-T/587-2204-1-ND/2002902. It’s 8mm x 6mm x 1mm. That must be the antenna off to the side of this board.


I think they show the same side of the board twice but one photo has the RF shield installed.

This is the recommended RF layout.

There’s almost enough information to design our own board.
….
The modules will be available in mid-June from Digikey. Maybe if one were to beg and pay lots of money one or two could be had now directly from DecaWave, but it’s less than two months away.

It’s better to use the modules from the standpoint of knowing they are wired up correctly and the layout is correct etc – but they are not plug-and-play. Either a mess of wires has to be soldered onto the sides of the module or a motherboard has to be made to hold the module.

….

The module has a chip antenna. It’s the device that says “T03” on it. The eval kit has an SMA connector the the dog-ear antenna screws on to.

Designing an antenna into a wrist band must be a very difficult task. Perhaps that’s a good reason to try to do it.

I don’t think the UWB will interfere with the BLE signal since they are not the same frequency but I don’t know much about it. There’s a good way to find out.

How small do you want our first DW-BLE board to be? Wrist-worn enclosure-sized?
….

dweeble.com – taken
dooble.com – taken
dewble.com – available
dewbly.com – available
dewable.com – taken
blebug.com – available
blebugger.com – available
buggerme.com – taken

Since I’m generally clueless and don’t know about the pitfalls, I don’t think making our own board is such a big deal. The hard part is selecting the right microcontroller and interfacing it with the DW1000. The antenna can be either the chip antenna or copy their dog ear, or connect any suitable UWB antenna to an SMA or SMP or whatever. If we make our own board it can have a large breadboarding area, and desired connectors.

The DW ST1000 PowerPoint shows a header with JTAG, USP and SPI. The uC is an ST32F105. $600 for two boards feels like robbery. However, you could connect up other stuff to it as long as it’s SPI. It would be the fastest way to try it out, and in the long run perhaps the least expensive. One big issue is the high-gain antenna won’t give real-world (chip antenna) results.

Some “Requirements”

Posted on by crackingcontraptions_3voi0v

So the obvious path to a fast rejection of DW is to buy their ready-to-go eval kit with the K9 antennae. If it fails we are done for an outlay of $600 and a little software. If it works it’s pretty much at end of life unless we can reprogram it to be some sort of base station.

If we buy modules then we have to make some sort of carrier board like you did for TS02a using the DW modules. That’s ugly and a lot of work, but it perhaps has some slightly more lasting utility, and we get to see how well a properly designed antenna operates. I think it will be a while before I have done the BLE part so waiting till June for modules is no big deal – indeed who knows when I will manage to get back to the US and carry on, though I should be able to work quietly in the UK for a while.
Building our own board with a chip and making our own antenna seems like a bridge too far, and there are too many things that have to work on your side of the house before we can test out the basic idea.
I think flexibility to try a whole bunch of fail-as-fast-as-possible experiments is the order of the day. We need an experimental apparatus more than anything else. “Pretty” isn’t important.
I think the first DWBLE (Dewbly?) board should attempt to meet the following goal (in decreasing importance):

  1. It should above all be easy to debug, so an idiot like me has to be able to attach debugger, and poke it with a scope, when you are not nearby to do it for me; 
  2. It should be at least possible to continuously measure the power and plot a graph against time (well wireless event really). I need to be able to compare different duty-cycles and protocols with some confidence – and do it pretty automatically each time I change a bit of code. It would be upsetting to work on the assumption that something was low-power to find out much later that I had it wrong. Can we count microCoulombes somehow? 
  3. It should be small enough to wrap up with duct tape and velcro to my wrist – even if it needed a D-cell for power 🙂 Have to try and understand the near-body propagation issues. We didn’t really test that with the BeSpoon. 
  4. It should be easy to add warts. If it works well enough we might want to solder on extra off-the-shelf breakout boards with beeper, vibrator, IMU etc. 

These are just my ideas, and I know they might be way, way beyond the pale. Tell me what you think about each, and what you think is missing.

Privacy

Posted on by crackingcontraptions_3voi0v

This blog can’t be found by search engines, or looked at by anyone but us (and the NSA I guess).  You can create new posts, edit mine, and add responses.

I think there is a way to store files of useful reference information.  I’ll figure that out.