The Internet of Things (IoT) is everywhere. Industry 4.0 is becoming serious and many companies develop hardware and software solutions. Relayr is a company with an interesting focus on the IoT and bringing industry to the cloud. Wissa Hettinga interviewed Jaime Gonzalez-Arintero Berciano, a Relayr developer and product evangelist, about the company, its technology, and future of innovation in the IoT space.
Wireless communications have revolutionized virtually every industry, from healthcare to defense to consumer electronics. We recently asked 10 engineers to prognosticate on the future of wireless technology. France-based engineer Robert Lacoste writes:
I don’t know if the forecasts about the Internet of Things (IoT) are realistic (some analysts predict from 20 to 100 billion devices in the next five years), but I’m sure it will be a huge market. And 99% of IoT products are and will be wireless. Currently, the vast majority of “things” connect to the Internet through a user’s smartphone, used as a gateway typically through a Bluetooth Smart link. Other devices (e.g., home control or smart metering) require the installation of a dedicated fixed RF-to-Internet gateway, using ZigBee, 6lowPan, or something similar. But the next big thing will be the availability of “connect anywhere” solutions, through low-power wide area networks, nicknamed LPWA. Even if the underlying technology is not actually new (i.e., using very low bit rates to achieve long range at low powers), the contenders are numerous: LORA Alliance, INGENU, SIGFOX, WEIGHTLESS, and a couple of others. At the same time, the traditional telcos are developing very similar solutions using cellular bands and variants of the 3GPP protocols. EC-GSM, LTE-MTC, and NB-IOT are the most discussed alternatives. So, the first big question is this: Which one (or ones, as a one-size-fits-all solution is unlikely) will be the winner? The second big question has to do with whether or not IoT products will be useful for society. But that’s another story! — Robert Lacoste, France (Founder, Alciom; Columnist, Circuit Cellar)
Silicon Labs recently introduced two new EFM32 Gecko microcontroller (MCU) families that feature advanced security and energy-management technologies. The Jade Gecko and Pearl Gecko MCUs combine a hardware cryptography engine, flexible low-energy modes, an on-chip DC-DC converter, and scalable memory options backed by Silicon Labs’s Simplicity Studio tools. The MCUs target an array of energy-sensitive and battery-powered devices, such as wearables and IoT node applications.
Jade and Pearl Gecko MCUs are meant to equip IoT-connected devices with the latest security technologies to thwart hackers. They feature a hardware cryptography engine providing fast, energy-efficient, autonomous encryption and decryption for Internet security protocols (e.g., TLS/SSL) with minimal CPU intervention. The on-chip crypto-accelerator supports advanced algorithms such as AES with 128- or 256-bit keys, elliptical curve cryptography (ECC), SHA-1, and SHA-224/256. Hardware cryptography enables developers to meet evolving IoT security requirements more efficiently than with conventional software-only techniques often required by competing MCUs.
Based respectively on ARM Cortex-M3 and M4 cores, Jade and Pearl Gecko MCUs provide ample performance for connected devices while enabling developers to optimize battery life or use smaller batteries for space-constrained designs. The new MCUs feature an enhanced peripheral reflex system (PRS) that lets low-power peripherals operate autonomously while the MCU core sleeps, allowing connected devices to sleep longer, thus extending battery life. Energy-saving low active-mode current (63 µA/MHz) enables computationally intensive tasks to execute faster. Low sleep-mode current (1.4 µA down to 30 nA) and ultra-fast wake-up/sleep transitions further minimize energy consumption.
Jade and Pearl Gecko MCUs also integrate a high-efficiency DC-DC buck converter. Offering a total current capacity of 200 mA, the on-chip converter can provide a power rail for other system components in addition to powering the MCU. This power management innovation reduces BOM cost and board area by eliminating the need for an external DC-DC converter.
Engineering samples of EFM32JG Jade Gecko and EFM32PG Pearl Gecko MCUs are available now in 5 mm × 5 mm QFN32 and 7 mm × 7 mm QFN48 packages. Production quantities are planned for Q2 2016. Jade Gecko pricing begins at $1.24 in 10,000-unit quantities. The Pearl Gecko pricing begins at $1.65 in 10,000-unit quantities. The SLSTK3401A EFM32PG Pearl Gecko Starter Kit costs $29.99.
Source: Silicon Labs
In the multipart article series, “The Internet of Things,” Bob Japenga details how to connect simple devices wirelessly to the Internet. This month, he covers at the requirements for, the cost of, and some of the problems with cell modem certification for embedded systems.
Almost every month, I get a call from some budding new entrepreneur with a great idea for an Internet of Things (IoT) product. Before we get too far along in the conversation, I ask the question: “What is your budget for cell modem certification?” More often than not, the answer is: “What is that and how much does it cost?” This month I would like to address these two questions as well as address the major issues we have had in cell certification. As always, this is a big topic that we cover in thin slices.
What are the requirements?
All cell modems are required to be certified by cell carriers prior to sale to customers like you and me. However, just because the cell modem is certified for a particular carrier, you are still required to certify the device that incorporates this modem. This makes sense for a lot of the certification requirements. For example, just because the cell modem has an acceptable receiver sensitivity and good robust transmit power, it doesn’t mean that your design has met these requirements. This necessitates that you separately test your device to the carrier’s requirements. The only exception to this is when the cell modem is self-contained and not an integral part of your design. For purposes of brevity, I will only cover the requirements for North America. Nor will I go over definitions defined in previous articles in this series.
If your IoT device is going to use AT&T (3G or 4G), you will be required to pass PTCRB and AT&T certification testing. PTCRB (an obsolete acronym that used to stand for PCS Type Certification Review Board) is an independent certification agency used by some North American cell carriers, including AT&T. Testing to the PTCRB standard is done by a third-party independent test lab. You, the designer, are responsible to contract with one of these independent test labs. Cetecom (www.cetecom.com) and 7Layers (http://7layers.com) are two such labs that we have worked with.
After you have passed the PTCRB tests, you need to obtain AT&T approval. Once scheduled, PTCRB testing will take three to four weeks. AT&T approval takes another one to two weeks. The lab costs depend on the particular test lab, but it will cost between $20,000 to $40,000 for GSM modems and $60,000 to $70,000 for LTE modems.
The process of certification for Verizon 3G (CDMA) and 4G (LTE) is done directly through Verizon. This testing can be done through an independent lab or through Verizon. Verizon recommends that you pre-certify your product through its Innovation Center. There you can work with Verizon test engineers and technicians to make sure your design is ready for prime time before you go to certification. Verizon provides this service to qualified companies.
Once you have pre-certified, then you can contract with an outside independent certification lab (e.g., Cetecom, 7Layers, and Intertek). The cost for a CDMA certification will be $15,000 to $20,000 while the LTE certification can cost as much as $70,000. Once scheduled, the pre-certification timeframe is about two to three weeks with another three to four weeks for certification once it is scheduled.
If you are deploying a GSM modem on the Aeris network in North America, you will require PTCRB certification as well as Aeris certification. The cost and schedule are the same as I described earlier. If you are deploying a CDMA solution, you only require Aeris certification (which has the least stringent requirements of all the carriers, is free and takes a week or two). Aeris also allows you to self-certify for small volumes of installations.
Let’s summarize the technical requirements for certification and our experience with these.
Total Isotropic Sensitivity (TIS): All carriers for all radio access technologies require a minimum receiver sensitivity. Basically, this test determines how weak a signal from the cell tower your device can respond to. This is one of the situations where certification is your friend—not your enemy. You don’t want to deploy your great new idea and have a lot of “Can you hear me now?” problems.
There are three primary ways that we have improved our TIS. First you must make your device whisper quiet in terms of radiated emissions in and around the receiver frequencies. If you thought meeting FCC Class B EMC requirements were tough, your requirements for making your device whisper quiet to meet the TIS requirements are much more stringent. I’ll talk more about this when I discuss EMC requirements.
Next is your choice of antenna. We have been unsuccessful meeting TIS requirements without using antennas significantly larger than used in our cell phones. We have often wondered how all of our cell phones met the TIS requirements with their very small antennas. I will leave it to your research and your imagination as to how cell phones are passing the cell carriers TIS requirements with such small antennas. In the words of Deep Throat, “Follow the money!”
Finally, your antenna should be placed as far away from any metal as possible and should have a nonmetallic path to the outside world. One product we had was mounted in a large metal base mounted to an outside wall that shadowed the entire hemisphere behind the product. PTCRB testing of this product required it to meet the TIS requirements completely and evenly around the sphere. We could not get the test lab to relax this 360° requirement. Instead we removed the product from its real world enclosure and performed the testing in a nonrealistic environment. This seemed ludicrous to us since we wanted to test it in the real world enclosure. This resulted in uncertainty on our part once the product passed certification. We were not certain how it would work in the real world when it had this metal box shadowing the back hemisphere. Thankfully, we have deployed more than 50,000 of these with no TIS problems.
Total Radiated Power (TRP): As with TIS, certification testing is your friend concerning TRP. The carriers have similar stringent requirements for TRP. Here your design must carefully place and tune your antenna to obtain the maximum TRP. A little bit of movement of the antenna can make a significant improvement or degradation of your radiated performance.
Another critical requirement for your design is that your power supplies must be capable of instantaneously delivering 1 to 2 A of power when a transmission takes place. Cell modems have one of the more demanding power supply requirements that we have worked with.
One design flaw we saw in one design was having the ground plane under the u.fl connector going to the external antenna. This ground plane was absorbing a significant amount of both outgoing (TRP) and incoming radiation (TIS). Your antenna connector must not be near either the ground or power plane.
Electromagnetic Compatibility/Electromagnetic Interference (EMC/EMI): We did a preliminary EMC scan on our first IoT cell modem design and were very happy that we met FCC Class B requirements for radiated spurious emissions (EMI) with flying colors. What we didn’t know was that PTCRB had its own idle mode radiated spurious emissions requirements which were far more stringent than FCC Class B. Initially, we were not even close to meeting these PTCRB requirements. We hired an RF expert to help us. His first suggestion was for us to rip apart an old cell phone and tell him what we saw. When we did this, we saw that the entire circuit board was covered with EMI shield cans (see Photo 1). “That’s what you need to do with your design.” So, after designing the circuit with all of the EMI suppression techniques and good layout practices that we knew, we still needed to populate the board with five shield cans.
Data Retry: If you were a carrier, you would not want to have devices tie up band width with incessant retries. So each carrier has its own unique retry requirements. Some of this retry logic is handled by your cell modem (retries connecting to the cell tower). But in addition, your application software must meet the retry requirements of each carrier. Generally, we are designing systems that use less than 1 MB of data every month so we don’t want too many retries at the application level either.
Data Throughput: Remembering that carriers are trying to get as much data through as quickly as possible, each carrier has data throughput requirements for some radio access technologies. This requirement is strictly a function of your cell modem chip. Since your chip is already certified for the particular carrier, it has already passed these tests. Unfortunately, some carriers require you to retest many of these requirements that have absolutely no bearing on your design unless you have modified the cell modem chip (which you can do). It is understandable that the carriers need to protect their network from rogue devices but I feel very strongly that they need to simplify this area of certification. So chip makers, carriers, and PTCRB board, if you are listening, isn’t there a better way to detect if we have modified the chip’s operation? For example, if there was a flag in the chip that indicated that the radio parameters have been altered in such a way that the carrier/PTCRB certification has been compromised, certification could be made much simpler.
A lot of these tests are very complicated and are being performed to moving standards. We were certifying one product that was failing tests that had nothing to do with our design—only with the cell modem chip. What it boiled down to was this: The chip was tested and passed Version A certification requirements. More stringent requirements were created later (Version B) which our modem failed. Since we were only required to pass Version A requirements, we should have been able to re-run the tests to Version A. The problem was that the certification lab did not have test equipment that ran Version A tests! Hopefully you see the problem. I strongly think this must change as it wastes a lot of time and money in the certification process. We have wasted several months trying to get this device ready for sale.
In 2010, I was at a football game with my grandsons and 103,000 other people. One of my grandsons was not able to make the game, so I wanted to send him a text at kickoff. Even though I had maximum signal strength, I could not make the call. When I looked around the stadium, it was clear that many wanted to text or call at the same time. Cell phones must work in close proximity to other cell phones. Most M2M devices do not have that requirement. PTCRB certification requires that your device not be transmitting on any frequencies other than the frequency you are licensed to transmit on so as to avoid interfering with nearby cell phones. The first device we took through PTCRB testing failed these tests at a couple of points. What we discovered was that every diode in your design acts as a re-radiator of the radio signal you are transmitting. And it radiates at one of the harmonics of the transmit frequency. This must be squelched or you will fail your Harmonic Radiated Spurious Emissions (RSE) tests.
Even after doing another spin of the board with small capacitors around every diode, we were still failing Harmonic RSE at a couple of frequencies by a few decibels. The product was already several months late. Should we do another spin of the board after we find the diode we missed? At this point, I pushed through a waiver. This was a formal request to the PTCRB board for an exception to the requirements. Our unit was stationary. Our unit did not operate in the presence of other cell phones. Come on, we are talking about only 2 db! Thankfully and quickly, the waiver got approved. We had our first cell modem-based IoT device ready to ship. So the moral of the story is: Work with the certifying agency. Some requirements that apply to cell phones do not apply to M2M products. Sometimes the certification process is our friend but a lot of time it is just a pain in the neck.
You have a good IoT idea that will make this world a better place. But before you bring it to fruition, you will need to pass the necessary certification tests imposed on you by the cell network carriers. This article gives you a thin slice as to what’s involved and what it will cost.
This article appears in Circuit Cellar 305, 2015.
Dialog Semiconductor recently announced its support for WeChat’s communications protocol with the launch of its WeChat SDK. With the kit, you can quickly add Bluetooth connectivity between WeChat apps and wearables and other IoT devices. Dialog’s development kit is available now and includes a protocol stack for the WeChat communication layer. The SDK—which is based on the DA1458x family of SmartBond SoCs—enables you to reduce the overall development time for connecting their products wirelessly to WeChat apps. Your users can control wearable devices via the app and share information via the platform.
DA1458x SoCs combine a Bluetooth low-energy radio with an ARM Cortex-M0 application processor. With intelligent power management circuitry and accessible processor resources via 32 GPIOs,you can build fully hosted applications.
The SmartBond WeChat SDK enables efficient coding and comes with SmartSnippets software development environment, which is based on Keil µVision tools.
Source: Dialog Semiconductor
Rich Legrand founded Charmed Labs in 2002 to develop and sell innovative robotics-related designs, including the Xport Robot Kit, the Qwerk robot controller, the GigaPan robotic camera mount, and the Pixy vision sensor. He recently told us about his background, passion for robotics, and interest in open-source hardware.
RICH: Back in 1982 when I was 12, one of my older brother’s friends was what they called a “whiz kid.” I would show up uninvited at his place because he was always creating something new, and he didn’t treat me like a snotty-nosed kid (which I was). On one particular afternoon he had disassembled a Big Trak toy (remember those?) and connected it to his Atari 800, so the Atari could control its movements. He wrote a simple BASIC program to read the joystick movements and translate them to Big Trak movements. You could then hit the return key and the Atari would play back the motions you just made. There were relays clicking and LEDs flashing, and the Big Trak did exactly what you told it to do. I had never seen a computer do this before, and I was absolutely amazed. I wanted to learn as much as I could about electronics after that. And I’m still learning, of course.
CIRCUIT CELLAR: You studied electrical engineering at both Rice University and North Carolina State University. Why electrical engineering?
RICH: I think it goes back to when I was 12 and trying to learn more about robotics. With a limited budget, it was largely a question of what I get my hands on. Back then you could go into Radio Shack and buy a handful of 7400 series parts and create something simple, but pretty amazing. Forrest Mims’s books (also available at Radio Shack) were full of inspiring circuit designs. And Steve Ciarcia’s “Circuit Cellar” column in Byte magazine focused on seat-of-the-pants electronics projects you could build yourself. The only tools you needed were a soldering iron, a voltmeter, and a logic probe. I think young people today see a similar landscape where it’s easier to get involved in electrical engineering than say mechanical engineering (although 3-D printing might change this). The Internet is full of source material and the hardware (computers, microcontrollers, power supplies, etc.) is lower-cost and easier to find. The Arduino is a good example of this. It has its own ecosystem from which you can launch practically any project or idea.
CIRCUIT CELLAR: Photography factors in a lot of your work and work history. Is photography a passion of yours?
RICH: I don’t think so, but I enjoy photography. Image processing, image understanding, machine vision—the idea that you can extract useful information from a digital image with a piece of software, an algorithm. It’s a cool idea to me because you can have multiple vision algorithms and effectively have several sensors in one package. Or in the case of Gigapan, being able to create a gigapixel imager from a fairly low-cost point-and-shoot camera, some motors, and customized photo stitching software. I’m a hardware guy at heart, but hardware tends to be expensive. Combining inexpensive hardware with software to create something that’s lower-cost—it sounds like a pretty niche idea, but these are the projects that I seem to fall for over and over again. Working on these projects is what I really enjoy.
CIRCUIT CELLAR: Prior to your current gig at Charmed Labs, you were with Gigapan Systems, which you co-founded. Tell us about how you came to launch Gigapan.
RICH: Gigapan is robotic camera mount that allows practically anyone with a digital camera to make high-resolution panoramas. The basic idea is that you take a camera with high resolution but narrow field-of-view (high-zoom) to capture a mosaic of pictures that can be later stitched together with software to form a much larger, highly-detailed panorama of the subject, whether it’s the Grand Canyon or the cockpit of the Space Shuttle. This technique is used by the Mars rovers, so it’s not surprising that a NASA engineer (Randy Sargent) first conceived Gigapan. Charmed Labs got a chance to bid on the hardware, and we designed and manufactured the first Gigapan units as part of a public beta program. (The beta was funded by Carnegie Mellon University through donations from NASA and Google.) The beta garnered enough attention to get investors and start a company to focus on Gigapan, which we did. We were on CNN, we were mentioned on Jay Leno. It was a fun and exciting time!
CIRCUIT CELLAR: In a 2004 article, “Closed-Loop Motion Control for Mobile Robotics“ (Circuit Cellar 169), you introduced us to your first product, the Xport. How did you come to design the Xport?
RICH: When the Gameboy Advance was announced back in 1999, I thought it was a perfect robot platform. It had a color LCD and a powerful 32-bit processor, it was optimized for battery power, and it was low-cost. The pitch went something like: “For $40 you can buy a cartridge for your Gameboy that allows you to play a game. For $99 you can buy a cartridge with motors and sensors that turns your Gameboy into a robot.” So the Gameboy becomes the “brains” of the robot if you will. I didn’t know what the robot would do exactly, other than be cool and robot-like, and I didn’t know how to land a consumer electronics product on the shelves of Toys “R” Us, so I tackled some of the bigger technical problems instead, like how to turn the Gameboy into an embedded system with the required I/O for robotics. I ordered a Gameboy from Japan through eBay prior to the US release and reverse-engineered the cartridge port. The first “Xport” prototype was working not long after the first Gameboys showed up in US stores, so that was pretty cool. It was a simple circuit board that plugged into the Gamboy’s cartridge port. It had flash for program storage and an FPGA for programmable I/O. The Xport seemed like an interesting product by itself, so I decided to sell it. I quit my job as a software engineer and started Charmed Labs.
CIRCUIT CELLAR: Tell us about the Xport Botball Controller (XBC).
RICH: The Xport turned the Gameboy into an embedded system with lots of I/O, but my real goal was to make a robot. So I added more electronics around the Xport for motor control, sensor inputs, a simple vision system, even Bluetooth. I sold it online for a while before the folks at Botball expressed interest in using it for their robot competition, which is geared for middle school and high school students. Building a robot out of a Gameboy was a compelling idea, especially for kids, and tens of thousands of students used the XBC to learn about engineering—that was really great. I never got the Gameboy robot on the shelves of Toys “R” Us, but it was a really happy ending to the project.
CIRCUIT CELLAR: Charmed Labs collaborated with the Carnegie Mellon CREATE Lab on the Qwerk robot controller. How did you end up collaborating with CMU?
RICH: I met Illah Nourbakhsh who runs the CREATE lab at a robot competition back when he was a grad student. His lab’s Telepresence Robotics Kit (TeRK) was created in part to address the falling rate of computer science graduates in the US. The idea was to create a curriculum that featured robotics to help attract more students to the field. Qwerk was an embedded Linux system that allowed you make a telepresence robot easily. You could literally plug in some motors, a webcam, and a battery, and fire up a web browser and become “telepresent” through the robot. We designed and manufactured Qwerk for a couple years before we licensed it.
CIRCUIT CELLAR: Pixy is a cool vision sensor for robotics that you can teach to track objects. What was the impetus for that design?
RICH: Pixy is actually the fifth version of the CMUcam. The first CMUcam was invented at Carnegie Mellon by Anthony Rowe back in 2000 when he was a graduate student. I got involved on a bit of a lark. NXP Semiconductors had just announced a processor that looked like an good fit for a low-cost vision sensor, so I sent Anthony a heads-up, that’s all. He was looking for someone to help with the next version of CMUcam, so it was a happy coincidence.
CIRCUIT CELLAR: You launched Pixy in 2013 on Kickstarter. Would you recommend Kickstarter to Circuit Cellar readers who are thinking of launching a hardware product?
RICH: Before crowdfunding was a thing, you either had to self-fund or convince a few investors to contribute a decent amount of cash based on the premise that you had a good idea. And the investors typically didn’t have your background or perspective, so it was usually a difficult sell. With crowdfunding, a couple hundred people with similar backgrounds and perspectives contribute $50 (or so) in exchange for becoming the very first customers. It’s an easier path I think, and it’s a great fit for products like Pixy that have a limited but enthusiastic audience. I think of crowdfunding as a cost-effective marketing strategy. Sites like Kickstarter get huge amounts of traffic, and getting your idea in front of such a large audience is usually expensive—cost-prohibitive in my case. It also answers two important questions for hardware makers: Are enough people interested in this thing to make it worthwhile? And if it is worthwhile, how many should I make?
But I really didn’t think many people would be interested in a vision sensor for hobbyist robotics, so when faced with the task of creating a Kickstarter for Pixy, I thought of lots of excuses not to move forward with it. Case in point—if your Kickstarter campaign fails, it’s public Internet knowledge. (Yikes!) But I’m always telling my boys that you learn more from your mistakes than from your successes, so it seemed pretty lame that I was dragging my heals on the Kickstarter thing because I wanted to avoid potential embarrassment. I eventually got the campaign launched, and it was a success, and Pixy got a chance to see the light of day, so that was good. It was a lot of work, and it was psychologically exhausting, but it was really fun to see folks excited about your idea. I’d totally do it again though, and I’d like to crowdfund my next project.
CIRCUIT CELLAR: Can you tell us about one or two of the more interesting projects you’ve seen featuring Pixy?
RICH: Ben Heck used Pixy in a couple of his episodes of the Ben Heck Show (www.element14.com/community/community/experts/benheck). He used Pixy to create a camera that can automatically track what he’s filming. And Microsoft used Pixy for an Windows 10 demo that played air hockey IR-Lock (www.irlock.com) is a small company that launched a successful Kickstarter campaign that featured Pixy as a beacon detector for use in autonomous drones. All of these projects have a high fun-factor, which I really enjoy seeing.
CIRCUIT CELLAR: What’s next for Charmed Labs?
RICH: I’ll tell you about one of my crazier ideas. My wife gets on my case every holiday season to hang lights on the house. It wouldn’t be that bad, except our next-door neighbors go all-out. They hang lights on every available surface of their house—think Griswolds from the Christmas Vacation movie. So anything I do to our house looks pretty sad by comparison. I’m competitive. But I had the idea that if I created a computer-controlled light show that’s synchronized to music, it might be a good face-saving technology, a way to possibly one-up the neighbors, because that’s what it’s all about, right? (Ha!) So I’ve been working on an easy-to-set-up and low-cost way to make your own holiday light show. It’s way outside of my robotics wheelhouse. I’m learning about high-voltage electronics and UL requirements, and there’s a decent chance it won’t be cost-competitive, or even work, but my hope is to launch a crowdfunding campaign in the next year or so.
CIRCUIT CELLAR: What are your thoughts on the future of open-source hardware?
RICH: We can probably thank the Arduino folks because before they came along, very few were talking about open hardware. They showed that you can fully open-source a design (including the hardware) and still be successful. Pixy was my first open hardware project and I must admit that I was a little nervous moving forward with it, but open hardware principles have definitely helped us. More people are using Pixy because it’s fully open. If you’re interested in licensing your software or firmware, open hardware is an effective marketing strategy, so I don’t think it’s about “giving it all away” as some might assume. That is, you can still offer closed-source licenses to customers that want to use your software, but not open-source their customizations. I’ve always liked the idea of open vs. proprietary, and I’ve learned plenty from fellow engineers who choose to share instead of lock things down. It’s great for innovation.
On a different robot, a flapping winged ornithopter, we had this PC104 computer running matlab as the controller. It probably weighed about 2 pounds, which forced us to build a huge wingspan – almost 6 feet. We dreamed about adding some machine vision to the platform as well. Having just built a vision-based robot for MIT’s MASLAB competition using an FPGA paired with an Arduino – the PC104 solution started to look pretty stupid to me. That was what really got me interested embedded work. FPGAs and Microcontrollers gave you an insane amount of computing power at comparatively minuscule power and weight footprints. And so died the PC104 standard.
This interview appears in Circuit Cellar 305 (December 2015).
The future of hardware design is in the cloud. Many companies are already focused on the Internet of Things (IoT) and creating hardware to be interconnected in the cloud. However, can we get to a point where we build hardware itself in the cloud?
Traditional methods of building hardware in the cloud recalls the large industry of EDA software packages—board layouts, 3-D circuit assemblies, and chip design. It’s arguable that this industry emphasizes mechanical design, focusing on intricate chip placement, 3-D space, and connections. There are also cloud-based SPICE simulators for electronics—a less-than-user-friendly experience with limited libraries of generic parts. Simulators that do have a larger library also tend to have a larger associated cost. Finding exact parts can be a frustrating experience. A SPICE transistor typically does not have a BOM part number requiring a working design to become a sourcing hunt amongst several vendor offerings.
What if I want to create real hardware in the cloud, and build a project like those in Circuit Cellar articles? This is where I see the innovation that is changing the future of how we make electronics. We now have cloud platforms that provide you with the experience of using actual parts from vendors and interfacing them with a microcontroller. Component lists including servo motors, IR remotes with buttons, LCDs, buzzers with sound, and accelerometers are needed if you’re actually building a project. Definitive parts carried by vendors and not just generic ICs are crucial. Ask any design engineer—they have their typical parts that they reuse and trust in every design. They need to verify that these parts move and work, so having an online platform with these parts allows for a real world simulation.
An Arduino IDE that allows for real-time debugging and stepping through code in the cloud is powerful. Advanced microcontroller IDEs do not have external components in their simulators or environment. A platform that can interconnect a controller with external components in simulation mirrors real life closer than anything else. By observing rises in computer processing power, many opportunities may be realized in the future with other more complex MCUs.
Most hardware designers are unaware of the newest cloud offerings or have not worked with a platform enough to evaluate it as a game-changer. But imagine if new electronics makers and existing engineers could learn and innovate without hardware for free in the cloud.
I remember spending considerable time working on circuit boards to learn the hardware “maker” side of electronics. I would typically start with a breadboard to build basic circuits. Afterwards it was migrated to a protoboard to build a smaller, robust circuit that could be soldered together. Several confident projects later, I jumped to designing and producing PCB boards that eventually led to an entirely different level in the semiconductor industry. Once the boards were designed, all the motors, sensors, and external parts could be assembled to the board for testing.
Traditionally, an assembled PCB was needed to run the hardware design—to test it for reliability, to program it, and to verify it works as desired. Parts could be implemented separately, but in the end, a final assembled design was required for software testing, peripheral integration, and quality testing. Imagine how this is now different using a hardware simulation. The quality aspect will always be tied to actual hardware testing, but the design phase is definitely undergoing disruption. A user can simply modify and test until the design works to their liking, and then design it straight away to a PCB after several online designs failures, all without consequence.
With an online simulation platform, aspiring engineers can now have experiences different from my traditional one. They don’t need labs or breadboards to blink LEDs. The cloud equalizes access to technology regardless of background. Hardware designs can flow like software. Instead of sending electronics kits to countries with importation issues, hardware designs can be shared online and people can toggle buttons and user test it. Students do not have to buy expensive hardware, batteries, or anything more than a computer.
An online simulation platform also affects the design cycle. Hardware design cycles can be fast when needed, but it’s not like software. But by merging the two sides means thousands can access a design and provide feedback overnight, just like a Facebook update. Changes to a design can be done instantly and deployed at the same time—an unheard of cycle time. That’s software’s contribution to the traditional hardware one.
There are other possibilities for hardware simulation on the end product side of the market. For instance, crowdfunding websites have become popular destinations for funding projects. But should we trust a simple video representing a working prototype and then buy the hardware ahead of a production? Why can’t we play with the real hardware online? By using an online simulation of actual hardware, even less can be invested in terms of hardware costs, and in the virtual environment, potential customers can experience the end product built on a real electronic design.
Subtle changes tend to build up and then avalanche to make dramatic changes in how industries operate. Seeing the early signs—realizing something should be simpler—allows you to ask questions and determine where market gaps exist. Hardware simulation in the cloud will change the future of electronics design, and it will provide a great platform for showcasing your designs and teaching others about the industry.
John Young is the Product Marketing Manager for Autodesk’s 123D Circuits (https://123d.circuits.io/) focusing on building a free online simulator for electronics. He has a semiconductor background in designing products—from R&D to market launch for Freescale and Renesas. His passion is finding the right market segment and building new/revamped products. He holds a BSEE from Florida Atlantic University, an MBA from the Thunderbird School of Global Management and is pursuing a project management certification from Stanford.
Imsys has developed a dual-core, runtime-reconfigurable processor that can run at 350 MHz with an active power consumption of 19.7 µW/MHz using one core. Intended for low-power applications, 97% of the processor’s transistors are used in memory blocks. The cores share memories and a five-port grid network router (NoC). Memory management is handled by microcode, and memory is closely integrated with the processor without the need for an ordinary cache controller. The active consumption of each core—executing from RAM, including its consumption there—is 6.9 mW at 350 MHz.
Imsys’s processor is suitable for sensor nodes powered by energy harvesting in the Internet of Things (IoT), as well as in many-core chips for microservers and robotics. Microcode, as opposed to logic gates, is compact and energy efficient. Imsys uses extensive microprogramming to accomplish a rich set of instructions, thereby reducing the number of cycles needed without energy inefficient speculative activity and duplicated hardware logic. Each core has two instruction sets, one of which executes Java and Python directly from the dense JVM bytecode representation. C code is compiled to the other set with unparalleled density. Internal microcode is used for computationally intensive standard routines, such as crypto algorithms, which would otherwise be assembly coded library routines or even special hardware blocks. Optimizing CPU intensive tasks by microcode can reduce execution time and energy consumption of by more than an order of magnitude compared to C code.
The rich instruction set optimized for the compiler reduces the memory needed for software. And just like the microcoded algorithms, it reduces the number of clock cycles needed for execution. This platform has a certified JVM and uses an RTOS kernel certified to ISO 26262 safety standard for automotive applications. The development tools will be enhanced with the support enabled by the LLVM infrastructure. A new instruction set optimized for an LLVM backend has been developed and is being implemented in the coming hardware generation.
Silicon Labs recently introduced a series of comprehensive reference designs that reduce time to market and simplify the development of ZigBee-based home automation, connected lighting and smart gateway products. The first in a series of Internet of Things (IoT) solutions, the new reference designs include hardware, firmware, and software tools for developing high-quality connected home solutions based on Silicon Labs’s ZigBee “Golden Unit” Home Automation (HA 1.2) software stack and ZigBee SoC mesh networking technology.Silicon Labs’ ZigBee connected lighting reference designs feature wireless lighting boards and a plug-in demo board. The Golden Unit ZigBee stack allows LED lights to reliably join, interoperate, and leave a mesh network. The connected lights can support white, color temperature tuning, and RGB color settings as well as dimming.
Silicon Labs’ ZigBee-based home automation reference designs include a capacitive-sense dimmable light switch and a small door/window contact sensor. The light switch provides color, color tuning, and dimming control capabilities. As opposed to conventional switches, the wireless, battery-powered switches have no moving parts and are easy to place anywhere in a home. The switch design includes Silicon Labs’s EFM8 capacitive sensing microcontroller to detect different user gestures (touch, hold, and swipe). The contact sensor reference design provides all the tools needed to create wireless, battery-powered sensors used to monitor door and window positions (open or closed).
Silicon Labs offers two ZigBee gateway options to complement the reference designs:
- A plug-and-play USB virtual gateway that works with any PC development platform and supports the Windows, OS X, and Linux environments as a virtual machine
- An out-of-the-box Wi-Fi/Ethernet gateway reference design based on an embedded Linux computer system
Both gateway options enable you to control and monitor ZigBee HA 1.2-compliant end nodes through Wi-Fi with any device with a web browser, such as a smartphone or tablet. With an intuitive, web-based user interface, you can easily create rules between ZigBee end devices including lights, dimmable light switches, and contact sensors.
Silicon Labs’ connected lighting, home automation, and smart gateway reference designs are currently available. The RD-0020-0601 and RD-0035-0601 connected lighting reference designs cost $49. The RD-0030-0201 contact sensor reference design is $39. The RD-0039-0201 capacitive-sense dimmable light switch reference design is $29. The USB virtual gateway is $49. The out-of-the-box Wi-Fi/Ethernet gateway reference design is $149.
Source: Silicon Labs
STMicroelectronics has announced that the STM32 family of ARM Cortex-M based microcontrollers is now enabled for the ARM mbed IoT Device Platform with the latest public version of the ARM mbed OS. The mbed platform adds a standard OS, cloud services, and development tools for creating new IoT applications.
By adding mbed to its handy design ecosystem, STMicro is encouraging more productivity and collaboration in IoT development. Using the mbed OS with STM32 development hardware enables you to innovate while reducing your product’s time to market. You can easily incorporate STM32 microcontrollers with STMicro’s sensor and power-management products to deploy “smart,” secure IoT designs.
The Arcturus uCMK64-IoT is a 60x60mm module for developing secure IoT devices that require a combination of connectivity and control. The hardware uses a 120MHz, Freescale Kinetis K64 microcontroller with Ethernet, Wi-Fi, TLS security, peripheral connectivity and optional audio. The platform is controlled using a simple command protocol over a UART or TCP/IP socket, providing options for both host-MCU or cloud integration. The protocol supports I/O, bi-directional UART-to-net communication, device services and settings. A “call home” feature automatically originates the secure TLS socket connection to a remote server, helping to egress firewalls.
The platform is fully compatible with the eco-system of Arcturus IoT tools, including Mbarx-System Manager, a powerful tool for securely managing entire network sites. Developers can easily connect, change firmware, configure, control or probe attached sensors and peripherals. An IoT apps store, provides direct access to firmware.
The uCMK64 is IoT made easy, no complex BSP or software system integration. The development kit contains everything you need to get started.
- 120MHz ARM® Cortex® M4 microcontroller
- Ethernet with network stack
- 11bgn Wi-Fi
- Optional audio
- Socket or UART control
- Eco-system of IoT Tools
- -40 to +85C parts rating
- TLS based secure connectivity
- I/O controls
- UART-to-net peripheral connectivity
- Optional VoIP, audio and PA firmware
How to buy:
- uCMK64-IoT Development Kit
- uCMK64-MOD – Module
- uCMK64-SSB – Board
Learn more at ArcturusNetworks.com
Microchip Technology recently launched next-generation Bluetooth Low Energy (LE) solutions intended for Internet of Things (IoT) and Bluetooth Beacon applications: the IS1870 Bluetooth LE RF module, the IS1871 Bluetooth LE RF module, and the BM70 module.
The Bluetooth LE devices include an integrated, certified Bluetooth 4.2 firmware stack. Data is transmitted over the Bluetooth link using Transparent UART mode, which you can integrate with any processor or PIC microcontroller with a UART interface. The module also supports standalone “hostless” operation for beacon applications.
The optimized power profile of these new devices minimizes current consumption for extended battery life, in compact form factors as small as 4 × 4 mm for the RF ICs and 15 × 12 mm for the module. The module options include RF regulatory certifications, or noncertified (unshielded/antenna-less) for smaller and more remote antenna designs that will undergo end-product emission certifications.
The BM70 Bluetooth Low Energy PICtail/PICtail Plus daughter board enables code development via USB interface to a PC. Or you can connect to Microchip’s existing microcontroller development boards, such as the Explorer 16, PIC18 Explorer and PIC32 I/O Expansion Board. The BM-70-PICTAIL costs $89.99.
The IS1870 Bluetooth LE RF IC (6 × 6 mm, 48-pin QFN package) costs $1.79 in 1,000-unit quantities. The IS1871 (4 × 4 mm, 32-pin QFN package) costs $1.76 in 1,000-unit quantities. The 30-pin BM70 Bluetooth LE modules are available with or without built-in PCB antennas, starting at $4.99 each in 1,000-unit quantities.
Source: Microchip Technology
Linx Technologies recently introduced new pre-certified remote control and sensor transceiver modules. Built on the Hummingbird platform, the HumRC Series transceiver is a frequency hopping spread spectrum (FHSS) transceiver designed for reliable bidirectional remote control and sensor applications. Available in 900 MHz, the HumRC outputs up to 10 dBm, which results in a line-of-sight range of up to 1 mile.
The HumRC Series module is a completely integrated RF transceiver and processor designed for bidirectional remote control. It employs a fast-locking FHSS system for noise immunity and higher transmitter output power as allowed by government regulations.
The remote control transceiver has eight status lines that can be individually configured as inputs to register button presses or as outputs to drive application circuitry. A selectable acknowledgement indicates that the transmission was successfully received. Primary settings are hardware-selectable, which eliminates the need for an external microcontroller or other digital interface.
The transceiver also has two analog-to-digital (ADC) inputs for sensors or circuits that output an analog voltage. The module can automatically respond to a command with these values, so a sensor node does not need an additional microprocessor.
To aid rapid development, the HumRC Series low-cost RF modules are available as part of a newly conceived type of Master Development System. This development kit is intended to assist in the rapid evaluation and integration of the HumRC Series data transceiver modules. It features several preassembled evaluation boards that include everything needed to quickly test the operation of the transceiver modules.
Source: Linx Technologies
IAR Systems recently launched IAR Connect, which is a portal that presents product development platforms and serves as hub intended to connect innovators interested in the Internet of Things (IoT) and other emerging technologies.
One of the first members of IAR Connect is Renesas Electronics. Customers using the Renesas Synergy Platform can begin product development at a high level of abstraction and focus completely on designing innovative features for embedded applications and connected devices.
“The best way to take advantage of the possibilities of the new connected world is by providing new technology offerings, sharing knowledge and establishing strategic alliances, such as our strong partnership with Renesas. With IAR Connect, we enable innovation by connecting people and technologies. I invite everyone to connect, get inspired and explore the potential of the Internet of Things and the connected world at www.iarconnect.com”, said IAR Systems CEO Stefan Skarin in a released statement.
Source: IAR Systems
Dialog Semiconductor recently announced that it is collaborating with Bosch Sensortec to develop a low-power smart sensor platform for Internet of Things (IoT) devices. The 12-DOF smart sensor reference platform is intended for gesture recognition in wearable computing devices and immersive gaming, including augmented reality and 3-D indoor mapping and navigation.
The platform comprises Dialog’s DA14580 Bluetooth Smart SoC with three low-power Bosch Sensortecsensors: the BMM150 (for three-axis geo-magnetic field measurement), the BME280 (pressure, humidity, and temperature sensor), and the siz-axis BMI160 (a combination of a three-axis accelerometer and three-axis gyroscope in one chip). The resulting 14 × 14 mm2 unit draws less than 500 µA from a 3-V coin cell when updating and transferring all 12 × 16 bits of data wirelessly to a smartphone.
The 2.5 × 2.5 × 0.5 mm DA14580 SmartBond SoC integrates a Bluetooth Smart radio with an ARM Cortex-M0 application processor and intelligent power management. It more than doubles the battery life of an application-enabled smartphone accessory, wearable device, or computer peripheral in comparison with other solutions. The DA14580 includes a variety of analog and digital interfaces and features less than 15 mW power consumption in active mode and 600-nA standby current.
Bosch Sensortec’s BMI160 six-axis Inertial Measurement Unit (IMU) integrates a 16 bit, three-axis, low-g accelerometer and an ultra-low power three-axis gyroscope within a single package. When the accelerometer and gyroscope are in full operation mode, the typical current consumption is 950 µA.
The BMM150 integrates a compact three-axis geo-magnetic field sensor using Bosch Sensortec’s high performance FlipCore technology. The BME280 Integrated Environmental Unit combines sensors for barometric pressure, humidity, and temperature measurement. Its altitude measurement function is a key requirement in applications such as indoor navigation with floor tracking.
Source: Dialog Semiconductor