IoT Monitoring System for Commercial Fridges

Using LoRa Technology

IoT implementations can take many shapes and forms. Learn how these four Camosun College students developed a system to monitor all the refrigeration units in a commercial kitchen simultaneously. The system uses Microchip PIC MCU-based monitoring units and wireless communication leveraging the LoRa wireless protocol.

By Tyler Canton, Akio Yasu, Trevor Ford and Luke Vinden

In 2017, the commercial food service industry created an estimated 14.6 million wet tons of food in the United States [1]. The second leading cause of food waste in commercial food service, next to overproduction, is product loss due to defects in product quality and/or equipment failure [2].

While one of our team members was working as the chef of a hotel in Vancouver, more than once he’d arrive at work to find that the hotel’s refrigeration equipment had failed overnight or over the weekend, and that thousands of dollars of food had become unusable due to being stored at unsafe temperatures. He always saw this as an unnecessary loss—especially because the establishment had multiple refrigeration units and ample space to move product around. In this IoT age, this is clearly a preventable problem.

For our Electronics & Computer Engineering Technologist Capstone project, we set forth to design a commercial refrigeration monitoring system that would concurrently monitor all the units in an establishment, and alert the chefs or managers when their product was not being stored safely. This system would also allow the chef to check in on his/her product at any time for peace of mind (Figure 1).

Figure 1
This was the first picture we took of our finished project assembled. This SLA printed enclosure houses our 10.1″ LCD screen, a Raspberry Pi Model 3B and custom designed PCB.

We began with some simple range testing using RFM95W LoRa modules from RF Solutions, to see if we could reliably transmit data from inside a steel box (a refrigerator), up several flights of stairs, through concrete walls, with electrical noise and the most disruptive interference: hollering chefs. It is common for commercial kitchens to feel like a cellular blackout zone, so reliable communication would be essential to our system’s success.

System Overview

We designed our main unit to be powered and controlled by a Raspberry Pi 3B (RPi) board. The RPi communicates with an RFM95W LoRa transceiver using Serial Peripheral Interface (SPI). This unit receives temperature data from our satellite units, and displays the temperatures on a 10.1″ LCD screen from Waveshare. A block diagram of the system is shown in Figure 2. We decided to go with Node-RED flow-based programming tool to design our GUI. This main unit is also responsible for logging the data online to a Google Form. We also used Node-RED’s “email” nodes to alert the users when their product is stored at unsafe temperatures. In the future, we plan to design an app that can notify the user via push notifications. This is not the ideal system for the type of user that at any time has 1,000+ emails in their inbox, but for our target user who won’t allow more than 3 or 4 to pile up it has worked fine.

Figure 2
The main unit can receive temperature data from as many satellite units as required. Data are stored locally on the Raspberry Pi 3B, displayed using a GUI designed by Node-RED and logged online via Google Sheets.

We designed an individual prototype (Figure 3) for each satellite monitoring unit, to measure the equipment’s temperature and periodically transmit the data to a centralized main unit through LoRa communication. The units were intended to operate at least a year on a single battery charge. These satellites, controlled by a Microchip Technology PIC24FJ64GA704 microcontroller (MCU), were designed with an internal Maxim Integrated DS18B20 digital sensor (TO-92 package) and an optional external Maxim

Figure 3
This enclosure houses the electronics responsible for monitoring the temperatures and transmitting to the main unit. These were 3D printed on Ultimaker 3 printers.

Integrated DS18B20 (waterproof stainless steel tube package) to measure the temperature using the serial 1-Wire interface.

Hardware

All our boards were designed using Altium Designer 2017 and manufactured by JLCPCB. We highly recommend JLCPCB for PCB manufacturing. On a Tuesday we submitted our order to the website, and the finished PCB’s were manufactured, shipped, and delivered within a week. We were amazed by the turnaround time and the quality of the boards we received for the price ($2 USD / 10 PCB).

Figure 4
The main unit PCB’s role is simply to allow the devices to communicate with each other. This includes the RFM95W LoRa transceivers, RPi, LCD screen and a small fan

Main Unit Hardware: As shown in Figure 4, our main board’s purpose is communicating with the RPi and the LCD. We first had to select an LCD display for the main unit. This was an important decision, as it was the primary human interface device (HID) between the system and its user. We wanted a display that was around 10″—a good compromise between physical size and readability. Shortly after beginning our search, we learned that displays between 7″ and 19″ are not only significantly more difficult to come by, but also significantly more expensive. Thankfully, we managed to source a 10.1″ display that met our budget from robotshop.com. On the back of the display was a set of female header pins designed to interface with the first 26 pins of the RPi’s GPIO pins. The only problem with the display was that we needed access to those same GPIO pins to interface with the rest of our peripherals.

Figure 5
Our main board, labeled Mr. Therm, was designed to attach directly to the LCD screen headers. RPi pins 1-26 share the same connectivity as the main board and the LCD.

We initially planned on fixing this problem by placing our circuit board between the RPi and the display, creating a three-board-stack. Upon delivery and initial inspection of the display, however, we noticed an undocumented footprint that was connected to all the same nets directly beneath the female headers. We quickly decided to abandon the idea of the three-board-stack and decided instead to connect our main board to that unused footprint in the same way the RPi connects to display (Figure 5). This enabled us to interface all three boards, while maintaining a relatively thin profile. The main board connects four separate components to the rest of the circuit. It connects the RFM95W transceiver to the RPi, front panel buttons, power supply and a small fan.

Read the full article in the April 345 issue of Circuit Cellar
(Full article word count: 3378 words; Figure count: 11 Figures.)

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

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

Connecting USB to Simple MCUs

Helpful Hosting

Sometimes you want to connect a USB device such as a flash drive to a simple microcontroller. The problem is most MCUs cannot function as a USB host. In this article, Stuart steps through the technology and device choices that solve this challenge. He also puts the idea into action via a project that provides this functionality.

By Stuart Ball

Even though many microcontrollers (MCUs) may have a USB device interface that can connect to a host, rarely is a host interface available on simple MCUs. There are various reasons for this, including the complexity of implementing a USB host interface on a simple processor, the need to enumerate and recognize many device types and the memory required to do so. Functioning as a single USB device is much simpler. Implementing a host interface also puts some constraints on the MCU for throughput and clock speed choices.

I have been working on a retro CPU board design, using the Z80180 processor that can run the old CP/M-80 operating system. This is just a fun project, with no real practical use. But the project needed storage that could replace the floppy disk normally used in CP/M. I considered using SD cards, but in experimenting with them, I decided that they are just not what I wanted. What I did want was the ability to plug a USB flash drive into the circuit.

Even though my CP/M project is not that useful, there are other applications where the ability to plug a USB flash drive into an MCU-based circuit is desirable. Examples include:

• Capturing logging or debug data
• Flashing new code into the MCU
(if the MCU has self-programming flash)
• Downloading crypto keys or other
one-time data to the MCU
• Downloading configuration information
to enable or disable features
• Downloading language translation
information
• Retaining critical data
• Serving as a “key” to restrict access to
maintenance mode functions only
to authorized personnel
• Downloading GPS coordinates or map
information
• Updating stored part numbers, serial
numbers or any stored value that can
change.

There are ways to implement USB host capability on an MCU, especially if it has a USB interface that supports OTG (on-the-go) USB capability. But no matter how you do it, you have to write or obtain drivers and integrate the functionality into your software. You will also be constrained as to which MCUs you can use, based on availability of USB host capability. But for a simple design, you may not want to be forced to use a part just because it has USB host capability.

VDrive3

FTDI makes a USB host module called the VDrive3 that provides a limited USB host interface and can connect to an MCU (or even a PC) using an asynchronous serial port. The module also has an SPI interface, although I did not use that in my design. A link to the datasheet is provided on the Circuit Cellar article materials webpage.

The VDrive3 (Figure 1) uses the FTDI Vinculum IC, which provides a USB host interface on one side and a serial or SPI interface to your MCU on the other. Since all of the hardware and software to implement the USB host interface is inside the VDrive3 module, you don’t need to develop USB stacks or drivers, or deal with licensing issues. The VDrive3 comes in a plastic housing so it is easy to mount in a rectangular cutout.

Figure 1
VDrive3 module. The module comes with the attached cable, which I modified to use a different connector on my board.

The VDrive3 has a file-based interface for USB flash drives, which means that you don’t need to manage the memory yourself. You open files, write to them, read them, close them and create directories. The VDrive3 shields the host from the memory management functionality, allowing all this to be done with simple commands over the serial interface. The VDrive3 manages the file system so you don’t have to.

In my application, I was emulating a floppy disk. I defined the “virtual floppy” to have 256 tracks of 32 sectors each. To implement that on the VDrive3, I created 256 directories named TRAK000 through TRAK0FF. In each directory, I created 32 files named SEC00 through SEC1F. So, when the CP/M operating system wants to read or write a specific sector, the AVR MCU navigates to the directory that represents the selected track and opens the sector file corresponding to the specified sector.

This is a simple mechanism that is really applicable only to the way I’m using the flash drive, but the general principles apply to any VDrive3 application. You can create a directory, and then create files within the directory that correspond to whatever information you need to store. Or you can skip the directories and store everything at the top directory level.

One advantage of using the VDrive3 is interoperability with a PC. If I used SD drives, I would either have a proprietary format that couldn’t be read in a PC, or else I’d have to manage a PC-compatible file system in my MCU. But the VDrive3 recognizes the standard FAT12, FAT16, and FAT32 file systems, so a flash drive written on a VDrive3 can be inserted into a PC and read. This could be very useful if you are collecting debug or log data from your MCU application. In my case, I could make a copy of a CP/M “floppy” on a PC.

Commands

The VDrive3 recognizes various commands, including SEK (seek to file offset), OPW (open file for writing) and WRF (write to file). The commands used in my application are listed in Table 1. VDrive3 commands can be sent in ASCII as in the command list in Table 1, or you can configure it to use a short command set that requires fewer bytes to transmit. Data can be either ASCII or binary. The VDrive3 defaults to the extended command set and binary data transfer, and I leave the module in that mode for my application.

Table 1
The VDrive3 recognizes various commands. Shown here are the commands used in my application. VDrive3 commands can be sent in ASCII as in this command list, or you can configure it to use a short command set that requires fewer bytes to transmit.

Generally, each command is sent as a string of two or three characters. If data such as a filename are needed, the command is followed by a space, the appropriate text and a carriage return character (0x0D). If no data are needed, such as for the FWV (FW version) command, the command can be immediately followed by the carriage return. Setting the baud rate requires a divisor value, so the SBD command (set baud rate) is followed by a 3-byte divisor value and then a carriage return. …

Read the full article in the January 342 issue of Circuit Cellar

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

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

Sensor Node Gets LoRaWAN Certification

Advantech offers its standardized M2.COM IoT LoRaWAN certified sensor node WISE-1510 with integrated ARM Cortex-M4 processor and LoRa transceiver. The module the  is able to provide multi-interfaces for sensors and I/O control such as UART, I2C, SPI, GPIO, PWM and ADC. The WISE-1510 sensor node is well suited for for smart cities, WISE-1510_3D _S20170602171747agriculture, metering, street lighting and environment monitoring. With power consumption optimization and wide area reception, LoRa  sensors or applications with low data rate requirements can achieve years of battery life and kilometers of long distance connection.

WISE-1510 has has received LoRaWAN certification from the LoRa Alliance. Depending on deployment requirements, developers can select to use Public LoRaWAN network services or build a private LoRa system with WISE-3610 LoRa IoT gateway. Advantech’s WISE-3610  is a Qualcomm ARM Cortex A7 based hardware platform with private LoRa ecosystem solution that can connect up to 500 WISE-1510 sensor node devices. Powered by Advantech’s WISE-PaaS IoT Software Platform, WISE-3610 features automatic cloud connection through its WISE-PaaS/WISE Agent service, manages wireless nodes and data via WSN management APIs, and helps customers streamline their IoT data acquisition development through sensor service APIs, and WSN drivers.

Developers can leverage microprocessors on WISE-1510 to build their own applications. WISE-1510 offers unified software—ARM Mbed OS and SDK for easy development with APIs and related documents. Developers can also find extensive resources from Github such as code review, library integration and free core tools. WISE-1510 also offers worldwide certification which allow developers to leverage their IoT devices anywhere. Using Advantech’s WISE-3610 LoRa IoT Gateway, WISE-1510 can be connected to WISE-  PaaS/RMM or  ARM Mbed Cloud service with IoT communication protocols including LWM2M, CoAP, and MQTT. End-to-end integration assists system integrators to overcome complex challenges and helps them build IoT applications quickly and easily.

WISE-1510 features and specifications:

  • ARM Cortex-M4 core processor
  • Compatible support for public LoRaWAN or private LoRa networks
  • Great for low power/wide range applications
  • Multiple I/O interfaces for sensor and control
  • Supports wide temperatures  -40 °C to 85 °C

Advantech | www.advantech.com

Flexible I/O Expansion for Rugged Applications

WynSystemsThe SBC35-CC405 series of multi-core embedded PCs includes on-board USB, gigabit Ethernet, and serial ports. These industrial computers are designed for rugged embedded applications requiring extended temperature operation and long-term availability.

The SBC35-CC405 series features the latest generation Intel Atom E3800 family of processors in an industry-standard 3.5” single-board computer (SBC) format COM Express carrier. A Type 6 COM Express module supporting a quad-, dual-, or single-core processor is used to integrate the computer. For networking and communications, the SBC35-CC405 includes two Intel I210 gigabit Ethernet controllers with IEEE 1588 timestamping and 10-/100-/1,000-Mbps multispeed operation. Four Type-A connectors support three USB 2.0 channels and one high-speed USB 3.0 channel. Two serial ports support RS-232/-422/-485 interface levels with clock options up to 20 Mbps in the RS-422/-485 mode and up to 1 Mbps in the RS-232 mode.

The SBC35-CC405 series also includes two MiniPCIe connectors and one IO60 connector to enable additional I/O expansion. Both MiniPCIe connectors support half-length and full-length cards with screw-down mounting for improved shock and vibration durability. One MiniPCIe connector also supports bootable mSATA solid-state disks while the other connector includes USB. The IO60 connector provides access to the I2C, SPI, PWM, and UART signals enabling a simple interface to sensors, data acquisition, and other low-speed I/O devices.

The SBC35-CC405 runs over a 10-to-50-VDC input power range and operates at temperatures from –40°C to 85°C. Enclosures, power supplies, and configuration services are also available.

Linux, Windows, and other x86 OSes can be booted from the CFast, mSATA, SATA, or USB interfaces, providing flexible data storage options. WinSystems provides drivers for Linux and Windows 7/8 as well as preconfigured embedded OSes.
The single-core SBC35-CC405 costs $499.

Winsystems, Inc.
www.winsystems.com

A Workspace for “Engineering Magic”

Brandsma_workspace2

Photo 1—Brandsma describes his workspace as his “little corner where the engineering magic happens.”

Sjoerd Brandsma, an R&D manager at CycloMedia, enjoys designing with cameras, GPS receivers, and transceivers. His creates his projects in a small workspace in Kerkwijk, The Netherlands (see Photo 1). He also designs in his garage, where he uses a mill and a lathe for some small and medium metal work (see Photo 2).

Brandsma_lathe_mill

Photo 2—Brandsma uses this Weiler lathe for metal work.

The Weiler lathe has served me and the previous owners for many years, but is still healthy and precise. The black and red mill does an acceptable job and is still on my list to be converted to a computer numerical control (CNC) machine.

Brandsma described some of his projects.

Brandsma_cool_projects

Photo 3—Some of Brandsma’s projects include an mbed-based camera project (left), a camera with an 8-bit parallel databus interface (center), and an MP3 player that uses a decoder chip that is connected to an mbed module (right).

I built a COMedia C328 UART camera with a 100° lens placed on a 360° servomotor (see Photo 3, left).  Both are connected to an mbed module. When the system starts, the camera takes a full-circle picture every 90°. The four images are stored on an SD card and can be stitched into a panoramic image. I built this project for the NXP mbed design challenge 2010 but never finished the project because the initial idea involved doing some stitching on the mbed module itself. This seemed to be a bit too complicated due to memory limitations.

I built this project built around a 16-MB framebuffer for the Aptina MT9D131 camera (see Photo 3, center). This camera has an 8-bit parallel databus interface that operates on 6 to 80 MHz. This is way too fast for most microcontrollers (e.g., Arduino, Atmel AVR, Microchip Technology PIC, etc.). With this framebuffer, it’s possible to capture still images and store/process the image data at a later point.

This project involves an MP3 player that uses a VLSI VS1053 decoder chip that is connected to an mbed module (see Photo 3, right). The great thing about the mbed platform is that there’s plenty of library code available. This is also the case for the VS1053. With that, it’s a piece of cake to build your own MP3 player. The green button is a Skip button. But beware! If you press that button it will play a song you don’t like and you cannot skip that song.

He continued by describing his test equipment.

Brandma_test_equipment

Photo 4—Brandsma’s test equipment collection includes a Tektronix TDS220 oscilloscope (top), a Total Phase Beagle protocol analyzer (second from top), a Seeed Technology Open Workbench Logic Sniffer (second from bottom), and a Cypress Semiconductor CY7C68013A USB microcontroller (bottom).

Most of the time, I’ll use my good old Tektronix TDS220 oscilloscope. It still works fine for the basic stuff I’m doing (see Photo 4, top). The Total Phase Beagle I2C/SPI protocol analyzer Beagle/SPI is a great tool to monitor and analyze I2C/SPI traffic (see Photo 4, second from top).

The red PCB is a Seeed Technology 16-channel Open Workbench Logic Sniffer (see Photo 4, second from bottom). This is actually a really cool low-budget open-source USB logic analyzer that’s quite handy once in a while when I need to analyze some data bus issues.

The board on the bottom is a Cypress CY7C68013A USB microcontroller high-speed USB peripheral controller that can be used as an eight-channel logic analyzer or as any other high-speed data-capture device (see Photo 4, bottom). It’s still on my “to-do” list to connect it to the Aptina MT9D131 camera and do some video streaming.

Brandsma believes that “books tell a lot about a person.” Photo 5 shows some books he uses when designing and or programming his projects.

Brandsma_books

Photo 5—A few of Brandsma’s “go-to” books are shown.

The technical difficulty of the books differs a lot. Electronica echt niet moeilijk (Electronics Made Easy) is an entry-level book that helped me understand the basics of electronics. On the other hand, the books about operating systems and the C++ programming language are certainly of a different level.

An article about Brandsma’s Sun Chaser GPS Reference Station is scheduled to appear in Circuit Cellar’s June issue.

Remote Control and Monitoring of Household Devices

Raul Alvarez, a freelance electronic engineer from Bolivia, has long been interested in wireless device-to-device communication.

“So when the idea of the Internet of Things (IoT) came around, it was like rediscovering the Internet,” he says.

I’m guessing that his dual fascinations with wireless and the IoT inspired his Home Energy Gateway project, which won second place in the 2012 DesignSpark chipKIT challenge administered by Circuit Cellar.

“The system enables users to remotely monitor their home’s power consumption and control household devices (e.g., fans, lights, coffee machines, etc.),” Alvarez says. “The main system consists of an embedded gateway/web server that, aside from its ability to communicate over the Internet, is also capable of local communications over a home area wireless network.”

Alvarez catered to his interests by creating his own wireless communication protocol for the system.

“As a learning exercise, I specifically developed the communication protocol I used in the home area wireless network from scratch,” he says. “I used low-cost RF transceivers to implement the protocol. It is simple and provides just the core functionality necessary for the application.”

Figure1: The Home Energy Gateway includes a Hope Microelectronics RFM12B transceiver, a Digilent chipKIT Max32 board, and a Microchip Technology ENC28J60 Ethernet controller chip.

Figure 1: The Home Energy Gateway includes a Hope Microelectronics RFM12B transceiver, a Digilent chipKIT Max32 board, and a Microchip Technology ENC28J60 Ethernet controller chip.

Alvarez writes about his project in the February issue of Circuit Cellar. His article concentrates on the project’s TCI/IP communications aspects and explains how they interface.

Here is his article’s overview of how the system functions and its primary hardware components:

Figure 1 shows the system’s block diagram and functional configuration. The smart meter collects the entire house’s power consumption information and sends that data every time it is requested by the gateway. In turn, the smart plugs receive commands from the gateway to turn on/off the household devices attached to them. This happens every time the user turns on/off the controls in the web control panel.

Photo 1: These are the three smart node hardware prototypes: upper left,  smart plug;  upper right, a second smart plug in a breadboard; and at bottom,  the smart meter.

Photo 1: These are the three smart node hardware prototypes: upper left, smart plug; upper right, a second smart plug in a breadboard; and at bottom, the smart meter.

I used the simple wireless protocol (SWP) I developed for this project for all of the home area wireless network’s wireless communications. I used low-cost Hope Microelectronics 433-/868-/915-MHz RFM12B transceivers to implement the smart nodes. (see Photo 1)
The wireless network is configured to work in a star topology. The gateway assumes the role of a central coordinator or master node and the smart devices act as end devices or slave nodes that react to requests sent by the master node.

The gateway/server is implemented in hardware around a Digilent chipKIT Max32 board (see Photo 2). It uses an RFM12B transceiver to connect to the home area wireless network and a Microchip Technology ENC28J60 chip module to connect to the LAN using Ethernet.

As the name implies, the gateway makes it possible to access the home area wireless network over the LAN or even remotely over the Internet. So, the smart devices are easily accessible from a PC, tablet, or smartphone using just a web browser. To achieve this, the gateway implements the SWP for wireless communications and simultaneously uses Microchip Technology’s TCP/IP Stack to work as a web server.

Photo 2: The Home Energy Gateway’s hardware includes a Digilent chipKIT Max32 board and a custom shield board.

Photo 2: The Home Energy Gateway’s hardware includes a Digilent chipKIT Max32 board and a custom shield board.

Thus, the Home Energy Gateway generates and serves the control panel web page over HTTP (this page contains the individual controls to turn on/off each smart plug and at the same time shows the power consumption in the house in real-time). It also uses the wireless network to pass control data from the user to the smart plugs and to read power consumption data from the smart meter.

The hardware module includes three main submodules: The chipKIT Max 32 board, the RFM12B wireless transceiver, and the ENC28J60 Ethernet module. The smart meter hardware module has an RFM12B transceiver for wireless communications and uses an 8-bit Microchip Technology PIC16F628A microcontroller as a main processor. The smart plug hardware module shows the smart plugs’ main hardware components and has the same microcontroller and radio transceiver as the smart meter. But the smart plugs also have a Sharp Microelectronics S212S01F solid-state relay to turn on/off the household devices.

On the software side, the gateway firmware is written in C for the Microchip Technology C32 Compiler. The smart meter’s PIC16F628A code is written in C for the Hi-TECH C compiler. The smart plug software is very similar.

Alvarez says DIY home-automation enthusiasts will find his prototype inexpensive and capable. He would like to add several features to the system, including the ability to e-mail notifications and reports to users.

For more details, check out the February issue now available for download by members or single-issue purchase.

Six-Channel RS-422 Line Driver/Receiver

ic-HausThe iC-HF provides six RS-422 line drivers for 3-to-5.5-V encoder applications. The device contains reverse polarity protection for a safe sensor-side supply of up to 60 mA.

The iC-HF is pin configurable. A safe external signal sequence at two complementary line driver outputs activates the Encoder Link state. In the Encoder Link state, nine pins are connected from the sensor side to the field side. With this low-impedance bypassing, internal analog sensor signals and digital communication signals (e.g., BiSS, SPI, I²C, etc.) can be accessed at the line driver output pins.

With the integrated Encoder Link function, the line drivers can be deactivated and A/D signals can be directly accessed through the line driver output pins. Conventional sensors can be calibrated or programmed through the usual RS-422 outputs via the Encoder Link function. Extra contacts, pins, control lines, or signals are not needed. For differential RS-422 line driver operation, six differential complementary drivers are implemented.

Each push-pull driver stage can drive up to 65 mA maximum at 5 V and operate at up to a 10-MHz output frequency with RS-422 termination. The driver stages are current limited, short-circuit proof, and over-temperature protected. The current limitation also reduces electromagnetic compatibility (EMC).

The device provides under-voltage detection and on-chip temperature monitoring to switch the driver stages to high impedance on demand. A sensor error signal is combined with the iC-HF error states. When a fault occurs, the open-drain error output NERR is activated. All inputs are CMOS- and TTL-compatible and ESD protected.

The iC-HF’s operating temperatures range from –40°C to 125°C. The device is available in a 5-mm × 5-mm 32-pin QFN package. The design-in process is supported by ready-to-operate demonstration boards including the Encoder Link signal sequence generator.

The iC-HF costs $3.65 in 1,000-unit quantities.

iC-Haus GmbH
www.ichaus.com

Turn Your Android Device into an Application Tool

A few years ago, the Android Open Accessory initiative was announced with the aim of making it easier for hardware manufacturers to create accessories that work with every Android device. Future Technology Devices International (FTDI) joined the initiative and last year introduced the FTD311D multi-interface Android host IC. The goal was to enable engineers and designers to make effective use of tablets and smartphones with the Android OS, according to Circuit Cellar columnist Jeff Bachiochi.

The FTD311D “provides an instant bridge from an Android USB port(B) to peripheral hardware over general purpose input-out (GPIO), UART, PWM, I2C Master, SPI Slave, or SPI Master interfaces,” Bachiochi says.

In the magazine’s December issue Bachiochi takes a comprehensive look at the USB Android host IC and how it works. By the end of his article, readers will have learned quite a bit about how to use FTDI’s apps and the FT311D chip to turn an Android device into their own I/0 tool.

Bachiochi used the SPI Master demo to read key presses and set LED states on this SPI slave 16-key touch panel.

Bachiochi used the SPI Master demo to read key presses and set LED states on this SPI slave 16-key touch panel.

Here is how Bachiochi describes the FT311D and its advantages:

The FT311D is a full-speed USB host targeted at providing access to peripheral hardware from a USB port on an Android device. While an Android device can be a USB host, many are mobile devices with limited power. For now, these On-The-Go (OTG) ports will be USB devices only (i.e., they can only connect to a USB host as a USB device).

Since the USB host is responsible for supplying power to a USB peripheral device, it would be bad design practice to enable a USB peripheral to drain an Android mobile device’s energy. Consequently, the FT311D takes on the task of USB host, eliminating any draw on the Android device’s battery.

All Android devices from V3.1 (Honeycomb) support the Android Open Accessory Mode (AOAM). The AOAM is the complete reverse of the conventional USB interconnect. This game-changing approach to attaching peripherals enables three key advantages. First, there is no need to develop special drivers for the hardware; second, it is unnecessary to root devices to alter permissions for loading drivers; and third, the peripheral provides the power to use the port, which ensures the mobile device battery is not quickly drained by the external hardware being attached.

Since the FT311D handles the entire USB host protocol, USB-specific firmware programming isn’t required. As the host, the FT311D must inquire whether the connected device supports the AOAM. If so, it will operate as an Open Accessory Mode device with one USB BULK IN endpoint and one USB BULK OUT endpoint (as well as the control endpoint.) This interface will be a full-speed (12-Mbps) USB enabling data transfer in and out.

The AOAM USB host has a set of string descriptors the Android OS is capable of reading. These strings are (user) associated with an Android OS application. The Android then uses these strings to automatically start the application when the hardware is connected. The FT311D is configured for one of its multiple interfaces via configuration inputs at power-up. Each configuration will supply the Android device with a unique set of string descriptors, therefore enabling different applications to run, depending on its setup.

The FT311D’s configuration determines whether each application will have access to several user interface APIs that are specific to each configuration.

The article goes on to examine the various interfaces in detail and to describe a number of demo projects, including a multimeter.

Many of Bachiochi's projects use printable ASCII text commands and replies. This enables a serial terminal to become a handy user I/O device. This current probe circuit outputs its measurements in ASCII-printable text.

Many of Bachiochi’s projects use printable ASCII text commands and replies. This enables a serial terminal to become a handy user I/O device. This current probe circuit outputs its measurements in ASCII-printable text.

Multimeters are great tools. They have portability that enables them to be brought to wherever a measurement must be made. An Android device has this same ability. Since applications can be written for these devices, they make a great portable application tool. Until the AOAM’s release, there was no way for these devices to be connected to any external circuitry and used as an effective tool.

I think FTDI has bridged this gap nicely. It provided a great interface chip that can be added to any circuit that will enable an Android device to serve as an effective user I/O device. I’ve used the chip to quickly interface with some technology to discover its potential or just test its abilities. But I’m sure you are already thinking about the other potential uses for this connection.

Bachiochi is curious to hear from readers about their own ideas.

If you think the AOAM has future potential, but you want to know what’s involved with writing Android applications for a specific purpose, send me an e-mail and I’ll add this to my list of future projects!

You can e-mail Bachiochi at jeff.bachiochi@imaginethatnow.com or post your comment here.

 

Scott Garman, Technical Evangelist

This article was a preview of an upcoming interview in the February issue of Circuit Cellar. The full interview is now available here.
Garman_web

Scott Garman is a Portland, OR-based Linux software engineer. Scott is very involved with the Yocto Project, an open-source collaboration that provides tools for the embedded Linux industry. Scott tells us about how he recently helped Intel launch MinnowBoard, the company’s first open-hardware SBC. The entire interview will be published in Circuit Cellar’s February issue.—Nan Price, Associate Editor

NAN: What is the Yocto Project?

 SCOTT: The Yocto Project is centered on the OpenEmbedded build system, which offers a tremendous amount of flexibility in how you can create embedded Linux distros. It gives you the ability to customize nearly every policy of your embedded Linux system.

I’ve developed training materials for new developers getting started with the Yocto Project, including “Getting Started with the Yocto Project—New Developer Screencast Tutorial.”

MinnowBoardWEB

Scott was involved with a MinnowBoard robotics and computer vision demo at LinuxCon Japan, May 2013.

NAN: Tell us about Intel’s recently introduced the MinnowBoard SBC.

SCOTT: The MinnowBoard is based on Intel’s Queens Bay platform, which pairs a Tunnel Creek Atom CPU (the E640 running at 1 GHz) with the Topcliff Platform controller hub. The board has 1 GB of RAM and includes PCI Express, which powers our SATA disk support and gigabit Ethernet. It’s an SBC that’s well suited for embedded applications that can use that extra CPU and especially I/O performance.

MinnowBoardOWI_web

Scott worked on a MinnowBoard demo built around an OWI Robotic Arm.

The MinnowBoard also has embedded bus standards including GPIO, I2C, SPI, and even CAN (used in automotive applications) support. We have an expansion connector on the board where we route these buses, as well as two lanes of PCI Express for custom high-speed I/O expansion.

NAN: What compelled Intel to make the MinnowBoard open hardware?

SCOTT: The main motivation for the MinnowBoard was to create an affordable Atom-based development platform for the Yocto Project. We also felt it was a great opportunity to try to release the board’s design as open hardware.

Two-Channel CW Laser Diode Driver with an MCU Interface

The iC-HT laser diode driver enables microcontroller-based activation of laser diodes in Continuous Wave mode. With this device, laser diodes can be driven by the optical output power (using APC), the laser diode current (using ACC), or a full controller-based power control unit.

The maximum laser diode current per channel is 750 mA. Both channels can be switched in parallel for high laser diode currents of up to 1.5 A. A current limit can also be configured for each channel.

Internal operating points and voltages can be output through ADCs. The integrated temperature sensor enables the system temperature to be monitored and can also be used to analyze control circuit feedback. Logarithmic DACs enable optimum power regulation across a large dynamic range. Therefore, a variety of laser diodes can be used.

The relevant configuration is stored in two equivalent memory areas. Internal current limits, a supply-voltage monitor, channel-specific interrupt-switching inputs, and a watchdog safeguard the laser diodes’ operation through iC-HT.

The device can be also operated by pin configuration in place of the SPI or I2C interface, where external resistors define the APC performance targets. An external supply voltage can be controlled through current output device configuration overlay (DCO) to reduce the system power dissipation (e.g., in battery-operated devices or systems).

The iC-HT operates on 2.8 to 8 V and can drive both blue and green laser diodes. The diode driver has a –40°C-to-125°C operating temperature range and is housed in a 5-mm × 5-mm, 28-pin QFN package.

The iC-HT costs $13.20 in 1,000-unit quantities.

iC-Haus GmbH
www.ichaus.com