The Arduino Yún turns one

The Arduino Yún – which was designed in collaboration with Dog Hunter – is based on Atmel’s ATmega32u4 microcontroller (MCU) and also features the Atheros AR9331, an SoC running Linino, a customized version of OpenWRT. Now, one year later, the Yún celebrates its one-year anniversary! With over 9,200 forum posts, 8 OpenWrt-Yún releases and 492,000 search results, the AVR based board has become quite a hit for Makers. We think this deserves an Arduino high-five, for sure!

Happy Birthday Arduino Yún with 9243 forum posts, 8 openwrt-yun rel., over 492k search results http://t.co/Jq5annmev5 pic.twitter.com/VzsWXcFXna

— Arduino (@arduino) September 12, 2014

Made available last September, the Yún was a somewhat unique addition to the existing Arduino line-up, as it boasts a lightweight Linux distribution to complement the traditional MCU interface.

Yún, which means “cloud” in Chinese, aspired to make it simple to connect to complex web services directly from Arduino. The board features WiFi and Ethernet connections, therefore enabling the board to communicate with networks out of the box. Additionally, the Yún’s Linux and Arduino processors link through the Bridge library, enabling Arduino sketches to send commands to the command line interface of Linux.

“The Arduino Yún has the same footprint as an Arduino Uno but combines an ATmega32u4 microcontroller (the same as the Leonardo) and a Linux system based on the Atheros AR9331 chipset,” Arduino’s Federico Vanzati explained. “Additionally, there are built-in Ethernet and WiFi capabilities. The combination of the classic Arduino programming experience and advanced internet capabilities afforded by a Linux system make the Yún a powerful tool for communicating with the internet of things (IoT).”

According to Vanzati, the Yún’s layout keeps the I/O pins the same as the Leonardo and is therefore compatible with the most shields designed for Arduino.

“With the Yún’s auto-discovery system, your computer can recognize boards connected to the same network. This enables you to upload sketches wirelessly to the Yún,” he continued. “You can still upload sketches to the Yún through the micro-USB connector just as you would with the Leonardo.”

On the connectivity side, the Yún is equipped with two separate network interfaces, a 10/100 Mbit/s Fast Ethernet port and a IEEE 802.11 b/g/n standard compliant 2.4GHz WiFi interface, supporting WEP, WPA and WPA2 encryption. As expected, the WiFi interface can also operate as an access point (AP). In AP mode any WiFi enabled device can connect directly to the network created on the Yún. While a Yún in this mode can’t connect to the internet, it could act as a hub for a group of WiFi enabled sensors.

As Vanzati notes, interfacing Arduino with web services has historically been rather challenging due to memory restrictions.

“[However], the Yun’s Linux environment simplifies the means to access internet services by using many of the same tools you would use on your computer,” he said. “You can run several applications as complex as you need, without stressing the ATmega microcontroller.”

To help engineers and Makers develop applications that can connect to popular web services, Arduini has partnered with Temboo, a service that simplifies accessing hundreds of the web’s most popular APIs. In fact, a Temboo library is packaged with the Yún, making it easy to connect to a large variety of online tools.

Facilitating a seamless connection between the two processors is achieved via the Yún’s Bridge library, which connects the hardware serial port of the AR9331 to Serial1 on the 32U4 (digital pins 0 & 1).

“The serial port of the AR9331 exposes the Linux console (aka, the command line interface, or CLI) for communication with the 32U4,” Vanzati confirmed. “The console is a means for the Linux kernel and other processes to output messages to the user and receive input from the user. File and system management tools are installed by default. It’s also possible to install and run your own applications using Bridge.”

Of course, the ATmega32u4 can also be programmed from the AR9331 by uploading a sketch through the Yún’s WiFi interface. When connected to the same WiFi network as your computer, the board will appear under the “Port” menu of the Arduino IDE. The sketch will be transferred to the AR9331 and the Linux distribution will program the ATmega32u4 through the SPI bus, emulating an AVR ISP programmer.

Last, but certainly not least, the Yún can be powered through the micro-USB connector, the Vin pin, or the optional Power Over Ethernet (POE) module. When powering the board though the Vin pin, users must supply a regulated 5VDC, as there is no on-board regulator for higher voltages.

As we come together to celebrate the Yún’s birthday, feel free to browse the latest projects powered by the board or access more information on the board’s official page here.

Don’t forget to join the Atmel team in Queens later this week for the 5th Annual World Maker Faire. Undoubtedly, this year will be amazing as an expected 750+ Makers and 85,000+ attendees head to the New York Hall of Science to see the latest DIY gizmos and gadgets, as well as AVR Man in the flesh. Once again a Silversmith Sponsor of the event, Atmel will put the spotlight on everything from Arduino to Arduino-related projects. See you soon!

ATmega8 powers this pool cleaning robot

Pools are great, especially in these summer months. Cleaning them, however, not so much. A Maker by the name of David Gironi has simplified this process by powering an automated pool cleaner with an Atmel ATmega8-controlled timer.

James Hobson over at Hackaday alerted us to Gironi’s Atmel-powered cleaning unit. After the Maker’s store-bought pool cleaning unit failed, in true DIY fashion he decided to employ some technology to fix the robot on his own. The project is broken down into two parts, the ATmega8-based timer and the underwater cleaning robot.

According to the Maker, the ATMega8-powered timer alternates between a “working” and “pause” periods. As a result, Gironi can run the robot at a predetermined interval of days, for any designated time period, i.e. 30 minutes. The out-of-water timer is responsible for converting 220VAC to low voltage DC for the robot. Apart from the timer, the robot itself features two motors. One of the motors pumps the water through the unit to filter it, the other to maneuver the cleaner under the surface.

To delve deeper in the Maker’s design, head over to his in-depth blog piece here.

The ABCs of ECDSA (Part 2)

Part 2 of The ABCs of ECDSA (“Sign-Here”) will describe how digital certificates are made and signed. In the previous article (The ABCs of ECDSA: Part 1), we examined the steps of ECDSA performing asymmetric authentication using digital certificates. You may have noticed that both Part 1 and Part 2 are in reverse chronological order; however, it makes better sense to first understand a bit about the actual authentication process before dissecting the details of making the certificate. (Just trust me on that.) Before we get into the nuances of the certificate, let’s recall that authentication is about keeping something real. Such things would be mobile, medical and consumer accessories; embedded firmware; industrial networks; and soon the new platforms of IoT, home automation, and vehicle-to-vehicle communications. Aside from those, there are several others given the fact that the need for authentication is increasing exponentially as more things communicate with each other, and through the cloud, are creating more opportunities for bad actors to apply their mal-intent.

Especially with the increased use of the Internet and the cloud for financial transactions and transmission of confidential personal/medical information, it’s critical to ensure that the sender of information is exactly who they are supposed to be, as well as that the data has not been tampered with. That is where authentication and hardware key storage come in. Here we will focus on asymmetric authentication. Asymmetric authentication using ECDSA is based upon a digital certificate, which in this case, is stored in the ATECC108A device.

So, now let’s go into the chip factory and see how the ECDSA certificate is made and stored in the device. Remember that ECDSA stands for Elliptic Curve Digital Signature Algorithm. The words “Elliptic Curve” are in the name because Elliptic Curve Cryptography (“ECC”) algorithms are used. No mystery there. The benefit of ECC is that it provides extremely strong security with shorter key lengths than other popular algorithms. Bitcoin, for example uses ECC predominantly for that reason.   (We won’t go into Bitcoin here.) “DSA” points to the fact that digital signatures are the key element of the process, which is also fairly self evident. The digital signing process is what we describe here, step by step. “Certificate” is the name given to the concept of putting certain types of data together in a prescribed format and then signing that data using hashing algorithms and signing algorithms. (Again, the usage of the certificate is covered in Part 1.)

While we are fully immersed here in cryptographic alphabet soup, we might as well add one more thing to it: The prescribed format used in the ECDSA in the ATECC108A is called ASN.1. ASN.1 basically defines what is what in the certificate, including the serial number, the public key and that sort of thing. It also defines the length of those data elements.

Now, back to building the certificate: The certificate is made and loaded in the key storage device in the chip factory. It is made from two main components:

1. The certificate data 
2. The signature

The certificate data is a collection of data from three sources:

1. Static data: Boiler plate type data that does not change, such as the name and address of the manufacturer. (This is the ASN.1 encoded stuff.)
2. Dynamic data: Data from the tester that can change with each device such as time, date, and serial number.
3. Client device’s public key, which has an algorithmic relationship to the client’s private key that will be securely stored in the client device.

The certificate data is formatted according to X.509 specifications (yes, more crypto jargon). X.509 defines the elements and order of the elements in the certificate, such as  serial number, public key, subject’s common name (i.e. the name of the certificate), authority ID (normally a SHA-1 hash of the public key), authority common name (i.e. the name of the authority that signs the certificate data), among other things. We will leave more about X.509 for another day.

The certificate data comprises just half of the certificate, the other half is the signature. What is a little tricky to understand at first is that the certificate data do two things: (1) become part of the certificate as it is, and (2) gets hashed and signed to make the signature. Both the certificate data itself and the signature make up the certificate.

The specific steps in order to make the signature begins with a copy of the certificate data being put through a hash algorithm to create a number called a hash value (or digest). ECDSA specifies a 32 byte digest length and SHA256 as the hashing algorithm. Once created, the digest is ready to be signed by the sign module in the factory.

The sign module is a piece of equipment that securely stores the signer’s private key. No one can get access to that key. The sign module uses the ECC sign algorithm to sign the digest of the certificate data with the signer’s private key. The result of that process becomes the “signature.” The signature then joins the original (i.e. unhashed) certificate data to complete the certificate. Note that the signing key is tied to the OEM’s root key to create the root of trust (the notion of root of trust will be addressed in another article).

The certificate is now finished and can be installed into the crypto device. Once the device is finished, it is then shipped to the customer’s factory to be assembled into an accessory, consumable, board or any number of things, i.e. a consumable water filter that later gets installed into refrigerator. In this scenario, when a new filter is installed by the consumer into the refrigerator when the old filter expires, the new filter will be authenticated by the host processor in the refrigerator according to the ECDSA process as described in The ABCs of ECDSA (Part 1).

Below is a video (sorry, no sound) that will visually help walk you through the steps noted above.

Benefits of asymmetric authentication with ECDSA include:

• Increased security because asymmetric authentication does not need secure key storage on the host (only the client)
• No need to update the host with secrets in the field (can update the public key at any time.)
• Uses the advantages of Elliptic Curve Cryptography (high security, short key, less computation)

Atmel CryptoAuthentication™ products such as Atmel’s ATSHA204A, ATECC108A  and ATAES132 implement hardware-based storage, which is much stronger then software based storage because of the defense mechanisms that only hardware can provide against attacks. Secure storage in hardware beats storage in software every time. Adding secure key storage is an inexpensive, easy, and ultra-secure way to protect firmware, software, and hardware products from cloning, counterfeiting, hacking, and other malicious threats. 

If you have yet to read the first portion of this article, you can find The ABCs of ECDSA (Part 1) here.

 

 

 

The ABCs of ECDSA (Part 1)

One of the major difficulties in explaining anything cryptographic, among many other things, is what I call “Acry-phobia” which is fear of cryptographic acronyms. This is a justified condition.

Acryphobia is far from irrational because in cryptography (since it is math) every little thing and the relationships between them must be defined, specified, examined, theorized, tested, formulated, processed, scrutinized, proved, and…. well, you get the picture. Simply stated, this means there’s a whole lot to it. Therefore, in order to teach cryptographic concepts, it’s imperative to focus on a specific area at a time and then break that down further into its fundamentals: That is sort of like breaking down the works of Shakespeare first into episodes, then into Old English then modern English and finally the ABCs. In pretty much similar fashion, that is what we want to do here. Namely, focus on one type of authentication scheme and break it down into its fundamentals and explain those one step at a time.

The specific fear-inducing cryptographic acronym we will try to overcome during this session (and one more after it) is ECDSA, or Elliptic Curve Digital Signature Algorithm.

To quickly dispel some of the Acryphobia, let’s look at authentication from a less mathematical viewpoint.

The basic idea of authentication (just like the name says) is to authenticate, meaning to confirm that the sender of a message is exactly who they say they are. Confirmation is the key to authentication and it requires using some type of trusted credential from another party to verify a declared identity. As noted in an earlier article, this identity confirmation process is sort of like those scenes in old movies where a guard of some type challenges an approacher by saying, “Halt! Who goes there?”

Once challenged, the approacher must respond by identifying himself (or herself) and produce a document (certificate) with the signature or seal of the king, general, or some other trusted authority to confirm that the bearer is not an impostor.  That seal or signature links the approacher to a recognized, trusted signer/sealer. The signer/sealer can be described therefore as the certificate authority. (Note that “Certificate Authority” is in fact a technical cryptographic term.)

Cryptographic authentication is just the mathematical version of this challenge-response-certificate-signing-verification process. It uses digital processors, rather than people with bayonets or other weapons of choice.

Getting back to the math, the type of authentication we are discussing in this article is asymmetric, meaning that the secret key is not stored on both the host and client (like with symmetric authentication). Asymmetric authentication stores the secret key on the client side only and then the uses certain mathematical algorithms on certain prescribed information that the client sends it for the ultimate purpose of verifying that the client is real. ECDSA is one of the available types of processes, and what we are going to explore throughout the rest of the article, in a step-by-step fashion. Later on, in an upcoming article, we will address the details about how the crypto devices are originally loaded in the chip factory with the important information needed to make ECDSA authentication happen out in the real world.

So, let’s get into the asymmetric authentication process, which  typically begins when a client device is inserted into a host system or the host system wants to know what exactly is connected to it. Examples include a printer ink cartridge being inserted into a printer, a thermostat control block wanting to talk to a remote temperature sensor, a cell phone connecting to a wall charger, among a number of others.

ECDSA (Elliptic Curve Digital Signature Algorithm) is a two-phased process:

• Phase 1 is to verify that the public key on the client
• Phase 2 is to verify the private key on the client.

If both phases pass these two verify calculations then the client is verified as real (i.e. by showing that there is a valid private-public key pair in the client).

(Remember that authentication of any type is meant to keep something real. How the keys are used defines if the process is symmetric or asymmetric.)

The steps of ECDSA are depicted in the diagrams below. In this particular example, the illustrations are based upon a host system that contains a microcontroller and a client (accessory) equipped with an ATECC108A secure key storage device.

Phase 1 starts with the host requesting information to be sent over by the client (accessory). That information comes over to the host as a “certificate.” This certificate is made and then programmed into the crypto device in the chip factory. For now, we’ll start with the already assembled, stored and ready-to-use certificate.

The certificate contains two main things:

1. Certificate data (made up of the client’s public key + static data + dynamic data)
2. Signature (made by hashing that certificate data and the signer’s secret key in the chip factory)

When the host receives the certificate, it extracts the certificate data (static data, dynamic data, and client public key) and the signature (made by the signing module in the chip factory). The host runs the same hashing that was used in the chip factory on the certificate data it just received, creating a 32-byte message digest that will be used in the phase one ECDSA calculation. If the client is real, then this hash function run in the host should have the exact same result (digest) as the one that was run the chip factory to create the signature.

On the host, the message digest made from the received certificate data, the signer’s public key, which also came over from the client (more on how that arrives will be in yet another article), and the signature from the certificate are put into the ECDSA verify calculation. If the ECDSA calculation is successful, the client’s public key is considered to be real. That then starts phase 2 to verify the client’s private key.The whole point of this two-phase process is to verify mathematically that the client’s private key and public key are indeed a valid key pair.

The goal of phase two is to verify the client’s private key. This phase begins with the host generating a random number challenge and sending it to the client. The client device uses the ECDSA signature engine in the ATECC108A to create a new signature using this random number and the client’s (secret) private key stored there. That new signature is then sent to back the host, which uses it along with the random number and the client’s public key (that was verified in phase one) as inputs to another ECDSA verify calculation. If that calculation succeeds, the host has then proven that the accessory (client) is real (i.e. contains a valid private-public key pair)

As you can see, the ATECC108A does all the heavy mathematical lifting, and Atmel provides what users need to make it easy to program the microcontroller to do its part of the process. The engineering and mathematics behind authentication using sophisticated algorithms may not be easy in theory, but that does not matter as Atmel makes it simple to implement cryptography without having to be a cryptography expert…. and that is the “REAL” point here.

The video (now with sound) will step you through the two phases of the ECDSA process described above.

So, in summary, the key aspects of asymmetric authentication with ECDSA include:

• Increased security because asymmetric authentication does not need secure key storage on the host (only the client)
• No need to update the host with secrets in the field. (can update the public key at any time.)
• Uses the advantages of Elliptic Curve Cryptography (high security, short key, less computation)

Atmel CryptoAuthentication™ products such as Atmel’s ATSHA204A, ATECC108A and ATAES132 implement hardware-based storage, which is much stronger then software based storage because of the defense mechanisms that only hardware can provide against attacks. Secure storage in hardware beats storage in software every time. Adding secure key storage is an inexpensive, easy, and ultra-secure way to protect firmware, software, and hardware products from cloning, counterfeiting, hacking, and other malicious threats. For more details on Atmel CryptoAuthentication products, head on over to its introduction page here.

Plese read   The ABCs of ECDSA (Part 2: Sign Here) to see how the certificate is built and signed in the chip factory.

Implementing Haptics: Defining and driving the actuator are major challenges

For the system designer, adding haptics capability and tactile feedback to a system is both easy and difficult. In general, the sensor has little or moderate impact on the BOM, space, and cost, while the software has no BOM and minimal cost implications. But the embedding hardware drive circuitry and the physical actuator require considerable assessment of design issues, power consumption, PC board and enclosure real estate as well as the cost dimension.

There are four key elements to implementing a haptics function in a system design:
1) The sensor, which may not be needed, depending on the system,
2) The software, which decides what output waveform is needed,
3) The hardware driver for the haptics actuator, and
4) The actuator itself.

These four blocks interact to close the loop and meet the unique requirements of haptics functionality. This article will take a deeper look at the sensor, hardware driver and the actuator in a haptics system.

The Sensor

While many haptics functions have or add a sensor to sense a physical parameter, others do not need a sensor function at all. For example, in a basic gaming system the software determines what the user is seeing and doing and generates outputs such as controller rumble that correspond to the action. Other systems make use of existing sensors, and only need to add additional software and output drive. For example, the Atmel AT42QT1085 QTouch microcontroller is specifically designed to use with the existing capacitive-touch sensors of a screen. (Fig. 1) It embeds software to interpret the user’s finger actions on various screen sliders, buttons and wheels, and then decides the appropriate response.

Fig. 1: The Atmel AT42QT1085 QTouch microcontroller is designed to work with a standard capacitive-sensing touchscreen and function as the interface between the panel and system, by assessing the meaning of the user’s finger swipes. (Source: Atmel)

More complicated designs need a haptics-specific sensor as their signal and data source with the use of multi-axis accelerometers to determine the motion of a game controller or robotic control. This accelerometer is almost always a MEMS device, and may provide a digitized output directly or an analog one that the system microcontroller must digitize. Fortunately, the resolution, accuracy and speed requirements are relatively modest: 8 to 10 bits at just several hundred samples per second or less.

Not all haptics inputs are based on motion and position. Some also sense the temperature of a user’s hands, which can be done with an inexpensive diode-based sensor or a low-cost easy-to-interface IC, such as a member of the Analog Devices AD590 family.

Driver and Actuator

In order to understand the hardware driver needed, a design engineer first must know what sort of haptics actuator will be used. This is one of the most difficult choices because the laws of physics clearly show that such actuation implies motion, and motion means “work,” so power needs to be delivered in the form of current and voltage. Each of the four most common actuators has pros and cons that affect the trade-off decision.

The design team must not only weigh the characteristics of the actuator, but also its unique electronic drive requirements. In contrast, the software that controls each actuator is relatively simple; OEMs can write their own code, they may be able to get it directly from the actuator vendor, or it may be available as a licensed library from the IC vendor or third-party sources, similar to what is done for audio sound-effect clips.

The four most common actuator options in use are:

1) An eccentric rotating mass (ERM) is a tiny motor with an off-balance rotating weight. The ERM is low cost since it is used for “rumble” effects in high-volume applications such as gaming controllers. The operating current is in the 150-mA range, and it vibrates between 100 and 200 Hz. The response time of the ERM is somewhat slow (50 ms), so it is not a good choice of keyboard or button response. The ERM’s size is approximately 10 mm long with a 5 mm swing of the eccentric mass.

2) The linear resonant actuator (LRA) is a motor-like component that looks like small puck, typically about 10 mm in diameter and 4 mm thick. LRAs vibrate a single frequency between 100 and 200 Hz, with a response that is somewhat faster than ERMs, at about 30 msec. They are more costly than ERMs but need less current (about 75 mA) for actuation as well as an AC drive signal.

3) Piezoelectric modules can provide high vibration fidelity due to their fast response time (5 ms) over a wide frequency range of approximately 150 to 300 Hz, and thus are a good choice for typing feedback applications. They come in a long, relatively slim form factor, about 3.5 mm square and 40 mm long. Piezo modules are high performance actuators that can be used to create realistic haptic effects and can be applied in smartphones or tablets. Although they draw no more aggregate power than ERMs or LRAs, they do need a relatively high current pulse of 300 mA at around ±75 V (often derived from a 3 V supply). Piezo modules are a highly capacitive load, which the interface IC must be able to drive. Although they are ceramic-based transducers and might be assumed to be brittle, they are actually rugged due to their small mass and layered construction.

4) The electroactive polymer (EAP) actuator is a thin, flat, durable panel that is less than 1 mm thick. It requires a somewhat complex mounting arrangement on a sled to act in conjunction with the associated movable mass. Due to its fast response time of just a few milliseconds and resonance at around 100 Hz, it is a good choice for touchscreen feedback and is most commonly found in top-of-the-line smartphones. The biggest challenge with EAPs is that they require a drive voltage of approximately 800 V, which means a sophisticated and somewhat costly boost power supply subsystem.

There is no simple “best” answer for providing tactile haptics feedback to the user, as each actuator type has unique and sometimes complex electronic drive requirements. IC vendors have responded to this need with a variety of drivers that bridge the voltage/current differential between the conventional low voltage and currents of most systems and the needs of the various actuators.

For example, Texas Instruments offers the DRV2605 driver for ERM and LRA actuators, using the I2C bus for the processor interface (Fig. 2). It embeds a smart-loop architecture, which simplifies achieving auto-resonant drive for the LRA as well as feedback-optimized drive for the ERM. This feedback feature provides automatic overdrive and braking, which in turn allows creating a simplified input-waveform model, along with reliable motor control and consistent motor performance. An audio-to-haptics mode automatically converts an audio input signal to consistent haptic effects. There is also no need to design haptic waveforms with this IC, since the vendor offers a royalty-free library of over 100 haptics effects. An evaluation kit and board aids design and experimentation (Fig. 3).

Fig. 2: Texas Instruments offers the DRV2605 haptic driver IC for LRA and ERM transducers; it incorporates features which help eliminate the design complexities of haptic motor control, and also has an available library of royalty-free haptics drivers. (Source: Texas Instruments)

Fig. 3: For those unfamiliar with either haptics in general, or specific software and hardware issues related to LRAs and ERMs, the available DRV2605EVM-CT evaluation kit eases the implementation process and reduces the design-in time for the DRV2605 haptic driver. (Source: Texas Instruments)

For piezo transducers, driver components such as the Texas Instruments DRV2667 are available (Fig. 4). Like the ERM/LRA driver IC, it interfaces to the processor via the I2C bus, but the similarities end there. It integrates a 105 V boost switch, power diode, fully differential amplifier, and digital front-end including waveform synthesizer. Its output is designed for capacitive loads. For example, it can drive a 330 nF load at 100 Vp-p and 300 Hz, and a 680 nF load at 50 Vp-p, also at 300 Hz. As with most haptics drivers/transducers, vendors offer evaluation kits (Fig. 5), so designers can explore operating characteristics and subtle design issues of these somewhat unique electrical-to-motion transducers.

Fig. 4: For piezo actuators, the DRV2667 from Texas Instruments provides the fast-slewing high-voltage drive into a capacitive load that is required by this actuator technology. (Source: Texas Instruments)

Fig. 5: Evaluation kits such as the DRV2667EVM allow designers to easily interface to and drive a piezo transducer and thus understand its special operating characteristics. (Source: Texas Instruments)

Other vendors are also seeing the broad and still not-fully defined opportunities for haptics technology; Avnet now distributes Samsung Electro-Mechanics’ line of LRAs.

There’s no doubt that adding haptics to a design adds another dimension to the user experience and human machine interface (HMI). For system designers, haptics technology also brings new challenges of actuator considerations, associated drive circuitry, and increases in space as well as power requirements.

This post was written by Bill Schweber and originally published in Avnet’s Technical Articles. For more engineering resources from Avnet, please visit their Design Zones. 

The evolution and DNA of the Internet of Things

The Internet of Things (IoT), as noted in previous Bits & Pieces articles, is really just a concept at this point because the “things” are undefined. As those “things” become more defined, the IoT’s things stop being just things and become something. So, the main question right now: What are those things going to be? Perhaps the IoT should more accurately be called the “IoXT” with “X” being the variable describing what that particular thing actually is. An example could be the Internet of wearable fitness trackers, factory robots, home automation, smart appliances, vehicle to vehicle communication, traffic control… well, you get the picture. The X can (and will) be many different things.

Clearly, for the IoT to be meaningful, the X must be identified in detail. The IoT must evolve from the ultra-general (i.e. “things”) to specific applications, components, systems, and integrated circuits, among others. There appears to be an emerging need for a classification hierarchy to describe the IoT as it differentiates and evolves. The Linnaeus classification model that is used in biology to describe living “things”, comes to mind. The same classification process can apply to silicon-based things and not just carbon-based things (beings).

Do you see the connection?

                           

In a silicon-based classification regime, the term “IoT” would probably lie somewhere between phylum and family. Though it is not entirely clear exactly where yet, that does really not matter at this point; however, what matters is that engineers and product managers must push product definition to the genus and species levels for the IoT to ever truly matter.

In the early stages of IoT’s evolution, there could easily be a type of Cambrian explosion with the genesis of an insane number of new devices covering a wide spectrum of applications that from the truly inspired to the ridiculous. Economic Darwinism would later surely take over to narrow down the numbers overtime with many going extinct and others continuing to adapt into world-changing “things.”

Because the IoT’s silicon building blocks (i.e. the DNA of IoT) are getting into place, it will become very easy to create, modify, and adapt countless smart, sensing, secure, communicating devices. That ease of design is what is making IoT’s potential staggering, and why so many companies (especially silicon companies) are aggressively pursuing the IoT market.

As for the numbers, Gartner believes 26 billion devices will have connectivity by 2022, while Ericsson and Cisco both forecast the number being even higher at 50 billion units by 2020 and 2022, respectively. McKinsey Global Institute (MGI)  expects IoT to have an economic impact of $2.7 to $6.2 trillion by 2025. Gartner notes that IoT suppliers will generate incremental product and service revenue exceeding $300 billion in 2020, resulting in over $1.9 trillion in global economic value-add in diverse end-markets. According to IDC, the installed base of IoT will be 212 billion by the end of 2020, with 30.1 billion of that being connected autonomous things.

The following chart from McKinsey Global Institute details their view of the impact from various economic categories. Note that healthcare is the largest, which makes perfect sense given the affinity of bio-sensors, continuous monitoring, wearable devices, and wireless communication. Subsequently, it is no accident that the major mobile platform and consumer product companies are pursuing bio-metric capabilities for wearable products.

With an increasing demand for medical care as populations age in Western countries, remote telemedicine to cover under-served populations makes great sense. Telemedicine could easily revolutionize medical care, and connected-sensing devices could revolutionize telemedicine. There is little to hold the growth of medical sensing and communicating networks back, especially since governmental agencies are on a mission to extend the provision of health care universally. Perhaps this is a perfect storm.

Health networks will be joined by networks of many types; each of those will be driven by the ability to create IoT devices from their four main building blocks:

1. Brains (MCU)
2. Wireless Communications
3. Sensors of Various Types
4. Security.

Devices with those fundamental IoT building blocks will differentiate on each of those four axes depending upon what they need to do. Some of the types of networks that could show up and drive the IoT’s evolution are noted below:

• M2M:  Machine to Machine network
• V2V: Vehicle to Vehicle network
• Personal medical network
• PAN: Personal area network (wearable network)
• Home entertainment network
• Personal social network.
• Home automation/security network
• Personal fitness network.
• Car infotainment network
• Highway sensor network
• Hazardous material sensing network
• Smart appliance network
• Augmented reality network
• Multi-screen network
• Energy management network

There are of course others, too.

One last thing: The dirty little secret of the IoT is that there probably cannot be such a thing as the Internet of Things if those things are not secure. That is where devices like Atmel CryptoAuthentication ICs play an important, if not catalytic role. Making sure that the nodes in the various networks are authentic and that the data being transmitted have not been tampered with is what CryptoAuthentication devices do. It is easy to see why security is important when there are billions of things keeping track of you, right?

So, authentication may in actual fact be the sine qua non (“without which there is nothing”) of the IoT.

Or, to put it another way: No security? No IoT for you.

 

IoT analogous to undifferentiated silicon stem cells

One could say that any term with the word “thing” in it is vague — by definition. So, one could also assume that the term “Internet of Things” (IoT) is also vague by definition. Why is it that the tech and investor communities cannot define IoT? Maybe it’s because the IoT is indefinable — by definition.

In order to try and define something, it helps to analyze is compsition. There appears to be an emerging consensus among engineers, industry analysts, authors, tech executives, and others about the fundamental pieces that will make up the IoT; namely, the following items:

• Intelligence
• Communication
• Sensing
• Security

Ultra-low power drain and miniaturization are other aspects. So, perhaps a definition of the IoT today could be the following: “Low power, ultra-small things inside other things that sense more things and communicate (securely) between these things and other things.”

Obviously, that’s not a meaningful definition, and rightfully so, because the problem of defining the IoT is that today the IoT is not any ‘thing.’ Certainly not anything specific. The IoT is a generality — by definition. The only true specifics are the component pieces as noted above, and once those components are assembled and programmed, they differentiate into real things.  

The point here is that the IoT is analogous to undifferentiated silicon stem cells, and these silicon stem cells can differentiate into a spectrum of specific, tangible, and identifiable…

The differentiated devices would address a wide spectrum of specific, diverse solutions for use in an even wider range of equipment and applications. Most of the eventual applications and solutions have not even been dreamed up yet. This is a similar situation to world of cellphones back in 2006 before anyone outside a certain city in Silicon Valley knew that a new device would eventually turn everyone’s phone into a smart black rectangle for years. IoT potentially will have similar power to transform the world on a large scale as well — far beyond mobile communications. We just don’t know exactly how the silicon stem cells will differentiate yet… but we will.

Each of the main IoT functions — communications, control, sensing, and security — will surely undergo micro and macro integration. Micro integration is putting the component subsystem pieces together into low power, small, integrated physical platforms. Companies with microcontroller, sensor, communication, and security IP will be best positioned. (Do any come to mind?)

Macro integration refers to creation of ecosystems. It is easy to visualize what those will be, like a medical ecosystem with biometric sensors of various types connected to one’s body and the cloud through smartphones. Another could be an automotive ecosystem that senses the location, speed, and direction of your car and other cars near you and reports that data to each other (V2V communications). One more automotive ecosystem could sense and control the systems inside a car, such as entertainment, information, and mechanical. Yet another would be mobile ecosystems that include wearable products that sense biometrics, interface with automotive and home entertainment systems, control home automation, perform electronic transactions, and a plethora of other functions. It is easy to envision a world where mobile handsets, tablets, glasses, watches, and other things that people wear or carry automatically interact with sensors and screens sprinkled throughout the environment. Some refer to the sensors spread all around as “sensor dust.” Now you can see why.

The irony is that by the time that the component pieces of the silicon stem cells differentiate into specific things, they cease being just things. And that means that the IoT starts to fade away, product by product.

To put this in a Dr. Seuss sort of way, “When a thing starts becoming something, it starts stopping being a thing.”

To be a leader in the post-IoT universe where things are not just things anymore, silicon providers must put all pieces in place and stimulate differentiation before the other guys do. It’s all about vision… but that is a topic for another day.

The robotic troika of Atmel summer interns in Trondheim

Troika: A Russian word for a group of three, and also a pretty good Norwegian chocolate bar.

It’s a safe assumption that most of us have had some sort of experience with summer jobs throughout our years as students. It’s also quite likely that some of us remember these jobs as full of sweat and manual work at a construction site, on a farm or in some kind of warehouse; however, not all summer jobs have to be this way. Today, I received a piece of mail from some of the summer interns at Atmel Trondheim, and from the sounds of it, they have some pretty cool things going on!

The Line Follower

A line follower is a machine equipped with some sort of light-sensitive sensors that follows a line — either a black line on a white surface or vica versa.

“This project utilizes two Light Dependent Resistors (LDRs) to detect the amount of reflected light from two Light Emitting Diodes (LEDs). The chassis is made of cardboard and the whole robot is made without any soldering. The idea behind this robot was to introduce some intelligence to a robot in an easy and inexpensive way,” explains Magne Normann, one of the summer interns at Atmel.

The Avoidance Robot

This is an obstacle avoidance-type robot based around the Atmel Abot. All that’s required to build this kind of robot is a platform, two motors/servos, some wires and a distance sensor. However, this particular project has got an additional servo. The ultrasonic sensor is mounted on a servo in front of the robot, and as the servo rotates, the sensor measures the distances in its envorionment and uses this information to choose a path between any obstacles.

The Atmel Tank

Have you ever seen one of those USB rocket launchers and wondered if they’re hackable? Well, they are.

“We got our hands on a USB missile launcher, disassembled it, did a reversed engineering and modified it. Then we added Bluetooth connectivity, put it on an Atmel Abot and made an app for it. The app does have both one and two-player modes; one player controls both the vehicle and the turret, and two-player mode where one player controls the car, while another controls the turret,” Magne shares.  

“Up until now the only way to interface with an USB rocket launcher had been through the complicated USB protocol. Unfortunately not many microcontrollers support this feature. We therefore decided to hack the rocket launcher down to the old school way, so we could control it with simple GPIOs. We opened the launcher up and discovered the unused footprint for a microcontroller. Apparently, initial design was based on using a microcontroller, but somewhere along the way someone decided to go with a die instead. This left the microcontroller pads unused and available for us to use. All we had to do was probe the signals for each command, disconnect the die from the circuit paths and solder our own wires to the microcontroller pads. This way we could use the existing H-bridges and switches without any additional hardware required.”

Magne notes that the tank is currently bringing havoc to the Atmel department located at Tiller, Norway. Interested in seeing it for yourself? The tank will be on display, along with several other Atmel-based projects, at Maker Faire Trondheim scheduled for August 29-30th. Maker Faire attendees will also have the opportunity to compete for the title of Maker Faire’s “Best Tank Commander.”

 

 

 

HackADay talks CryptoCape

The CryptoCape – which recently made its debut on SparkFun – is a dedicated security daughterboard for the BeagleBone designed in collaboration with Cryptotronix’s Josh Datko, which features Atmel’s Trusted Platform Module and SHA-256 Authenticator.

HackADay’s Brian Benchoff was lucky enough to catch up with Josh and asked him to break down how the nifty device works.

“If you need to add security to your project or you want to learn more about embedded security the CryptoCape adds encryption and authentication options,” the Maker added.

As its webpage notes, the CryptoCape functions as the BeagleBone’s first dedicated security daughterboard. Known as a BeagleBone Cape, the device attaches to the expansion headers of the BeagleBone and “adds specialized ICs that perform various cryptographic operations which will allow you to add a hardware security layer to your BeagleBone project.”

Previously discussed on Bits & Pieces, the CyrptoCape is packed with hardware, including 256k EEPROM with a defaulted I2C address (plus write protection), a real-time clock (RTC) module, a trusted platform module (TPM) for RSA encryption/decryption, an AES-128 encrypted EEPROM, an Atmel ATSHA204 authentication chip that performs SHA-256 and HMAC-25 and an Atmel ATECC108 that performs the Elliptic Curve Digital Signature Algorithm (ECDSA).

The reasoning behind the developer’s choice to use the SHA-256 Authenticator? “It creates 256-bit keys that can be used in keyed Message Authentication Codes (MACs), or HMAC, to prove the authenticity of the device.” In addition, the authenticator allows the device to “implement an anti-counterfeiting system with the exchange of nonces and MACs between other embedded devices.”

If you are interested in boosting the security of your Maker project or learning more about the CryptoCape, you can head to the product’s official SparkFun page here.

Designing IoT devices with Thingsquare and SAM R21

As we’ve previously discussed on Bits & Pieces, a number of recent Thingsquare demos have been powered by Atmel’s versatile SAM R21 Xplained PRO evaluation board – illustrating the seamless integration of Thingsquare’s software stack with Atmel’s new SAM R21 ultra-low power wireless microcontroller (MCU).

According to Atmel Product Marketing Director Magnus Pedersen, the SAM R21 allows Atmel’s customers to easily develop connected lighting, smart metering and wireless sensor network systems based on true Internet-connectivity and open standards such as IPv6 and 6lowpan.

“Our customers are demanding complete, easy-to-use IoT solutions that can quickly bring a full system to market,” said Pedersen. “Our cooperation with Thingsquare is an example of that, with a web-based toolchain and open source firmware to offer our customers a fully integrated hardware and software solution for various IoT applications.”

Recently, a Thingsquare rep told Bits & Pieces that a number of engineers and Makers are choosing the SAM R21 and the Thingsquare system to build secure and future-proof Internet of Things (IoT) applications and connected devices.

“The Thingsquare system and the SAM R21 SoCs follow you throughout the entire process from idea to market,” the rep explained. 

”The system supports IPv6 / 6lowpan, wireless mesh networking, firmware updates and end-to-end encryption. You can also easily build smartphone applications to interact with your SAM R21-powered devices.”

Interested in learning more? To quickly set up a prototype, you can use the Thingsquare system with SAM R21 Xplained Pro boards, as described here. Of course, Thingsquare can also help with your entire software project as well.

For additional information, contact sales@thingsquare.com. For hardware-related questions, contact Atmel.