http://senseg.com/technology/senseg-technology

I wonder if it would be possible to use something like this to create a range of different haptic feedback experiences to a ring/wrist-band wearer.  Several different types of discrete alarm?
I imagine the power requirements are too large, but it's interesting.

Senseg patented solution creates a sophisticated sensation of touch using Coloumb’s force, the principle of attraction between electrical charges. By passing an ultra-low electrical current into the insulated electrode, Senseg’s Tixel™, the proprietary charge driver can create a small attractive force to finger skin. By modulating this attractive force a variety of sensations can be generated, from textured surfaces and edges to vibrations and more.Unlike effects created by mechanical vibration and piezo solutions, Senseg is silent. With Senseg application developers have precise control of the location and type of effect users experience. What’s more, Senseg technology scales from touch pads, smart phones and tablets to the largest touch screens without increasing manufacturing complexity.

//Mik
General interest articles

PsiKick is a two-year-old startup coming out of research efforts at the Universities of Michigan, Virginia, and Washington that is preparing a wireless sensor module for batteryless operation based on sub-threshold circuitry. The module includes an RF transceiver, a microcontroller with sensor front end, and energy-harvesting blocks, making it a self-powered sensor platform suitable for a wide array of applications. A second-generation version of the design, based on standard CMOS processing, entered tape-out earlier this year, so a demonstrable product is likely by year’s end.
The power requirements for this module are astoundingly small, some 100 to 1000 times less than that of comparable sensor platforms currently available. In full operating mode the processor only uses 400 nanowatts while the RF transmitter generates 10 microwatts for an effective range of 10 meters. The module’s supply voltage can be anywhere from 0.25 to 1.2 V, making it a good match to the output capabilities of most energy harvesting methods.

PsiKick

SoC Specifications

Fully Integrated Wireless SoC
Tx Data 1 Mbps
Tx Power 10 Microwatts
Tx Range 10 Meters
Supply Voltage 0.25 V to 1.2 V
Off-Mode Current ~1 nano-Amp
Rx Sensitivity -86 dBm / -45 dBm
RX Power 150 Microwatts / 100 Nanowatts
CPU Mode Power 400 Nanowatts
Size 3.5 mm x 3.5 mm
Process Standard CMOS
//Mik

There are five objects in the debug toolchain:
IDE -> gdb-for-target-architecture  -> debugger-hw-server -> debugger-hw -> target-uC.

Here are some examples.

  1. IDE:  e.g. Atmel Studio 6;  Eclipse; IAR
  2. gdb-for-target-architecture: e.g. gdb-earm; gdm-nordic
  3. debugger-hw-server: e.g. st-util
  4. debugger-hw: e.g. AVR JTAGICE; SEGGER
  5. target-uC: e.g Atmel at2560, STM32F4xx

Items 3,4 and 5 are usually proprietary and supplied by the manufacturer of the target-uC (5).  A proprietary toolchain can cost $3K and way above.  It can be hobbled to limit how long it can be used for, or how big a program it can generate, or some other annoyance. 

There has been an open source attempt to standardize them, so the same IDE can be used to program and debug multiple different targets.  i.e. you don’t have to learn, and simultaneously use a bunch of different IDEs for each processor you are working with.  For example,  if you are writing code to communicate between a PC and and ARM chip then you would normally have to have two IDEs open – one for each host.

GDB with GDB Server

Architecture

So what do these five parts do, and how do they talk to each other?


Working backwards from the chip:

The debugger-hw uses one, or more “standards” like JTAG, or SWD, for connecting to the chip.  The physical pinout of each debugger-hw box seems to be different, and chosen according to the needs of the board layout person.  So Atmel provides a “standard” JTAG cable.  But  to connect an Atmel-JTAG to an ST-uC you have to build a squid cable.  But why are not common flavors of squid cable for for sale?  Tag Connect

Item 2 (gdb-for-target) talks to 3 gdb-hw-server using one of a variety of protocols.  Examples are J-Link, GNUARM J-Link; GNUARM-OpenOCD; OpenOCD via pipe; TCP-IP; …   I have no idea what the strengths or weakness of each is.  TCP-IP allows the debugger and the debuggee to be hosted on different physical machines.   gdb-for-target has a command line interface (CLI) for unix aficionados. 
IDEs are normally source-level graphical debugging systems.  They generate CLI commands themselves and send them to gdb, catch the results, and display them graphically.   i.e. A cursor moves over the source code to indicate the current program counter.

My intuition (unconfirmed by evidence) is that gdb-for-target-architecture is just a generic (open source?) gdb that has been given an architecture specific config-file, so it understands register names and positions, memory organization and so forth.

There also appears to be a generic open-source debugger-hw-server, but it isn’t well-supported and I find it hard to understand how to set it up for a particular debugger-hw



My notes on making a debug toolchain


This is how you turn the Atmel ICE JTAG debugger into an STM32F4xx SWD debugger.
I used these two documents to figure out the pin assignments.

  1. USER MANUAL for Discovery kit for STM32F407/417 lines (page 14)
  2. Atmel ICE Physical Interface

First abortive attempt

So I connected it up as per the numbers, like this.
But these connections make no sense to me based upon what is written on the back of the 10-pin JTAG connector.
For example SWDIO on the SWD is linked to JTAG pin-2 which is GND.

I think my problem stems from the 10-pin AVR JTAG and the 10-pin ARM JTAG being different.

Second attempt – still under development

SWD ARM JTAG AVR JTAG
1 Vdd 1 Vcc 1 TCK
2 SWCLK 2 TMS 2 GND
3 GND 3 GND 3 TDO
4 SWDIO 4 TCLK 4 VTref ?
5 NRST 5 GND 5 TMS
6 SWO 6 TDO 6 RES
7 RTCK 7 Vcc
8 TDI 8 NC
9 GND 9 TDI
10 RESET 10 GND
So maybe the connections should look like this.

I’m trying to figure out the maximum amount of data that we might need to store in one day.

My worst case usage scenario ignores battery life, and collects data at the maximum sustainable rate.

TS05 collected accelerometer data at 10Hz.  I was able to work perfectly well with that, but let’s assume we may need to log at 100Hz, i.e. 100 samples from all the sensors each second.  So I’m going to estimate the maximum number of bits in each sensor sample.

Timestamp

At 100Hz, the time field needs to measure a new record every 10 ms.   If we assumed we required an accuracy of 1uS.  A 64 bit time field can represent 500,000 years.  8 bytes!

Accelerometer

Most accelerometers produce about 12 bits for each of the three axes.  Let’s assume 16 bits/axis = 6 bytes.

Compass

A magnetometer is similar, but it responds very slowly so polling at 100Hz is probably pointless.  Anyway, let’s say another 6 bytes

Barometer

A barometer is  slow to respond – let’s assume 10Hz is the best it can do, and you get 2 bytes of P, and 2 of Temp.  There’s 4 bytes

BLE RSSI to one anchor

If you were taking RSSI measurements from the BLE beacons, each measurement is 16 bits, and let’s assume the beacon address is a full iPv6 address (16 bytes), and we don’t do anything smart to compress it. That’s 18 bytes.  Each polling cycle would hit a different beacon.  I’d expect to rotate through some subset of the beacons.

DW Range to one anchor

We use the relatively inexpensive BLE measurement, and any previous knowledge of the layout to guess the best three anchors to range.  This is only done when the user settles because it’s too power intensive.  But for the sake of argument let’s say it is gathered at the same  rate as the RSSI and in the same format.  That’s another 18 bytes.

Battery Coulombs?

Battery status is 2 bytes.

Adding it up

8+6+6+4+18+18+2 = 62 bytes.
At 100Hz we generate 6200 bytes /sec.  and 535,680,000 / day = 536MB.

When the subject comes to a complete rest then the device figures out it’s position and goes to sleep.
If we assume that people are stationary for 80% of their day. (pulled that number out my arse), and no samples will be gathered, then we will only generate data 20% of the time, and only produce 107MB / day.

At 10Hz it would be 10MB / day.

How much power would this consume?

We talked about how to record data. A MicroSD card is too large for a ring, obviously. However, a uSD card is good because it contains a controller that takes care of things like mapping bad memory sectors and doing load leveling. It’s not clear to me whether or not these functions need to be performed with a discrete flash memory IC.


Here is an SPI-connectable 1G-bit flash chip from Micron that is only 6mm x 8mm:
http://www.digikey.com/product-detail/en/N25Q00AA13G1240E/557-1557-ND/3874273
This device has 4 stacked 256 M-bit die. The memory is therefore arranged as 256Mbx4, or 128 M-Bytes. 

I am hoping that this device could be used both for data storage and program storage. For example, if the Dialog  DA14580 were used, the program could be loaded from the memory device to the 42kB system RAM.

If there were swapping involved that would most likely kill the power budget. After development is completed the OTP memory of the DA14580 could be used. Maybe an OTP memory saves some power.

Writing data to a flash memory takes a lot of power. Maybe it’s not practical to consider it.

Adesto 32Mbit memory, 6mm x 6mm BGA:  http://www.adestotech.com/sites/default/files/datasheets/doc3686.pdf

David’s email about DecaWave.

April 16

30 dev kits ready for shipment: http://www.digikey.com/product-search/en/rf-if-and-rfid/rf-evaluation-and-development-kits-boards/3539644?k=decawave. Only $606.67.

April 18

Two EVK1000 have sold sometime in the last two days. Now only 28 available

April 28

Today there are 18 EVK1000 available and the price has dropped slightly to $590.91. The sales rate is about one per day.

The DWM1000 is now listed at Digikey for $31.84 each. There’s a product brief. There’s no stock yet.
There are 3242 DW1000 in stock today. 3482 were in stock on 4/10/14. The sales rate has increased from 6.1 per day from March 12 – April 10 to 20 per day since .April 10.
I feel the urge to buy a Dev kit.

I tripped over this brochure in my travels.  My eye was drawn to the bit that said that the update voltage was 0.5 micro-amps per cm2, and that it runs off 5V.  Maybe this is outside the realm of possibility, but I love the idea that it draws no current when it is not updating.  Now this is a 33-segment display, and not a bitmap, but I assume you can have whatever you want if you pay enough.

http://media.digikey.com/pdf/Data%20Sheets/BNS%20Solutions%20PDFs/SC009221_Br.pdf

I’d quite like to futz around with a Dev Kit to see how much power it draws in practice.
DigiKey has one for $70
http://www.digikey.com/product-search/en/programmers-development-systems/eval-and-demo-boards-and-kits/2622039?k=BNS

I have poked around a bit and made a list of the BLE SOCs I could find easily. Then I tried to figure out what chip they are using.

Bluegiga

Bluegiga’s BLE112 and BLE113 – is an 8051-based TI module!

Panasonic

Panasonic’s PAN1323 is an 8051-based TI module!

Nordic

Nordic’s nRF51822

Cambridge Silicon Radio

CSR µEnergy® Product Family -Processor is TI CC2540 – 8051-based processor

Dialog Semiconductor

Just a few snippets drawn from David’s email of April 28, 2014 at 9:58 PM
DA14580 – http://support.dialog-semiconductor.com/downloads/DA14580_DS_v1.63.pdf

Memories

  • 32 kB One-Time-Programmable (OTP) memory
  • 42 kB System SRAM
  • 84 kB ROM
  • 8 kB Retention SRAM

Other than the lack of flash it is an attractive solution. The smallest package is only 2.5mm and only a few board components are needed.

EM

EM9601 – http://www.emmicroelectronic.com/webfiles/product/other/EM9601_FS.pdf
Well spotted David!  EM – http://www.emmicroelectronic.com/Sitemap.asp They seem to be based in Sao Paulo. The web-site is a bit amateurish. They have a wide variety of products, and don’t seem particularly focused on BLE. However their BLE system is based on the STM32F051x8 32-bit CortexTM M0 which is a good feature. It’s pretty similar to the Nordic system. 200 Ohm differential antenna – does this matter? It’s a BGA.
Typical current consumption:
12mA Tx current at 0dBm output power 13mA Rx current 14µA in connected BLE Sleep Mode (including Host MCU current) 10µA in Deep-Sleep Mode (with memory retention)
64K of Flash, and 8K of SRAM (woo hoo) and a Calandar RTC!

ST

BLUENRG: Announced September 2013.  And somehow I managed not to hear about it … or did I just forget.
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00092683.pdf
64K Flash and 12K
8.2 mA maximum TX current (@0 dBm, 3.0 V)
Down to 1.7 µA current consumption with active BLE stack
Accurate RSSI to allow power control. Uh huh 🙂
Cortex-M0
Demo boards  the one with the rubber antenna is already available from DigiKey, but the dongle version is not.  Same board is on backorder from Mouser.
EWARM Compiler 6.60 version is required for building the BlueNRG_DK_x.x.x demonstration applications.  Oh joy.  IAR again.  $3500
User docs for kits.

Which actual ST ARM M0 system is the Bluetooth chip?  32Lx…?  I still have not seen any evidence that it can be programmed.

The STEVAL-IDB002V1 is a product evaluation board based on the BlueNRG device. The BlueNRG is a Bluetooth low energy 4.0 compliant low power network coprocessor. The STEVALIDB002V1 is composed of an RF daughterboard and a microcontroller motherboard. The RF daughterboard features the BlueNRG device, an SMA connector for an antenna or measuring instruments and an SPI connector for external microcontroller. The motherboard is based on the STM32L, acting as external microcontroller driving the BlueNRG device. A JTAG connector allows development of firmware on the microcontroller.

I went to TI’s booth at EE Live earlier this month. I asked about the ARM-based BLE SOC and he said he could not tell me anything about it unless I signed an NDA. Under NDA, he said he could tell me something interesting.

I called TI and opened a Service Request. Today I received this email:

———————
RE: Service Request # 1-1399505934

support@ti.com
3:58 PM April 30, 2014

Hello David,

Unfortunately, in order to obtain an NDA, you will need to contact an authorized distributor.  The authorized distributor will obtain the necessary information and start the process with the local field sales rep if need be. I have provided a list of our authorized distributors in your area below. I apologize for any inconvenience this may cause you.

Arrow- 800-777-2776  www.arrow.com
Avnet- 906-632-4500   www.avnet.com
Digikey- 800-344-4539  www.digikey.com
Mouser- 800-346-6837   www.mouser.com

Best Regards,
Matthew Fenley
———————–

I’ll call Digikey.