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 :-/

My experience below typifies the issues I am having with the Nordic stuff.  It reminds me of that famous bit from Hitchhikers Guide to the Galaxy:

“BEWARE THE LEOPARD”“But Mr Dent, the plans have been available in the local planning office for the last nine months.”
“Oh yes, well as soon as I heard I went straight round to see them, yesterday afternoon. You hadn’t exactly gone out of your way to call attention to them, had you? I mean, like actually telling anybody or anything.”
“But the plans were on display …”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard’.”

I sent a query about flashing applications above the s130 softmachine to Nordic, having finally discovered a “beware of the Leopard” notice in the basement.

Load “C:\Nordic Semiconductor\nRF51 SDK_v6.1.0.0\Nordic\nrf51822\hex\Example\s130_demo_app\build\S130_demo.axf”

Set JLink Project File to “C:Nordic SemiconductornRF51 SDK_v6.1.0.0Nordicnrf51822hexExamples130_demo_appJLinkSettings.ini”
* JLink Info: Device “NRF51822_XXAA” selected (257 KB flash, 16 KB RAM).

JLink info:
————
DLL: V4.92 , compiled Sep 30 2014 09:33:42
Firmware: J-Link OB-SAM3U128 V1 compiled Aug 22 2014 17:25:44
Hardware: V1.00
S/N : 480209391

* JLink Info: Found SWD-DP with ID 0x0BB11477
* JLink Info: Found Cortex-M0 r0p0, Little endian.
* JLink Info: FPUnit: 4 code (BP) slots and 0 literal slots
ROMTableAddr = 0xE00FF003

Target info:
————
Device: nRF51822_xxAA
VTarget = 3.300V
State of Pins:

TCK: 0, TDI: 0, TDO: 1, TMS: 1, TRES: 1, TRST: 1
Hardware-Breakpoints: 4
Software-Breakpoints: 8192
Watchpoints: 2
JTAG speed: 2000 kHz

Include “C:\Nordic Semiconductor\nRF51 SDK_v6.1.0.0\Nordic\nrf51822\hex\Example\s130_demo_app\s130_demo_loader.ini”

LOAD %L INCREMENTAL
SET SRC=.\src
RESET
Insufficient RAM for Flash Algorithms !
Erase Failed!
Error: Flash Download failed – “Cortex-M0”