Long-Range, Memory Jewelry-Tagging Solution

EMThe EM4126 EPC radio-frequency identification (RFID) IC is designed to provide RFID tagging on small and/or high-value products (e.g., jewelry and watches). The IC’s high sensitivity enables long read ranges. EM4126-based tags can achieve –21-dBm read sensitivities. The ICs are designed for supply chain management, tracking and tracing, container identification, and access and asset control applications.

The EM4126’s 224 bits of nonvolatile memory support International Organization for Standardization (ISO) or Electronic Product Code (EPC) data structures and enable SGTIN-198 encoding, which uses alphanumeric serialization represented as a string of up to 20 7-bit characters. The EM4126’s additional features include ISO 18000-63 and EPC Class-1 Generation-2 compliance, 32-bit short-tag identification, 40-to-160 Kbps forward- and return-link data rates, and a –40°C-to-85°C extended temperature range.

Contact EM Microelectronic for pricing.

EM Microelectronic
www.emmicroelectronic.com

The Sun Chaser Energy-Harvesting System

When Sjoerd Brandsma entered the 2012 Renesas Green Energy Challenge, he wanted to create a fun project that would take advantage of his experience at a company that heavily uses GPS.

Brandsma, who lives in Kerkwijk, The Netherlands, has worked as a software engineer and is currently an R&D manager at CycloMedia, which produces 360° street-level panoramic images with geographic information system (GIS) accuracy.

Ultimately, Brandsma’s Sun Chaser project won third prize in the Renesas Green Energy Challenge. The Sun Chaser is an energy-harvesting system that automatically orients a solar panel to face the sun.

Photo 1: The Sun Chaser’s stepper motor controls the solar panel‘s “tilting.”

Photo 1: The Sun Chaser’s stepper motor controls the solar panel‘s “tilting.”

“The Sun Chaser perfectly follows the sun’s path and keeps the battery fully charged when there’s enough sunlight,” Brandsma says in his article about the project, which appears in Circuit Cellar’s June issue. ”It can power a small electronics system as long as there’s enough sunlight and no rain, which would damage the system due to lack of protection. This project also demonstrates that it’s possible to build an interesting green-energy system with a tight budget and a limited knowledge of  electronics.”

A registered GPS calculates the orientation of the Sun Chaser’s solar panel, which is mounted on a rotating disc. “You can use an external compass, the internal accelerometer, a DC motor, and a stepper motor to determine the solar panel’s exact position,” Brandsma says. “The Sun Chaser uses Renesas Electronics’s RDKRL78G13 evaluation board running the Micriµm µC/OS-III real-time kernel.”

The following article excerpt describes the GPS reference station and evaluation board in greater detail. The issue with Brandsma’s full article is available online for membership download or single-issue purchase.

GPS REFERENCE STATION
Whenever you want to know where you are, you can use a GPS receiver that provides your position. A single GPS receiver can provide about 10 to 15 m (i.e., 33’ to 50’) position accuracy. While this is sufficient for many people, some applications require positioning with significantly higher accuracy. In fact, GPS can readily produce positions that are accurate to 1 m (3’), 0.5 m (18”), or even 1 to 2 cm (less than 1“). A technique called “differential GPS” can be used to achieve higher accuracy.

The differential technique requires one GPS receiver to be located at a known position (often called a control or reference point) and a second “rover” receiver at the location to be measured. The information from the two GPS receivers (rover and control) is combined to determine the rover’s position. That’s where a GPS reference station comes in. It functions as the control point and serves potentially unlimited users and applications. Leica Geosystems has published an excellent introductory guide about GPS reference stations (Refer to the Resources at the end of this article.)

The GPS reference station should always be located at a position with a broad sight. In some situations it can be difficult to provide a decent power supply to the system. When regular power isn’t available, a solar panel can power the GPS reference station.

My Sun Chaser GPS reference station uses a 10-W solar panel connected to a 12-V battery to provide enough power. To increase the energy harvesting, the solar panel is mounted on a rotating disc that can be controlled by a DC motor to point in the desired direction. A stepper motor controls the solar panel’s “tilting.” Photo 1 highlights the main components.

USING THE EVALUATION BOARD
The RDKRL78G13 is an evaluation and demonstration tool for Renesas Electronics’s RL78 low-power microcontrollers. A set of human-machine interfaces (HMIs) is tightly integrated with the RL78’s features. I used several of these interfaces to control other devices, read sensors, or store data.

Most of the system’s hardware is related to placing the solar panel in the correct position. Figure 1 shows the top-level components used to store the GPS information and position the solar panel.

Figure 1: The Sun Chaser’s components include a Renesas Electronics RDKRL78G13 evaluation board, a GPS receiver, a stepper motor, and an SD card.

Figure 1: The Sun Chaser’s components include a Renesas Electronics RDKRL78G13 evaluation board, a GPS receiver, a stepper motor, and an SD card.

The RDKRL78G13 evaluation board has an on-board temperature and light sensor. Both sensor values are stored on the SD card. The on-board light sensor is used to determine if rotating/tilting makes sense (at night it’s better to sleep). For this project, the temperature values are stored just for fun so I could make some graphs or do some weather analysis.

A micro-SD memory card slot on the RDKRL78G13 evaluation board provides file system data storage. I used it to store all incoming data and log messages using the FAT16/FAT32 file system.

The on-board Renesas Electronics RQK0609CQDQS MOSFET controls the DC motor that rotates the evaluation board. The DC motor can be controlled by applying a PWM signal generated from one of the RL78’s timers. The MOSFET is controlled by the RL78’s TO05 port and powered from the 12-V battery. A PWM signal is generated on TO05 by using Timer4 as a master and Timer5 as a slave. It’s only necessary to rotate clockwise, so additional hardware to rotate the platform counterclockwise is not required.

A digital compass is needed to determine the evaluation board’s rotated position or heading (see Figure 2). The Honeywell HMC5883L is a widely used and low-cost compass. This I2C-based compass has three-axis magnetoresistive sensors and a 12-bit ADC on board. It can read out values at a 160-Hz rate, which is more than enough for this project.

Figure 2: A Honeywell HMC5883L digital compass verifies the evaluation board’s rotated position or heading.

Figure 2: A Honeywell HMC5883L digital compass verifies the evaluation board’s rotated position or heading.

The compass uses the RL78’s IICA0 port through the Total Phase Beagle debug header, which is mounted on the RDKRL78G13 evaluation board. The Beagle analyzer provides easy access to this I2C port, which increases the flexibility to change things during prototyping.

The HMC5883L compass turned out to be a very sensitive device. Even the slightest change in the hardware setup seemed to influence the results when rotating. This meant some sort of calibration was needed to ensure the output was consistent every time the system started. [Brandsman's full article descibes how how the HMC5883L can be calibrated. It’s important to know that every time the system starts, it makes a full turn to calibrate the compass.

A GPS module must be connected to the system to provide the system’s current location. I wanted the GPS module to be inexpensive, 3.3-V based, and have an easy and accessible interface (e.g., UART).

Figure 3 shows a schematic of a Skylab M&C Technology SKM53 GPS module, which is based on the MediaTek 3329 GPS receiver module. This module supports NMEA messages and the MTK NMEA Packet Protocol interface to control things such as power saving, output message frequency, and differential global positioning system (DGPS).

Unfortunately, the 3329 receiver can’t output “raw” GPS data (e.g., pseudorange, integrated carrier phase, Doppler shift, and satellite ephemeris), which would significantly improve the GPS reference station’s capabilities. Due to budget and time limitations (it takes some more software development effort to handle this raw data), I didn’t use a receiver that could output raw GPS data.

Figure 3:A Skylab M&C Technology SKM53 GPS receiver obtains the system’s current location.

Figure 3:A Skylab M&C Technology SKM53 GPS receiver obtains the system’s current location.

The SKM53 GPS receiver is connected to the RL78’s UART2. All data from the GPS receiver is stored on the SD card. As soon as a valid GPS position is received, the system calculates the sun’s position and moves the platform into the most ideal position.

A compact stepper motor is needed to tilt the platform in very small steps. The platform had to be tilted from fully vertical to fully horizontal in approximately 6 h when the sun was exactly following the equator, so speed wasn’t really an issue. I wanted to do very fine tilting, so I also needed a set of gears to slow down the platform tilting.

I used an inexpensive, easy-to-use, generic 5-V 28BYJ-48 stepper motor (see Figure 4). According to the specifications, the 28BYJ-48 stepper motor has a 1/64 gear reduction ratio and 64 steps per rotation (5.625°/step) of its internal motor shaft.

An important consideration here is that you don’t want to retain power on the stepper motor to keep it in position. This particular stepper motor has some internal gears that prevent the platform from flipping back when the stepper motor is not powered.

The stepper motor can be controlled by the well-known ULN2003 high-voltage high-current Darlington transistor array. The ULN2003 is connected to P71-P74. Each of the ULN2003’s four outputs is connected to one of the stepper motor’s coils. When two neighbor coils are set high (e.g., P72 and P73), the stepper motor will step in that direction.

When it comes to solar panels, you can build your own panel out of individual solar cells or buy a fully assembled one with known specifications. I used a no-name 10-W solar panel. The size (337 mm long × 205 mm wide × 18 mm high) was acceptable and it delivered more than enough energy. I used a charge controller to protect the battery from overcharging and to prevent it from supplying power to the solar panel at night.

Like solar panels, many charge controllers and battery protectors can be used in such a system. I chose the lazy approach: Just take one off the shelf. The CMP12/24 charge controller is specially designed for small solar systems. It has a stabilized 12-V output, which is taken from the connected battery. It can handle up to 12 A of charging or load current and, according to the specifications, it consumes about 20 mA of quiescent current. There is some room for improvement, but it worked for my project.

I had some 7805 voltage regulators lying around, which I figured could do the job and supply just enough power when the system was starting up. However, when it comes to power saving, the 7805 is not the way to go. It’s a linear regulator that works by taking the difference between the input and output voltages and burning it up as wasted heat.

What I needed was a switching regulator or a buck converter. I used a National Semiconductor (now Texas Instruments) LM2596. Note: The LM2596 is made by several companies and is available in inexpensive, high-quality modules (most cost a little more than $1 per converter). These ready-to-use modules already have the necessary capacitors, diodes, and so forth on board, so it’s really a matter of plug and play.

I used a lead acid RT1219 12-V 1.9-AH battery for power storage. You can use any 12-V battery with sufficient capacity.

Editor’s Note: Check out other projects from the 2012 Renesas RL78 Green Energy Challenge.

Measuring Jitter (EE Tip #132)

Jitter is one of the parameters you should consider when designing a project, especially when it involves planning a high-speed digital system. Moreover, jitter investigation—performed either manually or with the help of proper measurement tools—can provide you with a thorough analysis of your product.

There are at least two ways to measure jitter: cycle-to-cycle and time interval error (TIE).

WHAT IS JITTER?
The following is the generic definition offered by The International Telecommunication Union (ITU) in its G.810 recommendation. “Jitter (timing): The short-term variations of the significant instants of a timing signal from their ideal positions in time (where short-term implies that these variations are of frequency greater than or equal to 10 Hz).”

First, jitter refers to timing signals (e.g., a clock or a digital control signal that must be time-correlated to a given clock). Then you only consider “significant instants” of these signals (i.e., signal-useful transitions from one logical state to the other). These events are supposed to happen at a specific time. Jitter is the difference between this expected time and the actual time when the event occurs (see Figure 1).

Figure 1—Jitter includes all phenomena that result in an unwanted shift in timing of some digital signal transitions in comparison to a supposedly “perfect” signal.

Figure 1—Jitter includes all phenomena that result in an unwanted shift in timing of some digital signal transitions in comparison to a supposedly “perfect” signal.

Last, jitter concerns only short-term variations, meaning fast variations as compared to the signal frequency (in contrast, very slow variations, lower than 10 Hz, are called “wander”).

Clock jitter, for example, is a big concern for A/D conversions. Read my article on fast ADCs (“Playing with High-Speed ADCs,” Circuit Cellar 259, 2012) and you will discover that jitter could quickly jeopardize your expensive, high-end ADC’s signal-to-noise ratio.

CYCLE-TO-CYCLE JITTER
Assume you have a digital signal with transitions that should stay within preset time limits (which are usually calculated based on the receiver’s signal period and timing diagrams, such as setup duration and so forth). You are wondering if it is suffering from any excessive jitter. How do you measure the jitter? First, think about what you actually want to measure: Do you have a single signal (e.g., a clock) that could have jitter in its timing transitions as compared to absolute time? Or, do you have a digital signal that must be time-correlated to an accessible clock that is supposed to be perfect? The measurement methods will be different. For simplicity, I will assume the first scenario: You have a clock signal with rising edges that are supposed to be perfectly stable, and you want to double check it.

My first suggestion is to connect this clock to your best oscilloscope’s input, trigger the oscilloscope on the clock’s rising edge, adjust the time base to get a full period on the screen, and measure the clock edge’s time dispersion of the transition just following the trigger. This method will provide a measurement of the so-called cycle-to-cycle jitter (see Figure 2).

Figure 2—Cycle-to-cycle is the easiest way to measure jitter. You can simply trigger your oscilloscope on a signal transition and measure the dispersion of the following transition’s time.

Figure 2—Cycle-to-cycle is the easiest way to measure jitter. You can simply trigger your oscilloscope on a signal transition and measure the dispersion of the following transition’s time.

If you have a dual time base or a digital oscilloscope with zoom features, you could enlarge the time zone around the clock edge you are interested in for more accurate measurements. I used an old Philips PM5786B pulse generator from my lab to perform the test. I configured the pulse generator to generate a 6.6-MHz square signal and connected it to my Teledyne LeCroy WaveRunner 610Zi oscilloscope. I admit this is high-end equipment (1-GHz bandwidth, 20-GSPS sampling rate and an impressive 32-M word memory when using only two of its four channels), but it enabled me to demonstrate some other interesting things about jitter. I could have used an analog oscilloscope to perform the same measurement, as long as the oscilloscope provided enough bandwidth and a dual time base (e.g., an old Tektronix 7904 oscilloscope or something similar). Nevertheless, the result is shown in Figure 3.

Figure 3—This is the result of a cycle-to-cycle jitter measurement of the PM5786A pulse generator. The bottom curve is a zoom of the rising front just following the trigger. The cycle-to-cycle jitter is the horizontal span of this transition over time, here measured at about 620 ps.

Figure 3—This is the result of a cycle-to-cycle jitter measurement of the PM5786A pulse generator. The bottom curve is a zoom of the rising front just following the trigger. The cycle-to-cycle jitter is the horizontal span of this transition over time, here measured at about 620 ps.

This signal generator’s cycle-to-cycle jitter is clearly visible. I measured it around 620 ps. That’s not much, but it can’t be ignored as compared to the signal’s period, which is 151 ns (i.e., 1/6.6 MHz). In fact, 620 ps is ±0.2% of the clock period. Caution: When you are performing this type of measurement, double check the oscilloscope’s intrinsic jitter as you are measuring the sum of the jitter of the clock and the jitter of the oscilloscope. Here, the latter is far smaller.

TIME INTERVAL ERROR
Cycle-to-cycle is not the only way to measure jitter. In fact, this method is not the one stated by the definition of jitter I presented earlier. Cycle-to-cycle jitter is a measurement of the timing variation from one signal cycle to the next one, not between the signal and its “ideal” version. The jitter measurement closest to that definition is called time interval error (TIE). As its name suggests, this is a measure of a signal’s transitions actual time, as compared to its expected time (see Figure 4).

Figure 4—Time interval error (TIE) is another way to measure jitter. Here, the actual transitions are compared to a reference clock, which is supposed to be “perfect,” providing the TIE. This reference can be either another physical signal or it can be generated using a PLL. The measured signal’s accumulated plot, triggered by the reference clock, also provides the so-called eye diagram.

Figure 4—Time interval error (TIE) is another way to measure jitter. Here, the actual transitions are compared to a reference clock, which is supposed to be “perfect,” providing the TIE. This reference can be either another physical signal or it can be generated using a PLL. The measured signal’s accumulated plot, triggered by the reference clock, also provides the so-called eye diagram.

It’s difficult to know these expected times. If you are lucky, you could have a reference clock elsewhere on your circuit, which would supposedly be “perfect.” In that case, you could use this reference as a trigger source, connect the signal to be measured on the oscilloscope’s input channel, and measure its variation from trigger event to trigger event. This would give you a TIE measurement.

But how do you proceed if you don’t have anything other than your signal to be measured? With my previous example, I wanted to measure the jitter of a lab signal generator’s output, which isn’t correlated to any accessible reference clock. In that case, you could still measure a TIE, but first you would have to generate a “perfect” clock. How can this be accomplished? Generating an “ideal” clock, synchronized with a signal, is a perfect job for a phase-locked loop (PLL). The technique is explained my article, “Are You Locked? A PLL Primer” (Circuit Cellar 209, 2007.) You could design a PLL to lock on your signal frequency and it could be as stable as you want (provided you are willing to pay the expense).

Moreover, this PLL’s bandwidth (which is the bandwidth of its feedback filter) would give you an easy way to zoom in on your jitter of interest. For example, if the PLL bandwidth is 100 Hz, the PLL loop will capture any phase variation slower than 100 Hz. Therefore, you can measure the jitter components faster than this limit. This PLL (often called a carrier recovery circuit) can be either an actual hardware circuit or a software-based implementation.

So, there are at least two ways to measure jitter: Cycle-to-cycle and TIE. (As you may have anticipated, many other measurements exist, but I will limit myself to these two for simplicity.) Are these measurement methods related? Yes, of course, but the relationship is not immediate. If the TIE is not null but remains constant, the cycle-to-cycle jitter is null.  Similarly, if the cycle-to-cycle jitter is constant but not null, the TIE will increase over time. In fact, the TIE is closely linked to the mathematical integral over time of the cycle-to-cycle jitter, but this is a little more complex, as the jitter’s frequency range must be limited.

Editor’s Note: This is an excerpt from an article written by Robert Lacoste, “Analyzing a Case of the Jitters: Tips for Preventing Digital Design Issues,” Circuit Cellar 273, 2013.

Experimentation and Engineering

Frederic Vecoven is software engineer living in Luxembourg who enjoys experimenting with everything from his home’s central heating controller to FPGAs. He has been designing micrcontroller-based projects for more than a dozen years and is currently working on an EPROM emulator.—Nan Price, Associate Editor

 

NAN: What is your current occupation?

FREDERIC:: I am a software principal engineer at Oracle.

NAN: Your website Vecoven.com features projects involving capacitors, microcontrollers, and EEPROM and hardware emulators. Tell us a little about the projects and your design process.

vecovenFREDERIC: At work I design firmware for high-end servers. At home I like to design my own stuff, so I have full control and can create new devices and/or enhance existing ones. I work on various projects and I don’t find enough time to document all of them on the website. For example, I designed a controller for the central heating in my house, but never documented it (it’s too “custom”). I love retrocomputing, which is how my FreHD project started. This is a hard-drive emulator for TRS-80 computers.

My design process starts from an idea (I have too many, so I must carefully select one) then a lot of thinking about the future implementation (as always, designing something is about compromises). Once I have a clear view in my mind about how things should work, I start prototyping. If possible, I use a breadboard or I create a PCB. Sometimes I do a lot of simulation before starting the prototyping, as this will save a lot of time. However, that cannot be done for all projects.

NAN: How long have you been designing microcontroller-based systems?

FREDERIC: More than 15 years.

NAN: How did you become interested in technology?

FREDERIC: When I was 13 years old I fell in love with computers when I saw a TRS-80 model in high school. I am thankful to my parents, who gave me a computer one year later.
I went to college and got a master’s degree in computer science. But I wasn’t satisfied, so I studied some more years to get another master’s degree, this time in electrical engineering. The combination of software and hardware is really powerful. A few years later, I relocated to the San Francisco Bay Area, but I am back in Europe now.

NAN: Describe the first embedded system you designed. Where were you at the time? What did you learn from the experience?

FREDERIC: My first big experience with a real embedded system was when I was working for Sun Microsystems. My group was writing the firmware for the system controllers of the SunFire 3800-6900 line. The embedded system was a small SPARC CPU running Wind River Systems’s VxWorks and the firmware was almost entirely written in Java.

NAN: What was the last electronics design-related product you purchased and how did you use it?

FREDERIC: I bought some FPGAs recently. I haven’t released any project with it yet, it is still a work in progress. My hobby time is very limited.

My idea is to use a CPU core and enhance it with new instructions to enable the generation of real-time signals. FPGAs are very powerful in that area, where a microcontroller would spend most of its time processing interrupts.

NAN: Are you currently working on or planning any projects?

Vecoven_PWM

This is Frederic’s PWM prototype for his Roland Super JX synthesizer.

FREDERIC: Yes, I have rewritten the Roland JX-10/MKS-70 firmware from scratch because I wanted to add PWM waveforms. This quickly turned into a big project. Currently, the prototype setup involves a simulator running the “assigner” code on my laptop. The laptop sends the sound board commands in System Exclusive (SysEx) Musical Instrument Digital Interface (MIDI) messages, which go to a microcontroller that extracts the payload from the SysEx. The payload is then sent to the sound board, which believes it got its instructions directly from the assigner. The sound board (which runs its own microcontroller) uses an EPROM emulator connected over USB, so I can easily modify the assigner code (running in the simulator) or the sound board code (running in the EPROM emulator) without having to program any chip. Note that I didn’t have an EPROM emulator, so I designed mine.

Vecoven_scope

This oscilloscope capture shows the generated PWM signal.

FREDERIC: The power of CPUs and GPUs are really exciting. You can pretty much do everything with software now (a 32-bit core costs less than $5).
On the other side, people don’t pay enough attention to optimization, so I am sad anytime I see poorly written code. I am also excited with all the tools and hardware available today for so little cost. That wasn’t the case in the past, so it opens door to students and hobbyists.

NAN: Last question. Let’s say you had a full year and a nice budget to work on any embedded design project you wanted. Call it your “dream project.” What would it be?

FREDERIC: I would love to do some robotic design, but I am not an expert in mechanics and I don’t have the tools (e.g., lathe, milling machine, etc.). That would fill the gap: hardware, software, and mechanics.

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