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 coiled 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.

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

A Tiny but Good Boost Converter

With nothing connected to the CE012’s outputAs 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:

nanjing-logo

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.

2108a-06

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.

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.

Posted in Electronics | Leave a comment

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 Uncategorized | 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.

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.

5252finternal2-2

Fig. 1: YX805A

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

qx5252-internal

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.

motiongif

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.

diy1

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.

5252f-100u

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.

diy5v1m

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.

diy5v1qx5252scope

Fig. 9: QX5252F & 100uH inductor

diy5v1qx5252

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 , , , , | Leave a comment

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.

stx882

Fig 5: STX882 and SRX882

ask_882_rxtx

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:
  http://www.airspayce.com/mikem/arduino/RadioHead/classRH__ASK.html#details
  ------------
  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

RH_ASK driver(SPEED, RXPIN, TXPIN, PTTPIN, PTTINVERTED);

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

const int ledPin = 13; // onboard LED

void setup()
{
  digitalWrite(ledPin, HIGH);
  Serial.begin(19200);
  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.println("");
  Serial.print("Maximum message length requested of this Driver is ");
  Serial.print(RH_ASK_MAX_MESSAGE_LEN);
  Serial.println("");
  Serial.print("Maximum message length available in this Driver is ");
  Serial.print(driver.maxMessageLength());
  Serial.println("");
  Serial.println("Setup complete.");
  Serial.println("");
  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: [");
    Serial.print(kbdbuf);
    Serial.println("]");
    // Now, Send user typed string via radio
    driver.send(kbdbuf, strlen(kbdbuf));
    driver.waitPacketSent();
    Serial.println("Transmit complete");
    delay(500);  // settling time for RX turnon
    memset(kbdbuf,0,sizeof(kbdbuf));
  }

  // 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: ");
    Serial.println(rxbuf);
    Serial.println("-------------");
    memset(rxbuf,0,sizeof(rxbuf));
    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
   http://tinyurl.com/hmb8vwa
*/
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;
      default:
        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 | Leave a 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:
- [AUTODETECTED]       CURRENT_OS = LINUX 
- [USER]               ARDUINO_DIR = /home/ecomer/arduino-1.6.9 
- [USER]               ARDMK_DIR = /home/ecomer/Arduino/Arduino-Makefile 
- [AUTODETECTED]       ARDUINO_VERSION = 169 
- [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]            OPTIMIZATION_LEVEL = s 
- [DEFAULT]            MCU_FLAG_NAME = mmcu 
- [USER]               CFLAGS_STD = -std=gnu11 
- [USER]               CXXFLAGS_STD = -std=gnu++11 
- [COMPUTED]           DEVICE_PATH = /dev/ttyS0 (from MONITOR_PORT)
- [DEFAULT]            FORCE_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

Dubious eBay SD Cards – Caveat Emptor

Over the years, I have purchased a number of SD cards through eBay – often shipped directly from China. Today I was reading the setup instructions for a recent acquisition – a PINE-64 board. Pine-64 was adamant that the micro-SD card used be over 8GB and of Class 10. I dug around on the shelf and came up with a spare 32GB micro-SD. It was marked as Class-4. No good for this application BUT I got to wondering how it would test. A photo of the SD card’s markins is below, front and back.

I had recently discovered a suite of SD testing tools called F3 by Michel Machado. I downloaded the source and compiled the suite. Next, I ran the tools against the SD card. The results were BAD! The card is a fake and only has 7GB usable. The console’s output is pasted below. The reported average writing speed is 3.07 MB/s, which would be between a Class 2 and Class 4. The card is marked Class 4 so the speed is also a fake. I’ve learned my lesson – no more direct-from-China SD cards unless I can truly trust the seller – which seems pretty difficult on eBay. Consequentially, I think that I will stick to companies with good return policies (Amazon, NewEgg and Wal-Mart) and immediately test the new card with F3. Caveat Emptor!

dzrmo@bergamont ~/src/f3-6.0 $ ./f3write /media/dzrmo/9C6F-1ECD
Free space: 29.80 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Creating file 5.h2w ... OK!
Creating file 6.h2w ... OK!
Creating file 7.h2w ... OK!
Creating file 8.h2w ... OK!
Creating file 9.h2w ... OK!
Creating file 10.h2w ... OK!
Creating file 11.h2w ... OK!
Creating file 12.h2w ... OK!
Creating file 13.h2w ... OK!
Creating file 14.h2w ... OK!
Creating file 15.h2w ... OK!
Creating file 16.h2w ... OK!
Creating file 17.h2w ... OK!
Creating file 18.h2w ... OK!
Creating file 19.h2w ... OK!
Creating file 20.h2w ... OK!
Creating file 21.h2w ... OK!
Creating file 22.h2w ... OK!
Creating file 23.h2w ... OK!
Creating file 24.h2w ... OK!
Creating file 25.h2w ... OK!
Creating file 26.h2w ... OK!
Creating file 27.h2w ... OK!
Creating file 28.h2w ... OK!
Creating file 29.h2w ... OK!
Creating file 30.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 3.07 MB/s
dzrmo@bergamont ~/src/f3-6.0 $ 

dzrmo@bergamont ~/src/f3-6.0 $ ./f3read /media/dzrmo/9C6F-1ECD
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097140/        0/     12/      0
Validating file 4.h2w ... 2097151/        0/      1/      0
Validating file 5.h2w ... 2097152/        0/      0/      0
Validating file 6.h2w ... 2097152/        0/      0/      0
Validating file 7.h2w ... 2097152/        0/      0/      0
Validating file 8.h2w ...  678512/        8/      0/1418632
Validating file 9.h2w ...       0/        0/      0/2097152
Validating file 10.h2w ...       0/        0/      0/2097152
Validating file 11.h2w ...       0/        0/      0/2097152
Validating file 12.h2w ...       0/        0/      0/2097152
Validating file 13.h2w ...       0/        0/      0/2097152
Validating file 14.h2w ...       0/        0/      0/2097152
Validating file 15.h2w ...       0/        0/      0/2097152
Validating file 16.h2w ...       0/        0/      0/2097152
Validating file 17.h2w ...       0/        0/      0/2097152
Validating file 18.h2w ...       0/        0/      0/2097152
Validating file 19.h2w ...       0/        0/      0/2097152
Validating file 20.h2w ...       0/        0/      0/2097152
Validating file 21.h2w ...       0/        0/      0/2097152
Validating file 22.h2w ...       0/        0/      0/2097152
Validating file 23.h2w ...       0/        0/      0/2097152
Validating file 24.h2w ...       0/        0/      0/2097152
Validating file 25.h2w ...       0/        0/      0/2097152
Validating file 26.h2w ...       0/        0/      0/2097152
Validating file 27.h2w ...       0/        0/      0/2097152
Validating file 28.h2w ...       0/        0/      0/2097152
Validating file 29.h2w ...       0/        0/      0/2097152
Validating file 30.h2w ...    8256/        0/      0/1661312

  Data OK: 7.33 GB (15366819 sectors)
Data LOST: 22.47 GB (47120157 sectors)
	       Corrupted: 4.00 KB (8 sectors)
	Slightly changed: 6.50 KB (13 sectors)
	     Overwritten: 22.47 GB (47120136 sectors)
Average reading speed: 13.77 MB/s

dzrmo@bergamont ~/src/f3-6.0 $ sudo ./f3probe --destructive --time-ops /dev/sdf
[sudo] password for dzrmo:
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Bad news: The device `/dev/sdf' is a counterfeit of type limbo

You can &amp;quot;fix&amp;quot; this device using the following command:
f3fix --last-sec=15466495 /dev/sdf

Device geometry:
	         *Usable* size: 7.38 GB (15466496 blocks)
	        Announced size: 30.00 GB (62914560 blocks)
	                Module: 32.00 GB (2^35 Bytes)
	Approximate cache size: 3.88 MB (7952 blocks), need-reset=yes
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2'15&amp;quot;
 Operation: total time / count = avg time
      Read: 1.39s / 32937 = 42us
     Write: 2'09&amp;quot; / 125776 = 1.0ms
     Reset: 4.05s / 16 = 253.2ms
dzrmo@bergamont ~/src/f3-6.0 $ 

dzrmo@bergamont ~/src/f3-6.0 $ sudo ./f3fix --last-sec=15466495 /dev/sdf
F3 fix 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

Drive `/dev/sdf' was successfully fixed
dzrmo@bergamont ~/src/f3-6.0 $ 

dzrmo@bergamont ~/src/f3-6.0 $ sudo ./f3probe --destructive --time-ops /dev/sdf
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Bad news: The device `/dev/sdf' is a counterfeit of type limbo

You can &amp;quot;fix&amp;quot; this device using the following command:
f3fix --last-sec=15466495 /dev/sdf

Device geometry:
	         *Usable* size: 7.38 GB (15466496 blocks)
	        Announced size: 30.00 GB (62914560 blocks)
	                Module: 32.00 GB (2^35 Bytes)
	Approximate cache size: 7.00 MB (14336 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2'30&amp;quot;
 Operation: total time / count = avg time
      Read: 1.40s / 32937 = 42us
     Write: 2'28&amp;quot; / 215152 = 690us
     Reset: 494.2ms / 2 = 247.1ms
dzrmo@bergamont ~/src/f3-6.0 $ 

[[[ Ran gparted and reformatted the drive ]]

dzrmo@bergamont ~/src/f3-6.0 $ sudo ./f3probe --destructive --time-ops /dev/sdf
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Bad news: The device `/dev/sdf' is a counterfeit of type limbo

You can &amp;quot;fix&amp;quot; this device using the following command:
f3fix --last-sec=15466495 /dev/sdf

Device geometry:
	         *Usable* size: 7.38 GB (15466496 blocks)
	        Announced size: 30.00 GB (62914560 blocks)
	                Module: 32.00 GB (2^35 Bytes)
	Approximate cache size: 7.00 MB (14336 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2'25&amp;quot;
 Operation: total time / count = avg time
      Read: 1.42s / 32944 = 43us
     Write: 2'22&amp;quot; / 215152 = 664us
     Reset: 493.5ms / 2 = 246.7ms
dzrmo@bergamont ~/src/f3-6.0 $

Dubious Micro-SD

UPDATE: I found Russian website where this same SD (sip14076k011a) was tested, although using different test software. Anyway, it also failed their tests – JUNK confirmed!

BTW, although the chip id is identical, the Russian website lists the SD (sip14076k011a)  as ADATA microSDHC Class-4 8-Gb. At least the size is basically correct in the ADATA branded card versus my unbranded version.

 

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

Progress Report – Hall Transistor based Level Measure

Below you will find a progress report video. The video shows a demonstration of my work-in-progress project that I have mentioned, at least the 3D Print portion, in previous posts. The actual product is a powder level alerting system used in reloading. While reloading, if a case’s powder level is out of Tolerance, a beeper will sound. The firmware is written in C and C++ and while I am testing on an Arduino Nano the final product will be on a surface mounted ATTiny85. In fact all but two components on the circuit board will be surface mounted.

The only output on the device is a beeper and the only input is a single push-button. Despite this limitation I can change nine different settings based on the duration of the button press. The main body of the code uses a state machine with non-blocking code with the exception of routines that decode button presses and sound button press related beeps, which do use blocking subroutines.

I now consider the firmware to be complete. Next, I must start on the printed circuit board design and then fabrication. Once the product is finalized I will post an update. The entire product, both hardware and software, will be released open source when it is final. That is probably some months away.

By the way, I almost threw in the towel on this project because I could not get the hall effect transistor to be stable. After much frustration and, ultimately, a great deal of investigation, I discovered that the problem was that, during debugging, I was powering the Arduino device using a USB cable while also sending out debug serial ASCII text messages over the same cable. Apparently using serial data over the same USB cable that provides power was introducing sufficient noise to destabilize the hall effect transistor. Once my project switched over to a standalone power supply instead of using the USB cable, the hall effect transistor became stable. The final product will run off of a 1/2-AA battery. This bug should be of interest to anyone doing embedded system design – be careful about supplying serial data over the same cable that provides power.

 

Posted in Uncategorized | Leave a comment