Category Archives: electronics

Fun (and a question) with a solar energy project…

Yes, it’s me, back after a far too long hiatus. Sometimes life intervenes, and you just have to reset your priorities. But rest assured, the geeky stuff that I used to work on and chronicle in my blog continues, and on this long Labor Day weekend, I thought I might mention a project I’ve been working on.

Long time readers of my blog may remember that I experimented with using a Raspberry Pi and a Raspberry Pi Camera module to get pictures of my hummingbird feader. Here is a refresher in case you don’t remember or didn’t see it. But at the time it was just a prototype. In particular, I never constructed a permanent setup for it. It got put back into a box, and I didn’t think about for a while. Over the last year I had major construction in my back yard, replacing a retaining wall, and our feeders were down for a long time. But that ended, and I recently started to get a tiny amount of free time. So, I thought that it would be fun to try to make a more permanent version of this project.

But I decided to do a bit more. I decided that what I wanted to do was to create a small solar powered “pod” which could be used to hold the Pi, and which could be reconfigured for other uses.

So, I bought a few goodies to help me along the way:

  • Allpowers 20A Solar Charge Controller I didn’t have to go with a charge controller for this project, but I thought that I might as go with one a bit beefier than I needed for this project.
  • ML7-12 7.2aH SLA battery I just wanted an inexpensive SLA battery to go with my charge controller.
  • A Newpowa 10W 12V solar panel I wanted something a tiny bit bigger than the small 6V panels that you commonly see, and again, this one was modestly priced.

    • As it happens, this system is probably not really enough to run an Raspberry Pi with a camera for 24/7, even with pretty good sunshine during the day. But I wasn’t sure how far off it would be, and how efficient the charge controller would be.

    If you’ve never set up such a system before (I hadn’t) the basic idea is the charge controller has three sets of terminals:

  • the solar panel
  • the battery
  • the load, which is regulated 12v output to drive whatever it is you are powering

The basic idea of the charge controller is to make sure that the voltage and current from the solar cell are efficiently applied to the battery to charge it. The charge controller that I bought is also supposed to prevent over discharge by disconnecting the load from the battery if the voltage drops too low, and which also is supposed to prevent overcharging.

So, I thought I would test it out.

Instead of using my Raspberry Pi, I dusted of a WEMOS D1 Mini, my preferred < $5 ESP8266 module. To it, I connected a pair of INA219 modules, one that would read the battery and voltage directly from solar cell, and the other that would do the same for the circuit that leads to the battery. The ESP8266 would take all these measurements once a minute, and would upload them to the Adafruit MQTT server. You could view them directly from their dashboard, but I downloaded 24 hours of data, and made some graphs using matplotlib. The sensor data from the solar panel are in blue, whereas the data from the battery is in green.

Some of the data makes sense to me. Looking at the current data, you can see that the graph starts with no current from the solar panel, as it is starting in the dark. We see that there is a current running out of the battery (it’s discharging) at a rate of somewhere around 70mA. But as the sun rises, we begin to get current from the solar cell. It’s current climbs, and the current into the battery falls, eventually reversing as it begins charging the battery. That all seems great.

But here is what confuses me. If we look at the voltage, sunrise occurs around 15:00 UTC and the voltage begins to climb. It goes up, and up, and up. I believe that I had the “overcharge” setting to be around 13.7v. I would expect that as the solar panel becomes more brightly illuminated, it would pass that level, and I would expect the charge controller to reduce the amount of current to the battery. But we really don’t see that. The current stays quite high, eventually topping 0.5A at 17V, or about 8.5w. This doesn’t seem good to me. The voltage on the battery terminals gets quite high (topping 17v) and I’m worried that it might be overcharging. I’ve double checked my hookup, the settings on the controller, and I’m baffled.

Can anyone provide any insight as to where my understanding might be going astray?

I’ll eventually write up a complete description of this project, so if any of this doesn’t make sense and you have any questions, feel free to leave comments and questions, and I’ll try to explain further. Eventually the code and other bits of information will show up here.

Thanks everyone….

Musing about a 2 dimensional delta robot…

First of all, if anyone is still swinging by this blog, yes, I’m still alive. While I haven’t exactly been prolific in my leisure activities, they haven’t stopped entirely. I worked on some simple embedded development for the hackaday.io 1K code challenge, which you can see on my hackaday.io page, and which hopefully I’ll write up here. I’ve got some additional projects in mind, so perhaps with a little extra effort on my part I’ll be getting back to more regular entries.

One of the things that has been kicking around in my head is to “make something that moves.” In particular, I’ve long been interested in gadgets like plotters, 3d printers, laser cutters and CNC machines. A few months ago on a whim, I ordered a CNC shield and Arduino so that I could begin to think about maybe creating a project which drives some steppers around to trace some pattern. I doubt that I possess the skills or know-how to do a good job of making a real CNC machine, but I kind of liked the idea of making a plotter. I started to work on the basic mechanical design of a simple 2D gantry. But frankly, I began to balk at the idea. You need two different sets of parallel ways, which seemed large and cumbersome, and each axis is different.

At the Maker Faire I had observed some simpler setups which generally go under the name of “Drawbots”. You can see an excellent write-up here on the “Death To Sharpie” page. I liked the idea a lot: it uses two steppers and the setups for each are symmetric. Each one winds and unwinds a chain, and the pen is suspended at the intersection of the two chains. In this incarnation, the pen doesn’t even have a separate control: it is simply drug around the poster board, leaving a trail wherever it goes. Pretty cool! I must admit though, I thought his software setup (laptop + Raspberry Pi + Arduino?) was a little complicated, and I’d probably enjoy working on the control software anyway.

But I was discussing this with my constant lunchtime companion Tom, discussing catenary curves and the like, and he basically said “why don’t you just use solid arms, making a 2D analog of the 3D delta robots you see in 3D printers?”

An awesome idea! One of the cool things about constructing a delta robot is that it consists of three essentially identical pillars. Yes, the three pillars all move slightly differently, but that is really a software issue, not a hardware one. A few moments of thought and I realized that you could make a pretty spiffy 2D version, and the math would actually be pretty easy.

So, in between tasks, I worked out the necessary quadratic equations, and created this gif that will demonstrate how the motion works.

The work space is the unit-size gray square at the bottom. It is bracketed by two rails, each of length two. Each has a carriage which runs along its side, and pins one end of a fixed arm (again, of unit length) which are held together in the center by a pin, which is where the pen will be. As you drive the red and green carriages back and forth, the intersection moves back and forth. It isn’t hard to see that the pen can reach any location in the unit square at the bottom.

It isn’t quite as compact as the typical drawbot, but I can’t help but think there are some serious mechanical advantages to setting up a bot this way. It should not be very hard to create an interpreter that could run on the Arduino that would take a small subset of G code and some basic scaling and rate information, and drive a pair of steppers to create this kind of a robot. I’ve never written code exactly like this before. It should be fun.

Stay tuned.

Weekend Update: Maker Faire, new gadgets, and I ground myself…

Greetings readers. I’m hopefully wishing there is still more than one.

This weekend was the Bay Area Maker Faire 2015, the 10th incarnation of an event which has become increasingly (even frighteningly) popular. I’m tempted to channel Yogi Berra, who said “Nobody goes there. It’s way too crowded.” Anyway, I got out of my house around 9:00AM, with the plan of parking at one of the offsite parking lots and shuttling in. It took me about an hour to get to the Oracle lot on 10 Twin Dolphin Drive, and there were already probably six or eight busses lined up, but probably a thousand people lined up as well. As it happens, it took slightly more than an hour to make it onto a shuttle, drive in and enter the gates. Bleh. Not the most fun, but I had a good nights sleep the night before, so I was mostly in good spirits as I entered the park.

It was very crowded. I was by myself, so I just started wandering. When I go to these things, I am mainly looking for three things:

  • Projects that inspire new projects.
  • Cool new products, especially inexpensive dev boards and gadgets for future projects.
  • Cool artwork that I haven’t seen before.

Sadly, I didn’t see a ton of projects that made me think of new projects, but there were a couple. I had a nice chat with Ben Krasnow who brought some low-tech versions of his excellent rheoscopic coffee table, which were just plastic cells that rotated on a lazy susan. You’ve probably seen identical gadgets in science museums. Fluid flow is always interesting. He said the instructions were already on the Make Magazine site, but I forgot to copy the url, and didn’t find it. He also said it would be in the print edition sometime soon.

I had a nice chat with Erin Tomson of Modulo Labs LLC. She’s a former Pixar colleague, who has gone off and created Modulo, a set of pluggable programmable modules that can be used to assemble modules in a tiny, secure network, without the hassle of routing jumper wires on breadboards. (In fact, a system like this would have prevented a lost hour of my time tonight, I’ll tell that story below.) It’s a very slick little system, and I’d like to see something like this take off. I can particularly see this as useful in education.

Check out her Kickstarter video.

I particularly like optical gadgets like telescopes and microscopes. My buddies Rich and Dave from the Chabot Telescope Makers Workshop were there, grinding away and answering questions about telescopes. Nice to catch up with them. They said that quite a few people came up to them and asked “So, you guys sell telescopes?” Sigh. This is the Maker Faire. If you are in the North Bay and want to learn how to build a telescope, click on the link above, and think about attending one of their free workshops (every Friday!).

I like projects which reuse camera phones, and this microscope project seemed pretty cool. They had a little gadget that allowed you to swap out three different lenses to get different magnifications. Their system seemed pretty cool, but the basic idea is pretty simple (in fact, it’s basically a version of Antonie van Leeuwenhoek’s first microscopes, but instead of holding it close to your eye, it’s held close to your cell phone, which can use nifty features like zoom and exposure adjustments, and can of course record video and stills. I should design such a gadget myself.

I also had a nice chat with Alan Yates who was demonstrating some “Lighthouse” technology that he’s been working on at Valve. The basic idea is to create a set of “beacons” that can be scattered around an environment, and a sensor that can (for instance) be mounted on a VR headset and can be used to figure out the position and orientation of the headset with high accuracy and low latency. I don’t have a link for this work yet (did I miss it, Alan?) but when I do, I’ll try to update it.

That was kind of it. I did poke my nose into various people experimenting with aquaponics, which I find interesting. I had a brief chat with the creators of Chip, the $9 computer currently on Kickstarter (I hope to have more information on that soon, stay tuned.) I didn’t spend much time in the “Dark Room”, the noise and flashing gives me a headache. I did spend some time looking at the various gardening and bee keeping exhibits.

And, I did pick up some new gadgets. Here’s a short video of my purchases, along with some links to the various items mentioned.

And that’s about it. If anyone thinks I missed something super cool, drop me a comment below and I’ll check it out.

Today, I had a bunch of chores to do, but I did start to play around with my AD9850 project a bit more. Since I spent so much time driving around yesterday, I had lots of time to think, and realized that the code the determined the tuning word (the 32 bit value used to select the frequency of the oscillator) was probably going to not work properly, since it used floating point arithmetic, and that probably didn’t have sufficient precision to do the calculation the way that I had coded. Indeed, when I got home, I hooked up and Arduino and found that I was not getting the sub-Hz spacing that I requested. I played around with the math a little bit, and got it working better, and then set it up and started it going. I had the output of the AD9850 going into my oscilloscope, so I could monitor the waveform.

And it was glitchy. Intermittent. Not working properly. Had I made a programming mistake?

I spent the better part of 45 minutes trying to understand how I had broken the program. Nothing made sense. I was cranky. I decided to step back and go buy some cat litter than I had forgotten, and give it a rest.

And of course when I got back, I stared at the board again. And it was immediately obvious. I had the AD9850 module on a breadboard, with all the RESET/CLOCK/LOAD/DATA lines going to the Arduino. And… that was it…

There was no common GND. I had somehow tugged out that little jumper wire. Without a common ground, it was surprising that there was any communications between the module and the Arduino.

Plugged it back in and voila. All works. Sigh. An hour of my life, wasted.

Suddenly, Erin’s Modulo setup seems pretty nifty. 🙂

Making a simple RC switch…

Over the last couple of years, I’ve spent a little bit of time making fixed wing aircraft from Dollar Tree foam. The results have been interesting and fun, but I’ve found that the need to find relatively large areas to fly means that it’s harder to go fly than I would like. On the other hand, multicopters require relatively less area, and I suspect I could do some test flights almost anywhere. So, over the last few months I’ve begun to accumulate the necessary parts to put one together. As this project continues, I’ll write up some more.

But one of the things I thought about today in between World Cup matches was putting some LED lights on the quadcopter. Besides just looking cool, they are especially useful on quadcopters because they allow you to see the orientation of the quadcopter more easily.

My RC mentor Mark Harrison has some notes about he wired up LEDs on his quadcopter. The basic idea is to get some LED strips, and then power them from a brushed ESC (like this one for $4.95) driven by a spare channel on the RC receiver. It’s a pretty good way to go.

But I wondered if I could do better. I’ve made a Christmas hat with LEDs before, driven by an Atmel ATTiny13, surely I could homebrew something…

So here’s where my thought is: I want to create a small pc board with just a few components. It will be powered from the receiver, and will read the servo control channel, and will use an Atmel ATTiny85 (I have a dozen on hand that I got from Tayda Electronics for about about $1.12 each, and they have 8K of memory, plenty for this application). At it’s simplest, we want the program to configure one pin as an input, and one pin as an output. The servo control signal looks like this:

ServoPwm

The pulse will be somewhere between 1ms and 2ms long. The ATTiny just needs to monitor the channel, and if the pulse is longer than 1.5ms, it will set the output high, otherwise set the output low. And that is pretty easy.

In the past, I’ve used avr-gcc to program these tiny chips. For the ATTiny13 with just 1k of flash, that’s pretty understandable. But it turns out that with a bit of work, you can use the Arduino environment to program the ATTiny85s. This website gives most of the details. It’s pretty easy, and I got my MacBook all configured in just a few minutes. Then, I entered and compiled this (as yet untested) code:

[sourcecode lang=”cpp”]
/*
* I thought I would dummy up a simple RC controlled switch using
* an Atmel ATTINY85 processor, but code it all in the Arduino
* environment. The idea is to use pulseIn() to read the data signal
* from the RC receiver, and threshold it, setting an output pin
* if the pulse length is > 1500 ms, and clearing it if less.
* Very simple. It should be able to be powered directly from the
* receiver, and if we had some kind of FET we can switch large loads
* (like a strip of LEDS).
*/

int inputPin = 0 ;
int outputPin = 1 ;

void
setup()
{
pinMode(inputPin, INPUT) ;
pinMode(outputPin, OUTPUT) ;

// if we never get a pulse, we want to make sure the
// ourput stays switched off.
digitalWrite(outputPin, LOW) ;
}

void
loop()
{
digitalWrite(outputPin,
pulseIn(inputPin, HIGH) > 1500 ? HIGH : LOW) ;
}
[/sourcecode]

Couldn’t be much easier. If you hooked up an led with a current limiting resistor to pin 1, you can test this (I’ll put up some video once I get it going). To power a larger 12v string (like this red LED string I got for $8.90 for 5m from Amazon) you’ll use that output to power a FET to switch the much larger current, but that’s dead simple too. I can probably run the ATTiny off its internal oscillator at just 1Mhz.

But as cheap as that is, it’s probably not worth the cost of home brewing one.

But of course, you don’t need to stop with this stupid application. You have a total of five or six pins, so you can easily control multiple strings. You can also implement more sophisticated controls: instead of just using an on/off signal, you can look for short switch flips versus long switch flips, and change into different blinking modes. A short flip might make the landing lights blink. A long one turns them on steady. You could even use the ATTiny to drive RGB addressable LEDS (check out this Instructable for details). Different flips might turn on different colors, or switch between Larson scanner modes… blinking… the skies the limit.

I’ll let you know when I get more of this done.

A day at the Official Propeller Conference

Even casual readers of this blog know that I’ve enjoyed playing around with the Arduino and the Atmel AVR chips. I really like them, and have used them for a variety of personal projects, as well as using them for a variety of educational projects for a local high school where I mentor students. But I also have a variety of other boards, from MSP430s to the BeagleBone, from the Raspberry Pi to the Parallax Propeller.

The truth is, I haven’t done a lot with the Propeller board. I must admit that a lot of it is simply inertia: if something you already know fairly well serves your needs, then learning something new is often a distraction from your task at hand. But there are things about the Propeller that I do find interesting and compelling.

It’s fast. The chip can be clocked up to 80Mhz, and has 8 cogs, each a 32 bit core with 2KB of local storage for instructions and data.

It has a built in byte code interpreter for SPIN, a high level language. Each cog can execute about 80,000 of these high level byte codes per second, or about 640,000 max if all cogs are funning. I have mixed feelings about Spin, but it’s a cool idea nonetheless.

It avoids interrupts, preferring to use cogs to process events. Interrupt processing is challenging for new programmers (and in some cases, even experienced ones) and the cog model might be easier and more flexible for many real time tasks.

It avoids dedicated hardware peripherals, instead providing “virtual” peripherals as software. Because the chip is fast, and there are many cogs, it’s possible to implement many devices such as UARTS, PWM, servo drivers and even video as code which runs on a particular cog in parallel with the user program. This gives the programmer a great deal of flexibility. SPIN supports a library of user-contributed objects which can really lend to the flexibility of the Propeller.

So, there is lots to like! So, for the second year in a row, I’ve shuffled off to meet some of my friends from tymkrs.com at the Official Propeller Conference. It’s a fairly small get together of Propeller enthusiasts, hosted by Parallax and featuring short presentations on Propeller hardware and software techniques. I had a lot of fun. Parallax is a remarkably small company, run by Ken and Chip Gracey, and having maybe forty employees. Besides the Propeller, they manufacture a bunch of other items, including sensors and robotics items. The highlight of the day was a talk by Chip about the upcoming Propeller 2. Chip’s talk was remarkably informative, and so devoid of normal marketing bull that I actually blinked several times at his honesty.

Propeller 2 looks very cool. To me, the most exciting thing is that it one ups the flexibility of the Prop 1 in allowing any pin to be configured as digital or analog, and an input or output. The Prop 1 has been used by hams to directly generate beacon signals but the new capabilities would seem to open a variety of demodulation as well as modulation techniques. Chip said that the first actual silicon for the Prop 2 will be arriving at Parallax this Monday, and that he’ll let us know via the Parallax forums how that goes. I’ll be paying attention.

I had a great time, culminating with a BBQ dinner with Atdiy, Whisker, Roy, Joe, and some of the Parallax crew. It’s inspired me to actually dig in and start learning Spin. I’m staring over at my Parallax board, happily blinking LEDS. It’s a start.

More details on the Propeller as I goof around.

Simulation experiments with LT-Spice…

Yesterday, I mentioned Rory’s excellent introduction and exploration into DTL logic. He covers some of the basics here, including circuits for all the basic gates: AND, OR, NOT and NAND. The AND and OR gates are interesting, because they consist entirely of diodes and resistors. They do have the drawback that they are “lossy” (the technical term is non-regenerative). They experience a voltage drop across them, so they can’t be cascaded forever, as the voltage drop continues with each gate, and they ultimately lose the ability to compute effectively. The NOT and NAND gates on the other hand use a typical bipolar NPN transistor, and use the amplifying capability of transistors to regenerate the signal.

I was interested in a couple of things about the circuit though, so I fired up LTSpice for a little computational experiment.

I have played around with simple inverters like this one, which Rory mentioned which I always thought of as an effective inverter. But Rory mentioned that it was unable to run at higher speed (say, around 1Mhz). I was also interested in how the choice of diode affected the circuit.

So, I built it. Rory used BAT42 Schottky diodes, which weren’t in my component catalog, so instead I substituted a 1N5818 diode.

dtl-nand

And sure enough, it works pretty darn well. I coded up a 500kHz clock, and the output looks pretty clean. I fed it two pulse trains one delayed with the other, and it looks pretty good.

trace

If you substitute some of the cheap diodes I have on my bench (like a 1N914 or a 1N4148) you can see that it works pretty well at frequencies around 1000Hz, but fails miserably at frequencies of 1Mhz. Ditto for the simplified inverter circuit we looked at above: it simply can’t function at 500khz. Superimposed with the NAND pulse train, here is the output of the simplified inverter wired to InputA. As you can see, the input pulses just turn into a feeble triangle wave.

inverter

I suspect that thinking about why this is will lead me to a much more robust understanding of transistors.

Tiny-Tim: A DTL computer (in progress)

Previously, I had linked to Rory Mangles’ experiments with relay based computers. He had an incredible build of a relay logic computer called Tiny-8 which used paper as program mamory, inked with a pattern which could be read by photo sensors to sequence the control logic in his computer. I thought it was amazing. But surfing back to his website, he appears to now by working Tiny Tim, a diode-transistor logic (DTL) computer, made from discrete 2N3904 transistors and Schottky diodes. Sadly, there isn’t much actual build here yet (this update is six months old) but there is some good information, and I hope that he’ll pick up the project again.

Here is a link to his video of a simple flip flop:



Examining the output of a simple remote-keyless-entry transmitter…

Yesterday I was looking (sadly unsuccessfully) for some BPW32 photodiodes that I know I have somewhere, when I ran across some of 434 Mhz transmitter modules from Sparkfun (now a retired part) that I had never used. These little $4 transmitters are commonly used for remote-keyless access or similar applications. They have just four pins: power, ground, a data pin, and an antenna, so they are easy to interface. I thought that they might be useful as backup low power beacon transmitter aboard a high altitude balloon payload, but I had never unpacked them, never tried them out. It dawned on me that I might also be able to use them with my code which I had previously written to send Hellschrieber telemetry. But to start out, I just made a simple program that sent the string “BEACON” at 1 second intervals and fed it to the data pin.

But how to receive it? I fired up my FT-817 and tuned it roughly to 433.920 Mhz (the nominal frequency) and even without an antenna, I could clearly hear the buzzy signal with a 1 second period. In fact, I could still hear it over 50Khz away from the nominal frequency. The signal was very, very wide. That got me curious so I dug out my Funcube Dongle Pro, hooked up a simple wire whip antenna, and tuned it in.

Here’s a picture of 96Khz surrounding 433.920:

Bleh. Really wide, really ugly, and really unpleasant sounding in the earphone. The horizontal lines coincide with the transmissions, the long harmonic laden regions in between are the “dead times”.

I suppose that if you were only using these intermittently in a key fob kind of situation, I could justify using something like this, but for the kind of application I was envisioning, they just seem gratuitously poor. Still, it was fun getting my Funcube Dongle out of the box and playing with it again.

Addendum: they also don’t work as a Hellschrieber transmitter. I hooked up my “Hellduino” code, but the resulting spray of noise didn’t provide any useful decodes. I think that the transmitter has an upper limit on how long pulses can be, and is also sending AM modulated signals, rather that keyed CW.

Spray-on Antennas? I say “Spray-on Bunkum”

Thanks to John, who pointed out that this post was mangled. Fixed now.

I wasn’t going to mention this one, but Dave, Chris and Jeff over at The Amp Hour brought it up on their most recent podcast, but other than Jeff’s somewhat enthusiastic declaration that he thought it was BS, I don’t think they pulled it apart enough.

The topic is a recent video poasted under the auspices of Google’s new Solve for X program. Try watching it:



If you try googling for “spray on antennas”, you’ll find dozens and dozens of links to this video, or what amounts to a copied press release regarding this video. If you dig a little deeper, you’ll find lots of people complaining about how poor the presentation was. What is somewhat harder to find is any kind of a critical evaluation of the information (what little there is) on this antenna scheme. I’ll try to confine my comments to the latter.

It’s begins with a pitch, and not a modest one. We are told to imagine that we can send signals twice as far using no more power. Or the same distance with half the power. Or that we can get rid of cell towers. Or communicate from the depths of the ocean to outer space. And the key is some kind of nanotechnology. that Chamtech has developed for “spray on antennas”.

Following this pitch is a story: a story how “a business partner” who asked him develop a hidden antenna for Special Operations. He was then asked by “the government” to try his antenna technology, which was then tested by “a government team”, who found that this spray on antenna was “an order of magnitude better” than their best antenna.

I’m sorry, but that’s just bunk. Good antennas are efficient. A given antenna has a particular radiation resistance. For instance, a typical dipole antenna such as the antennas that many radio amateurs use might have a radiation resistance of around 70 ohms or so. But, of course, there are other bits of resistance in the antenna too. There is the ohmic resistance of the antenna, so-called “ground losses”, and “coil losses”. The antenna efficiency is just the ratio between the radiation resistance and the total resistance of the antenna.

But here’s the thing: at VHF+ frequencies, it’s just not that hard to make antennas with efficiencies that are 90% or higher. And that means that there is no “head room” to make an antenna which is “an order of magnitude more efficient”. It’s just basic math. You can’t get more energy out of an antenna than you put in, and existing antenna designs are already enormously efficient at radiating what you put in.

Beyond that, the geometry of antennas is important. You can’t generate an efficient one by just stringing a random conductor (or spraying one) higglety piggly all over the place. The length of the various elements change the feedpoint impedance and that must be matched carefully to the transmitter output impedance in order to be efficient. The idea that these nanocapacitors can “hold” electrons and then release them at their “happy place” is enough to make milk shoot out of my nose.

The “test” on the iPhone was comical: inside an Faraday cage (originally he said anechoic chamber, which I thought was an odd mistake for an RF engineer to make) he claimed that their technology improved the output power of the iPhone by “20 dBm”. I’m sorry, but I cry BS on this as well: dBm is the power ratio referenced to a 1mw signal. It doesn’t make any sense to say that there is a 20dBm improvement. An improvement of 20dB is a hundred fold increase in output power. Just where is this power supposed to be coming from? A typical cell phone has an output power of around 27dBm, or around 500mw. A 20dB improvement would raise that to 47dBm, which is about 50 watts. Bunkum.

Honestly Google, I know you have some pretty smart guys who know about RF: why did you let this guy use your forum to sell this complete nonsense? It doesn’t bode well for Solve For X if it can’t distinguish between “radical solutions” and “snake oil”.

More on ATtiny programming…

Last night’s hacking adventure was inspired by a couple of recent posts from Roger, G3XBM having to do with light based communication. The first was his simple beacon design: it’s just a keyer chip, a MOSFET, a voltage regulator, and some (beefy) current limiting resistors. Roger used this beacon to do some non-line-of-sight communications via “cloudbounce”.

It’s inspiring, so I’ve been thinking about trying some similar experiments. As it would happen, I have some reasonably high power LEDs floating around, and rigging up the transmitter really wouldn’t be too hard. I don’t have any of the K1EL chips that he used, but I do have a few of the Atmel ATtiny13s floating around, so I figured I’d go ahead and write up a simple beacon program to send my call via QRSS3 and (if a switch is tossed) 12wpm Morse. After my ATtiny powered Halloween Pumpkin and my ATtiny13 powered Christmas hat, I figured it would be a snap. I fetched an Arduino, programmed it with the AVRISP sketch, and then went to wire up the Arduino to program the code (did I mention I wrote some code?) to an ATtiny13 which I stuck on a breadboard.

And that’s when I realized that I didn’t take very good notes about how I did it last time, and refinding the necessary connections and commands was both difficult and some sources didn’t even have the information correct.

So I’ll remember, here’s the list of connections you need:

  • ATtiny pin 4 goes to ground.
  • ATtiny pin 8 goes to 5V.
  • ATtiny pin 1 goes to Arduino pin 10.
  • ATtiny pin 5 goes to Arduino pin 11.
  • ATtiny pin 6 goes to Arduino pin 12.
  • ATtiny pin 7 goes to Arduino pin 13.
  • Many sources say that for Unos, you must put a 10uF cap between the RESET and GROUND on the Arduino. I had one, so I did it. I’ve used older Arduinos (such as the NG) which have different reset circuits (you must manually reset them to program them) and for those it isn’t necessary. Your mileage may vary.

Lastly, you need the right avrdude command. It took me an embarrassingly long time to come up with the right command, mostly because it appears that I needed to manually set the baud rate to 19200 (what the AVRisp sketch expects). Archived for posterity:


avrdude -v -c avrisp -p t13 -P /dev/tty.usbserial-A800eKtX -b 19200 -U flash:w:beaker.hex

I discovered a couple of things: while the previous versions of the ATtiny I used seemed to have fuses set so that the internal oscillator (nominally 9.6Mhz) would be divided by 8, this one did not. I sorted this out by defining F_CPU appropriately, but it was late and I didn’t get my PWM code (which generates the 800hz sidetone) working properly. Tonight, I’ll dust it off and hook it to the scope and see what’s going on.

When this is done, it should be fairly simple to get the rest of the prototype transmitter together. Roger used a 4″ or so lens as the collimating optic for his transmitter. As it happens, I have a dusty 6″ Newtonian telescope that I purchased for a pittance, whose mirror really isn’t up to the kind of standards I appreciate. I think I can mount a high power LED into a 35mm film can and insert that into the telescope eyepiece, and it should make an excellent collimator (I may need an auxillary lens if the cone from my LED is too broad, I think the telescope is around f/5 or so). Perhaps by this weekend, I’ll have the transmitter setup, and I can start working on the (much harder) receiver.

Hope this article saves someone some time. I know I’ll be referring back to it in the future.

Web-based control of an RGB LED via the Nanode, an Arduino compatible microcontroller

Okay, I finally got some time to record a video about a simple little webserver project I hacked together earlier this week. My wife Carmen got me a Nanode kit from Wicked Device around Christmas. These are Arduino compatible development boards which include a Microchip ENC28J60 Ethernet device to enable web connectivity. One slight drawback is that they are not compatible with the Ethernet shields which are based upon the Wiznet 5100 chipsets, so you’ll need different drivers and different code. I’ve been experimenting with the Jeelabs EtherCard drivers, which seem to work well and are well supported, although they are limited in their TCP implementation (it limits TCP responses to just a single TCP/IP packet). Nevertheless, I implemented a simple webserver to control the I/O pins of the Nanode, based upon the ideas (but not the code) of Jason Gullickson’s RESTduino. I then did a short demo of how you could use it to control a strip of RGB LEDs from a simple jQuery based interface. Watch:



Here’s the sketch. Feel free to swipe it and any ideas for any web enabled projects you need (nothing here is worth copyrighting or licensing at all, consider it public domain).

[sourcecode lang=”cpp”]
#include <EtherCard.h>
#include <NanodeUNIO.h>

//
// remote by Mark VandeWettering
//
// a reimplementation of the "RESTduino" idea, first published at:
// http://jasongullickson.posterous.com/restduino-arduino-hacking-for-the-rest-of-us
//
// I decided to rewrite this application because:
// 1. originally, it was written for the Wiznet based Ethernet Shield, but I have
// mostly Nanodes, based upon the ENC28J60
// 2. It was ported to the Ethershield library by Andrew Lindsay, but Andy has decided
// that he’s decided not to continue development of that library, deferring to the
// EtherCard library being developed by JeeLabs
// 3. I thought there was a lot of cool additions that could be made! Okay, I haven’t
// implemented any at the moment, but I will!
//

#define DEBUG 1
#define BUFFER_SIZE (900)

byte Ethernet::buffer[BUFFER_SIZE] ;
BufferFiller bfill;

char okHeader[] PROGMEM =
"HTTP/1.0 200 OK\r\n"
"Content-Type: text/html\r\n"
"Pragma: no-cache\r\n"
"\r\n" ;

char responseHeader[] PROGMEM =
"HTTP/1.1 200 OK\r\n"
"Content-Type: text/html\r\n"
"Access-Control-Allow-Origin: *\r\n"
"\r\n" ;

void
homepage(BufferFiller& buf)
{
buf.emit_p(PSTR(
"$F"
"<html>"
"<head>"
"<title>webserver remote</title>"
"<style type=\"text/css\">"
"body { width: 640px ; }"
"</style>"
"</head>"
"<body>"
"<h1>webserver remote</h1>"
"<p>"
"This webserver is running on a <a href=\"http://nanode.eu\">Nanode</a>, an "
"Arduino-compatible microcontroller with web connectivity. It uses the <a"
"href=\"https://github.com/jcw/ethercard\">EtherCard library</a> written by "
"<a href=\"http://jeelabs.net/projects/cafe/wiki/EtherCard\">JeeLabs</a>. "
"Inspired by Jason Gullickson’s <a href=\"http://www.youtube.com/watch?v=X-s2se-34-g\">RESTduino</a>."
"</p>"
"<hr/>"
"<p style=\"text-align: right;\">Written by Mark VandeWettering</p>"
"</body>"
"</html>"
), okHeader) ;
}

#define CODE_ERROR (-1)
#define CODE_WRITE (0)
#define CODE_READ (1)
#define CODE_ANALOG_WRITE (2)
#define CODE_INDEX (3)

int
cmdparse(const char *cmd, int &pin, int &val)
{
const char *cp = cmd+4 ;

if (*cp++ == ‘/’) {
if (*cp == ‘ ‘) {
return CODE_INDEX ;
} else if (isdigit(*cp)) {
pin = atoi(cp) ;
while (isdigit(*cp)) cp++ ;
if (*cp == ‘ ‘) {
return CODE_READ ;
} else if (*cp == ‘/’) {
cp++ ;
if (isdigit(*cp)) {
val = atoi(cp) ;
while (isdigit(*cp)) cp++ ;
if (*cp == ‘ ‘)
return CODE_ANALOG_WRITE ;
else
return CODE_ERROR ;
} else if (strncmp(cp, "HIGH", 4) == 0) {
cp += 4 ;
if (*cp == ‘ ‘) {
val = 1 ;
return CODE_WRITE ;
} else
return CODE_ERROR ;
} else if (strncmp(cp, "LOW", 3) == 0) {
cp += 3 ;
if (*cp == ‘ ‘) {
val = 0 ;
return CODE_WRITE ;
} else
return CODE_ERROR ;
}
} else
return CODE_ERROR ;
} else {
return CODE_ERROR ;
}
} else {
return CODE_ERROR ;
}
}

void
setup()
{
byte mac[6] ;

Serial.begin(9600) ;
Serial.println("\nbrainwagon remote webserver\n") ;

NanodeUNIO unio(NANODE_MAC_DEVICE) ;
unio.read(mac, NANODE_MAC_ADDRESS, 6) ;

if (ether.begin(sizeof Ethernet::buffer, mac) == 0) {
Serial.println("Failed to access Ethernet controller.") ;
for (;;) ;
}

if (ether.dhcpSetup()) {
ether.printIp("IP: ", ether.myip) ;
ether.printIp("GW: ", ether.gwip) ;
ether.printIp("DNS: ", ether.dnsip) ;
} else {
Serial.println("DHCP failed.\n") ;
for (;;) ;
}
}

void
loop()
{
word len = ether.packetReceive() ;
word pos = ether.packetLoop(len) ;
int pin, val ;

if (pos) {
bfill = ether.tcpOffset() ;
char *data = (char *) Ethernet::buffer + pos ;
Serial.println(data) ;
switch (cmdparse(data, pin, val)) {
case CODE_READ:
pinMode(pin, INPUT) ;
bfill.emit_p(PSTR(
"$F"
"{\"$D\" : \"$S\"}"),
responseHeader,
pin, val ? "HIGH" : "LOW") ;
break ;
case CODE_WRITE:
pinMode(pin, OUTPUT) ;
digitalWrite(pin, val ? HIGH : LOW) ;
bfill.emit_p(PSTR(
"$F"), responseHeader) ;
break ;
case CODE_ANALOG_WRITE:
pinMode(pin, OUTPUT) ;
analogWrite(pin, val) ;
bfill.emit_p(PSTR(
"$F"), responseHeader) ;
break ;
case CODE_INDEX:
homepage(bfill) ;
break ;
case CODE_ERROR:
default:
bfill.emit_p(PSTR(
"HTTP/1.0 404 Not Found\r\n"
"Content-Type: text/html\r\n"
"\r\n"
"<html><body><h1>404 Not Found</h1></body></html>")) ;
break ;
}
ether.httpServerReply(bfill.position()) ;
}
}
[/sourcecode]

A $.33 MAX232CPE, or a $0.01 2N3904?

In response to my previous post, @xek replied:

https://twitter.com/#!/xek/status/163442298456260608

Well, the fact is I had heard of doing that. It’s not really hard to rig something that will convert the RS232 level from the GPS into TTL levels for the Arduino. It just takes a single transistor inverter: you rig an 10K resistor from the RS232 signal to the base, a 1K resistor from 5v to the collector, and then ground the emitter. Tap the transistor on the emitter side, and voila! It works. I rigged this up on the breadboard and checked it on the scope, and sure enough: 5v and 0v. I then coded up a simple sketch which used the SoftwareSerial library: it instantiates a serial port, then copies bytes when available to the normal Serial output device. Once I remembered that my GPS output at 4800 baud, the program worked flawlessly.

After I got this working, I gave the other direction a tiny amount of thought. I couldn’t think of a good, simple way to convert the TTL level to the negative levels without using some kind of charge pump, or a negative supply. But there is a cute trick you can use, that I discovered while surfing for alternative circuits: check it out. The trick is that if you are operating half duplex (only one side of the transmission transmits at the same time), the transmit line will go to the negative state. So, if you need to output a negative value, you simply swipe the voltage from Tx side of the RS232 line. That just takes a PNP transistor. Very cute.

Addendum: the receive circuit looks the same as mine, except they add a diode. Novice that I am, I don’t get why it is necessary or desirable. My circuit seems to work fine without it: can someone with experience tell me why it’s a good idea?

Addendum2: The MAX232s aren’t wasted: I am using it as an opportunity to learn Eagle and design a simple but still useful PCB. I’ll still be working on that.

Unequal Resistor R-2R Ladder Optimizer

I was reading up on resistor ladder DAC circuits on Wikipedia, and came across the Unequal Resistor R-2R Ladder Optimizer. It’s very neat! You can enter the number of bits you need, and the values of the pile of resistors that you have measured from your bench, and it will produce an optimized design using those values. When you are making an 8 bit DAC, the normal variation in a 5% tolerance (or even a 1% tolerance) can cascade to keep you from being entirely linear, or even monotonic, so doing this optimization seems enormously practical. As a bonus, once you have your DAC simulated using the Falstad Circuit Simulator, which is itself an enormously cool thing: a Java based circuit simulator that can accept new models encoded on the URL! Paul Falstad has a huge number of other cool educational Java applets, check it out!

New 6502 processor at Mouser.com?

Dave Jones (@eevblog) tweeted:
https://twitter.com/#!/eevblog/status/162530266513014784

And indeed, he’s right! WDC (the Western Design Center) has made a new version of the 6502 available at mouser.com. It’s a 40 pin DIP package, listed at $6.95 in quantity one, and can be clocked up to 14Mhz. It sends my mind racing back to the days of Star Raiders on my Atari 400. Not sure why it would be a good part to use other than nostalgia, but I’m bookmarking for future consideration.

W65C02S6TPG-14 Western Design Center (WDC) Microprocessors (MPU)

New addition to the brainwagon lab: a Rigol DS1102E

This week, I splurged and bought myself a new piece of test equipment: a Rigol DS1102E 100Mhz oscilloscope, and compared to my old 25Mhz Philips (which was indeed a great buy at only $20) it’s very, very cool. Among the most neat features that I’ve started to use is the ability to do screen and waveform grabs, and save them to a little USB flash drive. To gain some experience with the new gadget, I dusted off a version of Hans Summers’ low power QRSS beacon that I had breadboarded up a chunk of copper clad. Here’s the video I did about it (and a glimpse of my old scope too!):



The oscillator operates around 10.14 Mhz, and I couldn’t really see any detail of the waveform with my old scope: it just didn’t have the necessary bandwidth. But with the new scope, the situation is quite a bit different. I powered the oscillator up with a pair of D cell alkalines. I adjusted the bias potentiometer for the best looking sine wave, and it’s not too bad. Here’s a screendump of its best looking sine wave, and the FFT of that signal below. You can see that there is a bit of a second harmonic (due mostly to the asymmetrical waveform) but that it’s overall pretty good. The peak to peak voltage is around 2.18 volts, which is about a 12 mw.

By adjusting the bias potentiometer, you can get more power out: the peak to peak voltage rises to around 3.64V, for an output of around 33mw. But the waveform looks much less uniform, more energy scattered into the second harmonic.

I’m really liking this. I will probably make some additional changes to this circuit tomorrow, but having a good scope to examine how the changes affect the performance is really awesome. A great investment in my electronic education.