This is the most boring demo of them all.  This program simulates an iBeacon, i.e. it simply advertises itself to any other nearby BLE masters.  In this case I’m using an Android phone running a general-purpose BLE scanner.  This video catches the moment when the dev. board starts up, and broadcasts.  Immediately the phone displays the content of the broadcast.

Here are a pair of programs led_radio and button_led.   This uses the raw radio controller, not the BLE soft-machine.  Pressing a button on one sends a simple packet to the other radio which lights up the corresponding LED.

Here’s a program that tests the buttons,

int main(void){    // Configure LED-pins as outputs, and buttons as inputs with pullup    nrf_gpio_range_cfg_input(BUTTON_START, BUTTON_STOP, BUTTON_PULL); nrf_gpio_range_cfg_output(LED_START, LED_STOP);      while (true)    { if (! nrf_gpio_pin_read(BUTTON_0))  nrf_gpio_pin_set(LED_0);  else  nrf_gpio_pin_clear(LED_0); if (! nrf_gpio_pin_read(BUTTON_1))  nrf_gpio_pin_set(LED_1);  else  nrf_gpio_pin_clear(LED_1);    }}

David: I only need to add the programming header. And some LEDs. The regulator outputs 1.83V, supplied by a USB-B connector.

Here’s a program that drives the UART via a Silicon Labs USB to UART Bridge connected to putty.

/**********************************************************************
 * MIK’s version operates at 115K2 RTS/CTS 8N1
 **********************************************************************/

In case we have some TS06.1 hardware together I thought we should have a test program ready to try out.  I’m not sure what pins to assign to LEDs, but that’s easy to change.

int main(void)
{
// Configure LED-pins as outputs
nrf_gpio_cfg_output(LED_0);
nrf_gpio_cfg_output(LED_1);
// Make sure they are both off
nrf_gpio_pin_clear(LED_0);
nrf_gpio_pin_clear(LED_1);
// LED 0 only.
while (true)
{
// Send “TS” in Morse code
dah(); symbol_space();
dit(); dit(); dit(); symbol_space();
word_space();
}
}

My plan is to see if we can avoid setting up formal connections between BLE nodes, because there is an inherent limitation as to how many connections you can have active at any one time.   Eight(8) seems to be the limit, and if you use the s130 softmachine then it looks like the limitations are:

• 3 central connections
• 1 peripheral connection
• 1 observer
• 1 broadcaster

The three central connections allow a device running s130 to simultaneously connect to three devices acting as peripherals.  The s120 would only allow 8 connection to peripherals anyway, so there is always a severe upper limit on the number of peripherals (or anchors in our case) with which a mobile could connect at one time.  Managing/sharing a limited number of connections among many physical peers would complicate things – and I want to avoid that, at least for our initial protos.  Worse, an s301 can connect to exactly one central device.

So an anchor would have to discover a mobile,  then go through the whole process of forming a connection, and then would have to drop the connection before linking up with another peer.  I get the impression that forming, and maintaining a connection is expensive, and takes a relatively long time.

One thing I have discovered is that it is possible to do some minimal data exchanges without forming any connections.  A broadcaster simply emits advertising packets at some interval.  An advertising packet allegedly last 300-400 micro seconds.  Obviously the length of the interval between advertisements has a substantial impact on the battery life.  Equally, an observer can simply listen for advertising packets, but of course it has to wake up and listen at the right time, which can be costly if it doesn’t know exactly when to wake up and listen.

—-
Panasonic’s tiny new battery is destined for the wearables market
// Electronics-Lab.com Blog

by Ben Coxworth @ gizmag.com:

While keeping batteries small and light is definitely a factor with electronic devices in general, it becomes particularly important when dealing with wearable electronics such as smart glasses. With that in mind, Panasonic has just announced its CG-320. Measuring 20 x 3.5 mm, it’s being billed as “the industry’s smallest cylindrical shaped rechargeable Lithium Ion battery.”

The CG-320 weighs 0.6 grams, has a nominal capacity of 13 mAh, a nominal voltage of 3.75 volts, and a maximum charging voltage of 4.2 volts. It also has a stainless steel exterior case, designed to prevent swelling.

Panasonic’s tiny new battery is destined for the wearables market – [Link]

—-

Shared via my feedly reader

//Mik (mobile)

Hi Stephen,
Bluetooth low energy uses both Little- and Big-endian, so it might be confusing sometimes. For example, The service discovery protocol transfer multiple-byte fields in standard network byte order (Big Endian), while Multi-octet fields within the GATT Profile shall be sent least significant octet first (Little Endian). I am not sure why it is so.
Everything is of course specified in the Core Spec, where you can find more information.
Best Regards

So perhaps if I reverse the address bytes.

BLE_GAP_ADDR_TYPE_RANDOM_STATIC, {0xea, 0xaa, 0x2f, 0x36, 0x04, 0xc7}
/* BLE MAC 0xC704362FAAEA */

Try again…

Yay!  “My” first program that compiles and talks to another program that I have compiled.  A breakthrough moment :-/