Talking Hands: American Sign Language Gesture Recognition Glove

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

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.

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 DESIGN
We 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 & SENSORS
The 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.

Capture3

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.

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.

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.

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.

TINYREALTIME
For 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 COMMUNICATION
Communication 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 LEARNING
For 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.

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

RESULTS
Our 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%.

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 UPGRADES
The 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.

RESOURCES
Arduino, “MPU-6050 Accelerometer + Gyro,” http://playground.arduino.cc/ Main/MPU-6050.

Atmel Corp., “8-Bit AVR Microcontroller with 128K Bytes In-System Programmable Flash: ATmega1284P,” 8059D­AVR­ 11/09, 2009,
www.atmel. com/images/doc8059.pdf.

Fleury, “AVR-Software,” 2006,
http://homepage. hispeed.ch/peterfleury/avrsoftware.html.

Lund University, “Tiny Real Time,” 2006, www.control.lth. se/~anton/tinyrealtime/.

Parente, “pyttsx – Text-tospeech x-platform,” pyttsx “struct–Interpret Strings as Packed Binary Data,” https://docs.python.org/2/ library/struct.html.

scikit-learn, “Preprocessing Data,”
http:// scikit-learn.org/stable/modules/preprocessing. html.

“Support Vector Machines,” scikit-learn.org/stable/modules/svm.html.

Spectra Symbol, “Flex Sensor FS,” 2015,
www.spectrasymbol.com/wp-content/themes/spectra/images/datasheets/FlexSensor.pdf.

Villalba and M. Lin, “Sign Language Glove,” ECE4760, Cornell University, 2014,
http:// people.ece.cornell.edu/land/courses/ece4760/FinalProjects/f2014/rdv28_mjl256/webpage/.

SOURCES
ATmega1284P Microcontroller Atmel | www.atmel.com

MPU-6050 MEMS MotionTracking Device InvenSense | www.invensense.com

Article originally published in Circuit Cellar June 2016, Issue #311

Logger Device Tracks Amp Hours (Part 2)

Lead ImageWachsmann

Alternative Energy Sources

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

2017-11-012-Wachsmann-Fig1

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

Read the full article in the November 328 issue of Circuit Cellar

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!
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.

Two Controller Families Add eSPI Bus

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 37288858386_29fa55a67f_kdirectly 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.

Microchip Technology | www.microchip.com

Logger Device Tracks Amp Hours (Part 1)

Measuring Home Electricity

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.

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.
Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

NXP to Make Security Chips in its US Facilities

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_logo_RGB_web

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.

 

NXP Semiconductors | www.nxp.com

New STM32L4 MCUs with On-Chip Digital Filter

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:

  • Integrated Digital Filter for Sigma-Delta Modulators (DFSDM) enables advanced audio capabilities (e.g., noise cancellation or sound localization).
  • Up to 512 Kbyte on-chip Flash and 160 Kbyte SRAM provide generous code and data storage.
  • A True Random-Number Generator (TRNG) streamlines development of security-conscious applications
  • Smart analog peripherals include a 12-bit 5-Msps ADC, internal voltage reference, and ultra-low-power comparators.
  • Multiple timers, a motor-control channel, a temperature sensor, and a capacitive-sensing interface
  • Deliver high core performance and exceptional ultra-low-power efficiency
  • 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)

STMicro-STM32L4

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 | www.st.com

New STM32L4 Microcontrollers with On-Chip Digital Filter

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:

  • Integrated Digital Filter for Sigma-Delta Modulators (DFSDM) enables advanced audio capabilities (e.g., noise cancellation or sound localization).
  • Up to 512 Kbyte on-chip Flash and 160 Kbyte SRAM provide generous code and data storage.
  • A True Random-Number Generator (TRNG) streamlines development of security-conscious applications
  • Smart analog peripherals include a 12-bit 5-Msps ADC, internal voltage reference, and ultra-low-power comparators.
  • Multiple timers, a motor-control channel, a temperature sensor, and a capacitive-sensing interface
  • Deliver high core performance and exceptional ultra-low-power efficiency.
  • A 36-µA/MHz Active mode current enables a longer runtime on small batteries STMicro STM32L4

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.

Source: STMicroelectronics

Next-Generation 8-bit tinyAVR Microcontrollers

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.Microchip 8bittinyAVR

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.

Source: Microchip Technology

Flowcode 7 (Part 2): Displays in Flowcode (Sponsor: Matrix)

In the first part of this series, you were introduced to Flowcode 7, a flowchart-driven electronic IDE that enables you to produce hex code for more than 1,300 different microcontrollers, including PIC8, PIC16, PIC32, AVR, Arduino, and ARM. In the second free article in this series, embedded engineer Ben Rowland gets you working with displays in Flowcode. He covers: communicating with displays, code and display porting, a bitmap drawer component, and more.

A maze generation algorithm being tested using a graphical LCD and the Flowcode simulation.

A maze generation algorithm being tested using a graphical LCD and the Flowcode simulation.

Want a Free Trial and/or Buy Flowcode 7? Download Now

Flowcode is an IDE for electronic and electromechanical system development. Pro engineers, electronics enthusiasts, and academics can use Flowcode to develop systems for control and measurement based on microcontrollers or on rugged industrial interfaces using Windows-compatible personal computers. Visit www.flowcode.co.uk/circuitcellar to learn about Flowcode 7. You can access a free version, or you can purchase advanced features and professional Flowcode licenses through the modular licensing system. If you make a purchase through that page, Circuit Cellar will receive a commission.

Click to download the article

Flowcode 7 (Part 1): Simplifying Microcontroller Programming (Sponsor: Matrix)

These days the most commonly used device in electronic systems is the microcontroller: it is hard to find a piece of electronics without one, and you use thousands of them a day. In this free article, John Dobson, managing director at Matrix TSL, introduces Flowcode 7 and explains how you can use it for your next microcontroller-based design.

Want a Free Trial and/or Buy Flowcode 7? Download Now

Flowcode is an IDE for electronic and electromechanical system development. Pro engineers, electronics enthusiasts, and academics can use Flowcode to develop systems for control and measurement based on microcontrollers or on rugged industrial interfaces using Windows-compatible personal computers. Visit www.flowcode.co.uk/circuitcellar to learn about Flowcode 7. You can access a free version, or you can purchase advanced features and professional Flowcode licenses through the modular licensing system. If you make a purchase through that page, Circuit Cellar will receive a commission.

Click to download the article

Click to download the article

Renesas Electronics Europe and SEGGER Accelerate RX Ecosystem Expansion

Renesas Electronics Europe and SEGGER recently announced their collaboration to facilitate the expansion of Renesas’s RX Family of 32-bit microcontroller ecosystem through the adoption of SEGGER’s newly-released SystemView software. SystemView supports streaming over J-Link, as well as real-time analysis and visualization, in relation to any Renesas RX-based embedded design.Segger RS

SystemView gives you insight into the behavior of a program. It offers cycle accurate tracing of interrupts and task start/stop in addition to task activation and API calls when an RTOS is used. It visualizes and analyzes CPU load by task, interrupts, and software timers. Using SEGGER’s J-Link debug probe with SystemView enables real-time analysis, which gives you an in-depth understanding of the application’s run-time behavior.

SystemView uses SEGGER’s Real-Time Transfer (RTT) technology to ensure real-time delivery of data and minimal intrusiveness on the system. RTT enables up to 2 MB per second data transfer for continuous acquisition of real-time data, requiring no hardware other than a J-Link and the standard debug interface. SystemView records the data retrieved from the target and visualizes the results in different ways. You can save data recordings for later documentation and analysis.

SystemView works seamlessly with SEGGER’s RTOS embOS, which includes all the necessary recording capabilities. SystemView doesn’t require any OS involvement.

Source: SEGGER

Cryptography-Enabled 32-bit Microcontroller for IoT Designs

Microchip Technology’s CEC1302 hardware crypto-enabled 32-bit microcontroller enables you to easily add security to Internet of Things (IoT) devices. Enabling pre-boot authentication of system firmware, the microcontroller prevents a variety of security attacks (e.g., man-in-the-middle, denial-of-service, and backdoor). You can also use it to authenticate firmware updates.Microchip CEC1302

The CEC1302’s features, benefits, and specs:

  • Private key and customer programming flexibility
  • Power drain savings and improved execution of application performance
  • 32-bit microcontroller with an ARM Cortex-M4 core
  • The hardware-enabled public key engine of the device is 20 to 50 times faster than firmware-enabled algorithms

In order to quickly develop applications with the CEC1302, use MikroElektronika’s CEC1302 Clicker (MIKROE-1970) and CEC1302 Clicker 2 (MIKROE-1969). You can use the boards with MikroElektronika’s complete development toolchain for Microchip CEC1302 ARM Cortex-M4 MCUs.

The CEC1302 (CEC1302D-SZ-C0) is available today for sampling and volume production in a 144-WFBGA package starting at $1.75 each in 10,000-unit quantities.

Source: Microchip Technology

Execute Open-Source Arduino Code in a PIC Microcontroller Using the MPLAB IDE

The Arduino single-board computer is a de facto standard tool for developing microcomputer applications within the hobbyist and educational communities. It provides an open-source hardware (OSH) environment based on a simple microcontroller board, as well as an open-source (OS) development environment for writing software for the board.

Here’s an approach that enables Arduino code to be configured for execution with the Microchip Technology PIC32MX250F128B small-outline 32-bit microcontroller. It uses the Microchip Technology MPLAB X IDE and MPLAB XC32 C Compiler and the Microchip Technology Microstick II programmer/debugger.

Subscribe to Circuit Cellar magazine! Get 12 months of electrical engineering project articles, embedded design tutorials, embedded programming tips, and much more. We cover micrcontrollers, robotics, embedded Linux, IoT projects, and more!

Your own reasons for using this approach will depend on your personal needs and background. Perhaps as a long-term Arduino user, you want to explore a new processor performance option with your existing Arduino code base. Or, you want to take advantage of or gain experience with the Microchip advanced IDE development tools and debug with your existing Arduino code. All of these goals are easily achieved using the approach and the beta library covered in this article.

Several fundamental open-source Arduino code examples are described using the beta core library of Arduino functions I developed. The beta version is available, for evaluation purposes only, as a free download from the “Arduino Library Code for PIC32” link on my KibaCorp company website, kibacorp.com. From there, you can also download a short description of the Microstick II hardware configuration used for the library.

To illustrate the capabilities in their simplest form, here is a simple Blink LED example from my book Beginner’s Guide to Programming the PIC32. The example shows how this custom library makes it easy to convert Arduino code to a PIC32 binary file.

ARDUINO BLINK EXAMPLE 1
The Arduino code example is as follows: Wire an LED through a 1-K resistor to pin 13 (D7) of the Arduino. An output pin is configured to drive an LED using pinMode () function under setup (). Then under loop () this output is set high and then low using digitalWrite () and delay () functions to blink the LED. The community open-source Arduino code is:

Listing 1forwebPIC32 EXAMPLE 1 CODE MODIFICATIONS
The open-source example uses D13 or physical pin 13 on the Arduino. In relation to the PIC32MX, the D13 is physical pin 25. Pin 25 will be used in prototyping wiring.

Now, let’s review and understand the PIC32 project template and its associated “wrapping functions.”  The Arduino uses two principal functions: setup () to initialize the system and loop () to run a continuous execution loop. There is no Main function. Using the Microchip Technololgy XC32 C compiler, we are constrained to having a Main function. The Arduino setup () and loop () functions can be accommodated, but only as part of an overall template Main “wrapping” function. So within our PIC32 template, we accommodate this as follows:

Listing 2

This piece of code is a small but essential part of the template. Note that in this critical wrapping function, setup () is called once as in Arduino and loop () is configured to be called continuously (simulating the loop () function in Arduino) through the use of a while loop in Main.

The second critical wrapping function for our template is the use of C header files at the beginning of the code. The XC32 C compiler uses the C compiler directive #include reference files within the Main code. Arduino uses import, which is a similar construct that is used in higher-level languages such as Java and Python, which cannot be used by the MPLAB XC32 C.

The two include files necessary for our first example are as follows:

Listing 3

System.h references all the critical Microchip library functions supporting the PIC32MX250F128B. The Ardunio.h provides the Arduino specific library function set. Given these two key “wrapper” aspects, where does the Arduino code go? This is best illustrated with a side-by-side comparison between Arduino code and its Microchip equivalent. The Arduino code is essentially positioned between the wrapper codes as part of the Main function.

Blink side-by-side comparison

Blink side-by-side comparison

This approach enables Arduino code to execute on a Microchip PIC32 within an MPLAB X environment. Note that the Arduino code void setup () now appears as void setup (void), and void loop () appears as void loop (void). This is a minor inconvenience but again necessary for our C environment syntax for C prototype function definitions. Once the code is successfully compiled, the environment enables you to have access to the entire built-in tool suite of the MPLAB X and its debugger tool suite.

RUNNING EXAMPLE 1 CODE
Configure the Microstick II prototype as in the following schematic. Both the schematic and prototype are shown below:

Exercise 1 schematic

Exercise 1 schematic

Exercise 1 prototype

Exercise 1 prototype

BETA LIBRARY
Table 1 compares Arduino core functionality to what is contained in the Microchip PIC32 expanded beta library. In the beta version, I added additional C header files to accomplish the necessary library functionality. Table 2 compares variable types between Arduino and PIC32 variable types. Both Table 1 and Table 2 show the current beta version has a high degree of Arduino core library functionality. Current limitations are the use of only one serial port, interrupt with INT0 only, and no stream capability. In addition, with C the “!” operator is used for conditional test only and not as a complement function, as in Arduino. To use the complement function in C, the “~” operator is used. The library is easily adapted to other PIC32 devices or board types.

Table 1

Table 1: Arduino vs Microchip Technology PIC32 core library function comparison

Talble 2

Table 2: Arduino vs Microchip Technology PIC32 core library variable types

INTERRUPTS
If you use interrupts, you must identify to C the name of your interrupt service routine as used in your Arduino script. See below:

Interrupt support

Interrupt support

For more information on the beta release or to send comments and constructive criticism, or to report any detected problems, please contact me here.

LIBRARY TEST EXAMPLES
Four test case examples demonstrating additional core library functions are shown below as illustrations.

Serial communications

Serial communications

Serial find string test case

Serial find string test case

Serial parse INT

Serial parse INT

Interrupt

Interrupt

Editor’s Note: Portions of this post first appeared in Tom Kibalo’s book Beginner’s Guide to Programming the PIC32 (Electronics Products, 2013). They are reprinted with permission from Chuck Hellebuyck, Electronic Products. If you are interested in reading more articles by Kibalo, check out his two-part Circuit Cellar “robot boot camp” series posted in 2012 : “Autonomous Mobile Robot (Part 1): Overview & Hardware” and “Autonomous Mobile Robot (Part 2): Software & Operation.”

 

Tom Kibalo

Tom Kibalo

ABOUT THE AUTHOR
Tom Kibalo is principal engineer at a large defense firm and president of KibaCorp, a company dedicated to DIY hobbyist, student, and engineering education. Tom, who is also an Engineering Department adjunct faculty member at Anne Arundel Community College in Arnold, MD, is keenly interested in microcontroller applications and embedded designs. To find out more about Tom, read his 2013 Circuit Cellar member profile.

Cypress Expands Portfolio with New Traveo Automotive Microcontroller Series

Cypress Semiconductor Corp. recently expanded of its automotive portfolio with the first series of its Traveo microcontroller family. The series features up to 4 MB of high-density embedded flash, stepper motor control, TFT display control, advanced sound output capabilities, and support for all in-vehicle networking standards.Cypress Traveo

Otimized for high-end body and gateway systems, the new series provides the ability to embed more on-chip flash memory for advanced applications. In addition, the 40-nm Traveo microcontrollers make it easy to implement Firmware Over-The-Air (FOTA) updates.

The new 40-nm Traveo S6J331X/S6J332X/S6J333X/S6J334X series offers a high-performance platform for classic instrument clusters. Based on the ARM Cortex-R5 processor with 240-MHz performance, it supports the CAN-FD automotive communication protocol for increased data bandwidth for faster networking.

Additionally, Cypress introduced a transceiver for the Clock Extension Peripheral Interface (CXPI) designed to replace the Local Interconnect Network (LIN) automotive communication protocol.

The Traveo S6J331X/S6J332X/S6J333X/S6J334X and S6J335X series is currently sampling and will be in production in the second half of 2016. It is available in 144-pin, 176-pin and 208-pin TEQFP packages.
The S6BT11X CXPI transceiver series is sampling now. It is available in an 8-pin SOP package.

Source: Cypress Semiconductor

New Ecosystem to Accompany 8-bit FT51A MCUs

FTDI Chip recently announced an array of board level products to support its FT51A microcontroller. It executes an 8051 feature set that can operate at 48 MHz. In addition, it features a variety of interfaces, including USB client, UART, SPI, I2C, 245 FIFO, PWM, and GPIO. The USB hub feature enables multiple USB-enabled devices to be combined. The FT51A’s data conversion capabilities comprise of an 8-bit ADC. Its 16-KB shadow RAM accelerates read access of the core. The device draws 20 mA (typical) while active and 150 µA (typical) when in suspend mode.

The FT51A microcontroller is suitable for a variety of applications, including industrial test instrumentation and sensor control.

The FT51A-EVM evaluation module offers you several functions for learning about the FT51A MCU.  It includes a 2 × 20 LCD display and several sensor mechanisms for data acquisition. Also included are a heart-rate monitor (with filtered and amplified analo output), a force sensitive resistor, and a SPI-enabled temperature sensor.

Source: FTDI