There’s good news about BadUSB

The good news about the recently-revealed BadUSB is that there actually is a cure: Atmel CryptoAuthentication. Hardware crypto engines were invented to protect software, firmware and hardware from exactly these types of attacks, among many others. These uber-tiny, ultra secure hardware devices can be easily and cost-effectively added to USB sticks (and other peripherals) by manufacturers, who are seeking to protect their customers by ensuring that only the proper and intended code is downloaded and used. Once installed into the peripherals, CryptoAuthentication devices will block the bad code. Period.

Let’s look at what Bad USB has uncovered: It is that everything with a processor is vulnerable to attack. Most people don’t really think of a USB stick, modern thermostat, home router, fax machine, PC mouse or trackpad, a camera, iPod, microwave, and other “things” as being computers; however, they are. In fact, they all have at least one processor, memory, ways to get stuff in and out, and code (firmware) that tells the processor what to do. That last piece is where the danger lies.

As any PC or smartphone user knows, code gets updated all the time to get rid of bugs and add features. Updating code opens up a processor that was previously running good code, to code altered by people with mal-intent, i.e. malware. This is how good embedded systems go bad. We recently saw malware that allowed an ATM to spit out 40 bank notes at a time if a certain code was entered. Real nice for those who know the code!

BadUSB is Bad for More Than Just USB

All systems with processors are vulnerable to bad code, which can do bad things to good systems. All it takes is a way to transfer bad code from one processor to another… and, that happens all the time. USB sticks, USB accessories, the Internet, wireless links like Wi-Fi or Bluetooth — you name it — can be vectors for diseased code. What BadUSB has revealed to us is that all embedded systems, unless equipped with robust protection mechanisms, are now vulnerable to catching diseased code. (Embola?)

Embola

One contracted, a machine infected with Embola can send private and sensitive information to bad guys, or let them take over your system for ransom or other mal-purposes. They can turn on cameras and microphones to spy, grab your photos and bank account information, or even mess with your car. Whatever they want they can have, and you most likely will never know it.

By now you should see the point, which is that every embedded system and PC needs protection. Everything that runs software is vulnerable such as wearables, phones, USB accessories, USB sticks, cameras, cars, printers, thermostats, ATMs, meters, microwaves, appliances, and whatever the IoT will become. Simply put: If it has a processor and connects to something else, it is hackable.

So, what can you do to protect against Embola? The answer is twofold:

1. Don’t let the bad code in, and
2. If it does get in, don’t let it run.

While this sounds pedantically simplistic, these steps are NOT being taken. These two functions have the self-explanatory names of secure download and secure boot.

Secure Download

Secure download uses encryption to ensure that the code that is received by the embedded system is kept away from hackers. The code is encrypted using an algorithm such as Advanced Encryption Standard (AES) by using an encryption key. That encryption key is created using a secret that is only shared with the target system. The encrypted code is sent to the target embedded system to be decrypted and loaded for its use. Along with the encrypted code, a seed is also sent to the target system.

The seed is a number (typically unique with each session) that is hashed during the encryption session with a secure secret key. The result of that hashing is called the digest or Message Authentication Code (MAC) and it is used to encrypt the code (i.e. the MAC is the actual encryption key). The seed is sent to the target system to enable decryption, and not useful to anyone unless it is hashed with the secret key, which is what the target system will do. The target system runs the same hashing algorithm with the identical shared secret key stored there and the seed, which results in the same digest (MAC) that was used to encrypt the code. That MAC can now be used as the decryption key to decrypt the code. At this point, the decrypted code can be ran in the target embedded system.

However, there is another step that can be taken that adds even more security, which is authentication using a digital signature. To use authentication, the unencrypted original code is hashed and signed by the code originator at the same time as the original encryption process. The originator uses a signing key on that hash of the code to make a signature. That signature is sent with the encrypted code and seed to the target system. Once the encrypted code is decrypted using the process noted above, the newly decrypted code will be hashed by the target system, just like was done by the originator, and then signed with the signing key stored in the target system. That signing key is the same as on the originator’s signing module, so if the decrypted code has not been altered, the signature made on the digest of that decrypted code and the signing key will be exactly the same as the signature that was sent over. These two signatures are compared and if they match then the code has been authenticated and can be safely run on the target system. What does this mean? No risk of Embola!

The two levels or security provided by secure down load with authentication is obviously very robust. It will ensure that code that was received has been kept secret during transmission and has not been tampered.

Secure Boot

Secure boot also uses digital signatures to ensure that the code to be booted when the target system starts up matches the code that the manufacturer intended and has not been tampered with. It sort of works in a similar way as secure download. If the code to be booted has been altered, then the signature made by hashing the digest of that code with a secret signing key will not match the signature from the manufacturer. If they don’t match, the code will not load.

These methods are easy and inexpensive to implement and already exist. You should be able to see by now how Atmel has you covered. Ready, set, get secure!

 

Keeping time with a modded Etch-a-Sketch

Dodgey99 had never used stepper motors or real-time clocks before, but that didn’t stop this Maker from creating a really cool Etch-A-Sketch clock.

According to HackADay’s Kristina Panos, Dodgey99 originally employed two 5V stepper motors with ULN2003 drivers, but ultimately decided to upgrade to faster Nema17 motors driven by an ATmega328 powered kit.

“These [original] motors are mounted on the back and rotate the knobs via pulleys,” Panos explained.

“They are kind of slow; it takes about 2 1/2 minutes to draw the time, but the point of the hack is to watch the Etch-A-Sketch.”

Dodgey99 has already written three sketches for the clock: one to configure the RTC, a test hardware run to sample the look of the digits and the main code to replace the very first test sketch.

“The icing on this timekeeping cake is the acrylic base and mounting he’s fashioned,” said Panos.

“During his mounting trials, he learned a valuable lesson about drilling holes into an Etch-A-Sketch. You can’t shake an Etch-A-Sketch programmatically, so he rotates it with a Nema 17.”

Interested in learning more? You can check out the project’s official Instructables page here.

MQTT: M2M messaging for low-powered IoT devices

Message Queuing Telemetry Transport (MQTT) is a publish/subscribe messaging protocol for constrained, low-powered embedded Internet of Things devices. Think of it as the M2M (machine-to-machine) messaging protocol for low-bandwidth, high-latency, and unreliable network environments. This gives IoT developers a solid communication option when specifically working with embedded devices, which are expected to perform in “the wild,” while still needing to remain small, light, and have a high performance battery life.

Design and History Behind MQTT

MQTT was first developed in 1999, but has seen a massive explosion in growth and adoption with the surge of the Internet of Things. We now need a way to communicate, signal, and connect between low powered smart devices, and that’s where MQTT comes in. Built as a low-overhead protocol with strong considerations towards bandwidth and CPU limitations, MQTT has found its place in the embedded environment.

In terms of design, MQTT is a publish/subscribe M2M protocol for embedded devices. It enables clients to connect as a publisher, subscriber, or both, and connect to a broker that handles message passing. There is plenty of documentation and open source client implementations if you wish to dive further into the protocol itself.

The Core of MQTT is the Topic

The ‘topic’ is at the core of using MQTT as an M2M communication avenue for embedded devices. It’s a simple idea, and it’s not unique to MQTT. However, the MQTT protocol harnesses the ‘topic’ fairly well. The ‘topic’ does several things, it’s most important being to ensure that a message is delivered to the correct subscribers. MQTT treats the ‘topic’ as a file path. Overall, think of the ‘topic’ as a simple communication filter, which makes the path application very powerful.

topic = "user/path/topic"

You could be interested in a particular higher level of the path or the leaf element. Without explicitly saying so, MQTT filters messages based on where you subscribe in the tree path. A simple idea, that can be used very effectively.

Technical Specifications of MQTT

Looking a little deeper into the technical aspects of MQTT, the M2M protocol runs on the top of a TCP/IP networking stack. When a client connects for publish/subscribe, MQTT begins the handshaking process. The MQTT header is two bytes, and the first byte is constant. In the first byte, you specify the type of message being sent, as well as the QoS level, retain, and DUP flags. The second byte is the remaining length field. There is more information you can glean from the MQTT specification if you are interested.

Building MQTT on a Data Stream Network

With PubNub now supporting MQTT over our realtime, global data stream network, we wanted to give an overview of the protocol and why you might or might not use it from our perspective. We just went through some of the inner workings, features, and the value the protocol. We’ll now take a look at why you might want to use MQTT with PubNub, or PubNub native exclusively.

To utilize PubNub, our gateway is mqtt.pubnub.com and we’ll handle all the broker services and provide you access to our network. First, you publish to a topic (at PubNub we call them channels). Anyone who is subscribed to that topic will receive the message that was published.

If you want to read more and see a more in-depth tutorial, check out our blog post on using MQTT with the PubNub Data Stream Network here.

You may be wondering what the advantage is of using PubNub Native over MQTT?

from Pubnub import Pubnub
 
def callback(message, channel):
    print(message, channel)
 
pubnub = Pubnub('demo', 'demo')
pubnub.subscribe('my_channel', callback=callback)
- See more at: http://www.pubnub.com/blog/what-is-mqtt-use-cases/#sthash.Fm9tmkN5.dpuf

MQTT targets low-powered embedded device environments where resources are scarce. PubNub solves the problems of large-scale connectivity for realtime apps and IoT devices. If you’ve already deployed MQTT-based infrastructure, it makes sense to take advantage of this new PubNub gateway to facilitate scaling and maintenance of your embedded device connectivity layer.

If MQTT is not part of your current infrastructure, you might consider leveraging the PubNub Realtime Data Stream Network directly along with PubNub’s numerous IoT SDKs for all of your Internet of Things connectivity. To start, we provide over 50 client SDKs to use, extensive PubNub documentation and our blog where we showcase useful tutorials with open source code, demos, and other write ups on all things realtime technology.

MQTT does have many open source client implementations and documentation, and is a great publish/subscribe messaging protocol for low-powered devices. The protocol has a small footprint and has some great MQTT use cases.

import paho.mqtt.client as mqtt
 
def on_message(client, userdata, message):
print(msg.topic, str(msg.payload))
 
def on_connect(client, userdata, flags, rc):
client.subscribe('my_topic')
 
client = mqtt.Client()
client.on_message = on_message
client.on_connect = on_connect
client.connect('mqtt.pubnub.com', 1883)
client.loop_forever()

Arduino + MQTT = Two Peas in a Pod

There are several Arduino-MQTT implementations and resources available today, and the two go hand in hand for developers working on embedded device projects. As a user, if you are looking for a very small publish/subscribe protocol, MQTT may be for you. If you need more features, or need to scale to hundreds or thousands of connected devices, that’s where PubNub comes in. The transition from MQTT to PubNub in both code and ideology is a quick, exciting process.

Happy Hacking!

Vegard Wollan on the AVR and ARM cores and peripherals

In the fifth video of the series, I asked the co-inventor of the AVR microcontroller about the progression of the peripherals in the various microcontrollers Atmel offers. Vegard shares that when they invented the first AVR products, the team was concerned with ease-of-use, a clean instruction set that would run C, instructions that ran in a single cycle, and good quality tools.

However, he was just as proud of the peripherals that they then developed for the XMEGA line of AVR 8-bit chips. There, he said the stress was still on low power, but also a set of peripherals that were high performance, robust, strong, effective, and that included analog and digital advanced peripherals. Additionally, Vegard stressed how the XMEGA event system would allow programmers to handle complex events and take action, all without waking up the CPU core in the part.

Vegard Wollan becomes animated when talking about the peripherals in AVR and ARM chips offered by Atmel.

I knew this was cool for the low-power aspect, yet Vegard reminded me that it also allows you to service an interrupt faster and more deterministically — always a good thing in embedded systems. The great news for engineers is that all the cool things Atmel figured out for the XMEGA AVR also went into to the UC3, the 32-bit AVR product lines. Then, we made sure to put these same powerful and flexible peripheral systems into our ARM core-based MCUs. In addition we would add dedicated touch I/O pins and more accurate clocks and references. You can still see the AVR DNA from back in 1990 at the Norwegian University of Science and Technology where the AVR came to life.

What I really loved about Vegard was his humility. Every time I tried to give him credit for the AVR he was sure to remind me that there was a whole team that developed it. And, when I tried to point that the AVR was RISC (reduced instruction set computer) before ARM came out, he told me that he was more proud of the peripherals in all of Atmel’s chips, rather than just the core he invented for the AVR. That’s a good thing to keep in mind.

While using any ARM core will get you the instruction set and header files and open-source tools, Atmel’s ARM chips will also get these great peripherals and the event system to tie them all together, while the CPU sleeps peacefully. A recent article helped me understand Vegard’s Norwegian modesty, but I am sure glad he and his team worked on the AVR and ARM chips.

Vegard Wollan talks AVR chips and tools

While some of my earlier segments with Vegard explored the history of AVR, this video with its co-inventor addresses its product line and the tools one would use to write the firmware for the 8-bit chips.

Vegard touches on the availability of AVR chips in DIP (dual in-line) packages. These larger packages are loved by Makers and hobbyists since they are easy to prototype with. You can solder to the pins without a microscope and it is easy to make changes. They are also well-suited to installing in sockets, so you can replace them, or yank them out and program them in a separate programmer board.

Atmel still makes parts in the older DIP package, loved by hobbyists and Makers alike.

In the interview, Vegard refers to the ball grid array, commonly referred to as BGA by us acronym-loving tech people. BGAs are extremely small, just a little bigger than the silicon die itself. They also tend to transfer heat out of the die effectively, but that is rarely a factor in AVR chips since they are so low power. The headache with BGA chips is that you need an IR reflow oven to solder them on a board. Now, my buddy Wayne Yamaguchi has figured out a toaster oven will get the job done, just don’t toast any bread in it after you put a lead-soldered board into it.

Atmel parts in BGA packages are very small, but take special inspection and rework equipment.

The real headaches with BGA packages are rework and inspection. To replace the chip, you would need a camera mounted hot-air rework station from Metal/OKI; in order to make sure it is soldered correctly would require an X-ray machine (no, I am not kidding) to see that all the balls have sweated onto the pads under the chip. It helps to use gold-immersion finished circuit boards since they tend to be flatter than HASL (hot air solder-leveled) boards. However, if you are making some leading-edge tiny consumer product, all these prototyping and QC hassles are well worth it to get the smallest size possible.

To remove and resolder a BGA on your circuit board, you need to use a high-dollar camera equipped hot-air station like the Metcal Scorpion from Oki.

Vegard confirmed that Atmel uses the AVR 32-bit UC3 core in our touch controllers and mouse controller products. As you will see in the video above, we then went on to discuss Atmel’s legacy of providing really inexpensive demo boards and development tools.

Vegard Wollan smiles with pride as I show him an old demo board I used in 1999.

I also dragged out the actual AVR ICE 200 in-circuit emulator (ICE) I used in 1998, to design a point-of-sale terminal (note I misspeak in the video, calling it an STK200). The remarkable thing was this system would emulate an AVR chip in-circuit, and it only cost 200 dollars, back in an era when Intel Blue-Box 8051 systems were 50 grand.

Vegard Wollan really beams as I describe the 200-dollar Atmel AVR ICE 200, that got my startup off to a fast start in 2001.

To conclude the segment, Vegard Wollan shares how the Atmel Studio 6 integrated development environment is a high-quality software tool to develop your application, and works with AVR 8- and 32-bit parts as well as Atmel ARM-core microcontroller chips. When you add Atmel Gallery, Atmel Spaces, and the Atmel Software Framework (ASF), Atmel Studio becomes an integrated development platform (IDP). And, don’t forget you can get Atmel demo hardware through our distributors or the Atmel Store.

 

Hacking a 30-year-old printer back to life with megaAVR

Many engineers out there likely have an ever-increasing collection of old hardware that they promise to restore or use one day. Sound familiar? After coming across an old Radio Shack TRS-80 TP-10 thermal printer in one of his boxes of old gear, a Maker by the name of Danny Chouinard decided to give this vintage printer a brain transplant.

Back in 1984 the TP-10 was the crème de la crème. “It was relatively low cost at around $100 and was whisper-quiet,” Chouinard notes. As a result, the Maker had elected to keep it around hoping to get it in service one day.

Chouinard wanted to find new paper for the printer, however only had one half of a 30-year-old roll remaining. Cognizant of the fact that he would could go out and purchase thermal paper for fax machines, he soon realized that it would be too wide at 8.5 inches. Fortunately, the Maker was able to get his hands on a neighbor’s saw to trim the paper down to the right size. In fact, the new fax paper actually looked better than the old stuff!

To make this printer useful in the modern day, Chouinard wanted to increase the 32 characters per line limit and speed up the printing process a bit. First, he needed to understand exactly how the old printer worked. As Hackaday points out, if Chouinard was going to replace the CPU, he was going to need to know exactly how it functioned. He started by looking at the PCB to determine the various primary functions of the printer. He needed to know which functions were controlled by which CPU pins. After searching around, the Maker was able to locate an original manual for the machine, which also included the schematic for the circuit.

With that out of the way, the Maker decided to build a logic analyzer out of an Atmel ATmega664 and two static ram SPI chips. With a full investigation of the printer’s inner workings complete, Chouinard set out to finish his logic analyzer. Upon completion he tells, “It can sample 8 signals every 3 micro-seconds, 6 samples every 6, 24 every 10. With only 64KB it can fill its memory in about a fifth of a second, but can be tuned slower at run time.”

After some serious logging and exploration, Chouinard acquired a solid understanding of how the aging thermal printer operated. He knew he could increase the character limit with a full-fledged transplant of the printer’s brain. So, he repurposed another ATmega MCU and got the new firmware to crank out up to 80 characters a line — nearly double its original amount. And just like that, it is alive!

Chouinard has provided an incredibly detailed log of how he brought this printer up to modern speed on his website.

Vegard Wollan on AVR Freaks and early data books

In the fourth episode of my interview with Vegard Wollan, the co-inventor of the AVR MCU alluded to the passionate following that Atmel and its 8-bit chip have developed.

I can personally attest to this. When one of my pals said he was “going off the reservation” to solve an AVR problem, I thought he meant he was going to use a certain competitor’s microcontroller. Turns out, he was simply referring that he was headed to Atmel’s AVR Freaks forum to get an answer, rather than put in a support ticket or use our knowledge base. What delighted me was when he said, “I would rather jump off a bridge than use a [competitor] part.” Simple as that.

Atmel recently rolled out a redesigned site for the die-hard community, which incorporates both feedback and testing provided by the users themselves. Aside from the new look, the site will utilize a much more robust infrastructure and web technologies to provide users with an enhanced experience. (For those seeking an avid community built around the Atmel | SMART ARM-based products, you can check out AT91.com.)

What I loved about the interview is how Vegard explained it was his college experience that convinced him of the value of a strong user community. We all remember those 3:00am dorm sessions where we would discuss the meaning of life. Vegard noted that Atmel would provide servers and gifts and anything else we could do to support the user community.

The co-inventor also brought along a few copies of the first AVR data book. I was amused to see this post on the AVR Freaks forum, by a user that did not know what a “data book” was. Boy, that makes me feel old! See sonny, back when the Earth was still cooling and dinosaurs roamed the fields, engineers didn’t do everything at their fingertip on the intertube. Companies, much like Atmel, would take all their datasheets and bind them up in this thing called a printed book. I have to admit, it was a great day when I tossed my 500 pounds of databooks in the dumpster. Bless the Internet, it made life so much better.

Vegard Wollan holds up the draft version of the May 1995 AVR databook.

Of course, that draft was only a checkplot for the real book. The video also shows Vegard holding up the final version of the AVR databook that us old-timers so frequently depended on. How we would have killed for the modern microcontroller selector guide!

Here, Vegard Wollan holds up the actual printed data book from May 1995, the first release of the famous AVR microcontroller to the world. They had to make some changes so this databook has parts listed that Atmel never actually produced, and was missing some other parts. Those 4-months printed book lead times were a killer for everybody.

So there you have it, folks. With billions of chips in the wild, a following of over 290,000 AVR Freaks and nearly 100,000 forum posts around the topic annually, it’s safe to say we’ve come a long way since the earliest days of the 8-bit microcontroller. If you’re not already a member of the growing AVR Freaks community, be sure to head on over to the newly-updated site and join today!

Watch out for those snake robots!

Every engineer loves robots, it’s one of the few disciplines that mechanical, electrical, and software engineers all admire. There is a class of robots called snake robots due to their means of locomotion resembling the way a snake works. One such robot , Wheeko, was recently unveiled by the folks at NTNU, the Norwegian University of Science and Technology, the self-same place that Vegard Wollen, the inventor of the AVR microcontroller chip, attended before starting at Atmel.

Wheeko, a snake robot developed at the Norwegian University of Science and Technology.

When I asked a Norwegian co-worker if Wheeko might have Atmel microcontrollers in it, he was not sure about Wheeko, but pointed out and earlier robot at NTNU, the Anna Konda was run by eleven mega128 AVR chips.

The Anna Konda was intended as a fire-fighting robot that could crawl through burning or collapsed buildings. There are other applications as well, anywhere that a robot has to work in confined spaces.

So whether Wheeko goes to Mars or his little sister crawls through your veins, you can bet there will be a snake robot in your future.

SMART MCUs for low power, smarter designs in Internet of Things, wearables, and the Industrial Internet

According to analysts at ABI Research, over the next five years businesses will integrate into their wellness plans more than 13 million wearable devices with embedded wireless connectivity. Wearable tech also ties into the rapidly evolving Internet of Things (IoT), which refers to a future world where all types of electronic devices link to each other via the Internet. Today, it’s estimated there are nearly 10 billion devices in the world connected to the Internet, a figure expected to triple to nearly 30 billion devices by 2020. The inherent versatility of Atmel | SMART microcontrollers and Atmel radio chips have made our silicon a favorite of Makers and engineers.

Along with this setting stage, the design aspects for low power are becoming more and more important in the next embedded design products. Atmel is right in the middle of the industrial and wearable tech revolution, with a comprehensive portfolio of versatile microcontrollers (MCUs) that power a wide range of platforms and devices.

Blood glucose meters, sport watches, game controllers and accessories, guess what they are all in common? In fact, many of these today are going to shift and evolve into new form factors and application use case as connectivity and clever interacting interfaces become designed. Yes, like a lot of other industrial and consumer devices, they are all battery powered and demanding a long or extended battery life. Translating it into an engineer’s challenge designing an embedded computing system, you will need a central heart, in this case a microcontroller, consuming as low power as possible in both active and static modes without sacrificing the performance. And, Atmel SMART | ARM Cortex-M4 based SAM4L series is designed with this in mind.

The SAM4L microcontrollers redefine the low power, delivering the lowest power in the same class in active mode (90uZ/MHz) as well as static mode with full RAM retention running and with the shortest wake-up time (1.5us). And they are the most efficient microcontrollers available today, achieving up to 28 CoreMark/mA. In this video, you’ll get an overview of Atmel | SMART SAM4L low-power microcontrollers (MCU), based on the ARM Cortex-M4 core. SAM4L MCUs operate at 90uA/MHz and achieve an efficiency rating of 28 CoreMark/mA. The devices feature an array of power-saving technologies, including Atmel’s proprietary picoPower technology. You’ll see a demo using the SAM4L-EK evaluation kit.

The SAM4L series integrates Atmel’s proprietary picoPower technology, which ensures the devices are developed from the ground up, from transistor design to clocking options, to consume as little power as possible. In addition, Atmel’s SleepWalking technology allows the peripherals to make intelligent decisions and wake up the system upon qualifying events at the peripheral level.

In this video, you will see how SAM4L microcontrollers support multiple power configurations to allow the engineer to optimize its power consumption in different use cases. You will also see another good feature of the SAM4L series, power scaling, which is a technique to adjust the internal regulator output voltage to further reduce power consumption provided by the integrated backup power manager module. Additionally, the SAM4L series comes with 2 regulators options to supply system power based on the application requirement. While the buck/switching regulator delivers much higher efficiency and is operational from 2 to 3.6V, the linear regulator has higher noise immunity and operates from 1.68 to 3.6V.

It’s all about system intelligence and conserving energy. Simply put, the SAM4L microcontroller (See SAM4L Starter Kit) is your choice if you are designing a product with long battery life but without sacrificing the performance — as demonstrated in this walkthrough of the Xplained Pro SAM4L Starter Kit.

The SAM4LC Cortex-M4 processor-based Flash microcontrollers offer the industry’s lowest power consumption and fastest wake-up. On top of what’s mentioned, this sub family of Atmel | SMART microcontrollers [labeled as ATASAM4L] devices are ideal for a wide range of industrial, healthcare and consumer applications.

Get a jump-start on your design with dedicated evaluation kits and software packages.  You can also easily catch up on some of the recent and past articles we posted related to Atmel | SMART SAM4L Microcontrollers.

RF Modules: A low risk path to wireless success

It is rare for a day to go by without having at least one conversation with an embedded developer, project manager, Maker / hacker or hobbyist where the subject of the Internet of Things (IoT) and/or wireless connectivity does not come up in discussion.

Today, IoT is certainly a major focus in product development and wireless is a major component of that solution. Usually, my conversation centers around comments from product developers regarding how difficult it is to develop a production ready wireless product on the first pass; it is especially difficult for the growing number of product developers or Makers that are just getting their feet wet in wireless design and development.

Only the very experienced RF designers are willing to start from scratch when beginning a new wireless product design. For the rest of us, we look for proven reference designs and more recently, the first thing we browse for is an off-the-shelf certified module.

In comes Atmel! The company has recognized for a while that RF modules provide a low risk path to success, for those seeking to add wireless connectivity to their product. And, it is this realization that has led to a growing family of RF modules to meet one’s wireless needs in Wi-Fi, 802.15.4, and BLE coming soon.

The certified wireless module approach turns a complicated RF design task into an easier, more manageable digital peripheral interface task. Don’t misunderstand me, one still must be careful and adhere to best practices in your embedded PCB design to support an RF module; however, it is a much easier to be successful on the first go-around when using an RF module than it would be starting from a chipset or IC layout and design.

A typical wireless module with on board “chip” antenna (white rectangle shown in image).

For the most part, the layout of impedance controlled traces, and antenna layout and matching are all taken care of for you when using a module. Usually, the most difficult thing you have to consider is placement of the module on your target or carrier board, such that your placement does not adversely affect the radiation pattern or tuning of the antenna.

Not only does the design become simpler, but the costs associated with getting a wireless device to market becomes lower.  Because in general, all of the fees and time associated with governmental certification testing for agencies like the FCC, CE and IC (Industry Canada), are already taken care of for you. Also in most cases, the modules are shipped with a unique IEEE MAC address pre-programmed into the module’s non-volatile memory, so that each unit has a world wide unique address. By using a module that contains this pre-programmed assigned address, you can avoid the costs of obtaining a block of IEEE addresses assigned to your company.

At first glance, the cost of using a complete pre-certified RF module in a production design, as compared to implementing one’s own chip set design may appear more expensive. However, for those doing this for the first time with a staff that does not have a lot of RF design and certification experience, the hidden costs and time required to achieve the performance your application requires and to get the product into the market, leads to a lot of unwanted surprises requiring multiple attempts to achieve the final goal. Starting with a module helps get the product into the market faster with less risk, and provides a way to get product acceptance, before having to deal with cost reduction activity’s that may require moving from a module solution to a chip set solution.

For those that get to the position where the use of a pre-certified module on a proven product requires a cost reduction, Atmel has a solution ready for you. Each of the Atmel Zigbit modules have complete Altium design files and Gerber files available for free download via the Atmel website. This will enable you to take the exact design files that were used to create the module you were using or considering, and to use these files to devise your own version of that design. You can then have your new chip based layout manufactured by your own contract manufacturer; thus, you do not have to start over from the beginning and you already know that this RF design works well and can be easily certified. Governmental certification of your own board layout would be required, and in the case of the United States, you would be given your own FCC ID assigned to your company for this product.

For those product designers that are experienced in RF layout and design, a module can allow you to create a proof-of-concept product prototype very quickly and with little effort. Once the concepts have been proven and features have been decided upon, you can migrate from module to chip set design for high volume production.

Software developers, Makers, and hobbyists can eliminate a lot of the issues often found when trying to create low volume wireless products by obtaining one of the many Atmel evaluation boards that contain a wireless module.

These boards typically come with a bootloader and with some form of pre-loaded firmware to get you started immediately. You can explore that topic in more detail in an earlier Bits & Pieces post that describes the wireless composer and the Performance Analyzer firmware.

The Performance Analyzer firmware is what typically comes pre-installed on a Zigbit module “evaluation” board. Otherwise, the module itself would come with only a pre-programmed bootloader.

You can learn more and download user guides / datasheets for the Atmel Zigbit modules via this link.

With the Internet of Things becoming such a focus at this time, you may want to get started with a pair of low-cost wireless module evaluation boards and use this platform to learn wireless connectivity techniques that can be used in your current or future job.  Demand for those with knowledge and experience in wireless connectivity and embedded systems is growing greater everyday.

Whether you’re a Maker or an engineer that wants to create a home project that requires a microcontroller and some type of wireless connectivity, you might want to take a look at the ATZB-256RFR2-XPRO evaluation board that includes the ATZB-S1-256-3-0-C module already mounted on it. This module is based upon the megaAVR microcontroller core and includes an 802.15.4 2.4ghz radio as a peripheral/.You may recognize the megaAVR core as being the same MCU core as used in the well-known and incredibly popular Arduino Uno board. You can use the familiar Arduino IDE for development and many of the Arduino libraries available on the internet will run directly on this module. Additionally, you can also find a bootloader and sample Lwmesh (Light Weight Mesh wireless networking) applications for this module here. (Search for for “ATmega256RFR2 Arduino Solution.”)

Look to our friends at Adafruit and Sparkfun to obtain various sensor breakout boards to complete your wireless connectivity projects.

Do you have big ideas? You can feel confident that with the 256k of flash program memory and the 32k of data sram available with the ATZB-S1-256-3-0-C module, as you will be able to create any Arduino application that comes to mind. And don’t forget, you have an onboard 802.15.4 2.4Ghz radio for your wireless connectivity needs. If you find you need additional features in your development and debug tools, you can simply move to Atmel Studio with its rich set of features.

Calling all Radio Amateurs CQ CQ CQ de NS1C… 

Are you now, or have you been in the past, involved in Amateur Radio? Have you been dreaming about QRP low power radios that are very small, battery operated, a complete radio solution, and cost in the $29 to $39 dollar range? You’re in luck — boards and modules are available that operate in the 915mhz or 2.4ghz radio bands! As a HAM radio operator, you are allowed to take the capabilities of these 802.15.4 radio modules even further than an engineer who is required to create a license free ISM radio solution. You can experiment with additional RF output power and experiment with high gain directional antennas (use the modules with u.FL RF connectors).

Maybe a nice field day project for next year would be to use a low power 15.4 radio from the top of a mountain or high hill and use mesh networking to see how many hops a group of participants can communicate over. Voice communication certainly could be implemented using external analog circuitry and some additional software; however, when getting started, you could stick to digital data communications or use the wireless microcontrollers to control or monitor other components of your Amateur radio station.

Parents teach your children…. or maybe, children teach your parents!

I am sure that everyone can think of many home or science fair projects where a parent and child can work together (hardware / software / documentation) and everyone can learn something new. Heck, in the end, you may actually invent the next great product that your family can introduce to the world!

Your possibilities are endless.