Author: crackingcontraptions_3voi0v

Conversation with Bob Mayo about web dev tools

Posted on by crackingcontraptions_3voi0v

extracts from emails exchanged with Bob Mayo, starting April 18th, 2014

My current stack is:

Jade (template language)
Express (web framework)
Nodejs (server-side runtime)
Mongoosejs (database object modeling)
MongoDB (database)
There should be tutorials with this exact stack, perhaps advertised as node or express tutorials.
The example on the front page of http://nodejs.org/ is a place to start.

Next step could be http://expressjs.com/guide.html

–Bob

Thermoelectric generators and materials that might fit on a ring

Posted on by crackingcontraptions_3voi0v

Energy & Environmental Science Facebook page

This is the one from Korea Advanced Institute of Science and Technology (KAIST):
Wearable thermoelectric generator could extend your smartwatch’s battery life
Thermoelectric generator on glass fabric for wearable electronic devices

Tin selenide
Ultralow thermal conductivity and high thermoelectric figure of merit in SnSe crystals
A Great Improvement in Thermoelectric Material Found
Surprising Material Could Play Role in Saving Energy
However, this material appears to be most useful at hightemperature.

4mm square Peltier

Energy scavenging ring project

Thinking about how to make a power supply to maximize the power from a coin cell

Posted on by crackingcontraptions_3voi0v

I wrote this email on 6/14/13:

————————————
I think the best way to measure power consumption is to implement the Linear Technology fuel gauge / coulomb counter IC that we have on TS05b. Once we know the number of coulombs that have been consumed then we have to look at the current draw to de-rate the battery because of the power lost through the battery’s internal resistance. Hopefully battery life will be long enough that it’s not practical just to wait for the battery to run down to see how long it lasted (hopefully it will be many months).

I want to look into using a regulator to draw 0.19mA from the coin cell for longer periods to charge a big capacitor so that the capacitor is what powers devices when they come on. There would have to be a second regulator to buffer the supercapacitor output.  It’s hard for me to believe that somebody isn’t already making an all-in-one IC to do this but I can’t find it. There are several very interesting energy harvesting IC’s from Linear.

This device might work really well: http://cds.linear.com/docs/en/datasheet/3105fa.pdf. The drawback is 80% efficiency at 0.2mA which might approach the loss from the battery’s internal resistance, but having regulators will make the design a lot more stable than just running off a battery, and the battery can be used even when its voltage gets very low. This device has a power adjust pin (MPPC) that can be used to prevent too much current from being drawn from the battery. The boost voltage would be set to maximum (5.25V) to charge a supercapacitor and then that voltage would drive a buck-boost regulator (maybe http://cds.linear.com/docs/en/datasheet/3534f.pdf) to output the system voltage (maybe 1.8V or 2.5V). Since the LTC3105 will work with an input as low as 225mV we can completely drain the coin cell. The absolute maximum input voltage of the LTC3105 is 6V so putting two CR2032 in series (to increase capacity) is questionable. At 20 degrees C the output of a CR2032 is 2.9V but at 60 degrees it is 3.2V.
Or maybe it’s best just to put a big ceramic cap across the battery to minimize pulsed current and have no regulator. That’s probably what everybody else is doing.
————————————-
Now there are more energy harvesting products from LT. Here’s the portfolio: http://www.linear.com/parametric/Energy_Harvesting

Article: How much energy can you really get from a coin cell?
http://www.embedded.com/electronics-blogs/break-points/4429960/How-much-energy-can-you-really-get-from-a-coin-cell-

The article references this white paper from TI entitled Coin Cells and Peak Current Draw: http://www.ti.com/lit/wp/swra349/swra349.pdf
I assume for now that the way to achieving the longest battery life possible is to extract the most energy possible from the battery, and therefore the highest priority is to limit the amount of current drawn from the battery. The regulator chosen must limit the current drawn from the battery to 200uA or less, but must be able to deliver 300mA in short bursts.
The acronym to look for when selecting a device is MPPC – Maximum Power Point Control. To use the MPPC feature in a regulator, I think the coin cell must be used as the the energy harvesting source. The “battery” powering the regulator will be a large capacitor (“supercap”).
To use an energy harvesting source, such as a thermo-electric generator (TEG), multiple regulators would have to be used.
TI bq25504 (datasheet http://www.ti.com/lit/ds/symlink/bq25504.pdf) looks to be a flexible device. The startup voltage is 330mV but it will run down to 80mV. However, it can only supply about 80mA. A capacitor on the output might be able to absorb the 300mA spikes.

TI paper: Indoor Light Energy Harvesting Reference Design for Bluetooth® Low Energy (BLE) Beacon Subsystem. It uses a bq25505 and CC2541.



Papers that might contain relevant information:
Development of a Wearable HRV Telemetry System to be Operated by Non-Experts in Daily Life
Using a Supercapacitor to Power Wireless Nodes from a Low Power Source such as a 3V Button Battery
Parallel Battery Configuration for Coin Cell Operated Wireless Sensor Networks
A 700-uW Wireless Sensor Node SoC for Continuous Real-Time Health Monitoring
Battery Capacity Measurement and Analysis using Lithium Coin Cell Battery
Ultra Low-Power Smart Medical Sensor Node for In-Body Biomonitoring
Power Management Subsystem with Bi-directional DC to DC Converter for μ-Power Biomedical Applications


To be continued…

Preliminary thinking about small batteries in July, 2013 while discussing making the smallest possible thing finder

Posted on by crackingcontraptions_3voi0v

Battery

http://tclbattery.en.ec21.com/Polymer_Lithium_Ion_Battery_Cell–604293_604294.html https://www.sparkfun.com/products/11316 http://www.powerstream.com/thin-lithium-ion.htm http://www.aliexpress.com/item/Wholesale-Small-Rechargeable-Cylindrical-Lipo-Battery-3-7v-45mAh-60220-100pcs-lot/707397136.html http://www.aliexpress.com/item/Wholesale-3-7V-40mAh-PL031220-Small-Rechargeable-LIPO-Battery-100pcs-lot/707964273.html

 This is an interesting battery: http://www.fdk.com/battery/lithium_e/pdf/data_sheet/coin_p_type/CR1.3N_spec-sheet.pdf.

But it’s too high.

With this battery: http://www.digikey.com/product-detail/en/BR-1225/P183-ND/31915the enclosure could be 1/2″ in diameter and all the components could sit on top.

Buzzer

This buzzer claims almost 90dB at 4kHz.http://www.aliexpress.com/item/RUIDA-ELECTRONC-BUZZER-SMD-3V-5x5x2-5mm-PIEZO-TRANSDUCER/754733076.html

Layout

The TI BLE SOC is 6mm square. The new Invensense IMU is 3mm square. We need a 1206 capacitor and space for the antenna. Maybe the total size could be about 1/2″ by 1/4″. How would connection be made for programming? It would need pads and a special fixture to fit into.

Beeper

This beeper only draws 3mA but the rated voltage is 9V (78db) so at 3V I’ll bet it barely squeaks: http://www.aliexpress.com/item/SMD-120025F-09041TJ-SMD-piezo-disc/623852162.html. And it’s really big. I think it’s better to go with a low voltage, electromagnetic beeper (shown in the drawing, 5mm x 5mm) and just give it really short bursts of pulses. With a short pulse duration, short burst, and long duty cycle (perhaps once every three seconds) the power consumption may be acceptable.

Current Consumption

CC2541 CC2540
C
o
r
e

c
u
r
r
e
n
t

c
o
n
s
u
m
p
t
i
o
n

 Operating voltage 2V – 3.6V 2V – 3.6V
Shutdown current
Idle current
Max current
Task 1 current
Task 2 current
Task 3 current
RX mode, standard mode, no peripherals active, low MCU activity 17.9mA 19.6mA
RX mode, high-gain mode, no peripherals active, low MCU activity 20.2mA 22.1mA
TX mode, –20 dBm output power, no peripherals active, low MCU activity 16.8mA
TX mode, –23-dBm output power, no peripherals active, low MCU activity, MCU at 250 kHz 21.1mA
TX mode, 0 dBm output power, no peripherals active, low MCU activity 18.2mA 27mA
TX mode, –6-dBm output power, no peripherals active, low MCU activity, MCU at 250 kHz 23.8mA
TX mode, 4-dBm output power, no peripherals active, low MCU activity, MCU at 250 kHz 31.6mA
Power mode 1. Digital regulator on; 16-MHz RCOSC and 32MHz crystal oscillator off; 32.768-kHz XOSC, POR, BOD and sleep timer active; RAM and register retention 270uA 235uA
Power mode 2. Digital regulator off; 16-MHz RCOSC and 32MHz crystal oscillator off; 32.768-kHz XOSC, POR, and sleep timer active; RAM and register retention 1uA 0.9uA
Power mode 3. Digital regulator off; no clocks; POR active; RAM and register retention 0.5uA 0.4uA
Low MCU activity: 32-MHz XOSC running. No radio or peripherals. Limited flash access, no RAM access. 6.7mA 6.7mA
P
e
r
i
p
h
e
r
a
l
 Timer 1. Timer running, 32-MHz XOSC used 90uA 90uA
Timer 2. Timer running, 32-MHz XOSC used 90uA 90uA
Timer 3. Timer running, 32-MHz XOSC used 60uA 60uA
Timer 4. Timer running, 32-MHz XOSC used 70uA 70uA
Sleep timer, including 32.753-kHz RCOSC 0.6uA 0.6uA
ADC, when converting 1.2mA 1.2mA


Battery Power

As I look at the capacity of these coin cells and the power requirements of the components, I don’t see how it could work for more than a few months. The IMU draws 6.4uA with the accel running at 1Hz and the CPU needs 0.5uA with all clocks off just for RAM retention, and the sleep timer needs 0.6uA with the internal RC oscillator. If the crystal oscillator is running it needs 60uA-90uA. Whatever “BOD” is it takes more than 200uA.

 Hopefully the IMU has a deep sleep function to get its power consumption way down.

 At least things look good for making AA-battery-operated anchors to put around the house. They could potentially last years with a lithium AA battery (more than 3000 mAh).

This paper has a table that lists the power consumption for various medical devices and how long they typically last using a CR1025, which is the battery I have been considering.

I also attached the paper.

 If the battery is 10mm diameter the enclosure has two be at least another 1mm thick so the diameter will be at least 12mm. The height will have to be at least 7mm.

Inline image 1



























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.