CE012 Step-Up Boost – What’s Inside?

I am getting ready to design a circuit using the ME2108A Step-Up voltage converter, but first I wanted to closely examine the CE012 Voltage converter that I recently posted about – HERE. Since Canton Electronic’s  CE012 module performed so well I figured that it wouldn’t hurt to examine it closely since their design seemed different from the chip manufacturer’s examples.

Last year, I purchased a ICStation LC100-A High Precision Digital Inductance Capacitance meter on eBay. There are several versions of the LC100 being sold with some physical variation, mostly in pushbutton switch placement, but mine matches the functionality of the user manual for one of the different ones, so I suspect that they are all copies of each other. They are very inexpensive (under $20USD) yet perform admirably with about a 10% tolerance. It does have one fault – the alligator clips are too large and difficult to work with.

I used a hot-air rework station, also a fairly recent purchase, to take apart one of the CE012 Voltage Converter modules. Next, I used the LC100 to measure the inductive and capacitance components. Of particular interest were two totally unmarked SMD capacitors. Once again, the LC100 did its job! I have included photos of the inductor being tested. It is marked “220”. It is listed as a 22uH inductor with a SFOP4521 footprint – but I wanted to measure it to be sure.

The two capacitors measured 12uF and seem similar to Kemet C1210C126K8PACTU.  I believe them to be size EIA1210/METRIC3225. The module has one DO-214 packaged 1A Schottky diode, type SS14.  Of course it has a ME2108A Step-Up convertor, as described in my previous post. Last, there is the inductor, which is shown in the photos below. So, that’s it – five components plus the PCB.

After tracing out the CE012’s design, which was vastly easier with the components removed, I discovered that it is the same as the chip manufacturer’s first example titled “For use Built-in Transistor”. The apparent difference was just that the CE102 parallels two SMD 12uF capacitors to obtain 24uF. The components vary from the chip manufacturer’s example. The example uses a 47uF capacitor and a 47uH inductor while the CE102 uses a 24uF combined capacitor and a 22uH inductor. BTW, I found that additional filtering capacitance is required on the output, especially with the 5V version, which is rather saw-tooth looking. The 3V output is fairly smooth. I used a 1,000uF electrolytic but a lesser value would probably suffice and a tantalum may be a better choice. The schematic of the CE102 is shown in Figure 1, below.


Fig. 1: Schematic CE102 by Canton-Power

Okay, the images below show the CE102’s inductor under test with the LC100-A Digital Inductance Capacitance meter. Click on the image to enlarge it.


Posted in Electronics, hardware, Test Equipment | Tagged , , , | Leave a comment

Manchester for Arduino

There are several Manchester Coding libraries for Arduino wireless transfer (See http://tinyurl.com/jh95cju), I have gotten two of them to work satisfactorily for communicating a single byte of data. Both the “Mchr3k” library “http://mchr3k.github.io/arduino-libs-manchester/” and cano64’s library “https://github.com/cano64/ManchesterRF” worked for singly byte transfers but I needed more than one byte. The libraries of both Mchr3k and cano64 claim support array transfer but I could never get cano64’s to work. However, I was successful with Mchr3k’s transmitArray() and beginReceiveArray().

void transmitArray(uint8_t numBytes, uint8_t *data);

void beginReceiveArray(uint8_t maxBytes, uint8_t *data);

Getting Mchr3k’s code to work was a bit exasperating but ultimately successful. Mchr3k’s minimal documentation is focused on the single byte transfer. Array transfer is mostly ignored in the documentation. As a result, it was not obvious, to me at least, that the first byte in the array MUST be the array size. I had incorrectly expected the array size to be internally added and stripped such that the library would deliver an unmolested data array. I didn’t want to store the array size in my array but it was unavoidable. This was NOT the case I eventually discovered that the first byte in the array MUST be set to the array size by the coder and Bingo – it started working. Before I discovered this, the first byte of my array just happened to be a zero and that did not work at all – requesting to send zero bytes has exactly that result!

Posted in Arduino, Programming, software | 10 Comments

STX-882 / SRX-882 Radio Testing

I recently did some testing of the STX-882 433HHz transmitter and the SRX-882 433MHz receiver and, after additional tests, updated my original findings.

I tested line-of-sight along a road. I performed two tests using Arduino NANOs and two laptops, shown below in Figure 1.

Fig 1. STX/SRX-882 Test laptops

Fig 1. STX/SRX-882 Test laptops

Both of the radios were equipped with the Helical antennas that were supplied by the seller. They are being powered by the USB port, so the tests are using 5 Volts despite having read that the radios “may” perform best at 3.3 volts. There was no ground plane and, in fact, no connection to earth ground at all. This is not ideal, that is for sure, but “that” is what was tested.

For the first test I wrote a simple test program that transmits a string with an incrementing number that utilized the RadioHead library. The outcome was somewhat disappointing. The manufacturer only claims a range of “Long distance working with STX882“. In my test reliable communications was limited to 55 feet (16 3/4 meters).

For my second test I used the cano64/ManchesterRF  Manchester code library and its test programs with some serial output added. I am interested in this library because Manchester coding is said to make for more reliable communications when using ATTiny85s, which is my final goal. The RC oscillator in ATTiny85 is reputed to drift, especially with temperature change. By the way, I first planned to test the PJON SoftwareBitBang library but the compiled code was so large that there was little space left for my application – so I abandoned PJON. There was an attempt to write a more compact version of PJON, named PJON_C, but the repository seems broken/incomplete and will not compile.

The outcome of this second test was slightly better – 70 feet (21+ meters), a 27% improvement but still not what I would call Long Distance.

Part of the problem may be the cute and convenient coiled antennas. After reading THIS-ARTICLE I see that the coiled antennas are more inferior to a straight wire than I anticipated – 10dB worse in the author’s experiments. 10dB is a lot ~ 316%. If the experiments by the author, Ralph Doncaster, are correct, using 16.5cm straight wire antennas may yield a 50-to-64 meter range. In my planned application a 16.5cm straight wire antenna is feasible. Using a half wave dipole antenna should perform even better, Doncaster says 10dB better, but physical space (33cm) would be a problem for my application.

UPDATE: I made some quarter-wave 433MHz antennas, see Figure 2 below,  for the STX/SRX-882 radios and repeated the same test as before, namely the cano64/ManchesterRF  Manchester code library and its test programs with some serial output added, line-of-sight along a road. I performed two tests using Arduino NANOs and two laptops, the same as before.

Fig. 2: 433MHz 1/4 wave and coil Antennas

Fig. 2: 433MHz 1/4 wave and coil Antennas

The results with the λ/4 antennas were a significant improvement over the Chinese eBay coil antennas. Error free range was 135 feet (41.15m). I must point out that performance may actually be better on flat ground than my tests indicate. This is because my road is a steep incline. The λ/4 antenna radiation pattern looks a bit like a doughnut.  Propagation along flat ground (see red line) provides the greatest range. However, as I walk down my road (see green line) the propagation pattern would, in theory, indicate reduced range. In 41 meters possibly this isn’t relevant, but level ground tests may show an improvement.

Fig. 3: Side View of Radiation Pattern

Fig. 3: Side View of Radiation Pattern

Also, I was curious about the actual frequency emitted by the 433MHz STX-882 transmitter so I searched my closet until I found my old SDR USB receiver stick. Mine is only labeled “DAB+FM+DVB-T” but it is one of many similar inexpensive devices based on the RTL2832 IC by Realtek Corporation. I use the SDR fob with the GQRX Open Source software. The STX-882 manufacturer’s datasheet indicates its frequency is 433.82(min), 433.92(typical), 434.02(max). Refer to Figure 4 and you’ll see that my STX-882 is working right at the “typical” frequency. The vertical red line is where my transmitter is transmitting every 5 seconds and the little red spot in the yellow area below the red line was one such transmission. If you are ultra curious or very board, you can hear a mp3 format sample audio output from the gqrz software at THIS-LINK.

Measured STX-882 Frequency

Fig. 4: Measured STX-882 Frequency

UPDATE#2: I took the SRX/STX-882 radios e/w λ/4 antennas to my local jogging track oval so that I could test on level ground. Results were identical to my sloping road – Error free range was 135 feet (41.15m). There is a pretty quick drop off – like a cliff – beyond that distance. Go to 138 feet (42.06m) and dropouts start.

UPDATE#3: Again, with the same SRX/STX-882 radios and λ/4 antennas, I retested on my sloped street but, this time, with mchr3k’s Manchester array library.  I used his array functions – transmitArray and receiveArray to communicate seven bytes of data per transmission. I send the array shown below:

struct measurement {
  uint8_t payload_size;       // Used by Manchester library
  uint8_t node;          // Network node ID - 0 to 254
  uint8_t humidity;      // humidity as integer byte storage
  int16_t temperature;   // Temperature as integer storage
  uint8_t ticks;         // Ticking count 0 - to -255
  uint8_t checksum;      // Checksum

Using mchr3K’s array library my testing yielded a reliable 146 foot range. Again, There is a sharp digital type drop off cliff as in 146′ works reliably but 147′ does not.

Posted in Arduino, Electronics, Programming, software, wireless | Tagged , , , | 1 Comment

A Tiny but Good Boost Converter

As I continue to experiment with voltage boost converters I was intrigued by some Chinese DC-DC Boost Converter modules. There are several different types and module configurations, depending upon the manufacturer and chip type. I opted to buy a couple of modules made by Shenzhen Canton-Power Electronic Technology Co.,Ltd a four year old Chinese company which, based on their website photos, is a pretty small shop with about a twelve workstation capability.

I ordered two 0.8~3v to 3.3v Step Up Boost DC to DC Converters from a Hong Kong seller on eBay. I paid more for these to get them faster. Interestingly, I ordered what the Hong-Kong seller identified as a WTI-0833 module. However, what was delivered was a CE012 module – AND – it was delivered by a USA company based in Virginia. While the WTI-0833 and CE012 are physically different PCB layouts they appear to functionally equivalent and both use the 2108A ASIC. Canton-electronic sells the CE012 on eBay in single quantities for $1.59, delivered. The 5V output version is available via aliexpress – $1.26 in a quantity of eight, which I also ordered and it was delivered as I write this. Both of these modules utilize the 2108A boost chip. The 3.3V version is marked 2108A 1552/32 while the 5V version is marked 2108A 1620/50. They both have the following manufacturer’s logo on the chip:


2108A-1532/33 – 3.3 Volt Version
Input 0.8 ~ 3.3V output 3.3V
Maximum output current 500 MA,
Start Voltage 0.8V Output Current 10MA
INPUT 1-1.5V OUTPUT 3.3V 50-110MA;
INPUT 1.5-2V OUTPUT 3.3V 110-160MA;
INPUT 2-3V OUTPUT 3.3V 160-400MA;
INPUT above 3V OUTPUT 3.3V 400-500MA;
Boostfrequency 150KHZ efficiency 85% .
2.54mm pin pitch Breadboard friendly.
Excluding Pins 11mm x 10.5mm x 7.5mm
Weight ~1.2g
2108A-1620/50 5V Version
Input 0.9 ~ 5V, output 5V
Maximum output current 500 MA,
Start Voltage 0.9V Output Current 10MA
INPUT 1-1.5V OUTPUT 5V 50-110MA;
INPUT 1.5-2V OUTPUT 5V 110-160MA;
INPUT 2-3V OUTPUT 5V 160-400MA;
INPUT above 3V OUTPUT 5V 400-500MA;
Boostfrequency 180KHZ efficiency 85% .
Operating ambient temperature -25~+85 Degrees Celsius
2.54mm pin pitch Breadboard friendly.
Excluding Pin Size 11mm x 10.5mm x 7.5mm
Weight about 1.2g

The DC-DC converter package is a rather odd looking SOT89-3. The manufacturer of the chip was quite elusive but I was able to identify them. The 2108A DC-DC converter chips are manufactured by Nanjing Micro One Electronics as the ME2108 DC-DC Step Up Converter. The specification (in English) is available HERE.

I used a breadboard to connect a 1.3V NImH battery to the 2108A-1532/33 and measured first with a multimeter and then my little digital scope. The multimeter showed a nice, steady 3.3V. Next I looked at the 2108A-1532/33 output with the scope – very stable 3.3 Volts – see Figure 1, below. I added no filtering capacitor – this is with just the module.

Fig 1: Output of CE012 DC-to-DC Converter

Fig 1: Output of CE012 DC-to-DC Converter

CE012 DC-DC Converter Module - back view

Fig 2: CE012 DC-DC Converter Module – back view

CE012 DC-DC Converter Module - front view

Fig 3: CE012 DC-DC Converter Module – front view

Seeing a good steady 3.3V on the CE012’s output and given the specification’s output current rating of 50 to 110mA with this battery, I connected it to a breadboard with an ATTINY85-20SU loaded with the Arduino BLINK program – see Figure 4 below.

Test setup for CE012 powering ATTiny85

Fig 4: Test setup for CE012 powering ATTiny85

The CE012 module fueled by the 1.3V AA NiMH battery immediately cranked up the ATTINY85-20SU loaded with the Arduino BLINK program. See the video posted immediatly below.


With nothing connected to the CE012’s output the battery was sourcing 0.09mA. When the CE012 was powering the ATTINY85 the battery was sourcing 43mA to 75mA (59 mA average) depending on the LED’s state. With the 1,700mAh battery fully charged this circuit could run a theoretical maximum of 28 hours before exhaustion. Please note that this is 1.3V battery current and that I did not measure the current at 3.3V consumed by the ATTINY85.

The 5V version drew 55mA to 64mA depending on the LED’s state. With nothing connected to the 5V CE012’s output the battery was sourcing 0.5mA. Please note that this is 1.3V battery current and that I did not measure the current at 5V consumed by the ATTINY85.

Posted in Electronics | 5 Comments

Santa Light – What’s Inside

During the Christmas season I found a Santa light at the local Dollar Tree store. Knowing that it is just a garden light with a Santa head, I bought one just to experiment with. OK – I’m a little obsessed with these garden lights – BUT – that IS how this blog started. One of my earliest posts was about a garden light.

Every garden light that I examine has something unique about it. Santa’s electronics had differences. First, the ASIC chip is a new one to me. I cannot find a specification sheet for it but, based on haw it is wired, it is similar to the YX805A. It is marked “F1 4S597”. The other unique thing is the battery. It is a small “2/3AAA” NiCd 100mAh battery. Every other light that I’ve encountered uses a AAA NiCd/NiMH battery. Other than this and the shape of the housing there is nothing unusual in the design.

Disassembly and oscilloscope photos are below, as well as my reverse engineered schematic. (Click photo to enlarge) Enjoy!


Posted in Electronics, hardware | Leave a comment

Garden Light Redux – Power Supply

NOTE: This post is a work in progress. As long as it ends with “To be Continued”, please check back occasionally for updates.

The Garden Solar Light is a recurring interest of mine. It is often referred to as a Joule Thief but it is actually not.  A Joule Thief attempts to extract usable power from an almost dead battery ( under 0.8 volts) while this technology is a switch pulsed voltage boost converter that operate above 0.9V.  The somewhat mysterious little Chinese ASIC integrated circuits have been examined by a number of people since I first posted about the subject in 2012. Recently, a fellow member of the Asheville based Western North Carolina Linux Group (WNCLUG) re-sparked my interest in the topic. Our ultimate goal is a modified Garden Light that can power an ATTiny85, radio transmitter and sensor for periodic transmission of sensor data.

This time I decided to spend some time delving more into the somewhat mysterious little Chinese integrated circuits used in the solar garden lights so as to, hopefully, make more informed design decisions in the final project. There is a plethora of similar Chinese Garden Light integrated circuits and, despite having different identifying part numbers, they seem to all be similar of each other, despite some variation in pin assignments and capabilities.

A pretty good list of them is HERE. Despite their similarities, one reason for the overabundance choices, besides competition between manufacturers, is to accommodate for different current and voltage applications as well as other improvements, such as over discharge protection. Some of the improvements are patented.  I found an interesting list of Garden Light ASICs on 52rd.com in a post by user yuxinzxs. See the English translation of the Garden Light portion at garden-light-asic-list The YX8018 appears to be the granddaddy of them all. The YX8018 and the QX5252F seem to be the most commonly encountered. The QX5252F is manufactured by QX Micro Devices Co., LTD of Shenzhen, China who holds several patents for these types of chips that prevents the battery from being overly discharged in order to prolong battery life – Chinese patents 200910107832 and 200910107063 and 200910107064 for high efficiency charging.

By the way, before I start ignoring the YX8018 in favor of the QX5252F, if the YX8018 interests you check out SparkFun’s interesting project for creating a soil moisture sensor using a Garden Stake that uses the YX8018. It is simple but informative. If the soil is damp, the LED is out. If the soil is dry, the LED is lit. Read the SparkFun article at THIS-LINK.

The YX8018, like most of its cousins, come in 4 pin transistor SIP-4 package identified as TO-94, which can be seen in Figure 1, below. The internal schematic of these Chinese voltage booster chips is elusive. However, there are a few semi-schematics of the internals, one of which was posted in an Instructable by Dave Kruschke and it appears a little more complete than others that I have discovered – However, the slightly simpler internal schematic posted by burger2227 (Ted from Pittsburgh) is quite adequate and is shown immediately below in Fig. 1.


Fig. 1: YX805A

Below is a somewhat more detailed internal view from a manufacturer datasheet.


Fig 1a: QX5252F Functional Block Diagram

The integrated Shottkey diode between the solar panel on pin SBAT and the battery on pin BAT is part of the charging circuit and also blocks the battery from biasing on the controller/oscillator (white box in center). The gated oscillator runs at a ~200KHz driving an open drain NMOS switch ( output on pin LX ). The non-sinusoidal pulses on LX pin pulse the external inductor (Figure 2) at the ~200kHz rate and the resultant field collapses boot the voltage presented to the LED in the manner of a Joule Thief. The Instructable by Dave Kruschke has a nice explanation of how the inductor creates the voltage boost. Each pulse causes current to flow into the inductor which creates a magnetic field around the inductor, that is, in essence, stored energy. When the pulse ends, current flow stops, the inductor’s magnetic field collapses and its energy is returned back into the circuit, adding to, or “boosting” the voltage.


Voltage Boost via Coil Field Collapse

I purchased some YX805A chips through eBay and, as the first step, I am replicating a Garden Light’s circuitry on a breadboard. I configured the basic circuit in Figure 2, below, except for the solar charging portion. For now I am only testing the voltage booster section with an alkaline 1.57V. battery.


Fig. 2: Initial Test Circuit

My initial breadboard test circuit is shown in Figure 3, below.

Fig. 3

I used a YX805A chip with a 100uH inductor and a white LED. The battery used was a AA size alkaline battery that measured 1.57V with a voltmeter. This configuration oscillates at 215kHz. See Fig. 3, below. Most white LEDs require 3-Volts to conduct/illuminate, and typically operate in the 3.2V to 3.4V range. The output measured 3.6V between ground and LX, the pulsed output. At this point the 215kHz is only usable for the LED light application, where the human eye cannot detect the oscillation. Rectification and stabilization will be needed before the output is usable for anything else.

Fig. 4 – YX805A with Alkaline Battery

With a 1.29V NiMh battery the oscillation frequency was slightly different, at 226kHz, see Figure 5, below. However, the oscillator isn’t that stable so both the alkaline and NiMh batteries produced the expected approximate 200kHz frequency.

Fig. 5: nimh battery 100u

Fig. 5: YX805A with NiMH battery 100uH inductor

With the same circuit but using a 5252F ASIC instead of the YX805A. Results are very similar as can bee seen in Figure 6, below. The frequency was somewhat higher at 282kHz and the waveform even less of a square wave than with the YX805A. Nonetheless, quite similar and equally usable.


Fig. 6: 5252F, 100uH, 1.25V NiMh

My next incremental step was to rectify and stabilize the circuit’s output to 5 volts. At this point I have not installed the solar cell charger – that will come later.

The schematic shown in Figure 7, below, provides 5.18VDC across a megohm load (multimeter), at 45ma  (only multimeter’s load in Ampere mode) from a fully charged 1.29V NiMH battery. With a 33uH inductor it supplies 50ma. These readings match the YX805A datasheet in that the smaller inductor value does produce more current (290kHz) but the values differ from the chart. Possibly this is due to my using a signal diode instead of the datasheet’s white LED, or it is due to the particular manufacturer of my YX805A.

When measured across, and through, a sustained 19Ω load, meaning starting from a discharged capacitor, I see 5.1VDC at 580uA. Conversely, if the capacitor is fully charged prior to applying the load, I measure 5.1V @ 25ma. This test was using a 33uH inductor. When measured across, and through, a 1kΩ load with a charged capacitor I see 5.1VDC at 5.1mA. A subsequent test, with the circuit moved to a new breadboard and using a 22uF filter capacitor yielded ~17mA through a dead short (ammeter).

To be usable as a power supply, the load may need to be intermittent in order to charge the capacitor between higher current cycles. Fortunately, Dolen Le has researched and documented exactly how to do this with the ATTiny85.

The solar charging portion is not part of the initial tests. Without the 5.1V zener the output voltage is 8.5V.


Fig. 7: Basic 5V Supply Added

Using the oscilloscope I measured the 5V ripple at .05V – time to see what it can do!
I programmed an Arduino NANO with the one-second Blink program and connected it to be powered by the Garden Light Redux – Power Supply. It worked perfectly (for now) with the 1000uF capacitor providing a current reserve. A short video is below that shows the Arduino running under Joule Thief power from one NiMH AA battery.

UPDATE: Something changed and I can no longer replicate these results with the YX805A circuit described above, meaning that the NANO will no longer run with that power supply. Currently, I am seeing much less current than before and it isn’t enough to operate the Arduino NANO. Trying to see what was happening I put scope leads across the Arduino NANO power leads and then connected the my Garden Light DIY 5V Power Supply. What I see it starting at 5.2V and within 140ms voltage was down to 3V with a precipitous drop after that. See Figure 8, below. I don’t know what changed – I have replaced all components, one at a time between tests, except for the Arduino NANO. Changing the NANO is on my list. Meanwhile, I compared current load with “this” genuine Arduino NANO e/w FTDI serial I/O and a Chinese Arduino NANO e/w CH340G I/O – both running a “blink” program. Idle is the low current and LED-on is the high current:

  • genuine Arduino NANO e/w FTDI serial I/O – current 25-to-30mA
  • Chinese Arduino NANO e/w CH340G I/O – current 22-to25mA
Fig. 8: Voltage drop on NANO Connection

Fig. 8: Voltage drop on NANO Connection

Seeing that this circuit wasn’t going to be adequate to power the Arduino NANO, I did some measurements using the BLINK program in an ATTINY85-20SUR surface mount package – see video below. Idle current consumption is 8.7mA and with the LED on it is 11.5mA. Better, but still a challenge for the ATTiny85 and a transceiver plus sensor. The supply still needs work.

I made some changes and have a working circuit again! I hate the unexplained. Anyway, I switched to a QX5252F ASIC, 100uH inductor and a Schottky diode. See figure 9 below. I’m seeing 5.1V with 125mA on a dead short and 43mA through a 1000Ω resistor. This circuit correctly runs the ATTiny85 running Blink in the video immediately above.


Fig. 9: QX5252F & 100uH inductor


Fig. 10: QX5252F Schematic

I didn’t like the unexpected change in performance, so additional testing is in order before I can say that this circuit is solid. A future step will be to more extensively test the basic solar charging circuitry – I have already briefly tested it. After that, I may add and test Ivan Nechayev’s charge regulation circuitry.

Keep watching this post to expand – it is NOT finished. Other posts may be used will wait for other aspects of my project, such as adding the radio transmitter and sensor. Until then:

To Be Continued

Posted in Electronics, hardware | Tagged , , , , | 2 Comments

An inexpensive Software Enabled Pseudo-Transceiver for Arduino

Recently I taught a brief, three hour long, Arduino 101 course to some fellow members of the Western North Carolina Linux Users Group (WNCLUG). One of the three lessons in the course was for the students to pair off and use inexpensive Chinese 433 megahertz radio modules to send data between an Adruino Uno with a FS1000A transmitter running transmitter code and another Adruino Uno with a MX-RM-5V receiver running receiver code. We talked about applications using a transceiver but these radios were discrete transmitters and receivers, NOT transceivers. Of course that was understandable because this transmitter and receiver set only cost 88 cents (in bulk), including shipping from China via AliExpress.

Cheap ASK Radios

FIG 1: Cheap ASK Radios

Recently, I got to thinking – it seemed to me that I could use the two boards (FS1000A & MX-RM-5V) with a single Arduino to create an 88-cent transceiver through software. Consequently, I wrote some code that does just that is explained herein.

With the two radio modules in close proximity of the single controlling Arduino, such as on the same breadboard, I was concerned about the transmitter swamping the companion receiver during transmit, and possibly producing spurious results in the receiver. I decided to use the oft recommended RadioHead Arduino ASK library for this project. It can be downloaded from its author – airspayce.com/mikem/arduino/RadioHead/

RadioHead has a useful Push To Talk (PTT) feature that I opted to use to control receiver’s power. The PTT feature is intended to control a genuine transceiver but I use it to toggle on/off the power for the MX-RM-5V receiver. I invert the pin in software such that power is removed from the receiver when the transmitter is keyed. The receiver MX-RM-5v Working current at 5V is a nominal 4ma and the Arduino can source DC Current per I/O Pin at 40.0 mA, so powering the receiver via an Arduino works without issue.

I cobbled together a simple test of the software with two breadboards (see Fig 2). The serial ports were each monitored on my desktop and a laptop. Fig 3, below shows two-way messaging between the two pseudo transceivers.

Two pseudo Transceivers

Fig 2: Two pseudo Transceivers

While I have tested these cheap ASK radios at over 50 feet, I have read reports by others that they will work much, much further. These particular radios are test rejects from a bulk order made for my class and they won’t work much further than a foot apart. Someday I may try to tune the suspect receiver.

Test Results

Fig 3: Test Results – two screens

Below, in Fig 4, I show the wiring for my tests – both breadboards are wired identically and run the same code.

Pseudo Transceiver Wiring

Fig 4: Pseudo Transceiver Wiring

UPDATE: January 30, 2017 – I tested a different, higher rated radio with the exact setup and code, EXCEPT that I only tested one-way communications – because I was testing the radios, not the code. I tested the STX882 / SRX882 radio pair shown in Figure 5, below, and they worked well. Ok, not these two because I haven’t soldered the antennas onto these yet – it was another pair. I did not test maximum range but they worked across the table – see Figure 6, below. Their manufacturer, NiceRF, claims an effective range of 100 meters.


Fig 5: STX882 and SRX882


Fig 6: Test Communications with STX882 and SRX882


The source code can be downloaded from: http://pastebin.com/kv2wyWjv and is also shown below. NOTE: Source code updated on December 26, 2016.

  ask_rxtx.ino - V2
  AUTHOR: Edward Comer, USA
  Open Source Licenesed under Creative Commons Attribution 4.0 International (CC BY 4.0)
  See: https://creativecommons.org/licenses/by/4.0/
  Uses RadioHead library for messaging via a simple ASK transmitter and
  receiver, i.e., FS1000A and MX-RM-5V, etc.

  For RadioHead information, see:
  Controls both transmitter AND receiver
  Receiver is powered by inverted PTTPIN, which powers down receiver when
  transmitting in order to prevent swamping the receiver.
  Receiver MX-RM-5v Working current:≤5.5mA (5.0VDC) nominally 4ma
  Arduino DC Current per I/O Pin: 40.0 mA

   +-------+   +---------+
   |FS1000A|   |XD-RF-5V |
   |D 5 G  |   | 5 D  G  |
   ++-+-+--+   +-+-+--+--+
    | | |        | |  |
    | + +        | |  +
    |            | |
  | 1            1 1  |
  | 2            0 1  |
  |    ARDUINO        |

#include <RH_ASK.h>
#include <stdint.h>
#include <SPI.h> 	// Not actually used but needed to compile

#define SPEED 2000  // The desired bit rate in bits per second
#define RXPIN 11    // The pin that is used to get data from the receiver
#define TXPIN 12    // The pin that is used to send data to the transmitter
#define PTTPIN 10   // Push To Talk pin
#define PTTINVERTED true // true = LOW when transmitting, otherwise HIGH


char kbdbuf[RH_ASK_MAX_MESSAGE_LEN];
uint8_t rxbuflen = sizeof(rxbuf);

const int ledPin = 13; // onboard LED

void setup()
  digitalWrite(ledPin, HIGH);
  while (!Serial); // Wait for serial connect
  if (!driver.init())
    Serial.println("Radiohead driver.init failed - system halting");
    while (true) {}  // do nothing further until reset
  digitalWrite(ledPin, LOW);
  Serial.print("Maximum message length requested of this Driver is ");
  Serial.print("Maximum message length available in this Driver is ");
  Serial.println("Setup complete.");
  Serial.println("Enter New message: ");

   loop, contstantly checking for either a string to transmit or
   a received string. This loop is predominantly non-blocking. The receiver
   is powered down when the transmitter is sending to prevent swamping the
   receiver. Power down/up is accomplished by powering the receiver with
   the RadioHead PTT pin (pin 10). The receiver uses 5V @ 4ma and the
   Arduino can source 40ma.

   NOTE: There is no immediate local echo of characters typed
void loop()
  if (readline(Serial.read(), kbdbuf, RH_ASK_MAX_MESSAGE_LEN) > 0)
    Serial.print("You entered: [");
    // Now, Send user typed string via radio
    driver.send(kbdbuf, strlen(kbdbuf));
    Serial.println("Transmit complete");
    delay(500);  // settling time for RX turnon

  // Check for data received via radio
  if (driver.recv(rxbuf, &rxbuflen)) // Non-blocking
    // Message with a good checksum received, dump it.
    //driver.printBuffer("Received:", buf, QtyRead);
    Serial.write(0x07); // Ring bell on Putty console
    Serial.print("Received: ");
    rxbuflen = sizeof(rxbuf);
    Serial.println("Enter New message: ");

   Non-blocking string read from terminal
   name: readline(int readchar, char* buffer, int len)
   @param readchar is the character read
   @param buffer is storage for accumulated string
   @param len is maximum length input string allowed
   @return returns length of string read, otherwise negative value

   Inspired by Majenko's Hardware Hacking Blog
int readline(int readchar, char* buffer, int len)
  static int pos = 0;
  int ret_pos;

  if (readchar > 0) {
    switch (readchar) {
      case '\r': // Terminate with CR or LF
      case '\n':
        ret_pos = pos;
        pos = 0; // Reset position index ready for next entry
        return ret_pos;
        if (pos < len - 1) {
          buffer[pos++] = readchar;
          buffer[pos] = 0;
        } else {	// else buffer is full
          buffer[pos] = 0;
          ret_pos = pos;
          pos = 0; // Reset position index ready for next entry
          return ret_pos;
  // No end of line has been found, so return -1.
  return -1;

Posted in Arduino, Electronics, Programming, software, wireless | Tagged , , , | Leave a comment

Programming the ATTINY85-20SUR

This post ties together my two previous posts, “ATtiny85 SOIC chip Program Adapter” and “Universal programmer dusted off“. I inserted the ATTINY85-20SUR nested in the SOIC Adapter Socket OTS-20-1.27-01,  plugged it into my DIY Universal Programmer socket and connected it up to my USBasp programmer. I first burned the bootloader and then burned a typical “blink” program. Next, I plugged the ATTINY85-20SUR/ SOIC Adapter Socket into a small breadboard that I have for a Arduino Uno ProtoShield (it was my only empty breadboard) and connected 3.3V power from a handy breadboard power supply.

Everything worked nicely so I can now move on to the next phase of a long-running project that I’m working on. I’ve put a small video below that will give you a visual context of what I did.

Posted in Arduino, Electronics, hardware | Tagged , , | Leave a comment

ATtiny85 SOIC chip Program Adapter

When I purchased some surface mount ATtiny85 microcontrollers I didn’t realize that Atmel sold them in several widths, so I purchased the incorrect size SOIC programming adapter that would have enabled me to program the chip prior to soldering it onto the PCB. I had purchased ATTINY85-20SUR chips which use Atmel’s package type “8S2”. Using a micrometer, I measured the pin widths on a ATTINY85-20SUR and it measures 7.87mm, which is within the range specified by Atmel – 7.62mm to 8.38mm wide pin edge to pin edge.

So, back to eBay I go and I purchased a SOIC Adapter Socket OTS-20-1.27-01 mounted on a small PCB and sold as a SOIC Programmer Adapter Socket compatible with 200/208mil SOIC, 1.27mm Pitch. The PCB is wired to facilitate programming on a breadboard. Wiring is pin to pin, thus SOIC pin 1 goes to PCB pin1, etc. See Figure 1, below.

SOIC Socket From eBay

Figure 1: SOIC Socket From eBay

Figure 2, below, illustrates the ATmel specifications for the ATTINY85-20SUR chip and what I actually measured.


atmel SOIC spec

Figure 2: ATmel 8S2 SOIC spec

The very short video clip, below, demonstrates how easy it is to insert/remove a 8S2 SOIC chip in the SOIC Adapter Socket OTS-20-1.27-01.


Posted in Arduino, Electronics, hardware | 1 Comment

Universal programmer dusted off

Lately, I have increased my microprocessor/gadget activity after a hiatus/slow down. A project that I have been (slowly) working on was developed and debugged on an Arduino NANO but the final target is a surface mounted SOIC ATtiny85-20SUR operating at 3-Volts. On an interim basis, I am testing with 8-DIP ATtiny85-20 chips. I have been programming the ATtiny85-20 chips with a USBasp programmer and a perf-board adapter that I made back in 2012.  The perf-board adapter is shown in Figure 1, below.

In the same storage box as the perf-board adapter was a universal adapter that I also made in 2012. I needed it for some other, larger chips that I was programming, at the time. It has a 48-pin Zero Insertion Force socket (ZIF 250-3345).

The USBasp programmer in the photo is another story. I have two of these inexpensive Chinese programmers. I purchased the first one in 2012 and I liked it so much that I bought a second one as a maintenance spare. In the years that have passed I have changed my desktop workstation operating two or three times. I am now on Mint 17.3. Something in Linux has changed because this USBasp programmer originally created a /dev/ttyUSB0 port but – no longer! I tried every udev rule offered by the Internet pundits but nothing would work. I have the programmer working on /dev/ttyS0 but it bugs me that Linux’s behavior has changed. Since my two USBasp devices are Chinese-made and several years old, I suspect that their FTDI chips are probably counterfiet. I am growing suspicious that FTDI may have inserted some form of their malicious code into Linux. It is widely publicized about what they did to Linux drivers (http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/). Seeing that FTDI supplies the Linux kernel’s USB drivers, I went looking for the source to see what I could find out. Guess what – FTDI’s driver ReadMe file states “FTDI do not release the source code for libftd2xx. If you prefer to work with source code and are starting a project from scratch, consider using the open-source libFTDI.” Sure enough, Linux is using FTDI supplied compiled objects into the kernel. Oh well, I guess I’ll stick to using /dev/ttyS0.

Universal Programmer

Figure 1. – Universal Programmer

My DIY universal programmer adapter was made on a quickie, somewhat crude one-sided printed circuit board. I was making quite a few PC boards in 2012/3. The artwork and schematic for this board is at the bottom of this post.

Universal Programmer Board

Figure 2. – Universal Programmer Board TOP

Universal Programmer Board

Figure 3. – Universal Programmer Board BACK (ignore felt pen incorrect legend)

I just setup the Universal Programmer board and burned a ATtiny85-20 fused to run at 8MHz. I’m glad that the universal adapter still works well. The console output below is just a “blink” program to test the programmer. I have already tested my project’s code in a 3.3-volt adafruit trinket so I know that it is going to work well inside an ATtiny85.

ecomer@bergamont ~/Arduino/BlinkATTiny85 $ make upload
Arduino.mk Configuration:
- [USER]               ARDUINO_DIR = /home/ecomer/arduino-1.6.9 
- [USER]               ARDMK_DIR = /home/ecomer/Arduino/Arduino-Makefile 
- [DEFAULT]            ARCHITECTURE = avr 
- [DEFAULT]            ARDMK_VENDOR = arduino 
- [AUTODETECTED]       ARDUINO_PREFERENCES_PATH = /home/ecomer/.arduino15/preferences.txt 
- [AUTODETECTED]       ARDUINO_SKETCHBOOK = /home/ecomer/Arduino (from arduino preferences file)
- [USER]               AVR_TOOLS_DIR = /home/ecomer/arduino-1.6.9/hardware/tools/avr 
- [COMPUTED]           ARDUINO_LIB_PATH = /home/ecomer/arduino-1.6.9/libraries (from ARDUINO_DIR)
- [COMPUTED]           ARDUINO_PLATFORM_LIB_PATH = /home/ecomer/arduino-1.6.9/hardware/arduino/avr/libraries (from ARDUINO_DIR)
- [USER]               ALTERNATE_CORE = tiny 
- [COMPUTED]           ALTERNATE_CORE_PATH = /home/ecomer/Arduino/hardware/tiny/avr  (from ARDUINO_SKETCHBOOK and ALTERNATE_CORE)
- [COMPUTED]           BOARDS_TXT = /home/ecomer/Arduino/hardware/tiny/avr/boards.txt (from ALTERNATE_CORE_PATH)
- [USER]               USER_LIB_PATH = /home/ecomer/Arduino/lib 
- [DEFAULT]            PRE_BUILD_HOOK = pre-build-hook.sh 
- [USER]               BOARD_TAG = attiny85at8 
- [COMPUTED]           CORE = tiny (from build.core)
- [COMPUTED]           VARIANT =  (from build.variant)
- [USER]               OBJDIR = /home/ecomer/Arduino/BlinkATTiny85/attiny85at8/bin 
- [USER]               ARDUINO_CORE_PATH = /home/ecomer/Arduino/hardware/tiny/avr/cores/tiny 
- [USER]               MONITOR_BAUDRATE = 115200 
- [DEFAULT]            MCU_FLAG_NAME = mmcu 
- [USER]               CFLAGS_STD = -std=gnu11 
- [USER]               CXXFLAGS_STD = -std=gnu++11 
- [COMPUTED]           DEVICE_PATH = /dev/ttyS0 (from MONITOR_PORT)
- [AUTODETECTED]       Size utility: AVR-aware for enhanced output
- [COMPUTED]           BOOTLOADER_PARENT = /home/ecomer/arduino-1.6.9/hardware/arduino/avr/bootloaders (from ARDUINO_DIR)
- [COMPUTED]           ARDMK_VERSION = 1.5 
- [COMPUTED]           CC_VERSION = 4.8.1 (avr-gcc)
mkdir -p /home/ecomer/Arduino/BlinkATTiny85/attiny85at8/bin
make reset
make[1]: Entering directory `/home/ecomer/Arduino/BlinkATTiny85'
/home/ecomer/Arduino/Arduino-Makefile/bin/ard-reset-arduino  /dev/ttyS0
make[1]: Leaving directory `/home/ecomer/Arduino/BlinkATTiny85'
make do_upload
make[1]: Entering directory `/home/ecomer/Arduino/BlinkATTiny85'
/usr/bin/avrdude -q -V -p attiny85 -C /home/ecomer/arduino-1.6.9/hardware/tools/avr/etc/avrdude.conf -D -c usbasp -b 9600 -P /dev/ttyS0 \
			-U flash:w:/home/ecomer/Arduino/BlinkATTiny85/attiny85at8/bin/BlinkATTiny85.hex:i

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e930b
avrdude: reading input file "/home/ecomer/Arduino/BlinkATTiny85/attiny85at8/bin/BlinkATTiny85.hex"
avrdude: writing flash (714 bytes):
avrdude: 714 bytes of flash written

avrdude: safemode: Fuses OK (H:FF, E:D7, L:E2)

avrdude done.  Thank you.

As you can see, I have also been fiddling with Make for Arduino compiling and burning. This particular Makefile is by Sudar Muthu of Chennai, India. You can download it at https://github.com/sudar/Arduino-Makefile. I gravitated to this Makefile because some of my semi-anonymous work is within. Sudar built upon Christopher Peplin’s previous work and I am a contributor to Peplin’s now depricated makefile. Consequentially, I knew this particular Makefile well. Nonetheless, things have changed since 2012. The format of “boards.txt”, a critical Arduino parameter file, has dramatically changed since 2012. Arduino has added a new structured “menu” version of “boards.txt” that can be very difficult to parse with a Makefile, especially since Arduino.cc has no published standard. Due to this, each Arduino “core” developer invented “tags” in “boards.txt” that are unique to their “core”. I frustratingly tested several and gave up and settled on the ONE that worked well. It is arduino-tine version 0150-0020in the Google code repository at https://code.google.com/archive/p/arduino-tiny/downloads Can I do what I need in the Arduino IDE? – Sure but I am a hands-on guy and the goal of the Arduino ide is to insulate the developer from what is happening. I don’t like that and usually pick the hands-on approach even if it isn’t always as easy.

zifboard1s schematic

Figure 4. – ZIF Universal Programmer Adapter Schematic

ZIF Universal Programmer Adapter Art

Figure 5. – ZIF Universal Programmer Adapter Single Sided Art

Posted in Arduino, computer, Electronics, hardware, Linux, PCB Etching, Programming | Leave a comment