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.

Background

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.

Assumptions

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.

Keywords

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
flooding

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.
RBS

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.
FLOPSYNC-2

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.
Beacons

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.

Cloud IDE for programming

About this post

The subject is software development environments that are easy to set up and use from anywhere.

This post’s quality is low:

  • written quickly
  • more questions than answers
  • from my limited experience, not exhaustive
  • it discusses programming embedded micro controllers, not programming in general

The problem

You want:

  • to minimize effort administering your development environment, and maximize time spent writing software (SetupEase)
  • to work from any physical location (Mobility)
  • to use version control (Versioning)
  • not to lose work (Backup)
  • to share (OpenSource)

Some software developers work in a single development environment in a single location.  Others may switch between many environments and many locations.  For example, software developers for embedded systems might switch environments for each brand of microprocessor they use.  They may develop at home and at work.

The State of the Art

AFAIK, there is not currently a development environment that gives you all of the above.

Solution Pieces

  • Github
  • Dropbox
  • Containers or virtual machines
  • IDE’s in the cloud

Github

Github the software provides you Versioning and Github.com the website gives you some Mobility.  But it only gives you Mobility for your source and some parts of your development environment ( such as makefiles), not for your total development environment (such as what compiler you are using.)  And the Mobility is clunky, you can’t work in your open master repository, you must work in a clone and remember to push to origin master after each work session, so that your work will be available tomorrow from another location.

Dropbox

Dropbox gives you Mobility for your source files: anywhere you work, your files will be automatically synchronized (with slight lags.)  And you can put Github clones inside Dropbox.  But you still don’t have Mobility for your complete development environment, since your IDE or compiler is installed locally, not in Dropbox.

Containers

Containers or virtual machines give you SetupEase.  Someone else can install and configure your development environment, and you download and use the whole.  For example, a development environment for open source OS Mynewt is available in a container.

But containers don’t give you Mobility.  You must set up distinct (but identical) container instances in every location.  Any files you create in a container instance, and any modifications to the development environment, are local to the container instance.   Your container could include Dropbox having a Github clone, but you still must remember to push after each session, and that might not mobilize any modifications to the environment in the container instance.

IDE’s In the Cloud

Also known as “IDE as service.”  Here, you run your development environment in a browser.  A server:

  • stores your source files
  • stores your environment
  • does all the compilation
  • runs and debugs your app (with help from an agent to the target device)

An example is Texas Instrument’s CCS Cloud.  My knowledge is limited.  AFAIK it give you SetupEase, Mobility, and Backup.  It doesn’t seem to give you Versioning and Share.  It seems to let you clone Github repositories, but not commit in the clone, or push to the origin.

TI admits in the FAQ for CCS Cloud that for advanced work you probably will need to use CCS on the desktop.  In other words, CCS Cloud is only for experimenting or trials.

CCS Cloud does let you download any files from it, so you could use a manual process in which after every session, you download, commit, and push any files you have changed in CCS Cloud to your master Github repository in Dropbox.

Other examples might be “Particle online” and “mbed online.”  (I don’t know these.)

References

EmbeddedWeekly  blogs a little about this subject.  I read that before writing this post.

 

Using Energia with EZ430-F2013 LaunchPad on Linux

About this post

This pulls together various other posts and links.  Audience is someone who is new to embedded microprocessors (MCU) but otherwise  familiar with software development.

Context

Energia is an IDE.  It is a port of the Arduino IDE (swapping out Atmel AVR mcu for the TI MSP430 mcu.)  In other words, it is the Wiring development platform, but specialized for a different embedded mcu.

The IDE lets you edit programs and write them (flash them) to a target board.  This particular IDE does not have integrated debugging.

MSP430 is a family of ultra low power microprocessors from TI.  See the FAQ.

The EZ430-F2013  is one model of development kit for the MSP430.  It includes:

  • an FET (flash emulation tool) hardware
  • a detachable target board (detachable is unusual, most have pluggable IC’s)
  • other IDE software tools on a CD

A FET is an adaptor from your development PC to the target board.  Adaptor: it has a USB connector on one end, and a connector to the target board on the other end.   It adapts from USB serial to Spy Bi Wire serial.  This particular FET and connected target board are in a USB stick form factor or package.  With the IDE, it lets you:

  • flash the memory of the target board
  • debug the target board using a version of gdb talking JTAG/SBW to the target

The target board is a small PCB having:

  • the MSP430F2013 model mcu
  • one LED
  • two rows of breakout pins for you to add circuitry
  • a four-pin connector to the FET.

You can also buy a  EZ430-F2012 (part number), which is a package of three compatible target boards, except they have the MSP430F2012 (model number) mcu.

Why this combination?

Pros of all TI’s other development kits:

  • cheap, TI seems to be subsidizing
  • target mcu is ultra low power, TI seems to be emphasizing low power for the IOT, and has many other low power chips
  • target mcu is small in area

Pros of this development kit:

  • the target mcu is VERY small (a few tens of mm squared)
  • you could use the detachable target board as a component (although it has an odd half-moon shape).  It’s the size of your thumbnail.

Pros of Energia:

  • it has an approachable language (a simple subset of C++)
  • it has many built-in libraries
  • you can also program in C++

Cons:

  • its basic, low-end, and older
  • the target mcu has too small 2K flash memory for large programs
  • the target mcu has few IO pins
  • the target mcu has few modules (peripherals): only an ADC, and a few timers
  • its not very popular, most professionals use other development kits, other IDE’s, and other programming languages (assembler or C)
  • several IDE functions use the command line (debugging)
  • it flashes using SBW, which is slower than a full JTAG programmer
  • it doesn’t interface the serial port of the target board (to let you print)

For learning, its great.  But consider whether the target board will meet the needs of your application.

Install Energia

Download Energia   On Linux, expect a .tgz file to download.

Unarchive it.  Expect it to create a directory “energia….” in your home directory.

Follow the instructions for installation on that page (except for the udev.)

Setting up the udev

On Linux you must set up a UDEV.  If not, you may later see an error message:

ti3410: warning: can't detach kernel driver: Operation not permitted

which means, in Linux, you don’t have permission to write to the USB device.

However, the given instructions don’t work. ( The USB stick has ID  0451:f430  which is different from any listed in the downloadable udev rules.)

Instead use an editor to create a file named 46-TI_launchpad.rules in this directory location:

/etc/udev/rules.d/46-TI_launchpad.rules
having this contents:
ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f430", MODE="0660", GROUP="foo"

where ‘foo’ is the group that you belong to.  You need to be superuser, so use >sudo nano or >sudo vi to create the file.  What this does: at boot time, the OS gives permission for anyone in the group to read and write the OS device file (/dev/tty?).

Restart your computer.

Patch Energia for the MSP430F2012 or 2013

Energia doesn’t properly support this development kit (there are patches waiting to be approved and merged on GitHub.) But you can fix that by:

Edit ~/ener*/hardware/msp430/boards.txt.

Copy and paste the first block of text.

In the copy, change:

‘r2500’ to ‘uif’ after the word ‘protocol’.

‘msp430g2331’ to ‘msp430f2012’ or ‘msp430f2013’ everywhere in the copied block only

If you omit this step, when uploading you may see the error message:

usbutil: unable to find a device matching 0451:f432

Start Energia

Open a terminal.

>cd ~/energ*
>./energ*

Expect a GUI application to start.  Stuff will still scroll in your terminal window, but the same stuff appears in the bottom pane of the GUI.

Swapping target boards

You can pry the plastic USB case apart with a small blade or screwdriver.   It is split down the middle.  It has friction fit, plastic pins.  Pry one half straight up.   Then the target board pulls off the end.  You probably should saw the end off the plastic case so you can handle the unit but more easily change the target board (if you intend to flash more than one target board.)

If you intend to use the ADC of the F2012 mcu, swap the target board out first thing.  The F2013 has a different ADC (a SMA_16 16-bit) versus the F2012’s ADC10 (10-bit).  The ADC registers are at different addresses.  The MSP430 architecture (ISA) does NOT generate exceptions (trap) for all illegal addresses or illegal opcodes!  Instead, it quietly lets you read and write some addresses (device registers) for which there is no device.  In other words, if your program that uses the ADC doesn’t work as expected, maybe you are including the .h file for a different target and addressing the wrong ADC.  The ISA is subject to change between models, read the datasheets carefully.

Plugin your EZ430-F2013 USB stick

Plugin your EZ430 USB stick.  Expect it’s LED to start blinking.  (When powered up, it resets, and the factory programmed “blink” program starts running.)  The LED may never blink again, depending on your programming skills.

Test the Blink program

Choose File>Examples>Basics>Blink.  Expect a new program to load into the IDE.  This program is compatible with the target board (which has one green LED on Port1.Bit0).

Choose Tools>Board.  Expect to see a list of boards.  Select ‘LaunchPad w/ msp430f2012 (1MHz)’.  (Or …f2013)  Expect the item becomes selected, but nothing else.

Choose File>Upload.  Expect output from the compiler and an upload result message.

If it fails, try again.  Inexplicably, sometimes it fails to upload, with this:

fet: FET returned error code 4 (Could not find device or device not supported)
fet: identify failed

When it works, expect:

ti3410: warning: can't detach kernel driver: No data available
Device: MSP430F20x2
fet: FET returned NAK
warning: device does not support power profiling
Erasing...
Programming...
Done, 788 bytes total

Note that here I have already swapped out the F2013 target board for a F2012.

Expect your USB stick blinking again.

Now you can go on to write other programs.

Using the serial port

The menu Tools>Serial Port remains greyed out (disabled) and will remain so.   The FET has two pins toward the target board that are not connected to the target board.  Thus the FET can not read the serial port of the target board, and your program will not be able to print to the serial port and expect it to appear on the IDE.

The target board does have breakout holes for the TXD and RXD pins of the target mcu.  You might be able to jumper them to the FET.

Probably the designers of the target board decided that since memory on the target board is limited, it would not hold a library implementing serial IO (in addition to other program code.)

Debugging

You can use gdb on a command line to debug the target device remotely (the target supports JTAG so this is possible) as described by an Energia dev.

Energia invokes the mspgcc compiler with optimization.  You might need to alter you program (remove inlining) to insure that functions appear as symbols.

From an obscure post by Ingo:

mspdebug does not use debug symbols (the ones you enable with the -g compiler switch), just the plain symbol names that are also used for linking. However, in the ELF format, each symbol has a type field, and mspdebug only uses symbols of certain types (object, function, etc.). You can display the symbol table of an ELF object with “readelf –syms file.o”. Symbols whose type is listed as NOTYPE will be ignored by mspdebug.

An example of what you can do (see gdb for more):

  • set breakpoints (>break foo)
  • print object (variable) values (>print foo),
  • ctl-C interrupt the target and show the backtrace (>bt)

Programming in C++

You don’t need to use Wiring.  You can program in C++, C, or even assembly language.  A short blog.

Not using Wiring saves much program memory. For example, the  Stepper library with a few other Wiring libraries would not fit into the 2k memory.  But recoding relevant parts in C++ did fit.

To code in C++/C you might need to understand:

  • the gcc compiler variant that Energia invokes
  • the intrinsics to assembler that the compiler supports (section 6.8 of the above)
  • interrupt handling and the ‘vector’ pragma (section 6.7)
  • the runtime environment (section 6.  It sets up the stack, etc.)
  • the include file that defines target addresses, constants, and other language constructs (in this case “#include msp430f2012.h” or …f2013.h )  which are found at ~/ener*/hardware/tools/msp430/msp430/include/

Typical code flow

See TI’s Application Report MSP430 Software Coding Techniques.

But adjust to fit.  For low power, you will need to use interrupts, but you don’t need to use flags, you can have a state machine and enter low power mode from many states.

Development Kit User’s Guide

The development kit User’s Guide  :

  • includes a schematic
  • tells how to use the other IDE’s, but not Energia
  • gives instructions for opening the case

Using the FET for other targets

You can design your production PCB with a matching four-pin connector, and program/debug it using the FET portion of the development kit.  The four pin connector has Vcc, Vss, and two SBW signal lines.

You might be able to use the FET with a different target.  I haven’t tried it yet.  I don’t know of any impediments.  My opinion is that TI is downplaying the ability of the FET.  The User’s Guide says it will work with other devices in the ‘MSP430F20xx’ family.  (I am hoping it works with devices in the MSP430FRxxxx family.)

Ultra Low Power Hardware and Coding

Ultra low means: less than about 1uA average current.  That gives tens of years on a coin cell battery.  Or lets you use energy harvesting.

The mcu when active draws tens or hundreds of uA.  Thus to achieve ultra low power, the mcu must be sleeping (in a low power mode) much of the time, and use interrupts to wake up.

If you have external interrupts, the lowest power mode is LPM4 (the mcu and peripherals off, but external interrupts will wake.)  Called ‘Off Mode with RAM Retention’.  Draws 0.1uA.

If you don’t have external interrupts, sleeping is low power mode LPM3 with a timer peripheral running in the mcu to interrupt and wake the cpu up.  In this mode (called standby), the MSP430F201x draws 0.5uA.

If you need accurate time, you can implement a 32-bit  RTC in software, as described by a TI Application Report, using an external clock crystal (loses 1 second per month) to the 16-bit timer (which wakes up the system every few seconds to tick the 32-bit software RTC.)

If you don’t need accurate time, you can use the VLO portion of the clock module as the clock source for your timer.  That is the lowest power standby mode.  See the datasheet for the MSP430201x.

If you need even lower average power, you can switch power Vcc to the mcu, using an external chip such as the TPL5010 Nano Timer which draws only 35nA (0.035uA.)  But then you might lose any data saved in volatile memory (RAM) such as the context of your application (and the application must restart.)

TI makes MSP430FRxxxx‘s having FRAM and using as little as 0.35uA current in standby mode.  Some models have a 32-bit RTC implemented in hardware.  Check the datasheets, its not clear to me for which applications this family saves power.   The smallest member/package for this family has 24 pins, compared to the 14 pins of the F2012, and is 16mm square, about the same area.  (These packages are near the limits of what you can solder at home.)

More about JTAG and Spy By Wire (SBW)

See JTAG and SBW. JTAG uses many signal wires, SBW only two.  SBW is slower.

Also see section 28 Embedded Emulation Module of the MSP430x2xx Family User’s Guide.

In short, it means that you can use a software debugger (similar to gdb) to remotely debug a program on an  embedded MCU while in-circuit (soldered to a prototype or production  PCB) using only two wires to connect from the development machine to the PCB.  That is, you don’t need to simulate, you can debug under actual hardware conditions.  If the hardware timing conditions are not so severe that you need a more powerful solution.

 

 

 

Panelizing a PCB in KiCad

About

This is a tutorial for panelizing (producing a panel comprising replicates of a small PCB) in KiCad.

The goal is a separate design, a panel comprising a horizontal row of my boards separated by the 100 mil routing width that my fab uses.  The purpose is a panel that is an easily handled batch during assembly  (solder paste stenciling, placing SMD components, and moving to the reflow oven.)

This is specialized:

  1. uses KiCad
  2. replicates one small board,
  3. I don’t design internal support tabs
  4. I don’t design a frame around the replicates
  5. it’s a manual operation using fiducials and block copying

In this example, I assume the fab is OHSPark:

  1. requires 100 mil separation
  2. they will add internal and external support tabs
  3. they don’t require a frame (since I will accept if the panels break apart in shipping.)

Internal support tabs hold the panel together.  External support tabs hold my panel in the larger panel that the fab makes.

There might be other ways to do this.  At one time there existed Python scripts to automate this.

Overview of the process

Use fiducials (layer alignment targets.)  Create an initial fiducial pair at grid size 100 mils. Use a minimum grid size( 0.01mm) and nudging with the arrow keys when aligning copies.  Use block copy to copy both the PCB and nearby fiducials.

Here is a picture of the nearly finished result:

Panel

 

Before you start

You have a finished existing board design.  (Any changes to it will not automatically flow into your panel design.  You will need to redo your panel if the child PCB changes.)

Your zone outlines and all other components are within your PCB edge outline ( simplifies block copy.)

The line width of your board outline (in Edge.Cuts layer) is small (say the default of 0.15 mm).  This matches the line width of fiducials, making it easier to see when your board outline is corner aligned to a fiducial.  (Your fab cuts to the center of the graphic line defining the edge.)

Your existing board design need not be aligned to any particular grid size.  Your board size need not be a multiple of any particular grid size.  (Although it might be easier if your board is aligned to a 100 mil grid and a multiple of 100 mils in size.)

The process

Starting PCBNew app

Click on the PCBNew icon (in your desktop, launcher, or file browser.)  Expect a window showing an empty PCB design.  (Note you can’t start PCBNew from within your existing project, since then it opens your existing design, that you should keep separate.)

Import your existing PCB into the empty panel design

Choose File>Append Board.  Expect a file browser to open.

Select the foo.kicad_pcb file of your existing PCB design and choose the OK button.  Expect a floating view of your existing PCB design.

Click in the sheet anywhere to place the first copy of your PCB.

Add two fiducials on a 100 mil grid

Choose ‘100 mils’ from the grid combobox in the toolbar.  Expect the grid to change.

Select the fiducial tool by clicking in the “Add layer alignment target” icon in the right toolbar.  Expect the cursor to change to a pencil icon.  Click in the sheet near the upper right corner of the PCB copy.  Expect a fiducial symbol placed on the sheet, snapped to the nearest grid point. (It is in the Edge.Cuts layer.)

Repeat, placing another fiducial 100 mils to the right of the first fiducial.

Align the first replicate’s upper right corner to the left fiducial

Choose ‘0.01 mils’ from the grid combobox in the toolbar.

Zoom in so you can see precise alignment.

Choose the pointer tool.

Drag out a rect around the PCB.  Expect a “Block Operation” dialog to open.  Choose the OK button.  Expect an image of the PCB to follow the cursor (an the original to remain visible.)

Align upper right of the first replicate to the fiducial’s cross, and click the LMB (left mouse button.) Expect the PCB to be placed.

Delete the left fiducial

Using the pointer tool, click the RMB (right mouse button) on the left fiducial.  Expect a context menu to pop up.  Choose “Delete Target.”

Block copy the PCB and fiducial

Using the pointer tool, drag out a rect around the first PCB replicate and the fiducial to its right. Expect a “Block Operation” dialog to open.  Choose the OK button.  Expect an image of the PCB  and fiducial to follow the cursor, but for the original also to be visible.

Align upper left of the dragged copy to the  fiducial of the original.  Click the RMB ( right! mouse button.) Expect a context menu to pop up.  Choose “Copy Block”.  Expect a second replicate of your PCB to be placed.

(Also expect horizontal rat’s nest lines to appear, connecting nets in the left copy to nets in the right copy.  You can ignore those, or “Hide board ratsnest”.)

Note that unless your board is a multiple of 100 mils wide, the newly copied fiducial won’t be on a 100 mils grid.

Repeat

Delete the left fiducial and again copy the right PCB ( or many of them) and the fiducial to its right.

You might make a few more copies.  You should not make more copies than will fit in the larger panels used in the fab.

Delete  fiducials

KiCad puts fiducials in the Edge.Cuts layer.  Some fabs (OSHPark) might deal with this as you expect, while other fabs may route out (drill) the fiducials!  A post on the KiCad forums discusses this.

You should probably delete the fiducials, so you don’t worry about how your fab interprets them.

Save As

Choose File>Save As and so forth to save the panel design.  You probably should create a separate folder to put it in.  In that separate folder, you can also put the Gerbers for the panel.

(If you choose File>Save you might get an error message, probably because on some platforms, KiCad attempts to save in the locked directory of the application file.)

Finishing up

You might want to run the DRC.  It should still work.

You now can plot Gerbers and generate a drill file.  (It seems like you must choose an absolute path for the drill file, else KiCad attempts to write it in a locked app directory?)

One advantage of a panel such as this: the solder mask Gerber layer will precisely align with the boards of the panel.  (You don’t need to panelize a solder paste stencil like you might for a happenstance panelization that the fab might create and deliver to you.)

Accuracy

I don’t think you need to be super accurate.  When I do it, the alignment seems a few pixels off, less than a mil off.  Use the arrow keys while dragging to nudge your PCB a few pixels.

Even if the distance between your PCB copies is a few mils off, the fab actually uses a router bit that is smaller than 100 mils (it cuts on the way into a slot, moves over, and cuts on the way out.)

If the outer edges of your panel are a few mils off, your panel will still probably fit in the jig for your solder paste stencil.

In other words, don’t worry about a few mils, because your home hobbyist processes don’t require that accuracy.

Disclaimer

I haven’t tested this with OSHPark yet.

 

 

 

Fundamentals of mobile, indoor energy harvesting

This is a quick list of essential facts, without links or references.  I learned these working on my application: solar powered Calder mobiles (trademarked Solabiles.)

Energy harvesting:

  • not connected to the power grid
  • years, or forever, between any battery changes
  • harvests ambient or waste energy
  • harvests light, heat, or vibration

Light has the most energy, for mobile or ‘anywhere’ harvesting.  Only constrained points, such as on a hot surface (a body?) or on a vibrating motor, might have more harvestable energy.

Energy harvested is proportional to the light level.

Light levels indoors are exponentially smaller than outdoors.  Roughly:

  • full sun: 100k lux
  • shade but with full sky exposure: 10k lux
  • bright indoor: 1k lux
  • average home lighting: 100 lux

The lighting within a room can vary exponentially:

  • near a south facing window, overcast winter day: 1k lux
  • other side of the room: <100 lux

Lighting in a room can depend on the direction windows face:

  • near a south facing window, overcast winter day: 1k lux
  • near a north facing window, overcast winter day: 100 lux
  • other side of the north room: 10 lux

The human eye and brain hides the above facts.  It doesn’t seem that the lighting is so different in a room, but a luxometer tells the story.

Solar cells produce energy proportional to their area.

Solar cell technology probably is not going to get much better soon.  They might double in efficiency, but they probably won’t reach 100% efficiency.  You must make improvements elsewhere.

At low light levels (indoors), amorphous silicon solar cells produce more energy than crystalline silicon solar cells.

Solar cells and panels produce the most power at their maximum power point (see MPPT.)  In other words, when they ‘see into a load’ of the voltage of their MPP.  (I don’t really understand why, and the best water analogy I can come up with is:  a very thin sheet of water is a lot of water but has little pressure, and can’t do much useful work.)

You don’t necessarily need an “energy harvesting” chip.  They provide:

  • voltage boosting
  • MPPT
  • battery management (using a battery might bring its own set of problems to a design.)

If you don’t need either of those, you do your own MPPT: insure the voltage the solar cell sees remains near the MPP (whenever conditions allow.)

Ordinary capacitors, supercapacitors, and batteries use different technologies that each bring their own design problems.

At very low light levels, say <50 lux, the leakage of circuits is important to a design.  See my next post.

Panelizing Gerber masks for solder paste stencil for tiny PCB’s

Context

You have ordered tiny PCB’s from a fab such as OSHPark. The boards are SMD.  You want to order a solder paste stencil such as from OSHStencils.  You want the stencil to cover many of your PCB’s at once.  This tells how to edit the Gerber paste mask (that you will submit to OSHStencils) to do that.

More background.  For the cheapest service, you order multiples of three from OSHPark.  For very small boards, OSHPark MAY deliver them in panels: multiples still connected together by break-off tabs.   Call that a ‘happenstance panel.’   Then you can paste them many at a time (say three at a time).

You can’t predict what happenstance panels (what size and what orientation) OSHPark will deliver.  You may need to wait till your PCB’s are delivered (to see what panels they are in) before you order your stencil.

Some fabs may break them all apart for you, and these instructions are moot.

Alternative

If you don’t want to rely on the luck of the draw in happenstance panels, you panelize your board before submitting to OSHPark.  This means you design an outer, framing board that contains multiples of your real board.  See Panelizing: OSHPark.  OSHPark delivers the panel without breaking out your contained boards.  You can design a stencil that exactly aligns with the contained boards (since you designed the panel, you know the separation between contained boards.)

One disadvantage is that you pay more, since the panel includes a border of empty board.  The border is a handle for use by the fab, and for your use to hold your boards in alignment for the stencil.  Also, you still must order a multiple of three panels.  E.g. if your panel contains three of your board, you must order three panels, or nine of your boards.

Example

board size: 16mm by 16 mm

OSHPark kerf (width of the saw blade or router that cuts the outline of boards), aka space between boards:  100 mils = 2.54 mm

Repeats of your PCB in a panel: 3

Panel layout orientation: horizontal (side by side.)

How-to

Start GerbV (a GUI app for viewing and editing Gerber files)

Change units to mm (for this example)

  1. Choose View>Units>mm.  Expect the rulers to change, etc.

Open your paste mask Gerber file

  1. Choose File>Open Layers.  Expect a file chooser dialog
  2. Navigate to your Gerber file
  3. Choose OK.  Expect you Gerber file to appear as a new layer

Repeat the above twice more.  That is, open the same Gerber file to create many layers each showing the same paste mask.  Each will be a different color but they overlay each other.

Translate a layer by the width of your board plus the kerf.

  1. Select a layer in the left frame of the GUI. Click on the layer and expect it to highlight in the left frame.
  2. Choose Layer>Modify Orientation.  Expect a dialog
  3. Enter a value in the Translation>X(mm) text box, for example 18.254 (16 for the board plus 2.54 for the kerf)
  4. Choose OK.  Expect the dialog to close.
  5. Zoom out.  Expect to see the translated layer moved to the right

Repeat once more, but offset the layer by a multiple of two ( 2 times 18.54).  Expect to now have three different color layers spread out horizontally.

Merge the layers into one file.

  1. Choose File>Export>RS-274X Merge (Gerber)….  Expect a file chooser to open.
  2. Enter a name and directory for the file, say “MyPasteMaskPanel.gbr” (its traditional to have a .gbr extension, but the file chooser doesn’t add it for you?)
  3. Choose OK.  Expect the file to be created.

Check your work by closing this GerbV project (if you are saving projects), start a new project, and File>Open Layer on the file you just created.  Expect it to show the same graphics, but now in one layer of one color.

That’s it, submit the file to your stencil maker.

Other notes

You don’t need to worry about how the paste mask panel is aligned on a page.  The stencil maker will cut your tiny panel in the center of a page of plastic film.  You will cut it out and mount it in a jig that registers it over a panel of PCB boards.

You probably shouldn’t use a repeat of more than about ten.  Errors may accumulate?  For a repeat of three, you can be sure the center repeat exactly aligns with a board, and the farther you go to the sides, you may see inconsequential errors in alignment?