Teardown: Behind the ESC collector’s badge
At EDN we’ve dug into the design to give you insights into the design thinking behind the ESC 2016 Collectable Badge as well as a head start on building or modifying your own.
The high-level concept for the badge called for it to address several requirements. It needed to support business networking among badge wearers by using wireless networking to draw together those with similar interests. It also needed to provide an educational opportunity for wearers to learn more about mesh networking and embedded development. Finally, because all work and no play makes everything dull, it needed to provide opportunities for just plain fun. And, as always, cost was a consideration – especially as these were to be given away.
Initial design thinking
A preliminary design phase, including several e-mail design reviews, established much of the badge’s functionality. The developers started out by exploring the badge format’s potential for the project, analysing the designs of other electronic badges that have appeared at various trade shows. This investigation established the size parameters that would be tolerable for a badge-like device and revealed that weight was not a significant consideration. The research also suggested that the badge advertise a user’s interests to other attendees to help support business networking.
The team wanted to perform this advertising in two ways. One was to use a visual display that would communicate wearer interests to everyone around. The other was the use of wireless mesh networking to communicate interests specifically to other badge wearers. The same networking technology as used in the earlier propeller beanie design – SNAP from Synapse Wireless – would be used in the badge design. This approach would provide both the wireless connectivity and a user-programmable application processor in a single package.
The nature of the visual display was a significant consideration, however. The display needed to be large enough to be read at a distance and dramatic enough so that badge wearers could spot one another in a crowd. It also had to be versatile enough to provide more than text messaging, but it could not be too expensive. This combination of needs quickly eliminated such options as graphical displays, e-ink, and LCDs.
The developers settled for a matrix of individual LEDs, chosen for their low cost, high visibility, and simple interface. This matrix would support both text as well as simple graphics, with text scrolling across the display for extended messages The final decision was to use simple red LEDs. Tricolour LEDs received consideration, but the LED price difference as well as the more complex drive requirements outweighed the benefits of tricolour for this application.
Power considerations
Power was another key consideration in the initial design thinking, with 10 hours of continuous operation a design goal. Battery power was obviously essential, but the lack of a weight restriction on the badge opened many options, including use of standard cylindrical cells instead of more expensive and lower energy coin cells. The team considered rechargeable cells, but concluded that the cost and added complexity of the charging circuit (especially if designed to avoid potential fire hazards due to overcharging) outweighed any benefits. The final choice was to use alkaline AAA cells.
While AAA cells would provide a nominal 1.5V each, however, they do not have a flat discharge curve, as seen below. This discharge curve complicates the power situation, especially when trying to maximise the badge’s operating lifetime on a single battery. Using two AAA cells would provide a supply voltage that started at 3.0V but would decline to just under 2V over time. Three AAA cells would provide 4.5V declining to just under 3V. While there is a large body of electronic devices that work with a nominal 3.3V power, their full operating ranges vary. Some will not tolerate voltages above 3.6V while others will not operate below 2.4V. So, either the devices used would have to be restricted to those that work over the full discharge curve, or some sort of power regulation would be necessary.
Figure 1 – Typical alkaline battery discharge curve
The use of LEDs for the display also encouraged the use of power regulation. With an unregulated battery supply the display’s brightness would vary over time, gradually dimming as the batteries discharge. While such dimming is not a failure, exactly, it works against the objective of having a highly visible display.
The problem with power regulation, however, is that it is inefficient; it wastes power. To maximise battery life while meeting the need for regulated power to some parts of the design, then, the developers decided to split the design into two power domains. One domain would use unregulated battery power while the other domain would use regulated battery power. This approach would minimise the current draw through the regulators as well as provide opportunities to selectively remove power from domains, creating “sleep” modes that would help extend battery life.
Promoting hackability
A third key consideration in the badge’s preliminary design centred on providing the design with the resources for expanding its operation beyond the initial business-oriented interest display. This expansion needed to provide opportunities for both education and play. Ultimately the team decided to include one sensor – an accelerometer – that could be leveraged for a wide variety of applications, including activity detection to trigger a sleep mode when the badge was not in use. The team also included connectors for attaching additional electronics to the badge’s core processor. To support widely-available open-source expansion hardware, the team decided to make the expansion connections compatible with Arduino shields.
The final hardware design elements, shown below, include an 8×8 LED matrix to scroll messages, a Synapse Wireless SM 220 SNAP module to provide the wireless networking and applications processor, various switches for configuration and control functions such as selecting areas of technical interest (ANALOG, DIGITAL, HARDWARE, SOFTWARE, STEM, and/or the IOT), a USB interface, an accelerometer, and the hardware expansion sockets. The badge can be powered with two AAA batteries or via the USB port and power conditioning and regulation is provided where appropriate.
Figure 2 – Final design layout of ESC 2016 Collectable badge
An 8×8 matrix arrangement was chosen for the display LEDs to help simplify programming by allowing developers to leverage a considerable body of text fonts and graphics characters. There is also an open source character editor available for an 8×8 array. Both are a legacy of the old Commodore 64 computers, which used the 8×8 arrangement in their displays.
Hardware design details
In line with the open-source spirit behind the ESC 2016 Collectable Badge design, the developers used the KiCAD EDA platform to create the hardware design. The libraries used in the design as well as the resulting output documentation, including schematics, Gerber files, and bills of material, are freely available under the Synapse Wireless GitHub account for readers to replicate (and modify) their own badges.
A detailed look at the hardware design schematics (Rev B as of this writing) shows that the ESC badge uses one of two, switch-selectable energy sources: a pair of AAA batteries or the USB port. From these sources the badge develops four power domains: Vin_USB, Vreg_in, Vcc, and LED_3V.
The Vin_USB power domain arises from the USB port’s input power signal after filtering. This power domain supplies the USB-to-serial converter (U3) as well as an inrush limiter circuit (Q2) that produces Vreg_in. The arrangement ensures that the converter is only energised when a USB power source is present; no battery power is involved.
Vreg_in passes through an LD1117 3.3V regulator (U4) to provide the USB input to a DPDT power selection switch (SW1). The BATT input to switch SW1 comes from the AAA batteries following some filtering and a reverse-polarity protection circuit (Q1). The power selection switch output forms Vcc, ensuring that Vcc is either the unregulated battery voltage or a regulated 3.3V from the USB. The Vcc power domain supplies most of the board’s circuits as well as the expansion connection. NOTE: This design requires that only 3.3V Arduino shields be used to expand the badge’s operation.
The LED array as well as the LED controller, however, operate from the LED_3V power domain, as does a level-shifter IC (U7) that translates the controller’s I²C signals between Vcc and LED_3V. The LED_3V domain arises from a boost circuit connected to Vcc, as shown below. The TPS61070 used in the boost circuit can generate 150 mA at 3.3V with an input voltage as low as 1.8V, or 0.9V per battery cell. A control line that disables the boost circuit and level shifter – LED_PWR_EN – provides the board’s application processor a means of shutting down both the LED array and its associated circuits when not needed, to conserve battery power.
Figure 3 – Boost circuit for LED power domain
The AS1115 LED controller (U2) provides two functions for the board: it drives the LED array and scans an 8-element, function-select DIP switch (SW5) that users configure to signal their areas of interest. The board’s silkscreen designates six switch elements for STEM, analog, digital, hardware, software, and IoT areas of interest. The remaining two switch elements are simply numbered S7 and S8.
Reports from the developers indicate that the LED array and the LED controller presented some of the first challenges during initial board debugging. The open-source EDA library element for the LEDs, it turns out, had its silkscreen symbol showing the opposite polarity from its schematic symbol. As a result, the board’s first prototype run had all of the LEDs installed backwards, requiring hand rework of 64 surface-mount LEDs. While this library problem has been fixed in the project’s GitHub files, it serves as a cautionary note to all open source users. Check all aspects of new library elements before adopting them.
Another problem found during debugging resulted from a mismatch between the LED controller’s operation and the 8×8 character fonts used in messaging. As shown below, the spec-sheet diagram for the AS1115 shows that in its 8×8 display mode, eight digit lines (D0-D7) drive the columns while eight segment lines drive the rows in the array. The typical 8×8 font element has each byte represent one row of the array, so it would appear that the program should simply load eight bytes into the digit registers in order to display the character.
Figure 4 – Spec-sheet recommended LED controller matrix mode configuration
With the array wired under this assumption, however, the result of using standard character libraries is a transposed character. The AS1115 controller is designed primarily to drive eight seven-segment (plus decimal point) LED displays using values stored in its eight digit registers. The controller achieves this by scanning out individual bits from each digit register to the eight display lines (D0-D7) in sync with scanning the corresponding segment lines. So, bit 0 for all eight digit registers goes out as D0-D7 when Seg A is active, bit 1 when Seg B is active, and so on. A byte stored in a digit register thus corresponds to a column, not a row, when the array is wired per the spec sheet. To avoid a need to transpose all the character font libraries, the development team needed to rewire the array.
The remaining elements of the hardware design are the SM220 module (U1) and the I²C accelerometer (U5), pushbutton switches, and expansion headers attached to it, along with various decoupling capacitors. The SM220 module is the heart of the board design, providing an Atmel ATmega128RFA1 microcontroller with integrated transceiver, RF circuitry, and integral antenna.
Badge software design
The microcontroller on the SM220 module used in the badge design comes pre-loaded with the SNAP operating system and other code to handle the mesh networking protocols as well as an interpreter for the Python-based SNAPpy programming language to provide an API and to handle application scripts for users. The firmware in for the badge thus has two components: an open-source applications script and the proprietary SNAP operating system, SNAPpy interpreter, and API.
Developers seeking to replicate or experiment with the badge design need not worry much about the proprietary components, however. That firmware has a free developer’s license for those working with one hundred or fewer units in their system. The license also includes download and use of the Portal development environment needed for development with the module.
All of the application scripts for the ESC 2016 Collectable badge are available for download on the Synapse GitHub. These are works in progress and not all components had been released at the time of this writing, although they will before ESC Boston. The repository also includes drivers for a motor-control Arduino shield used in a robot mode available for the badge, character fonts, and other “doodads.”
The master script defining how the badge will operate at ESC provides several modes of operation. In the default mode the badge will scan the interest switches and use those values to display a scrolling message on the LED array listing the wearer’s interest. It also will send out a “heartbeat” signal to locate other nearby badges.
In the event a badge detects another nearby badge, it changes its display to flash “Hi” and the two badges exchange information regarding their interest settings. When nearby badges share similar interest settings they will flash a specialised message. If more than five badges are in proximity, they will all flash synchronised “fireworks,” instead. This behaviour can be avoided, however, if the user has selected S8 in the interest switch array (dubbed the “anti-social” bit.)
One specialised mode that can be activated during ESC, by means of commands sent over the badge mesh network by conference personnel, serves as a contest for badge holders. Activation of the contest mode overrides all other operating modes for the badge. Details of the contest are to be revealed at the conference.
The badges also allow a user to switch from the default mode to a game mode by using the two pushbuttons L and R near the top of the badge. Pressing both buttons and holding them for several seconds will bring the board to a menu select mode that displays an animated icon for one of ten additional modes (plus the default) the badge can enter. Users scroll back and forth among these icons using the R and L buttons individually and select the desired mode by pressing both buttons together. As of this writing, these additional modes include snake, rollerball, breakout, and dice games. By the time of ESC the menu should also include rock-paper-scissors and reflex games, a spirit level, a spectrum analyser, and an ability to enter a user-defined message into the display. Exiting any of the additional modes returns the badge to the default mode.
The script the developers have created are structured to facilitate hacking. All of the operating modes, including the game modes, can be readily implemented in the Portal development environment as stand-along functions for the badge. They each offer two entry points: one for use with the menu selection mode and one for use in a standalone mode.
The master script is also designed for hacking. Its structure, as seen below, uses an application-switching script that the menu selection script calls when the user has chosen an operating mode. The switching script makes use of a “context tuple” the menu selection script supplies. This context tuple specifies what code runs when hook events occur. Hook events include initialisation, timer occurrences, button presses, and the like.
Figure 6 – Software structure for the badge master script
(Source: David Ewing, Synapse Wireless)
The advantage of this structure is that it simplifies the modification of menu items or the addition of new ones to the design. All a developer needs to do is create the script for the desired mode, including any special display characters needed, and define the relevant context tuple. In the master script, import the new script and insert the context tuple into the esc_selection_contexts list. The new (or modified) mode is now available without affecting the remaining code.
Not all scripts will need all the hooks defined in the context tuple. The software design accommodates such variation by allowing developers to specify “0” or “None” to retain a prior callback from the previous mode, or to insert an empty callback for an unused hook, respectively. This approach allows for a collection of menu items to re-use code for certain event hooks without needing to replicate the code for each menu script.
One special feature of the code that comes with the ESC 2016 Collectable Badge is a robot remote control mode. This mode allows a user with one badge to control a robot made from a second badge with a motor control shield attached. The user steers the robot by tilting the control badge.
Figure 7 – Software structure of the robot control mode
(Source: David Ewing, Synapse Wireless)
The code structure for this robot mode is shown above. One block of code runs on the control badge, either stand-alone or as a menu-selectable item. The other block of code runs as stand-alone code on the robot badge.
Conclusion
Only some 100 or so attendees to the 2016 Embedded Systems Conference in Boston will receive a fully-configured ESC 2016 Collectable badge and just a handful more will be able to win robots built on the badge. But the design itself is open source and all the files needed to build and program your own badge are available at the links provided. The developers intended the badge to serve as an ongoing platform for experimentation and development using wireless mesh networking and have made it available to the world. Let us know what you would like to do (or have done) with it.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :