Month: June 2015

Animated landscape light spec. thoughts

Posted on by crackingcontraptions_3voi0v
I googled your landscape lights idea, and didn't find anything that quite matched.  I saw lots of lame blinkys that were either not solar powered, or wireless.

My two conclusions were:
  • RELIABLE zero/low-power person detection is required to avoid annoying operational behaviors.
  • the value of various animation effects is subjective, and probably minimal
In detail:
If the lights are stretched in a straight line down a path, then that's a special degenerate case of a mesh that we'd have to recognize.
I was thinking about high-value usage cases.  Basically all I could come up with was lights that came on when you started to walk down the path, and went off when you went away.   Maybe for airplane-style "emergency egress".  The easiest way to do that would be to put a PIR on every light.   That would allow multiple subjects to activate their own pools of light – but why?   Most of the time you want the whole path to turn on, and turn off when you leave.   All can be done with local PIR-kind of things that detect movement for a couple of light-radii..
The dynamic effect employed to turn them on/off is mere fluff with no real value that I can think of.  That could all be done with one BLE broadcast, and a watchdog timer to make sure they turn off.
The simplest animated effect would be to slowly fade up/down lights in sequence.  To do more elaborate effects (which I think would be irritating after a while) more careful timing, taking into account spacing would be required, and of course an accurate clock to sync them.  All pretty straightforward I think.
To detect where a person is on the path would require a person sensor on each light.  Just putting person sensors on the path ends may be cheaper but then you have two kinds of light to install, and perhaps to "aim"  which makes it a slightly more complicated process for the average punter.
One way to do proximity detection might be simply to look for changes in RSSI between two gatepost lights.  That would probably be unreliable, and would probably be triggered by waving trees or shrubs.
In summary, it all looks pretty feasible to me, but the hard bit is coming up with a cheap, simple and above all reliable, person-proximity detector, and the rest is straightforward, and can be enhanced with software to do very creative things.


//Mik

What latency?

Posted on by crackingcontraptions_3voi0v
I have the basic comms for a mesh working (no actual packet forwarding, but the basic IO is working, i.e. a TS can be in listen, and broadcast mode.
I have rigged up push-buttons to simulate some IMU event.   So when a node senses it has moved  it would fire off a ranging sequence to recompute the revised topology of the mesh.   
So now I can press a button on either node and the other node get's told about it – that's the big breakthroug.  It provides the basic transport mechanism for propagating topology changes throughout the mesh.
So far so good, but of course…
Obviously a node will not advertise changes unless it has some to share, so that side of things should not consume much power.
On the other hand, listening out for advertisements is something you have to do all the time.  After some experimentation I begin to see that the listen overhead is kind of fixed.
If an advert occurs once every 10 ms, then you have to listen out for 10 ms to be sure of hearing a packet go by.  Of course you don't have to listen every 10ms (i.e. continuously) because you could just decide that you are not going to try and catch every advert, and will just listen for one in ten. So you listen for 10ms every 100ms.  On the other hand it requires that the advertiser sends the same packet 10 times at regular intervals.
The consequence of this that you get to choose the trade off between time spent listening, and time spent advertising.   You can advertise once an hour if the receiver listens continuously for an hour. You can listen for just ten minutes continuously if the advertiser sends the same packet 6 times an hour.  What that split should be is determined by the anticipated frequency of transmissions, and the power-budgets.  I'd like to measure thos values.  Maybe we are in the toilet already.
The other consequence of the choice is latency.  If you only design to hear one out of 10 advertising packets, then that means on average you will miss 5 before you hear the first.
So the important thing to decide for our application is how long the application can tolerate to wait before it should hear updates.   
I have paramterised my code so that I can choose any average latency from a few milliseconds out to 5 seconds (i.e. a worst case wait of 10s naively assuming no packet losses).   The longer the latency, the less time spent listening, and that's going to be the battery killer.
It should also be noted that the latency is for one hop.  If it takes 3 hops to get to the edge of the network and thus to the cloud then there could be a 30s wait.

//Mik

Small BLE snag

Posted on by crackingcontraptions_3voi0v
I have made some good progress with the BLE side of things.  I am getting to the point where I am fairly confident that I know what minimal BLE functionality we will need in out device, and more importantly, what size it's footprint will be 56K + 88K for softmachine = 144K Flash and 2K+8K for RAM.  I'm pretty sure the DW code will fit in the remaining space, but it uses an (as yet unknown) bunch of RAM for buffers.

But I have also discovered a snag with BLE.  It's too popular!  I have a bunch of Apple devices within wireless earshot (apartment below), all of which implement Apple's iBeacon protocol (based on BLE).  They are issuing unwanted advertising packets that wake me up many times a minutes, just so that I can ignore them and go back to sleep.

There is a mechanism, called a "white list" that allows you to register the MAC addresses of devices in which you are interested, so that the radio controller can quickly ignore unwanted devices without bothering the processor.  The problem is that that list can only be 8 items long.   It also means that you have to tell each TS the identity of all the other TSs.  So if an unknown wearable suddenly arrives, it won't be in the white list and will get ignored.  But if you don't have a white list, then you get  a storm of advertising packets.
The other problem is that iBeacons appear to keep changing their MAC address so you can't ignore a particular MAC address for very long anyway.   
Below, a list of packets I flagged as unwanted in just 60 seconds.  
60 second tick interrupt
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(0)
on_ble_evt BLE_GAP_EVT_ADV_REPORT – BLACK 88(1)
60 second tick interrupt

S130 advertise, listen and connect

Posted on by crackingcontraptions_3voi0v

It’s been a struggle but I have an S130 simultaneously listening for broadcasts, while advertising, and able to listen for UI connections.

Receiving a broadcast advertising packet from another node called “Z1”.  The example packet contains a maximally-sized 20-byte block of “proprietary data”, i.e. it doesn’t conform to the BLE standard and will only make sense to TS devices.
TS (7) [c7.60.61.56.c1.bf] – BLE_GAP_EVT_ADV_REPORT                              
  T9(2)NAME Z1    Field type and length                                  
  T1(1)FLAGS 04                                                                  
  T255(22)TS_PROPRIETARY_DATA [(20), 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 ]

It requests second block of data from the broadcaster – the so-called scan response data.   (For some reason this appears to come from a different MAC address – 0xbe instead of 0xbf?? )  This block contains the state of the sender’s battery, and the temp – just random bits of data it was easy to provide.
TS (8) [c7.60.61.56.c1.be] – BLE_GAP_EVT_ADV_REPORT
  T22(3)BLE_UUID_BATTERY_SERVICE 100%              
  T22(6)BLE_UUID_HEALTH_THERMOMETER_SERVICE 34C    

Now I use my Android phone and an off-the-shelf applciation to make a “TS_UART” connection to the S130.  TS_UART is a connection that simply sends and receives strings of characters (up to 20).
———————-
UI connected.
———————-

While waiting for some activity on the connection it continues to report broadcast packets…
TS (9) [c7.60.61.56.c1.c6] – BLE_GAP_EVT_ADV_REPORT                              
  T9(2)NAME Z1                                                                   
  T1(1)FLAGS 04                                                                  
  T255(22)TS_PROPRIETARY_DATA [(20), 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 ]                                                                 
TS (10) [c7.60.61.56.c1.c6] – BLE_GAP_EVT_ADV_REPORT                             
  T22(3)BLE_UUID_BATTERY_SERVICE 100%                                            
  T22(6)BLE_UUID_HEALTH_THERMOMETER_SERVICE 34C                                  
TS (11) [c7.60.61.56.c1.c6] – BLE_GAP_EVT_ADV_REPORT                             
  T9(2)NAME Z1                                                                   
  T1(1)FLAGS 04                                                                  
  T255(22)TS_PROPRIETARY_DATA [(20), 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 ]  

I type a string “buddy” into my phone UI and press “send”.  This is the interim mechanism I intend to use to configure each node, and to query it for statistics and so forth.
———————-    
UI received string “buddy”
———————-    

.
.
At the same time, in another typescript window, a peer is receiving broadcast packets from the S130, demonstrating that (with some kludgery) it is possible to send and receive broadcast packets at the same time.

Z1 (22157) [92.3d.42.c2.f1.f8] -62dB BLE_GAP_EVT_SCAN_REQ_REPORT
Z1 (22158) [92.3d.42.c2.f1.f8] -61dB BLE_GAP_EVT_SCAN_REQ_REPORT
Z1 (22159) [92.3d.42.c2.f1.f8] -68dB BLE_GAP_EVT_SCAN_REQ_REPORT
Z1 (22160) [92.3d.42.c2.f1.f8] -67dB BLE_GAP_EVT_SCAN_REQ_REPORT
Z1 (22161) [92.3d.42.c2.f1.f8] -69dB BLE_GAP_EVT_SCAN_REQ_REPORT
Z1 (22162) [92.3d.42.c2.f1.f8] -68dB BLE_GAP_EVT_SCAN_REQ_REPORT
Z1 (22163) [92.3d.42.c2.f1.f8] -67dB BLE_GAP_EVT_SCAN_REQ_REPORT
I have not yet managed to send UI responses back to the phone, but I’m pretty confident that it’s just a small program bug.

The code is a complete haystack, and will take a few days to clean up.

S130 advertiser

Posted on by crackingcontraptions_3voi0v

How slowly everything proceeds! I’m just banging away at getting the right/minimal combination of BLE features into our footprint.

The challenge is to be able to have BLE do three things at the same time:

  1. On some condition (TBD) broadcast a BLE command to peers asking them to to turn on their DW chip for subsequent ranging; 
  2. Listen out for instructions from peers to turn on theDW chip and respond to their subsequent range request; 
  3. Respond to operator commands to set various parameters on the peer. Don’t quite know what they will be, but probably some short UID, role(anchor, wearable, gateway…). 

Being both a broadcaster/advertiser (aka service), and a listener(aka central/application/scanner) is not the standard behavior for Nordic chips.

Recently Nordic created a new soft machine called the S130 which is able to be a broadcaster/advertiser and a listener/scanner simultaneously – albeit in a limited way. The soft-machine is basically an operating system.

TS06 requirements are actually quite modest, but unusual and I’m trying to build them atop the S130, and shoe-horn them into the nRF51822 along with the DW libraries. I think the code will fit OK, but the challenge is likely to be the limited RAM size for buffers.

Since this is a show-stopper until we get the 32K chips (and maybe even then) it’s a priority to see if this can all be done.

So far I have managed to get some trivial programs that generate zero radio traffic, but blink LEDs running atop the S130. This turned out to be more of a configuration nightmare than I thought because there was an errors in Nordic’s “.ld” file they published for the S130. That was several days wasted.

Yesterday I managed to get an advertiser running atop the S130, and I was able to observe it’s adverts were correct using my phone. It’s a simple and almost trivial accomplishment, but a relief to have made a bit of progress.

The next step is see if I can get the scanner side working in parallel with the advertiser.

Pebble “Time” teardown

Posted on by crackingcontraptions_3voi0v
This latest Pebble teardown is really interesting/

https://www.ifixit.com/Teardown/Pebble+Time+Teardown/42382

Image #1Image #1

Highlights

They use an ST + external memory and an external BT chip.  Two chips for their IMU.
This “motor driver” is interesting.  Seems like a lot of effort for a little advantage – if I understand it’s purpose.   DRV2603
It references this “smartstrap” page which seems like a useful thing to know.

This 150 mAh, 0.57 Wh, 3.8 V battery packs a bit less punch than even the smallish 205 mAh, 0.78 Wh battery we found in the Apple Watch. 

That’s also about half the juice of other recent smartwatches, like the Moto 360 and the Samsung Gear Live—but with its e-paper display, Pebble claims that the Time can last up to seven days between charges.

//Mik

Grrr

Posted on by crackingcontraptions_3voi0v

I have been struggling to get any program to run with the s130 softmachine.  The programs just don’t start, and I think they are just generating a fault in the startup code.  This has consumed me for days.  The trick, as always, is to figure out the right google search terms.

Hi,
I’m sorry for the late response. I tried to recreate this problem with gcc when I found that there was a typo in the SD document. The flash origin should be 0x1C000 and not 0x2000 as stated in the documentation. This will be fixed in the next release.