Framed Panels and Nested PCB’s using KiCad and OSHPark

This continues my earlier post.

About OSHPark

Here is an Element14 article about the OSHPark business model and company history.

Briefly, it says that OSHPark adds value for small makers by aggregating small boards from many customers into large boards that PCB manufacturers are equipped to make.  Some of added value is the software that runs the OSHPark business:  the web store, the software that aggregates many small PCB designs into a larger one, the software that understands and converts many different design file formats.

I appreciate their work and wish them continued success.

OSHPark and ad hoc panels (without frames)

A panel created according to my earlier post does not have any explicit support tabs or a frame.  I will call this an ‘ad hoc panel.’

OSHPark adds support tabs for you, between the PCB’s of your ad hoc panel.  (They also add support tabs on the outside of your panel, to the adjacent customer’s board or panel in the manufactured, huge, aggregate board.)

Unfortunately, OSHPark might also break apart your ad hoc panel at their convenience or need.  OSHPark breaks apart their aggregate, huge panels into customer’s boards.  While they are doing this, they don’t know which groups of boards are a customer’s ad hoc panel.  So OSHPark may break apart your ad hoc panel.

Just looking at the aggregate panel pictured in the above linked article, you can see that it might be difficult for the person separating customer’s boards NOT to break apart your ad hoc panel.

My point is: if you want your panel to stay together, you need to add a frame.  Otherwise, you are taking your chances.  The frame is what tells OSHPark not to break apart the boards.

Why create panels?

  • so you can save labor by stenciling or assembling boards in panels/batches
  • to save board costs by nesting odd-shaped boards

For the first purpose, the fact that OSHPark may break apart your ad hoc panel might defeat the purpose.  In my experience, making panels of 3 small boards, to stencil them by threes, for hand pick and place, it has not been a problem.  If OSHPark breaks apart your ad hoc panel in odd ways, you can always break them into individual units and stencil them by ones (using a corner of the same stencil for the whole panel.)

As I mentioned in an earlier post, OSHPark doesn’t always break your multiple board order into individual boards.  Sometimes you get ‘happenstance panels’ even if you did not order an ad hoc panel.  (Assuming your boards are much smaller than OSHPark cardboard shipping envelopes of about 5×7 inches.)

I am not really serious about volume production yet.  If you are, you should frame your panels.

Nesting odd-shaped boards into ad hoc panels

Say you have an L-shaped board.  OSHPark calculates the cost from the bounding rectangle.  That is, they will charge you for the empty space between the arms of the L.

If you nest two such L-shaped boards into an ad-hoc panel, the cost for the bounding rectangle of the panel will be less than twice the cost of the individual boards.

Other words for nesting are tiling or bin packing.

Tiling is partly how OSHPark subsidizes small makers, by fitting small boards into the wasted space of larger, odd-shaped boards.  If you create your own tiled, ad hoc panels, you save costs, but then someone else might be less subsidized.



Understanding clocks on Nordic nrf5x embedded radio, towards a long clock


This is a quick summary of other posts.  I disambiguate terms in an object oriented way.   I explain elementary things.

I capitalize words to emphasize they are well-known objects, with well-known data and behaviour. You should verify, I could be wrong and I wrote this in haste.  Errors here might illustrate the confusion surrounding the subject.

See Also

A post on Nordic DevZone.

A blog about the nrf5x Application Timer library.


Time (I don’t discuss, I assume an intuitive notion suffices.)  Subclasses are:

  • UnsynchronizedShortTime
  • RealTime

UnsynchronizedShortTime is a basic Counter.  It is not expected to be synchronized with other instances.  It rolls over every few days.

RealTime is the notion of time used in the real world.   It takes many bits to keep RealTime that is precise to seconds and won’t roll over within centuries.   It takes even more bits (say 64 bits) to keep RealTime that is precise to micro seconds (uSec.)   RealTime is expected to be synchronized with other RealTimes.

A Clock keeps time.  Methods are:

  • set the time
  • ask for the time (now, or current time)
  • set alarms to go off at a certain time.

Subclasses of Clock:

  • RealTimeClock
  • LongClock

A RealTimeClock  is a hardware Device or Peripheral.  It comprises a Counter and a CompareRegister.  The Counter is free-running.  You can configure the RTC so that when the Counter equals the CompareRegister, an Event and/or Interrupt is generated.  A RTC Counter is typically 24-bits.  There is some ambiguity here:  a RealTimeClock does not always keep RealTime and need not be synchronized or accurate.

There is much ambiguity here:  some use RTC to mean real time counter, some use it to mean real time clock.  Some use Real Time Counter to describe a Clock (having alarm functions.)

A LongClock is a longer running clock (before it rolls over.)  A LongClock is typically implemented in software using a RealTimeClock. A LongClock may keep RealTime, or not.

This is where you typically find ambiguity: some “RTC IC’s (chips)” implement RealTime in hardware (they keep time very accurately, and have many bits of time available in a format you typically use in the real world e.g.  YYYY:MM:DD:SS. )   RealTimeClock’s embedded as a Peripheral of a SystemOnAChip (SoC) typically do not implement RealTime (although they can be accurate.)

Precision and Accuracy  and Drift (see wiki.)  Accuracy and Drift are the same notion describing the relation between two Clock instances.

RealTimeClock subclasses:

  • RTCByRCOscillator
  • RTCByCrystal.

They differ in accuracy.

A RTCByRCOscillator uses a resistor and capacitor oscillator embedded in the hardware.   Its accuracy is typically worse than 200 ppm.  That gives a drift of a second every few days.

A RTCByCrystal uses a resonant, ceramic crystal (and sometimes capacitors) external to the hardware.   (There is some ambiguity here:  the circuit the crystal is part of can also be called an oscillator.)  Its accuracy is typically better than 20 ppm.  That gives a drift of a second every month.

A Timer just sets off an alarm.  You can’t tell Time from a Timer (unless you record when you started the Timer.)  You can ask a Timer for time remaining, which is a TiA LongClock meDelta (not a Time.)  Timers are implemented in software using a Clock.

Use Cases

A TimeStamp is a read-only copy of a Time instance.  Many applications don’t need TimeStamps, but only need differences between Times. Often you need to compute a Time difference to set an alarm.

You must be careful when computing differences between Time instances if the Clock has rolled over between the two Time instances.  It is useful to keep a LongClock because pragmatically you don’t need to worry about roll over when computing differences.

Generally Times are kept as unsigned ints.  It is safe to difference two Times if the Clock from which they were taken has only rolled over once between, and if the subtracted Time was actually earlier than the second, later, subtrahend time.  (Since difference of unsigned ints is modulo, like a circular clock.)  If the first time was actually later than the second time, it is not safe to use the difference operator to get a delta.  And it is not safe if the Clock has rolled over twice between.

Design considerations

A RTCByRCOscillator embedded in a SoC is free, using no extra components or board space.

A RTCByCrystal requires an extra component and board space.  A crystal is typically $1.

An external RTC IC requires more board space for itself, and also for a crystal.

A LongClock implemented in software using an embedded RealTimeClock:  the software is free (except for the hassle of finding/writing it) but might still require a crystal.

In general, low-frequency (low precision or resolution) clocks take less power.  Because in general, in CMOS semiconductors, it is the switching of flip-flops that takes power.

How LongClock is implemented

Keep upper (most significant) bits in a memory word.  Keep the lower bits in a RealTimeClock.  Configure the RealTimeClock to trigger an event when it rolls over.  The handler for the roll over event increments the upper bits memory word.

How Timers are implemented

Usually a library provides multiple, concurrent Timers.  The library uses one Clock.  Keep an ordered queue of alarm times of the timer instances.  When the clock alarm goes off, reset the clock alarm for the next timer in the queue (set the counter to the DeltaTime from now to the next alarm time.)

Specifics for the nrf5x embedded radio chip

Since Nordic>InfoCenter>NRF52 Series>Product Specification> :

  • RTC

The CLOCK section actually describes Counters.  The nrf5x has:

  • low-frequency Counters that can be ByRCOscillator or ByCrystal (if you add an external crystal.)  The frequency is 32kHz.  Called LFRC and LFXO.
  • high-frequency 16Mhz  Counters.   The crystal is not optional.   Its accuracy is needed by the radio.  These use much more power than the low-frequency counters.  Called HFRC and HRXO.  To use the radio, you must start the HFCLK.  Then the radio automatically switches between HFRC and HRXO as needed (switching it to RC source to save power when not transceiving.)

Not all modules (boards with an nrf5x on them) have a 32-kHz crystal.  E.g. the RedBear BLE Nano does, the Rigado BMD-300 doesn’t.  They MUST have a 16MHz crystal (or else they have low-performance radios, or will they even work at all?)

The RTC section describes an instance of RealTimeClock (having a compare register.)  Its source can be either of the low-frequency Counters.   It is 24-bits.  Its roll-over depends on the prescaler.

The Timer section describes another instance of RealTimeClock.  Its source is the HFCLK, whose source is either of the high-frequency Counters.

The app_timer library provided by Nordic uses the RTC.  It provides Timers (alarms in the future.)  It allows many concurrent Timers.

Implementing a LongClock using Nordic app_timer.  This is really my goal, and where I leave off until I figure it out.  I want a LongClock (with usec resolution) so I don’t need to worry about roll over, but I want to use app_timer API so I don’t have to worry about low-level interface to the RTC.


Setting up Linux/Eclipse for Nordic embedded wireless development


These are rough notes about my experience.

The Nordic tutorial.  This post elaborates, because the tutorial is somewhat incomplete, and assumes you are using Eclipse on a Windows host.

Broad overview of the development environment

Nordic seems to support this development environment (Linux, Eclipse, GNU, SEGGER).

They provide example apps that include Makefiles for this environment.

The Nordic tutorial includes Eclipse projects.  The projects use soft file links (“linked resources” in Eclipse terminology.)

The toolchain is not very modern with respect to finding and declaring dependencies:  you must maintain your own Makefile (starting from one provided by Nordic in their examples) and you must create new soft linked resources in the project.  (When you change your project to call additional functions in the SDK.)


  • IDE: Eclipse
  • compiler: GNU gcc compiler for ARM
  • debugger: GNU gdb for ARM
  • interface to the dev board:  SEGGER tools, JLink
  • flashing: nrfjprog command line tool

My host platform is a clean Ubuntu 16.04.1 installation.

My target is the nrf52 family (nrf52832 chip) on a development board from Nordic, which includes a SEGGER brand debugger probe (JTAG interface.)


These are the rough steps:

  1. Preliminaries: install your usual but optional tools like git and Dropbox
  2. install a JRE (Java runtime needed by Eclipse)
  3. install Eclipse installer
  4. install Eclipse C/C++ (an IDE)
  5. install ARM plugin for Eclipse
  6. install GNU ARM tools (gcc-arm-none-eabi and arm-none-eabi-gdb, needed by ARM plugin for Eclipse)
  7. install the Nordic nRF5x SDK (libraries used by your app)
  8. install SEGGER JLink tools (interface to the debugger probe on the target development board)
  9. install nRF5x command line tools (to flash the target)
  10. import an example project into Eclipse
  11. choose a Dev pack for the project (a dev pack is a description of the target, optional for debugging)
  12. modify the project and its Makefile
  13. build
  14. flash
  15. debug your example project


These are selected details about the steps.  (But I gloss over other details that are easily searched.)

  1. Since I keep my projects in local git repositories and use the “Team” functions of Eclipse:
    sudo apt-get install git
  2. Eclipse is written in Java:
    sudo apt-get install default-jre
  3. At the Eclipse website you first download a small installer app.  (“Ubuntu Software” app will let you install an older Eclipse.)
  4. Then you run that app and choose from a variety of environments, here C/C++
  5. A third party plugin adds function to Eclipse for developing embedded ARM.  The Nordic chip has an ARM mcu.  Search for “Eclipse ARM plugin” and find the page where you can just drag an icon into Eclipse.  Alternatively, you can use the more usual method of installing Eclipse plugins, that is, choose Help>Install New Software, then enter a URL to the place where this Eclipse plugin lives, etc.
  6. There is a gcc compiler and gdb debugger for ARM that are not installed with the usual development tools (such as make) that are already installed on many Linux hosts.
    sudo apt-get install gcc-arm-none-eabi
    sudo apt-get install gdb-arm-none-eabi
  7.  The Nordic SDK includes many libraries (in source form) and example projects (including Makefiles for this dev environment.)  This toolchain uses soft links to various files in the SDK (the source is not copied to the project.)
  8. The development board includes a SEGGER brand of hardware debugger probe (a JTAG interface to the target) so you are entitled to use SEGGER’s tools to talk to it from Eclipse.   See below.
  9. The nRF5x command line tools are a separate download from the Nordic site.  It yields nrfjprog, a tool to flash your app to the target.  I am not sure you need it, you can also use JFlash, a SEGGER tool?
  10. Outdated example projects are attached to the tutorial as zip files.   The example projects contains an “Eclipse project file”, i.e. it is not just the source files, but a file that configures Eclipse with many soft links to the SDK.    Example Makefiles and .ld files are in the SDK.  E.G. $(NRF_SDK_ROOT)/examples/peripheral/blinky/pca10040/blank/armgcc/Makefile, but using those you must create your own Eclipse project.
  11. ARM Eclipse plugin has support for Packages Manager.   It is optional, but especially needed if you want to use a debugger and examine registers and other memory locations.  See below.
  12. See below
  13. At this point, an example project might build successfully.
  14. See below
  15. See below

More details of installing SEGGER tools (step 8, 15)

The ARM Eclipse plugin has support for the SEGGER debugger probe, but you need to download the SEGGER tools separately from the SEGGER website.  It comes as a .deb package.  Clicking on it opens the “Ubuntu Software” app.  Choose the “Install” button.  It installs executables to /usr/bin.

To test SEGGER tools, plugin your dev board, and at a terminal:


Expect many lines to scroll by, such as:

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jul  5 2016 08:42:09

This means the host communicated with the probe side of the dev board.  But it will quit because it cannot connect to the app process running on the target side of the dev board?

The Nordic tutorial describes configuring the GNU ARM Eclipse plugin for debugging.

The GNU ARM Plugin site gives a better tutorial for configuring a “Run/Debug Configuration” for SEGGER JLink. Note that for non-embedded C programming, a debug configuration usually exists already, but here you must create one.

After you create a debug configuration, make sure you choose the correct one:  the arrow to the right of the Debug icon lists the configurations.  You will have two after you create another one.  If you choose the wrong one (the C/C++ Application configuration)  you get:

nrf52832_xxaa.out: cannot execute binary file: Exec format error

Note that the “Main>C/C++ Application” field is  “_build/nrf52832.out”,  not .elf.  Other than that, I only entered the device name field, “nRF53832_xxAA”.  (Since I had not already loaded a dev pack it was not filled in automatically?)

Do not choose “Connect to running target” because you usually want to reset the mcu before you start debugging.

When you debug (for example by clicking on the Debug icon), expect Eclipse to change to the debug perspective and for the debugger to break at main().  This worked for me even though I had not flashed the test program, i.e. it stopped at the standard location for main.

More details of installing packs

Follow ARM Eclipse plugin has support for Packages Manager.

In Eclipse, switch to the Packs perspective.  Click the refresh button at the top of the “Packs” pane.  It takes many minutes to refresh (from the web.)  If it fails to refresh packs, try deleting the Packages folder.  Expect a list to appear in the Packs pane.

The left pane is for filtering the Packvoid RTC1_IRQHandler(void);s pane.  If you select an entry there, it filters the list in the Packs pane.

I selected the “Device” tab in the left, filtering pane, and selected “Nordic Semiconductor>nRF52 Series.”  Then in the “Packs” pane I expanded the “nRF_DeviceFamilyPack” item, and right-mouse-button clicked on the latest version and chose “Install” from the pop-up menu.

I don’t understand what the “Board” tab does, and I didn’t use it.

After you install a device pack, the debugger magically (without you needing to change the debug configuration) starts showing more information, such as dissassembly and registers.  Until you do this, they are empty or blank.

More details of futzing with the project (step 12)

Fix path variables in the project

In Project>Properties>Resource>Linked Resources>Path Variables, add a new entry “NRF_SDK_ROOT” to point to where you installed the SDK.

In …Linked Resource>Linked Resources, edit each entry that is broken (has an exclamation point) to use the NRF_SDK_ROOT path variable you just defined.

Fix the path to the compiler in the Makefile

(This is described in the Nordic tutorial, but obliquely, for Windows.)

The Makefile in the example project includes a Makefile.posix from the SDK.  Makefile.posix defines the path to the gcc compiler for ARM.  Edit $(NRF_SDK_ROOT)/examples/toolchain/gcc/Makefile.posix.  Change the first definition (of GNU_INSTALL_ROOT) to have the value “/usr”

Fix capitalization errors (case) in the SDK

The SDK was developed on a Windows host, which is case-insensitive to filenames.  There are some capitalization changes (bugs that Nordic is aware of) needed:

$(NRF_SDK_ROOT)/components/toolchain/gcc/gcc_startup_nrf52.S => .s

In the Makefile:

CMSinclude/Include => cmsis/include

Define path variables in the Makefile

Do something like

NRF_SDK_ROOT = /home/bootch/nrf5_sdk
TEMPLATE_PATH = /home/bootch/nrf5_sdk/components/toolchain/gcc

More details on a Flash target (step 14)

The Makefile has a target (something you can ask to make) for flashing.  The target invokes the Nordic command line tool nrfjprog.  (In more modern toolchains, for non-embedded programming, you neither maintain the Makefile nor invoke more than one make target.  For desktop app, other targets might package an app.  For embedded, you must flash the app.)

You can configure Eclipse so that you can click an icon to make that target (and flash your app to the dev board):  in the C/C++ perspective, in the right pane, select the “Make Target” tab, next to the “Outline” tab.  Then select your project in the body of the pane.  Then choose the “New Make Target” icon (an icon of green, concentric rings with a plus sign.)  Expect a dialog to open.

Enter a “Target name” (extracted from the Makefile), in this case “flash”.

Choose OK.  Expect the dialog to close and a new entry named “flash” in the body of the pane.

To flash your app, double-click that new entry .  Expect the console to show messages about the progress of the flash.

The tool nrfjprog must be in your shell path, or you can modify the makefile to invoke it using an absolute path to its installed location.

More about debugging (step 15)

When you click on the Debug icon (and choose the proper debug configuration) the perspective changes to the Debug perspective and the program is halted at main() (a default of the configuration?)  You can choose from the icons to Resume, Step Into, etc.

If you have installed a dev pack, the Dissassembly tab of the right, middle pane will show assembly code (sometimes?)  The Outline tab of the same pane will show the context of the current program counter?  Sometimes it shows that you have wandered into an exception handler (a green dot?)

The left, middle pane has an arrow in the left margin showing where the program counter is in the source code.  If the PC is in a macro such as APP_TIMER_INIT, that is not very useful.

If you are stepping along and the console shows “Starting target CPU…” and the blue arrow does not advance in the source code, it means you have thrown an exception and entered an infinite loop in the default exception handlers (see startup_nrf52.s).  Click the Pause icon to see where you are looping.  Then the Debug pane in the upper left will show you the call stack and you can examine it to see where in the code you were when the exception was thrown.

Debugging using NRF_LOG

This section is work in progress, not working yet because NRF_LOG has C linkage, not C++

This section is highly dependent on SDK version, here using v12.

The two usual techniques for debugging are:

  • use a debugger e.g. gdb
  • use “printf” or “log” statements sprinkled through your code

NRF_LOG is a logging library from Nordic.  A logging library is glorified printf:  it adds the capability to specify a logging level such as: INFO, DEBUG, etc.  The level can change for each module.

Configuring your project for logging

NRF_LOG requires use of a UART peripheral.   In your sdk_config.h (if SDK v12) file:

#define USE_UART 1

Inserting logging code into your source

At the top of each file (module) where you want to call logging functions to write to the log:

#define NRF_LOG_ENABLED 1#include "nrf_log.h"

Note the order is important, define before include?

At the top of main.c, where you initialize logging:

#include "nrf_log_ctrl.h"

That might require to add more linked resources to your project (depending on whether you are already using a UART) as evidenced by compiler or linker warnings.

Early in main.c, insert and call from main():

static void initLogging(void)
    // Initialize logging library.
    __attribute__((unused)) uint32_t err_code = NRF_LOG_INIT(NULL);
    // APP_ERROR_CHECK(err_code);

Here NULL means: without timestamping.  I chose to ignore any error return.

Logging to the Eclipse console

TODO Does this work????  The log can go to the Eclipse console. The log statements will be interspersed with messages from the SEGGER GDB Server (e.g. “Reading registers…”)

To arrange that in Eclipse, click on the arrow next to the Debug icon.  Expect a pop-up menu.  Choose “Debug Configurations.”  Expect a dialog.  Select your configuration in the left pane.  Expect the right pane to refresh with the attributes of your configuration.  In the right pane, choose the “Startup” tab.  Choose the “Enable semihosting” checkbox and the “GDB client” checkbox.  Choose “Apply” and “Close.”

Logging to SEGGER RTT

You can also use a faster solution, SEGGER RTT. Faster means it takes less cpu cycles away from say your ISR routines.  It is faster because the logging goes directly from your target mcu to a terminal app on your host, without going through the GDB Server on your host?

Described by E. Styger’s post.  That requires more setup, and requires a SEGGER probe (which your nrf52 DK board has.)

Also described by this post.

Also a Nordic tutorial.

Debugging off in the weeds, lost in never never land

Especially if you are debugging your own code (versus an example project), you might end up with the program state “Running” but not hitting any of your breakpoints you expect to hit.  When you click the “Pause” icon, it might show the PC in:

  • WDT_IRQHandler
  • HardFault_Handler

I think this means an interrupt occurred for which you did not define a handler.  Default handlers are provided in startup_nrf52.s.  You can also see them in the  .map file.

Each of the internal interrupts (for exceptions such as invalid op code, invalid memory address, etc.) has a separate default handler defined.  They are all just infinite loops, but at different addresses.

The default handlers for IRQ (external interrupts) are all just one, same handler (at the same address) that is an infinite loop (assembly code:  “BR  . ”  that is, branch to the value of the current PC program counter register, i.e. a loop.)


The debugger will say it is the WDT_IRQHandler, because that is the last name that points to this location.  But it might not be the WDT device that interrupted, and started looping in the default handler.  Once you are paused, to know what IRQ device interrupt occurred,  examine the XPSR register.  One of its sub-registers is the IPSR register, the low-order 9 bits.  (For unknown reasons, SEGGER and gdb did not show the IPSR sub-register by itself, and showed the contents of the full  XPSR register in decimal.)  Convert to hex (using a calculator) and mask off all but the low-order 9 bits.  From that value, subtract decimal 16 (hex 10).  That gives you the index of the interrupt.  Then examine /components/device/nrf52.h for its list of the interrupt indices.  In my case, I got zero, meaning the “POWER_CLOCK” IRQ.

Then you can define your own handler in C, just a function with the same name e.g. WDT_IRQHandler.  The default handlers are defined as “weak” in assembly language, so defining the same name function in C overrides the default.

Here, I am using C++ compiler so I am careful to specify C linkage so that the compiler doesn’t mangle the name and the linker then overrides the default, weak definition:

extern "C" {
void WDT_IRQHandler() {
    while (1);

In my case, the interrupt I was not handling was one used by app_timer.  In the SDK /components/drivers_nrf/clock/nrf_drv_clock.h  I added this (so that the C++ compiler did not mangle the name and thus fail to override the weak default):

#ifdef __cplusplus 
extern "C" { 
void POWER_CLOCK_IRQHandler(void);
#ifdef __cplusplus 

Also in components/libraries/timer/app_timer.c

#ifdef __cplusplus 
extern "C" { 
void SWI0_IRQHandler(void);
void RTC1_IRQHandler(void);
#ifdef __cplusplus 

This is only because I used app_timer from the Nordic library.  In general, if you use more from the library that might use interrupts, you should examine your .map file for any “…IRQHandler” whose name is mangled by the C++ compiler.

If you fail to make these changes (and you are using C++ and app_timer) the symptoms will be: your app compiles but halts, showing a stack trace that ends in some IRQHandler, after a call to an app_timer function.

Note that Nordic does NOT fully support C++.  Thus you may find instances such as above, where you need to alter the SDK code to support C++.  There are many places in the SDK code that seem to support C++ (i.e.  #ifdef __cplusplus) , but the support seems to be incomplete.

(Here I rant:  I hate C++ but I like object oriented programming.  I use C++ in a highly constrained way.   I don’t want to use a C standard dated to 1999. I need all the help I can get from a compiler.  I wish Nordic would embrace C++, or even some other modern language like Python or Rust.  )


See here.

A short summary is: many bugs (programming errors) such as bad pointers end up as hard faults.  (And not necessarily an op code exception or a memory exception, depending on how exceptions are enabled?)  The debugger often does not show you the call stack when a hard fault occurs.   So install a handler for this exception that helps the debugger show you the call stack when the exception occurred.  A few statements/instructions before the last call is often the errant code.

After thoughts

The build system takes much hands on maintenance of the Makefile, and is not as smart as some build systems about avoiding redoing steps that don’t need doing:

  • build, it only compiles.
  • flash, it compiles then flashes
  • debug, it builds, then starts the debugger, without flashing!

Some of the dependencies are defined in the Makefiles which you are maintaining.  If you create a dependency error in the Makefile, it might build with stale code.

Other build steps are specified in the Eclipse configuration.

If the debugger ever seems lost, start over by cleaning, building, flashing, and debugging.





Patching (for Linux) lib_search tool in TI’s tool chain for embedded wireless development



Trying to use CCS Desktop on Linux or OSX to build SimpleLink example programs for TI’s embedded wireless chips such as the CC26xx family of chips.


Fixing a Windows specific tool invoked by the projects of the examples.


A one-year old post on TI’s forum

TI’s wiki page for Linux

TI’s wiki page for OSX

TI’s wiki on Portable Projects

Why do you need the lib_search tool?

As far as I know, certain needed code is shipped as pre-built libraries ( .a files.) The example projects are not configured to build the libraries, only to link them in.

The lib_search tool does some sort of configuration.


I don’t understand what exactly the tool does, why all the libraries are not just in some directory that the linker searches for needed unresolved symbols.

The references seem to suggest that the libraries CAN be built on the Windows platform.  That seems to imply the library source code is not proprietary, i.e. not secret, only copyrighted and licensed.  It seems like it SHOULD be possible to build the libraries on any host system.

How so ever the libraries get built, they are hardcoded for a specific target chip, and possibly for other code such as a version of TI-RTOS?  Or does it pertain more to what the app image needs from the stack image of the embedded program?

Anyway, you don’t need to understand it to patch it.

Where in the project build is the tool invoked?

The example projects are configured to use the tool as a ‘pre-build’ step.  To see that, highlight a project in the Project Explorer pane of the CCS Desktop IDE, click on it with right mouse button, and choose ‘Properties.’  Expect a dialog.  Select ‘Build’ in the left pane of the dialog.  Expect the right pane to show many tabs. Look under the ‘Steps’ tab for a ‘Pre-build steps’ section.

Symptoms of non-portable tool use

When you build on a non-Windows platform you might get:

error #10234-D: unresolved symbols remain

that is, the linker could not find said certain libraries, because the linker command file was not built by the pre-build step.  The root cause is visible much earlier in the log of the build, the pre-build step (lib_search) failed and the build process ignores the failure (proceeds to compile and link.)

The non-portable aspects of the tool

The pre-build step invokes lib_search.exe.  That is a python program (and the interpreter) that has been packaged/bundled for Windows OS (so that python does not need to be installed onto the host.)

(Strange: the BT SDK developers don’t support non-Windows platforms, but they use the tool Python which Windows OS does not support, and they used the tool py2exe so they can ship the SDK portable to any stock/virgin Windows host.)

But as of BT SDK v2, the python source is shipped with the SDK.  So on any host where python2.7 is installed (most Linux/Unix and OSX hosts), and where certain other dependencies (the python package ‘lxml’) are installed, the tool will run as interpreted python.

Old patch for the problem

Some of the references suggest installing Wine and other tools that let Windows executables run on Linux/Unix hosts.

Then the fix is (roughly speaking) prepending wine to the command:

lib_search.exe ...     =>     wine lib_search.exe....

Another patch for the problem

Here we invoke the python interpreter on the python source.

Then the patch is (roughly speaking) prepending ‘python’ to the command and changing .exe to .py:

lib_search.exe ...     =>     python  ....

Here, we assume  “python” invokes python2.7 (which it often does, except if you have changed it to invoke Python 3 or later.)

For this step to work, you must install the python packages that lib_search uses, and the package’s dependencies (lib_search depends on python package lxml which depends on C libraries libxml2 and libxslt.

To install those dependencies:

pip --upgrade pip
pip install wheel
pip install lxml

More exactly, in the build step change:



python "${TOOLS_BLE}/lib_search/src/"

More to the patch

Define and redefine certain project path variables:

In the project’s Properties>Resources>Linked Resources>Path Variables  redefine


and define

BLE_SDK_ROOT <= /home/<you>/ti/simplelink/ble_sdk_2_02_00_31

Change the .xml configuration file

(e.g. in TOOLS_BLE/lib_search/params_split_cc2640.xml)

Use a text editor to change “\” to “/” everywhere in file paths.  (Windows uses backslash in paths, other OS’s use forward slash.)

If you haven’t done this step, you see an error message that lib_search emits, saying

Cannot match   <foo> to any library .opt file in <bar>

where bar is a file path like “…./.\host….”

Setting Up a Linux Development System for Embedded Wireless using TI LaunchpadXL-CC2650 EVM


A record of my learning experience.  Discusses general, high-level considerations. Gathers many links that I followed.


For advanced, C programmers who are new to TI’s tool chain for programming embedded devices.

Similar documents

CC26xx Family SW Quickstart Guide also covers this material.

This blog shows a similar process for an older EVM (SensorTag), but using Windows OS and CCS Desktop.

The Narrow Subject

Here I assume the CC2650 target (an mcu and radio system on a chip) but only discuss:

  • Bluetooth (the chip allows other protocol choices i.e. WiFi or Zigbee)
  • TI-RTOS (other RTOS choices might be various free OS’s)

This might apply to other TI chips such as CC13xx, CC2640, and other earlier chips.

The Broader Subject

Wireless networks, not necessarily IoT development.  My use case is not serious IoT: I don’t want to connect to the Internet and I don’t even want to talk to standard Bluetooth devices, just between two of my own.  I don’t even want Bluetooth protocol, it just happens to be what I studied first.


I could be wrong.  You should follow links to original sources.

Other target, IoT, and wireless network ecosystem choices

ARM mBed ecosystem also offers an online IDE, desktop development tools, an RTOS, and bluetooth stack.

The CC26xx target uses the ARM ISA.  You might be able to use the ARM ecosystem, but I think the bluetooth stack in the ARM ecosystem might not work on the CC26xx?  The CC26xx has two processors, a host (ARM M3) and a network (ARM M0) processor.  A Bluetooth stack should have an interface at the HAL layer between the upper layers of the BT stack and a network processor’s implementation of the lower layers.  I don’t know whether either the ARM bluetooth stack upper layers, or the TI network processor lower layers (in firmware on the M0), conform to any HAL interface standard.

(Note that TI also has much documentation on implementing “network processors”.  There, they are treating the CC26xx as a server for yet another processor, the application processor, say a powerful cpu of a desktop PC.)

ARM does not make chips (only the design IP for them).  You might consider whether using TI tools locks you into their chips, and whether using the ARM ecosystem would give you a choice of chips.

TI’s IDE Choices

CCS Cloud – “online IDE” or “online compiler”: browser and cloud based: few files stored or installed on your development system (host)

CCS Desktop – installed on your host computer, based on Eclipse IDE

Energia – (Arduino clone) does not support the CC26xx family target.

Dev System OS Choices

For CCS Cloud, shouldn’t matter, but it does: to burn to the EVM requires setting up communication via USB to the EVM, which is host OS dependent (drivers and permissions.)  CCS Cloud requires installation of TI Cloud Agent on your desktop.  All three major OS’s are supported.

For CCS Desktop, all three major OS’s are supported, but Windows seems to be favored.  E.g. installing the Bluetooth stack is biased: requires Wine on Linux.

TI’s instructions  for Building BLE Projects on Linux.  It acknowledges that TI does not officially support their BT stack on a Linux dev system (but they do support their IDE and RTOS.)


To develop, you need three components:

  • IDE (CCS Desktop or Cloud)
  • Bluetooth stack (or another wireless stack, i.e. library)

Using CCS Cloud, all three components come easy, automatically.

Using CCS Desktop, you must know the steps.

Installing CCS Cloud

Installation is minimal.  Search for “CCS Cloud Tools”.  Click on “CCS Cloud>Click to Start Developing”.  It will open in your browser.  When you first try to “Run” your target app, it will give you further instructions for installing:

  • a browser plugin
  • TICloudAgent

You must install TICloudAgent, and on Linux it depends on installing certain 32-bit libraries.  It’s web page seems out of date, it doesn’t show support for Ubuntu 16.4 or for this EVM (Launchpad.)

CCS Cloud is intended for starting programmers or small trials, i.e. for education and evangelism.  I don’t think the user base is large, yet.

I want to use it ( I have used Energia for small projects.)  But so far, I have had a fitful experience.  In other words, it seems somewhat fragile: requires refresh or restarting things.  Maybe slow.  But at least you can quickly experiment and learn the scope of your project (what might work, what else you need to learn.)

For example, at first ‘Run’ (burning to target) didn’t work for me, and after rebooting my dev system the next morning and plugging in the EVM after CCS Cloud was started, it did work.

For example, at first a project built successfully.  Then subsequent builds failed even though I had not changed a line of code.  The fix may be to delete a project and redownload it (using TI Resource Explorer.)  Maybe it is a consequence of changing between my two host computers.

Sometimes it fails to login (“too many logins”).  I guess there are limits on their servers?

The browser connection times out at inconvenient times (say every 30 minutes.)

Run (download to target)

“Failed to connect to target” : you don’t have the target plugged into a USB port on your desktop.

“Firmware update required” : the debugging interface half of the EVM board requires flashing.  This seems to be a warning, as download to the target seemed to proceed.

Installing CCS Desktop

Linux instructions.

A training video.

Additional notes

CCS Desktop is based on Eclipse IDE.  It is not a plugin that you can download from within Eclipse, but is downloaded and installed(?) separately (thats weird.)  If you are an Eclipse user, the overall look-and-feel is familiar, but specifics might not be.

The installer is 32-bit, but TI  says to use 64-bit Linux (that’s weird.)  You MUST follow the instructions for installing 32-bit library dependencies. (a 64-bit host will run 32-bit apps if the needed 32-bit libraries are also installed.)

The installer won’t run by double clicking it (because “>file *.run” shows it is 32-bit ELF?) but will run from the command line.  The installer is a .run instead of a .bin (thats weird?) but see this explanation of what a .run file is (essentially, an installation tool outside the approved Debian process.)

If you the installer starts but shows an error dialog “Failed to locate …libgcrypt…” you didn’t follow the instructions for installing that component.  You follow the link and click on “32-bit” (which points to ftp for a .deb file)  and expect to continue to install libgcrypt using “Ubuntu Software” installer app.

When the CCS Desktop installer runs, expect a wizard to run, that downloads and installs.

CCS Desktop: Installing TI-RTOS

You install TI-RTOS (development libraries) from within CCS.  Navigate to the TI App Center and choose “TI-RTOS for CC13xx and CC26xx”.

CCS Desktop: Installing Bluetooth Stack

TI’s instructions  for Building BLE Projects on Linux gives specifics for installing the BT stack on Linux using Wine (Windows emulator.)  Those instructions seem to be out-of-date.  I needed these changed instructions:

sudo apt-get install wine
sudo apt-get install winbind
(Download the Windows .exe installer.)
cd ~/Downloads
wine ble_cc26xx_setupwin32_2_01_00_44423.exe  (expect installer dialog)
cd ~/ti
cp -r ../.wine/drive_c/ti/simplelink/ . 

My changes to the instructions:

  1. Once you install the BLE SDK, I suppose it creates files in the proper place, and then you can uninstall Wine from your Linux computer?
  2. When I tried “>wine ble….exe”  it yielded errors about “ntlm” and needing package “winbind.”  And failed to create ~/<me>/.wine/drive_c/ti  (where it should be installing files.)  So I also installed package winbind.
  3. The installer did not seem to create .wine/drive_c/Program Files(x86\)/Texas Instruments/Boundary/  so I omitted the step of copying it.

(I haven’t successfully built a project yet.)

CCS Desktop: Importing Example Projects

I tried the TI Resource Explorer and did not have much luck finding

TI’s instructions  for Building BLE Projects on Linux also gives instructions for importing example projects.

CCS Desktop: Tweaking Example Projects

The instructions there for changing the linked resources (paths, capitalization of fileNames, and fileName wording) are slightly dated but generally accurate: you will need to use the principle and tweak the exact changes yourself.  For example, the filename “RF.c” seems to have changed in the latest release of BLE SDK.

If you get:

error: can't create session manager: can't find a JVM;
 the environment variable 'XDCTOOLS_JAVA_HOME' is set,
 but does not appear to be a directory containing a 64-bit
 Java Runtime Environment

Then see this post on TI Forum .


What are Images?

For the CC26xx, burning the target comprises two steps:

  • the app
  • the bluetooth stack

These are two different projects in the IDE.

TI calls them “images”.  I suppose that means they are loaded in different addresses of target ROM, and that the app on the target knows where to find the BT stack.  You only need to burn the BT stack once (unless it changes upstream, a new version.)

What are the symptoms of failing to burn both?  The app and not the BT stack:  does the app complain somehow?  The BT stack and not the app: nothing whatsoever happens, there is no app to boot?

Test Projects, CCS Cloud

How to use TI’s example projects to test your dev system.  These were written while I was using CCS Cloud; they might not apply to CCS Desktop.

Project Zero for CC2650

A demo app to burn onto your SimpleLink LaunchPad.   Essentially it sets up the Launchpad as a BT peripheral that a central device (a phone, etc.) can poll (see advertisements), connect to, and change attributes (to blink LED’s.)    This describes the demonstration, what a user sees.

As near as I can tell, this is NOT the app that is burned into a LaunchPadXL-CC2650 out of the box.  At that time, pushing the upper right button on the LaunchPad causes it to BT advertise, and for the green LED to blink.

This can be a test case for your development system.  If you successfully build and burn it, it should behave as described, talking to a BT scanner on another device.  Unfortunately, to see the results you need to use some of the free BT scanner apps, you need another BTLE enabled device, Android 4.3 or greater, or a recent iPhone or iPad that supports BT Low Energy.


This project prints “debug messages” once per second for a few seconds. It doesn’t use the radio.  It is intended to teach how to code semaphores etc.

CCS Cloud:  When you click the Debug icon, expect a dialog to open (the dialog that shows progress).  It should say, in order, paraphrased:

  • Building…
  • Loading…
  • Initializing…

The red/green led on the top half of the EVM should blink as the program is burned.

CCS Cloud: Then the dialog goes away and the debug panels of the IDE show new information, and a marker appears across from “main()” in the panel that shows the code.  The debugger is waiting for you to start the app.

Press the “Resume” icon in the debugger panel (looks like the standard “Play/Pause” icon on VCR’s).  Expect the program to run and print some messages into the Debug tab of the panel across the bottom of the IDE.  The final message should be “bigTime ended.”


This example project is configured for another EVM.  When you try to “Run” it on the LaunchpadXL-CC2650 EVM, you get the error “….Failed to connect….”.

To fix it, click right mouse button on the project in the Project Explorer Pane of CCS Cloud.  Expect a menu to pop up.  Choose “Project Properties”.   Expect a dialog to appear.  In the “General” section, in the “Connection” textbox, click.  Expect a pulldown menu to appear.  Choose “XDS110” (the type of interface on the upper half of this EVM.)  Choose OK and build again.

Repeat for the other half of the project, the …App… versus the ….Stack….

Other Notes

It seems like a few “Run” errors in red while burning, such as “Failed Device Reset”, are ~normal~ and that CCS Cloud retries and eventually succeeds.

Sometimes Ubuntu displays “You have just opened  a digital audo device” dialog meaning it has seen the Launchpad on the USB port somehow.  Choose “Do nothing” and “Do this always.”  Maybe it interferes with CCS Cloud if you don’t?

Distributed, Non-centralized, Sleep Synchronization in Ultra-low Power, Balanced, Single-hop, Sensorless, Wireless Networks


About this document

What: a survey, or notes

Status:  draft

I am coding an algorithm of my own design.  Shared code.

I plan to test either using simulation or TI Launchpads using CC2650 mcu/radios.

Explanation of the title and focus of this document

Distributed:  there are many units (processors.)   They communicate and cooperate.

Non-centralized: units are the same.  They execute the same code.  No unit has more resources.  Units may take different roles, but they all can take any role.  No central unit has complete information.

Sleep synchronization: synchronizing wake periods.  Units have sleep and wake periods.  More specialized than clock synchronization where units are always awake.

Balanced: all units have the same power.  None are powered by an electric utility grid.

Ultra-low power: units use microamps of power on average.  They use milliamps when active, but they are duty cycled (sleeping often.)  They use harvested energy such as solar energy.  They have a small or no battery.  They often reboot as energy is exhausted.

Single-hop: all units can communicate directly with all other units.  No unit needs to relay or route messages.  The network topology is bipartite.

Sensors: the units do not sense external events not synchronized with the network.  They can sleep for as long as necessary, without concern for missing sensing external events (that don’t have interrupts.)

Wireless: the units have a radio.  Messages can be broadcast.  There is contention for shared channels.  A radio may not be able to transmit and receive at the same time.

Relevant Literature

Digi Corporation’s proprietary DigiMesh product apparently has a sleep synchronization algorithm.  It apparently is a leader-election algorithm.  Many details are unavailable?

“Firefly Clock Synchronization in an 802.15.4 Wireless Network”, Leidenfrost and Elmenreich, 2009 describes an algorithm where units can sleep and synchronize.  They call it a “reach back firefly” algorithm.  Unlike a firefly (where a message is just a one-bit blink at the time of the synchronization point, without content), here a sync message is transmitted at an offset from the synchronization point and has the offset (many bits of information) as content.  Like most firefly algorithms, all units send sync messages.

Wireless HART has sleep synchronization, but it is centralized: synchronization propagates from a gateway device that has more resources (a connection to the internet) than other units.

There is much more literature, see later.


In clock synchronization,  a network (the units together) maintain a global notion of time. This lets units schedule internal events to occur simultaneously, or timestamp external events.  The units communicate to synchronize clocks.

Sleep synchronization means: synchronize the events: unit awaken and unit sleep.  Many clock synchronization algorithms assume the units are always awake.  It is harder to synchronize when units may sleep.

Time is kept by a Clock. It need not be referenced to an external, real time, such as sidereal (sun) time.

Each unit has a hardware clock, really just a counter.

A GlobalClock keeps the global  time.  Each unit has a GlobalClock.  It is based on the hardware clock. A GlobalClock is just an offset from the hardware clock.  Initially the offset is zero.  When a unit receives  a sync message from a master, a unit can calculate an offset and the local GlobalClock becomes ‘in sync’ with the master’s GlobalClock.

Hardware clocks drift (have slightly different tick rates) and so each unit’s GlobalClock drifts from every other units GlobalClock (especially the master’s.)  Thus to maintain an accurate GlobalClock, a unit must periodically receive a sync giving message.

The problem of maintaining the global clock is:
– getting an initial offset from a master (startup)
– periodically receiving offsets to correct for hardware clock drift (maintenance)

The global clock is NOT received from an external source e.g. GPS.


Each unit is duty-cycled: sleeping and waking.  When sleeping, unable to receive since mcu and radio are powered off (only a timer to wake the mcu is powered.)

The network is symmetric-powered. No unit has more power than others. No unit is not duty-cycled.

Units are the same, hardware and software. Each unit is capable of assuming any role.

Units have one transceiver that cannot transmit and receive at the same time. A unit cannot detect its own transmission has collided.

There is contention: collisions can occur on the radio channels.

Network topology is totally connected.  Each unit can hear all other units (and does so, except for collisions.)  No unit relays messages to other units.

Duty-cycle is high (sleeping mostly.) That is, put a high priority on conserving power at the cost of slow execution or missing external events. For example, when energy is harvested and units are small, the power available may be very low, supporting only a very high duty cycle (sleeping most of the time.)

Low performance. The work being done is not critical and extremely low data rate. Don’t care if the work doesn’t get done always. Only care that the work gets done sometimes. Here the work is both the synchronization and some additional coordination or data exchange.

Not Constrained

Not assume that units play equal, same role.

Not assume that the communication is uniform. Some units may play roles having more communication than others.

Not assume that lower layers of the protocol stack, e.g. the MAC layer, support synchronization, e.g. by timestamping messages with clocks used in those layers.

Not assume a sensing network. That is, the network may do something self-contained, without sensing external conditions or events.  Because units sleep so often, they probably would miss sensing many external events.

Classes of Algorithms

In “firefly” algorithms, roles are equal. Firefly insects are leaderless.

In “leader election” algorithms, some units play the role of leader (master of the clock.) Opposite of firefly.

In “time triggered protocol” algorithms, units have a common, slotted schedule, a priori, built into the protocol. Not only is the wake period scheduled, but the wake period is divided into slots reserved for certain units and tasks. Eventually, the schedules of different units are synchronized. This is TDMA.


This is a list of search terms. In searching, you must cast a wide net, since authors use diverse terms for subject matter that overlaps.

clock synchronization
firefly synchronization
sleep scheduling
distributed algorithms
wireless networks
wireless sensor networks or mobile ad-hoc networks
energy conservation or duty-cycling
clusters or cliques
self-organizing networks

Leader elections algorithms

Some algorithms form cliques (clusters) of units where units within a clique are synchronized, but cliques not synchronized with each other. The algorithms are said to go through phases of startup and maintenance. In the startup phase, cliques form and merge. Eventually all units are synchronized in one clique, and the algorithm is in the maintenance phase.

The maintenance phase corrects clock drift, and merges new cliques, when units join the network dynamically.  Joining units  may form new cliques until they synchronize with existing cliques.

General review of concerns in the literature

The general literature has many concerns.  Here I briefly discuss those concerns.

Coverage: in multi-hop networks (not bi-partite), insuring that the area covered by the awake network is maximal, so that any external events e.g. are sensed.

Precision: the goal may be more clock precision (e.g. uSec) than is needed just to synchronize sleep (e.g. mSec). This might require support in lower layers such as MAC.

Dynamic: networks in which units (possibly mobile) may join/leave the network.

Fault tolerance: if one unit fails or has inadequate power, the algorithm still keeps or recovers synchronization.

Drift correction: the drift of one hardware clock can be estimated. Drift is generally linear. Thus it can be corrected for. That saves effort in global synchronization.

Correctness: whether you can prove mathematically that the algorithm works:  1. doesn’t suffer deadlock 2. converges to a single synchronized clique.

Routing under energy constraints: when the network is multi-hop (not bipartite), routing through nodes having the most energy reserves.

Flooding: spreading a message quickly and with minimum transmissions (and/or energy.)

General review of the history of the literature

Radio has existed for a century, but it was controlled by people and transmitted analog messages.  Computer control of radios is relatively new.

Clock synchronization has been studied for centuries.

DARPA explored digital, packet-switched, computer controlled radio networks circa 1970 in the “ALOHA net”.

Radio networks where energy must be conserved and units sleep often is still a subject of research, with many recent papers.

Review of Recent Literature

Most papers use a capitalized acronym to describe their algorithm/protocol.

“Firefly Clock Synchronization in an 802.15.4 Wireless Network”

Discusses an algorithm that is both firefly and time triggered. It is reachback: sync messages have an offset.  It is firefly: all units transmit sync messages.

FTSP “Fine-grained network time synchronization using reference broadcasts”. Epson et al. 2002.
Distributed Sleep-Scheduling Protocols for Energy Conservation in Wireless Networks, Naik et al

The protocol is in the app/transport layer. No master, each unit sends sync (firefly). A unit sends sync in the wake period of its own schedule. A unit periodically listens for the entire sync period (to hear other cliques.) A unit also transmits sync in the sleep period of its schedule, to apprise other cliques (redundantly with listening.)
“A Survey of Energy-Efficient Scheduling Mechanisms in Sensor Networks”, Wang and Xiao.

“An application-specific protocol architecture for wireless microsensor networks” Heinzelman et al. 2002. LEACH-C. Multi-hop. Low-energy routing. Clustering.

“Self-organizing distributed sensor net- works” Clare et al. 1999. An early description of the basic idea of TDMA to conserve energy while organizing networks.

“Randomized Independent Scheduling (RIS)” Kumar et al. 2004. Glosses time synchronization in favor of coverage concerns.

Sponsored Sector” Tian et al.

GLOSSY. The concern here is flooding, with clock synchronization as a secondary benefit. The novel idea: when two nodes simultaneously send an exact same message (with no distinguishing characteristics such as sender ID), the messages do NOT destructively interfere, but are heard by many receivers as one message.

Firefly algorithms

Firefly algorithms are non-centralized and leaderless.

In general, firefly algorithms are not concerned with sleeping. Firefly insects don’t sleep while they are synchronizing. They also can transmit and receive at the same time. Also, they can communicate with multiple others at the same instant, since their eyes are multi-processing.

Firefly algorithms may be concerned with multi-hop networks, since firefly insects can be spread so far that each firefly cannot see some others.

Firefly algorithms (especially for insects, i.e. models of biology) may assume only a binary message, a pulse.

IEEE 1588 Precision Time Protocol (PTP)

This is “leader election.” An advance form sends two messages to establish a precise time: the first announces intent to synchronize at a time, and the second gives the precise time the first message was sent. The timestamp in the first message is not precise because of inherent unpredictable delays in the protocol stack, while some stacks will give you the precise time that a timestamped message WAS sent (via the return code or interrupt from the sending of the first message.)

Thus there are two sub-classes of “leader election”: “imprecise subclass” in which only one message is sent, and “precise subclass” in which two messages are sent.

PTP is not concerned with energy conservation and assumes network is always on.

Bluetooth as the Communication Stack

Classic Bluetooth is asymmetric power and connection oriented. A Central is typically a phone with much power. A Peripheral is typically low power and listens periodically for connections, but after a connection is made, stays awake.

Bluetooth radios have a choice of counter/clocks: precise crystals or imprecise resistor capacitor.

The Scanner/Observer roles can be used for broadcasting (without connections), not just for classic advertising of services.

BT advertiser is multiple access, but not carrier sense?

Typical jitter in the stack is as much as 5 milliseconds.

My specific use case

Ultra low power. Units lack batteries, instead use harvested solar power. They may sleep at night. They may have periods without enough power to sustain the volatile memory or a timer, and reboot often, say every morning. Duty cycle is very low, say 1%.  Bipartite: units are all within range of each other.  The units just display in sync, they blink an led or move.


Understanding “Unconnected” using KiCad Pcbnew

Using KiCad Pcbnew (PCB layout tool) you may see “Unconnected 1” in the status bar at the bottom of the GUI.  And you will see a ratsnest line (a thin white line) visible between some pin and the nearest place it could be connected.

This may happen even if you see that a copper layer (say ground fill) touches said pin.   And if you use “Highlight net” tool, clicking on that pin, it will highlight other ground pins.

So the message seems to mean “there is no trace that starts or ends on the pin.”  It does not mean “the pin is not electrically connected to the correct net.”  And the produced board might work, since the real, copper, ground layer will touch the pin.   So the message seems to be a warning in this case.

If you want to be safe and get rid of the message, simply draw a trace from the pin to some place in the ground fill, create a via, and end the trace.

Please check for yourself.   I could be wrong, I am not an expert.  KiCad might have changed since I wrote this.  The notion of connectedness is different in the schematic editor.