Tag Archives: microcontroller

Post navigation

Cypress Semiconductor has announced that Pioneer has integrated Cypress’ Wi-Fi and Bluetooth Combo solution into its flagship in-dash navigation AV receiver. The solution enables passengers to display and use their smartphone’s apps on the receiver’s screen via Apple CarPlay or Android Auto, which provide the ability to use smartphone voice recognition to search for information or respond to text messages. The Cypress Wi-Fi and Bluetooth combo solution uses Real Simultaneous Dual Band (RSDB) technology so that Apple CarPlay and Android Auto can operate concurrently without degradation caused by switching back and forth between bands.The Pioneer AVH-W8400NEX receiver uses Cypress’ CYW89359 combo solution, which includes an advanced coexistence engine that enables optimal performance for dual-band 2.4-GHz and 5-GHz 802.11ac Wi-Fi and dual-mode Bluetooth/Bluetooth Low Energy (BLE) simultaneously for superior multimedia experiences. The CYW89359’s RSDB architecture enables two unique data streams to run at full throughput simultaneously by integrating two complete Wi-Fi subsystems into a single chip.

The CYW89359 is fully automotive qualified with AECQ-100 grade-3 validation and is being designed in by numerous top-tier car OEMs and automotive suppliers as a full in-vehicle connectivity solution, supporting infotainment and telematics applications such as smartphone screen-mirroring, content streaming and Bluetooth voice connectivity in car kits.

Segger has introduced emPack, a complete operating system for IoT devices and embedded systems. It is delivered in source code for all 8-/16-/32-bit microcontrollers and microprocessors. emPack is optimized for high performance, and small memory footprint and easily fits onto typical MCUs without requiring expensive external memory, keeping the cost of the embedded computing system to a minimum.emPack components are written in plain C and can be compiled by standard ANSI/ISO C compilers. The software package includes embOS, emWin, emFile, embOS/IP, emUSB- Device, emUSB-Host, emModbus, emCompress, emCrypt, emSecure, emSSL, emSSH, and SEGGER’s IoT Toolkit.

All emPack components work seamlessly together and are continuously tested on a variety of microcontrollers from different vendors. According to the company, it is very easy to get started with emPack. And it significantly reduces the time it requires to deliver a product using robust and well tested components that simply work.

Another benefit of using emPack as a platform is portability: Switching to a different microcontroller even with a different core requires minimal changes. Standardizing on emPack enables you to enhance your products when newer, more powerful processors are introduced, or can target a wider customer base with cost-optimized products using less expensive MCUs.

Because all components work together through well-defined interfaces, existing projects that already have a mandated RTOS can use emPack’s components by simply customizing a small number of OS adaptation functions. emPack has been fully tested with Amazon FreeRTOS and example configurations are available upon request.

Microchip Technology has introduced the MPLAB PICkit 4 In-Circuit Debugger. This low-cost PICkit 4 in-circuit programming and debugging development tool is meant to replace the popular PICkit 3 programmer by offering five times faster programming, a wider voltage range (1.2 V to 5 V), improved USB connectivity and more debugging interface options. In addition to supporting Microchip’s PIC microcontrollers (MCUs) and dsPIC Digital Signal Controllers (DSCs), the tool also supports debugging and programming for the CEC1702 family of hardware cryptography-enabled devices.

This low-cost programming and debugging solution is well suited for those designing in the 8-bit space, but it is also perfectly suited for 16- and 32-bit development due, in part, to its 300 MHz, high-performance ATSAME70Q21B microcontroller on board. The benefits of faster programming time are less waiting and better productivity during development. This is especially important when designing with 32-bit microcontrollers with larger memory capacities.

The PICkit 4 development tool enables debugging and programing using the graphical user interface of MPLAB X Integrated Development Environment (IDE). The tool connects to the design engineer’s computer using a Hi-Speed USB 2.0 interface and can be connected to the target via an 8-pin single inline header that supports advanced interfaces such as 4-wire JTAG and serial wire debug with streaming data gateway. It is also backward compatible for demo boards, headers and target systems using 2-wire JTAG and In-Circuit Serial Programming (ICSP) compatibility.

The new interfaces make this low-cost tool compatible with Microchip’s CEC1702 hardware cryptography-enabled devices. This low-power, but powerful, 32-bit MCU offers easy-to-use encryption, authentication and private and public key capabilities. CEC1702 users can now benefit from using Microchip’s development tools and support rather than being required to invest in third-party tools for programming and debugging. The MPLAB PICkit 4 (PG164140) development tool is available today for $47.95.

Can texting be leveraged for use in IoT Wi-Fi devices? Jeff has been using Wi-Fi widgets for a lot of IoT projects lately. This month Jeff lays the groundwork for describing a project that will involve texting. He starts off with a look at Espressif System’s ESP8266EX SoC.

By Jeff Bachiochi

Believe it or not, texting while driving as of this writing is still legal in a few states. About 10% of all motor vehicles deaths in the US can be traced back to distracted drivers. Granted that includes any distraction—however cell phone distraction has quickly become a serious issue. While hazards exist for any technology, common sense should tell you this is a dangerous act.

When the technology is used correctly, texting can deliver essential information quickly—without requiring both (or many) parties to be active at the same time. This allows you to make better use of your time. I still use email for much of my correspondence, however it’s great to be able to send your spouse a text to add milk to the grocery list—after they’ve already left for the store! And even though I chuckle when I see two people sitting next to each other texting, it is a sad commentary on emerging lifestyles.

I’ve been using Wi-Fi widgets for a lot of IoT projects lately. The cost to enter the fray is low, and with free tools it’s easy to get started. This month’s article is a about a project that will involve text, even though that may not be apparent at first. Let’s start off slowly, laying the groundwork for those who have been thinking about building this kind of project. We’ll then quickly build from this foundation into crafting a useful gadget.

A Look at the ESP8266EX

The innovative team of chip-design specialists, software/firmware developers and marketers at Espressif System developed and manufactures the ESP8266EX system-on-chip (SoC). This 32-bit processor runs at 80 MHz and embeds 2.4 GHz Wi-Fi functionality—802.11 b/g/n, supporting WPA/WPA2—as well as the normal gamut of general-purpose I/O and peripherals. It has a 64 KB boot ROM, 64 KB instruction RAM and 96 KB data RAM. Their WROOM module integrates the ESP8266 with a serial EEPROM and an RF front end with a PCB antenna for a complete IoT interface.

Anyone who has ever used a dial-up modem is most likely familiar with the term AT command set. The Hayes command set is a specific command language originally developed in 1981 by Dennis Hayes for the Hayes 300 baud Smartmodem. Each command in the set begins with the letters AT+ followed by a command word used for high-level control of internal functions. For the modem these enabled tasks like dialing the phone or sending data. As an application for the WROOM, an AT command set seemed like a perfect match. This allows an embedded designer to use the device to achieve a goal without ever having to “get their hands dirty.”

This photo shows the ESP-01 and ESP-07 modules along with the FTDI 232 USB-to-serial converter used for programming either module.

I first learned of the ESP8266 years ago and purchased the ESP-01 on eBay. It was around $5 at the time (Photo 1). I used it along with the MEGA 2560—my favorite Arduino module because of its high number of I/Os and multiple hardware UARTs. With the ESP-01 connected to a serial port on an Arduino, an application could directly talk with the ESP-01 and get the Arduino connected to your LAN. From this point, the world is under your control thanks to the AT Wi-Fi and TCP commands.

The ESP8266 literature states the Wi-Fi stack only requires about 20% of the processing power. Meanwhile, 80% is still available for user application programming and development.
So why not eliminate the Arduino’s Atmel processor altogether and put your Arduino code right in the 8266? Espressif Systems has an SDK and while it provides a development and programming environment, the Arduino IDE is comfortable for many. And it offers the installation of third-party platform packages using the Boards Manager. That means you can add support for the ESP8266EX and use much of the code you’ve already written.

Using the ESP-01

Since the ESP-01 has only 8 pins, adding the necessary hardware is pretty simple. This low power device runs on 2.5 V to 3.6 V, so you must make appropriate level corrections if you wish to use it with 5 V devices like Arduino boards. …

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Connecting to the IoT edge requires highly integrated technology, blending wireless connectivity and intelligence. Feeding those needs, a variety of IoT modules have emerged that offer pre-certified solutions that are ready to use.

By Jeff Child, Editor-in-Chief

he Internet of Things (IoT) is one of the most dynamic areas of embedded systems design today. Opportunities are huge as organizations large and small work to develop IoT implementations. IoT implementations are generally comprised of three main parts: the devices in the field, the cloud and the network (gateways) linking them together. This article focuses on the “things” side—in other words, the smart, connected edge devices of the IoT. For more on IoT gateways, see “IoT Gateway Advances Take Diverse Paths“ (Circuit Cellar 328, November 2017).

Because this sub-segment of technology is growing and changing so fast, it’s impossible to get a handle on everything that’s happening. The scope that comprises IoT edge devices includes a combination of embedded processors and microcontrollers that provide intelligence. It also includes various wireless, cellular and other connectivity solutions to connect to the network. And it includes sensors to collect data and battery technologies to keep the devices running.

Connecting the various nodes of an IoT implementation can involve a number of wired and wireless network technologies. But it’s rare that an IoT system can be completely hardwired end to end. Most IoT systems of any large scale depend on a variety of wireless technologies including Wi-Fi, Bluetooth, Zigbee and even cellular networking.

What’s most interesting among all that, are not those individual pieces themselves, but rather an emerging crop of modular IoT products that combine intelligence and connectivity, while also taking on the vital certifications needed to get IoT implementations up and running. With all that in mind, the last 12 months have seen an interesting mix of module-based products aimed directly at IoT.

Certified IoT Modules

Exemplifying those trends, in September 2017, STMicroelectronics (ST)introduced the SPBTLE-1S, a ready-to-use Bluetooth Low Energy (BLE) module that integrates all the components needed to complete the radio subsystem (Photo 1). The BLE module integrates ST’s proven BlueNRG-1 application-processor SoC and balun, high-frequency oscillators and a chip antenna.

Photo 1The SPBTLE-1S is a BLE module that integrates all the components needed to complete the radio subsystem. It’s BQE-approved, and FCC, IC and CE-RED certified to simplify end-product approval for North America and EU markets.

Developers can use this module to bypass hardware design and RF-circuit layout challenges. The SPBTLE-1S is BQE-approved, and FCC, IC and CE-RED (Radio Equipment Directive) certified to simplify end-product approval for North America and EU markets. ST’s Bluetooth 4.2 certified BLE protocol stack is included, and the supporting Software-Development Kit (SDK) contains a wide range of Bluetooth profiles and sample application code.

The device is packaged in a space-efficient 11.5 mm x 13.5 mm outline and has a wide supply-voltage range of 1.7 V to 3.6 V. The SPBTLE-1S module is well suited for small, battery-operated objects powered by various types of sources such as a primary button cell or rechargeable Li-ion battery. High RF output power of +5 dBm and good receiver sensitivity help to maximize communication range and reliability.

The BlueNRG-1 SoC at the heart of the SPBTLE-1S implements the complete BLE physical layer (PHY), link layer and network/application-processing engine comprising a low-power ARM Cortex-M0 core with 160 KB flash, 24 KB RAM with data retention and a security co-processor. The SoC also implements smart power management, with a DC/DC converter capable of powering the SPBTLE-1S module to ensure optimum energy efficiency. Users can leverage an extensive set of interfaces, including a UART, two I²C ports, SPI port, single-wire debug and 14 GPIOs, as well as peripherals including two multifunction timers, a 10-bit ADC, watchdog timer and real-time clock and a DMA controller. There is also a PDM stream processor interface, which is ideal for developing voice-controlled applications.

IoT Module for Development

Riding the IoT wave, all the major microcontroller vendors have beefed up their module-based IoT solutions in order to make it easier for developers to design in their MCUs. One example along those lines is the LPC54018 IoT module, developed by NXP in partnership with Embedded Artists. …

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Texas Instruments (TI) has introduced an op amp that combines ultra-high precision with low supply current. The LPV821 zero-drift, nanopower op amp enables engineers to attain the highest DC precision, while consuming 60% less power than competitive zero-drift devices, according to TI. The LPV821 is designed for use in precision applications such as wireless sensing nodes, home and factory automation equipment, and portable electronics.

The LPV821 is a single-channel, nanopower, zero-drift operational amplifier for “Always ON” sensing applications in wireless and wired equipment where low input offset is required. With the combination of low initial offset, low offset drift, and 8 kHz of bandwidth from 650 nA of quiescent current, the LPV821 is the industry’s lowest power zero-drift amplifier that can be used for end equipment that monitor current consumption, temperature, gas, or strain gauges.

The LPV821 zero-drift op amp uses a proprietary auto-calibration technique to simultaneously provide low offset voltage (10 μV, maximum) and minimal drift over time and temperature. In addition to having low offset and ultra-low quiescent current, the LPV821 amplifier has pico-amp bias currents which reduce errors commonly introduced in applications monitoring sensors with high output impedance and amplifier configurations with megaohm feedback resistors.

Engineers can pair the LPV821 op amp with the TLV3691 nanopower comparator or ADS7142 nanopower analog-to-digital converter (ADC) to program a threshold that will automatically wake up a microcontroller (MCU) such as the CC1310 SimpleLink Sub-1 GHz MCU, further reducing system power consumption.

Designers can download the TINA-TI SPICE model to simulate their designs and predict circuit behavior when using the LPV821 op amp. Engineers can also jump-start gas-sensing system designs using the LPV821 op amp with the Always-On Low-Power Gas Sensing with 10+ Year Coin Cell Battery Life Reference Design and Micropower Electrochemical Gas Sensor Amplifier Reference Design.

Pre-production samples of the LPV821 op amp are now available through the TI store and authorized distributors in a 5-pin small-outline transistor (SOT-23) package. Pricing starts at $0.80 in 1,000-unit quantities.

STMicroelectronics offers a new software tool, STM32CubeProgrammer, the provides device-programming and firmware upgrades for STM32 microcontrollers in a unified, multi-platform and user-configurable environment. Ready to run on Windows, Linux,or MacOS operating systems, the STM32CubeProgrammer can program the STM32 microcontroller’s on-chip Flash/RAM or external memories using various file formats. Further capabilities include whole-memory or sector erase and programming microcontroller option bytes. Users can also generate encrypted files for secure programming (Secure Firmware Install/Update) to authenticate production and protect intellectual property.

With this tool, users can program STM32 microcontrollers through the device’s SWD (Single-Wire Debug) or JTAG debugging ports, or the bootloader ports (such as UART and USB). Hence the STM32CubeProgrammer brings the individual capabilities of the ST Visual Programmer, DFUse Device Firmware Update tool, Flash Loader, and ST-Link utility together within the STM32Cube ecosystem. ST will extend the STM32CubeProgrammer’s capabilities by adding programming access via microcontroller I2C and CAN ports.

The STM32CubeProgrammer provides many opportunities to customize and configure features, using either the GUI or the command-line interface (CLI). Also, this all-in-one tool can be used in standalone mode or integrated and controlled from a custom application. Programming can be done manually or automated using scripts.

Roberto developed a glove that enables communication between the user and those
around him. While the design is intended for use by people communicating in American Sign Language, you can apply what you learn in this article to a variety of communications applications.
PHOTO 1-Here you see the finished product with all of the sensors sewn in. The use of string as opposed to adhesive for the sensors allowed the components to smoothly slide back and forth as the hand was articulated.

By Roberto Villalba

While studying at Cornell University in 2014, my lab partner Monica Lin and I designed and built a glove to be worn on the right hand that uses a machine learning (ML) algorithm to translate sign language into spoken English (see Photo 1). Our goal was to create a way for the speech impaired to be able to communicate with the general public more easily. Since every person’s hand is a unique size and shape, we aimed to create a device that could provide reliable translations regardless of those differences. Our device relies on a variety of sensors, such as flex sensors, a gyroscope, an accelerometer, and touch sensors to quantify the state of the user’s hand. These sensors allow us to capture the flex on each of the fingers, the hand’s orientation, rotation, and points of contact. By collecting a moderate amount of this data for each sign and feeding it into a ML algorithm, we are able to learn the association between sensor readings and their corresponding signs. We make use of a microcontroller to read, filter and send the data from the glove to a PC. Initially, some data is gathered from the users and the information is used to train a classifier that learns to differentiate between signs. Once the training is done, the user is able to put on the glove and make gestures which the computer then turns into audible output.

FIGURE 1-After performing some calculation and characterizing our flex sensors, we decided to use a 10-kΩ resistor. Note that the rightmost point goes into one of the microcontroller’s ADC.

HIGH-LEVEL DESIGNWe use the microcontroller’s analog-to digital converter (ADC) to read the voltage drop across each of the flex sensors. We then move on to reading the linear acceleration and rotation values from the accelerometer and gyro sensor using I 2C. And finally, we get binary readings from each of the touch sensors regarding if there exists contact or not. We perform as many readings as possible within a given window of time and use all of this data to do some smoothing. This information is then sent through serial to the PC where it is gathered and processed. Python must listen to information coming in from the microprocessor and either store data or predict based on already learned information. Our code includes scripts for gathering data, loading stored data, classifying the data that is being streamed live, and some additional scripts to help with visualization of sensor readings and so on.

MCU & SENSORSThe design comprises an Atmel ATmega1284P microcontroller and a glove onto which the various sensors and necessary wires were sewn. Each finger has one Spectra Symbol flex sensor stitched on the backside of the glove. The accelerometer and gyro sensors are attached to the center of the back of the glove. The two contact sensors were made out of copper tape and wire that was affixed to four key locations.

Since each flex sensor has a resistance that varies depending on how much the finger is bent, we attached each flex sensor as part of a voltage divider circuit in order to obtain a corresponding voltage that can then be input into the microcontroller.

We determined a good value for R1 by analyzing expected values from the flex sensor. Each one has a flat resistance of 10 k and a maximum expected resistance (obtained by measuring its resistance on a clenched fist) of about 27 k. In order to obtain the maximum range of possible output voltages from the divider circuit given an input voltage of 5 V, we plotted the expected ranges using the above equation and values of R1 in the range of 10 to 22 k. We found that the differences between the ranges were negligible and opted to use 10 k for R1 (see Figure 1).

Our resulting voltage divider has an output range of about 1 V. We were initially concerned that the resulting values from the microcontroller’s ADC converter would be too close together for the learning algorithm to discern between different values sufficiently. We planned to address this by increasing the input voltage to the voltage divider if necessary, but we found that the range of voltages described earlier was sufficient and performed extremely well.

The InvenSense MPU-6050 accelerometer and gyro sensor packet operates on a lower VCC (3.3 V) compared to the microcontroller’s 5 V. So as not to burn out the chip, we created a voltage regulator using an NPN transistor and a trimpot, connected as shown. The trimpot was adjusted so that the output of the regulator reads 3.3 V. This voltage also serves as the source for the pull-up resistors on the SDA and SCL wires to the microcontroller. Since the I 2C devices are capable only of driving the input voltages low, we connect them to VCC via two 4.7-k pull-up resistors (see Figure 2).

As described later, we found that we needed to add contact sensors to several key spots on the glove (see Figure 3). These would essentially function as switches that would pull the microcontroller input pins to ground to signal contact (be sure to set up the microcontroller pins to use the internal pull up resistors).

Figure 2: Here we see the schematic of the voltage regulator circuit that we created in order to obtain 3.3 V. The bottom of the schematic shows how this same regulator was used to pull up the signals at SCL and SDA.

Figure 3: The contact sensor circuitry was quite simple. The input pins of the microcontroller are set to the internal pull-up resistors and whenever the two corresponding copper ends on the fingers touch the input is pulled low.

I2C COMMUNICATIONS
Interfacing with the MPU-6050 required I 2C communication, for which we chose to use Peter Fleury’s public I 2C library for AVR microcontrollers. I 2C is designed to support multiple devices using a single dedicated data (SDA) bus and a single clock (SCL) bus. Even though we were only using the interface for the microcontroller to regularly poll the MPU6050, we had to adhere to the I 2C protocol. Fleury’s library provided us with macros for issuing start and stop conditions from the microcontroller (which represent different signals that the microcontroller is requesting data from the MPU-6050 or is releasing control of the bus). These provided macros allowed for us to easily initialize the I 2C interface, set up the MPU-6050, and request and receive the accelerometer and gyroscope data (described later).

Figure 4: The image is the visual output received from plotting sequences of sensor readings. The clear divisions across the horizontal signal the different signs A, B, C, and D, respectively.

While testing our I2C communication with the MPU-6050, we found that the microcontroller would on rare occasions hang while waiting for data from the I2C bus. To prevent this from stalling our program, we enabled a watchdog timer that would reset the system every 0.5 seconds, unless our program continued to progress to regular checkpoint intervals, at which time we would reset the watchdog timer to prevent it from unnecessarily resetting the system. We were able to leverage the fact that our microcontroller’s work consists primarily of continuously collecting sensor data and sending packets to a separate PC.

Photo 2: In this image we see the hand gestures for R, U, and V. As you can tell, there is not much difference in the hand’s orientation or the amount of flex on the fingers. However, note that the copper pieces make different kinds of contact for each of the signs.

TINYREALTIMEFor the majority of the code, we used Dan Henriksson and Anton Cervin’s TinyRealTime kernel. The primary reason for using this kernel is that we wanted to take advantage of the already implemented non-blocking UART library in order to communicate with the PC. While we only had a single thread running, we tried to squeeze in as much computation as possible while the data was being transmitted.

The program first initializes the I 2C, the MPU, and the ADC. After it enters an infinite loop it resets the watchdog timer and gets 16 readings from all of the sensors: accelerometers, gyroscopes, flex-sensors, and touch sensors. We then take all of the sensor values and compute filtered values by summing all of the 16 readings from each sensor. Since summation of the IMU sensors can produce overflow, we make sure to shift all of their values by 8 before summing them up. The data is then wrapped up into byte array packet that is organized in the form of a header (0xA1B2C3D4), the data, and a checksum of the data. Each of the sensors is stored into 2 bytes and the checksum is calculated by summing up the unsigned representation of each of the bytes in the data portion of the packet into a 2-byte integer. Once the packet has been created it is sent through the USB cable into the computer and the process repeats.

PYTHON COMMUNICATIONCommunication with the microcontroller was established through the use of Python’s socket and struct libraries. We created a class called SerialWrapper whose main goal is to receive data from the microcontroller. It does so by opening a port and running a separate thread that waits on new data to be available. The data is then scanned for the header and a packet of the right length is removed when available. The checksum is then calculated and verified, and, if valid, the data is unpacked into the appropriate values and fed into a queue for other processes to extract. Since we know the format of the packet, we can use the struct library to extract all of the data from the packet, which is in a byte array format. We then provide the user with two modes of use. One that continuously captures and labels data in order to make a dataset, and another that continuously tries to classify incoming data. Support Vector Machines (SVM) are a widely used set of ML algorithms that learn to classify by using a kernel. While the kernel can take various forms, the most common kind are the linear SVMs. Simply put, the classification, or sign, for a set of readings is decided by taking the dot product of the readings and the classifier. While this may seem like a simple approach, the results are quite impressive. For more information about SVMs, take a look at scikit-learn’s “Support Vector Machines” (http://scikit-learn.org/stable/modules/svm.html).

PYTHON MACHINE LEARNINGFor the purposes of this project we chose to focus primarily on the alphabet, a-z, and we added two more labels, “nothing” and “relaxed”, to the set. Our rationale for providing the classifier “nothing” was in order to have a class that was made up of mostly noise. This class would not only provide negative instances to help learn our other classes, but it also gave the classifier a way of outputting that the gestured sign is not recognized as one of the ones that we care about. In addition, we didn’t want the classifier to be trying to predict any of the letters when the user was simply standing by, thus we taught it what a “relaxed” state was. This state was simply the position that the user put his/her hand when they were not signing anything. In total there were 28 signs or labels. For our project we made extensive use of Python’s scikit-learn library. Since we were using various kinds of sensors with drastically different ranges of values, it was important to scale all of our data so that the SVM would have an easier time classifying. To do so we made use of the preprocessing tools available from scikit-learn. We chose to take all of our data and scale it so that the mean for each sensor was centered at zero and the readings had unit variance. This approach brought about drastic improvements in our performance and is strongly recommended. The classifier that we ended up using was a SVM that is provided by scikit-learn under the name of SVC.

Figure 5: The confusion matrix demonstrates how many times each label is predicted and how many times that prediction is accurate. We would like to see a perfect diagonal line, but we see that one square does not adhere to this. This square corresponds to “predicted V when it was really U” and it shows about a 66% accuracy.

Another part that was crucial to us as developers was the use of plotting in order to visualize the data and qualify how well a learning algorithm should be able to predict the various signs. The main tool that was developed for this was the plotting of a sequence of sensor readings as an image (see Figure 4). Since each packet contained a value for each of the sensors (13 in total), we could concatenate multiple packets to create a matrix. Each row is thus one of the sensor and we look at a row from left to right we get progressively later sensor readings. In addition, every packet makes up a column. This matrix could then be plotted with instances of the same sign grouped together and the differences between these and the others could then be observed. If the difference is clear to us, then the learning algorithm should have no issue telling them apart. If this is not the case, then it is possible that the algorithm could struggle more and changes to the approach could have been necessary.

The final step to classification is to pass the output of the classifier through a final level of filtering and debouncing before the output reaches the user. To accomplish this, we fill up a buffer with the last 10 predictions and only consider something a valid prediction if it has been predicted for at least nine out of the last 10 predictions. Furthermore, we debounce this output and only notify the user if this is a novel prediction and not just a continuation of the previous. We print this result on the screen and also make use of Peter Parente’s pyttsx text-to-speech x-platform to output the result as audio in the case that it is neither “nothing” or “relaxed.”

RESULTSOur original glove did not have contact sensors on the index and middle fingers. As a result, it had a hard time predicting “R,” “U,” and “V” properly. These signs are actually quite similar to each other in terms of hand orientation and flex. To mitigate this, we added two contact sensors: one set on the tips of the index and middle fingers to detect “R,” and another pair in between the index and middle fingers to discern between “U” and “V.”

As you might have guessed, the speed of our approach is limited by the rate of communication between the microcontroller and the computer and by the rate at which we are able to poll the ADC on the microprocessor. We determined how quickly we could send data to the PC by sending data serially and increasing the send rate until we noticed a difference between the rate at which data was being received and the rate at which data was being sent. We then reduced the send frequency back to a reasonable value and converted this into a loop interval (about 3 ms).

We then aimed to gather as much data as possible from the sensors in between packet transmission. To accomplish this, we had the microcontroller gather as much data as possible between packets. And in addition to sending a packet, the microcontroller also sent the number of readings that it had performed. We then used this number to come up with a reasonable number of values to poll before aggregating the data and sending it to the PC. We concluded that the microcontroller was capable of reading and averaging each of the sensors 16 times each, which for our purposes would provide enough room to do some averaging.

The Python algorithm is currently limited by the rate at which the microcontroller sends data to the PC and the time that it takes the speech engine to say the word or letter. The rate of transfer is currently about thirty hertz and we wait to fill a buffer with about ten unanimous predictions. This means that the fastest that we could output a prediction would be about three times per second which for our needs was suitable. Of course, one can mess around with the values in order to get faster but slightly less accurate predictions. However, we felt that the glove was responsive enough at three predictions per second.

While we were able to get very accurate predictions, we did see some slight variations in accuracy depending on the size of the person’s hands. The accuracy of each flexsensor is limited beyond a certain point. Smaller hands will result in a larger degree of bend. As a result, the difference between slightly different signs with a lot of flex tends to be smaller for users with more petite hands. For example, consider the signs for “M” and “S.” The only difference between these signs is that “S” will elicit slightly more flex in the fingers. However, for smaller hands, the change in the resistance from the flex-sensor is small, and the algorithm may be unable to discern the difference between these signs.

Figure 6: We can see that even with very small amounts of data the classifier does quite well. After gathering just over 60 readings per sign it achieves an accuracy of over 98%.

In the end, our current classifier was able to achieve an accuracy of 98% (the error being composed almost solely of u, v sign confusion) on a task of 28 signs, the full alphabet as well as “relaxed” and “nothing” (see Figure 5). A random classifier would guess correctly 4% of the time, clearly indicating that our device is quite accurate. It is however worth noting that the algorithm could greatly benefit from improved touch sensors (seeing as the most common mistake is confusing U for V), being trained on a larger population of users, and especially on larger datasets. With a broad enough data set we could provide the new users with a small test script that only covers difficult letters to predict and relies on the already available data for the rest. The software has currently been trained on the two team members and it has been tested on some users outside of the team. The results were excellent for the team members that trained the glove and mostly satisfying though not perfect for the other volunteers. Since the volunteers did not have a chance to train the glove and were not very familiar with the signs, it is hard to say if their accuracy was a result of overfitting, individual variations in signing, or inexperience with American Sign Language. Regardless, the accuracy of the software on users who trained was near perfect and mostly accurate for users that did not know American Sign Language prior to and did not train the glove.

Lastly it is worth noting that the amount of data necessary for training the classifier was actually surprisingly small. With about 60 instances per label the classifier was able to reach the 98% mark. Given that we receive 30 samples per second and that there are 28 signs, this would mean that gathering data for training could be done in under a minute (see Figure 6).

FUTURE UPGRADESThe project met our expectations. Our initial goal was to create a system capable of recognizing and classifying gestures. We were able to do so with more than 98% average accuracy across all 28 classes. While we did not have a solid time requirement for the rate of prediction, the resulting speed made using the glove comfortable and it did not feel sluggish. Looking ahead, it would make sense to improve our approach for the touch sensors since the majority of the ambiguity in signs come from the difference between U and V. We want to use materials that lend themselves more seamlessly to clothing and provide a more reliable connection. In addition, it will be beneficial to test and train our project on a large group of people since this would provide us with richer data and more consistency. Lastly, we hope to make the glove wireless, which would allow it to easily communicate with phones and other devices and make the system truly portable.

In this follow on to Part 1 of his story, Bill describes putting to use the amp-hour logger that he built using a microcontroller and a clamp-on ammeter. This time he discusses modifying the amp-hour software so it can be used as an analog input logger to measure solar and wind power. A small solar cell and a homemade windmill are used..

By William Wachsmann

FIGURE 1 Amp-hour log for the Office Circuit over 24 hours. It adds up to 14.728 A-hours and 1.767 kW-hours at 120 V.

In November and December 2016, I monitored all the circuits in my house. Some of the results were eye opening. We have a shed/workshop that is spray-foam insulated, where—among other things—we store paint cans. It’s heated by a 240-V baseboard heater and in the winter, we keep the temperature at around 10°C or about 50°F. The amp-hour logger showed that the heater was coming on about 3 times each hour and stayed on for 7 to 9 minutes each time. When it was on, it drew almost 7 A. The spreadsheet (file: SteelShed.xls) with the chart for these readings is included with the code—see Circuit Cellar article materials webpage for links.

Over a 24-hour period this amounted to an energy use of 12.5 kW-hours. At the rate we pay for electricity, it was costing around $3 per day or $90 dollars per month. Needless to say, we got rid of the old paint and turned the heater off. Now I only heat it if I need to work out there and it would otherwise be too cold. Figure 1 shows a chart of amp-hour usage in our office where my wife and I normally have three computers and two monitors running. Over a 24-hour period we use 1.767 kW-hours costing us about $0.50 per day. That’s not too bad but it’s actually more than the refrigerator at 1.357 kW-hours.

Table 1 (available in full article) shows the results from all the circuits in our house over a 24-hour period. (Not all on the same day!) I have since turned off the ‘Steel Shed Heater’ thus removing its 12.5297 kW-hours. The daily total is 31.39 kW-hours and monthly is 941.59 kW-hours. As a sanity check, that is quite close to our annual monthly average about 950 kW-hours. I have previously looked into going completely off grid, but it turns out to be too costly—mainly because the payback period would be 12 years or more. This also applies to “feed-in tariff” programs where solar or wind generated power is sent to the grid. The amount paid for this power is subsidized, and is higher than what we pay. But it requires an investment of $30,000 or more—for solar anyway—and wouldn’t be profitable for 8 to 10 years.

There is one exception to getting off grid cheaply. We have natural gas, which at current prices could be used to produce electricity at half the price we pay for power from the grid. The first problem here is that the type of small generators I would need are sold as backup systems and are just that. In other words, they are not designed to run continuously. If I tried to do that, I would void the warranty and the generator wouldn’t last anyway. There are larger ones designed to run continuously and are made to supply power in remote areas. They will run on either propane or natural gas, but are much larger than I need and much more expensive. Second, they are noisy and neither us nor our neighbors would be too happy. …

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Microchip Technology has made available its MEC17XX and MEC14XX families of embedded controllers with enhanced Serial Peripheral Interface (eSPI). The eSPI bus is the host interface supported by the latest PC computing chip sets and is required for new, upcoming computing applications. The MEC17XX family is based on an ARM Cortex-M4F core and has advanced hardware-accelerated cryptography algorithms to efficiently support the secure boot of a computer. The family offers several additional features including two UARTS and an extended industrial operating temperature range that make the family ideal for industrial computing. In addition, Microchip’s popular MIPS-based MEC14XX family has been expanded to include functionality for supporting the new eSPI Slave Attached Flash (SAF) feature, which allows the Microchip embedded controller to be directly connected to an SPI Flash memory using an on-board master controller.

These new embedded controllers are part of an expanded family of devices that have been an integral part in the computing industry’s transition from LPC to eSPI. The MEC17XX adds security through cryptography functionality to advance secure boot, a security feature developed to ensure a system boots only from software that is trusted by the manufacturer. Furthermore, the addition of two UARTS and support for industrial temperature is necessary for industrial computing applications.

The latest members of the MEC14XX family add a new level of design functionality for computing engineers by adding SAF, which is an optimal solution for USB Type-C power delivery. The latest MEC1428 devices are pin and register compatible with the MEC140X and MEC141X families, which allows designers to easily add eSPI and additional features and have more flexibility in their designs. Both families retain eSPI Master Attached Flash (MAF) capability. All of Microchip’s computing embedded controllers are supported by a variety of development and debug tools and evaluation boards, plus datasheets and other documentation.

The eSPI interface has numerous benefits including allowing for multiple input/output signals to be configured to support either 3.3 V or 1.8 V, which reduces the system cost by eliminating the need for external voltage translators. These features allow for seamless migration of intellectual property (IP) across multiple x86 computing platforms including those based on Intel’s Atom processors, Intel’s iCore processors and Ryzen processors from AMD.

The four-part MEC17XX family is available in a variety of WFBGA package options, starting at $2.59 each in 10,000 unit quantities. The family features industrial-qualified parts as well as the option of additional EEPROM memory. The MEC1428 is available today in a variety of package options, starting at $2.16 each in 10,000 unit quantities.

Setting out to monitor and log electricity usage in his house, Bill built an amp-hour
logger using a microcontroller and a clamp-on ammeter. He gets into the software
development details exploring solutions like mbed and Microsoft Visual Studio.

By William Wachsmann

Like many people I found that electricity costs have been increasing rapidly over the past few years. Where I live, we have smart meters that allow the power company to charge different rates for high usage, moderate usage and low usage times of the day. The bills show how much energy is used during the different periods but only for the dwelling as a whole.

For this project, I used an NXP-Freescale FRDM-KL25Z microcontroller board.

I wanted to know which parts of my house use how much electricity and at what times of the day. With this information, I would be able to see what parts of the house are using how much energy, and I’d even be able to calculate how much it’s costing to run certain appliances. I could then look into the feasibility of supplementing my energy supply with solar or wind, or maybe use a battery storage system that is charged in the less expensive hours for use during peak periods. Or perhaps even some combination of all three.

THE BASICS

To measure AC current, you normally use a “Clamp on Ammeter” on either the live or neutral wire in the circuit of interest. These ammeters are readily available but they will only tell you the current at the particular point in time that you are using it. What I needed was one that I could leave connected over a 24-hour period and get a log of the current usage throughout the day and night. If such a device exists, I was unable to find one, so I needed to make my own.

The device would have to monitor currents in 120 V and 240 V AC circuits and be reasonably accurate over a range of 200 mA to 30 A. The price we pay for electricity is based on kilowatt-hours (kW-h) multiplied by the rate— usually specified in cents-per-kWh. In my case, in the fall of 2016 we were paying an average of about $ 0.27 / kWh after all extra charges such as delivery and taxes were included.

Using the data from the amp-hour logger would allow calculation of the number of kWh used in each circuit of my house. Since kWh is a measure of energy I also needed to know what the voltage is at the time that the current is being measured. Then, given that P = VI, I would get a measure of the power being used at a given time. Integrating this over a period of time gives me the energy in watt-hours or—dividing by 1,000—in kWh.

To be really accurate, I should measure the voltage as well as the current but I have found that whenever I check the voltage it is pretty constant at 120 V (+ or – a couple of volts). Therefore, using a nominal value of 120 V (or 240 V for some circuits) should be accurate enough for my purposes. If the amp-hour logger is designed to save current measurements for each minute, that should give a pretty good indication of load changes in the circuit that is being monitored. Also, just adding up the amp-hour/minute readings effectively integrates them and provides the total amp-hours used over a 24-hour period. Multiply this by the voltage and divide by 1,000 and I’ll get the number of kWh used in a day. Great. That’s the theory. Now to make something that will work.

Read the full article in the October 327 issue of Circuit Cellar

We’ve made the October 2017 issue of Circuit Cellar available as a sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

NXP Semiconductors has announced a $22 million dollar program that expands its operations in the United States, enabling the Company’s US facilities to manufacture security chips for government applications that can support critical US national and homeland security programs. Upon completion of the expansion project, NXP facilities in Austin, TX and Chandler, AZ will be certified to manufacture finished products that exceed the highest domestic and international security and quality standards.

NXP R&D manufacturing facilities in San Jose, Austin and Chandler have also undergone a thorough security site certification process to produce Common Criteria EAL6+ SmartMX microcontroller family products. Common Criteria is an international set of guidelines and specifications developed for evaluating information security products to ensure they meet a rigorous security standard for government deployments.

NXP’s SmartMX microcontroller platform is designed for highly secure and fast data transactions. It is ,a proven solution for contact, contactless and dual interface applications. with over six billion ICs deployed in the field. It secures transactions for over one-third of chip-based payment cards in circulation, serving banks all over the world.

More SmartMX info:

It serves as the core component in a variety of digital identity schemes and is deployed in nearly 120 out of 145 countries implementing e-Government programs.

Used in many sovereign electronic documents such as ePassports, citizen cards, national ID cards, driving licenses, social security cards and health cards.

SmartMX is the 6th generation in the market, with NXP holding the most security certificates in the industry.

It is the preferred technology for the secure element of NFC-enabled phones.

STMicroelectronics’s ultra-low-power STM32L45x microcontrollers (the STM32L451, the STM32L452, and the STM32L462 lines) are supported by a development ecosystem based on the STM32Cube platform. The new microcontroller lines offer a variety of features and benefits:

A 36-µA/MHz Active mode current enables a longer runtime on small batteries

The development ecosystem includes the STM32CubeMX initialization-code generator and STM32CubeL4 package comprising:

Middleware components

Nucleo-64 Board-Support Package (BSP)

Hardware Abstraction Layer (HAL)

Low-Layer APIs (LLAPIs)

The STM32CubeMX has a power-estimation wizard, as well as other wizards for managing clock signals and pin assignments. The affordable Nucleo-64 board, NUCLEO-L452RE, enables you to test ideas and build prototypes. It integrates the ST-LINK/V2 probe-free debugger/programmer and you can expand it via Arduino-compatible headers.
The devices are currently available in small form-factor packages from QFN-48 to LQFP-100, including a 3.36 mm × 3.66 mm WLCSP. Prices start from $2.77 in 1,000-piece quantities for the STM32L451CCU6 with 256-KB flash memory and 160-KB SRAM in QFN-48. The development boards start at $14 for the legacy-compatible Nucleo-64 board (NUCLEO-L452RE). The NUCLEO-L452RE-P board with external DC/DC converter will be available to distributors in June 2017.

STMicroelectronics’s ultra-low-power STM32L45x microcontrollers (STM32L451, STM32L452, and STM32L462 lines) are supported by a development ecosystem based on the STM32Cube platform. The new microcontroller lines offer a variety of features and benefits:

A 36-µA/MHz Active mode current enables a longer runtime on small batteries

The development ecosystem includes the STM32CubeMX initialization-code generator and STM32CubeL4 package comprising:

Middleware components

Nucleo-64 Board-Support Package (BSP)

Hardware Abstraction Layer (HAL),

Low-Layer APIs (LLAPIs)

The STM32CubeMX has a power-estimation wizard, as well as other wizards for managing clock signals and pin assignments. The affordable Nucleo-64 board, NUCLEO-L452RE, enables you to test ideas and build prototypes. It integrates the ST-LINK/V2 probe-free debugger/programmer and you can expand it via Arduino-compatible headers.

The devices are currently available in small form-factor packages from QFN-48 to LQFP-100, including a 3.36 mm × 3.66 mm WLCSP. Prices start from $2.77 in 1,000-piece quantities for the STM32L451CCU6 with 256-KB flash memory and 160-KB SRAM in QFN-48. The development boards start at $14 for the legacy-compatible Nucleo-64 board (NUCLEO-L452RE). The NUCLEO-L452RE-P board with external DC/DC converter will be available to distributors in June 2017.

Microchip Technology recently launched a new generation of 8-bit tinyAVR microcontrollers. The four new devices range from 14 to 24 pins and 4 KB to 8 KB of flash memory. Furthermore, they are the first tinyAVR microcontrollers to feature Core Independent Peripherals (CIPs). The new devices will be supported by Atmel START, an innovative online tool for intuitive, graphical configuration of embedded software projects.

The new ATtiny817/816/814/417 devices provide features to help drive product innovation including small, low pin count and feature-rich packaging in 4 or 8 KB of flash memory. Other integrated features include:

A CIP called Peripheral Touch Controller (PTC)

Event System for peripheral co-operation

Custom programmable logic blocks

Self-programming for firmware upgrades

Nonvolatile data storage

20-MHz internal oscillator

High-speed serial communication with USART

Operating voltages ranging from 1.8 to 5.5 V

10-bit ADC with internal voltage references

Sleep currents at less than 100 nA in power down mode with SRAM retention

CIPs allow the peripherals to operate independently of the core, including serial communication and analog peripherals. Together with the Event System, that allows peripherals to communicate without using the CPU and applications can be optimized at a system level. This lowers power consumption and increases throughput and system reliability.

Accompanying the release of the four new devices, Microchip is adding support for the new AVR family in Atmel START, the online tool to configure software components and tailor embedded applications. This tool is free of charge and offers an optimized framework that allows the user to focus on adding differentiating features to their application.

To help accelerate evaluation and development, a new Xplained Mini Kit is now available for $8.88 USD. The Xplained Mini Kit is also compatible with the Arduino kit ecosystem. The kit can be used for standalone development and is fully supported by the Atmel START and Atmel Studio 7 software development tools.

The new generation of 8-bit tinyAVR MCUs is now available in QFN and SOIC packaging. Devices are available in 4 KB and 8 KB Flash variants, with volume pricing starting at $0.43 for 10,000-unit quantities.