Monthly Archives: January 2012

The downside of Arduino…

First of all, I really like the Arduino. There are lots of reasons: great community, relatively inexpensive, wide hardware availability and variety, and often a good “impedance” match to projects. But there are a few design choices (both hardware and software) that can be a nuisance, especially as you try to push the limits of what can be done on such inexpensive and low power hardware.

First of all, there is the basic software philosophy. I love the fact that it is a single download: this simplifies installation, and whether you are an expert or a novice doesn’t matter, that’s simply more convenient. But using the program editor provided is simply not that desirable for experts who might be more used to Eclipse, or to an old fashioned kind of guy like myself for whom vi and Makefiles is more reasonable. With a little work you can find out where avr-gcc, avr-libc and avrdude are installed and add them to your search path, but you still have some work to build a Makefile which can compile your sketch from the command line. That’s a little annoying.

But more annoying are the design choices of the libraries themselves.

High among them are the heavy use of delay and the relative invisibility of interrupts. This may simplify short programs, but it provides no help to more sophisticated programs, and may in fact hinder them. Consider my experiments of last night (which fueled the rant of this morning). I merely wanted to implement a serial terminal using the TVout library and some serial communications library. The idea would be “read from serial, print to TVout”, voila, should be simple.

TVout generates NTSC video on the fly, and it basically works great. To do so, it uses regular timer interrupts. and if you dig into the library itself, you might find out that it uses Timer1. At regular interval, the timer 1 counter overflows, and the library knows that it’s time to bitbang out the video using some carefully constructed code. It also appears to use Timer2 to generate audio tones. Hmmm. The AVR chip that underlies the normal Arduino has only three timers… is that going to be a problem? How can I tell if another library also uses those timers?

You won’t find it in the documentation to any library. Arduino programming is supposed to be easy, and remove the need to understand how the underlying hardware works. Except that when you try to use two libraries together, and they happen to both use the same underlying timer resources, it doesn’t work right. There are no compile issues, it’s just one or both of the modules fail.

Which it did of course last night. You’d think that a loop like:

void
loop()
{
    TV.print((char)Serial.read()) ;
}

might have a chance of working, but it doesn’t. It drops and mangles characters horribly. While you might be able to poll some switches, apparently typing is something that is simply beyond the realm of expectation.

Some of you are probably going to leap to TVout’s defense, claiming that “You’re not doing it right! There is an example sketch which shows you the right way to do Serial and TVout!” Let’s have a look at that little sketch, shall we?

#include <TVout.h>
#include <pollserial.h>
#include <fontALL.h>

TVout TV;
pollserial pserial;

void setup()  {
  TV.begin(_NTSC,184,72);
  TV.select_font(font6x8);
  TV.println("Serial Terminal");
  TV.println("-- Version 0.1 --");
  TV.set_hbi_hook(pserial.begin(57600));
}

void loop() {
  if (pserial.available()) {
    TV.print((char)pserial.read());
  }
}

Okay, we have some new library, which we never heard of before. It’s apparently part of the TVout download. Documentation? No. It calls a function I haven’t seen before, “set_hbi_hook”. Is that documented? No. I am pretty sure it’s a hook which will get called at the end (or the beginning?) of a horizontal blanking interrupt (this isn’t my first rodeo) but what’s really going on here. The pserial.begin call must return a function… time to crack open the source code.

And, it’s about what you expect. There is a hook function that gets called on every line, right before the line is rendered. My guess is that it’s bad if the timing of the hook function is in anyway indeterminate, because then the rows will start at odd intervals. But each render routine starts with a line which waits… for some length…. maybe there is some amount of time (undocumented, different for PAL/NTSC, maybe just the front part of each scanline, read more code) that if you don’t exceed, you’ll be fine. What does pollserial do? Well, it snoops at the serial data registers (polling!) to see if a new character has arrived. It then puts it in a ringbuffer, so that it can be made available to the read call later. Okay, I understand.

But did I mention the reason I didn’t use this code in the first place? It’s that pollserial didn’t compile on my Arduino 1.0 setup (most libraries that aren’t part of the core don’t out of the box yet, in my experience). I could probably figure that out (has something to do with inheriting from the Print class and a prototype mismatch) but in my real, ultimate application, I wanted to read from a PS/2 keyboard. It will of course have the same (but differing in details) issues, and I’ll have to tweak their driver code to make it work with TVout too. Sigh.

Ultimately, I guess I disagree with one part of the Arduino philosophy: that programming can ever really be simple. Writing a program to blink an led, or read a switch isn’t hard, no matter what language or processor you use. Simple programs are simple, but the virtue of computers is that they can do things which are complex. If your software environment doesn’t give you sufficient help in organizing and doing complex actions, then you are missing out a great deal of the purpose of computers.

Addendum: While trying to fix the compile errors in pollserial, I found this fragment:

int pollserial::read() {
        if (rxbuffer.head == rxbuffer.tail)
                return -1;
        else {
                uint8_t c = rxbuffer.buffer[rxbuffer.tail];
                //tail = (tail + 1) & 63;
                if (rxbuffer.tail == BUFFER_SIZE)
                        rxbuffer.tail = 0;
                else
                        rxbuffer.tail++;  
                return c;
        }
}

Can you spot the problem? Hints: BUFFER_SIZE is defined to 64, and rxbuffer.buffer is malloced to be BUFFER_SIZE bytes long.

Hellduino: Sending Hellschreiber from an Arduino

Update: Welcome Hack-a-day readers! If you are looking for the schematics for this “transmitter” (really just a simple oscillator, send some love to radio guru Steve Weber over at his website. You could really use any oscillator you like, even a canned oscillator (although the square waves would generate lots of harmonics).

Yesterday’s project coupled a simple Colpitt’s oscillator (snipped from Steve Weber, KD1JV) with an Arduino. Steve used it to send temperature telemetry in Morse code back to his shack from an outdoor thermometer. But I thought that something else could be done: sending telemetry in Hellschreiber.

Hellschreiber is an early type of facsimile teleprinter system developed in the 1920s, which has enjoyed a certain amount of popularity in the amateur radio community. It sends characters using a conventional on-off keyed transmitter, just like Morse, but instead of sending dots and dashes of different lengths, it scans characters left to right, and top to bottom, and keys the transmitter on where each letter is “on”. Thus, a Morse transmitter can be modified pretty simply to send Hellschreiber.

So I did.


Here are some details. Hellschreiber is normally defined as sending characters defined on a 7×7 matrix, at 122.5 dots (2.5 characters) per second. But the actual font is actually defined on a 7×14 matrix. To keep the bandwidth of the signal down, the font doesn’t ever define a character that requires turning single dots on or off: the minimum signal changes are two dots long. These “half dots” are sent at 245 baud, or about 4.08ms per dot. Because I needed to account for the time spent looking up the character, I tuned that down to about 4.045ms. I was concerned that because I was keying the oscillator on and off, the startup time (which I estimated at about 2ms) could be a problem, but I suspect the shutdown time is about 2ms as well, so the overall system works better than you might imagine. The startup and shutdown keying waveforms are a bit erratic though, and the bandwidth of the signal is probably too wide. I think a better way to do this would be to build an oscillator that runs continuously, and then key a buffer amp with a filtered pulse to keep the bandwidth low. But for a 500 microwatt transmitter (estimated, and represents power going into the antenna, not radiated) it probably works just fine.

Here’s the source code:


int radioPin = 13 ;

typedef struct glyph {
    char ch ;
    word col[7] ;
} Glyph ;

Glyph glyphtab[] PROGMEM = {
{' ', {0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000}},
{'A', {0x07fc, 0x0e60, 0x0c60, 0x0e60, 0x07fc, 0x0000, 0x0000}},
{'B', {0x0c0c, 0x0ffc, 0x0ccc, 0x0ccc, 0x0738, 0x0000, 0x0000}},
{'C', {0x0ffc, 0x0c0c, 0x0c0c, 0x0c0c, 0x0c0c, 0x0000, 0x0000}},
{'D', {0x0c0c, 0x0ffc, 0x0c0c, 0x0c0c, 0x07f8, 0x0000, 0x0000}},
{'E', {0x0ffc, 0x0ccc, 0x0ccc, 0x0c0c, 0x0c0c, 0x0000, 0x0000}},
{'F', {0x0ffc, 0x0cc0, 0x0cc0, 0x0c00, 0x0c00, 0x0000, 0x0000}},
{'G', {0x0ffc, 0x0c0c, 0x0c0c, 0x0ccc, 0x0cfc, 0x0000, 0x0000}},
{'H', {0x0ffc, 0x00c0, 0x00c0, 0x00c0, 0x0ffc, 0x0000, 0x0000}},
{'I', {0x0ffc, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000}},
{'J', {0x003c, 0x000c, 0x000c, 0x000c, 0x0ffc, 0x0000, 0x0000}},
{'K', {0x0ffc, 0x00c0, 0x00e0, 0x0330, 0x0e1c, 0x0000, 0x0000}},
{'L', {0x0ffc, 0x000c, 0x000c, 0x000c, 0x000c, 0x0000, 0x0000}},
{'M', {0x0ffc, 0x0600, 0x0300, 0x0600, 0x0ffc, 0x0000, 0x0000}},
{'N', {0x0ffc, 0x0700, 0x01c0, 0x0070, 0x0ffc, 0x0000, 0x0000}},
{'O', {0x0ffc, 0x0c0c, 0x0c0c, 0x0c0c, 0x0ffc, 0x0000, 0x0000}},
{'P', {0x0c0c, 0x0ffc, 0x0ccc, 0x0cc0, 0x0780, 0x0000, 0x0000}},
{'Q', {0x0ffc, 0x0c0c, 0x0c3c, 0x0ffc, 0x000f, 0x0000, 0x0000}},
{'R', {0x0ffc, 0x0cc0, 0x0cc0, 0x0cf0, 0x079c, 0x0000, 0x0000}},
{'S', {0x078c, 0x0ccc, 0x0ccc, 0x0ccc, 0x0c78, 0x0000, 0x0000}},
{'T', {0x0c00, 0x0c00, 0x0ffc, 0x0c00, 0x0c00, 0x0000, 0x0000}},
{'U', {0x0ff8, 0x000c, 0x000c, 0x000c, 0x0ff8, 0x0000, 0x0000}},
{'V', {0x0ffc, 0x0038, 0x00e0, 0x0380, 0x0e00, 0x0000, 0x0000}},
{'W', {0x0ff8, 0x000c, 0x00f8, 0x000c, 0x0ff8, 0x0000, 0x0000}},
{'X', {0x0e1c, 0x0330, 0x01e0, 0x0330, 0x0e1c, 0x0000, 0x0000}},
{'Y', {0x0e00, 0x0380, 0x00fc, 0x0380, 0x0e00, 0x0000, 0x0000}},
{'Z', {0x0c1c, 0x0c7c, 0x0ccc, 0x0f8c, 0x0e0c, 0x0000, 0x0000}},
{'0', {0x07f8, 0x0c0c, 0x0c0c, 0x0c0c, 0x07f8, 0x0000, 0x0000}},
{'1', {0x0300, 0x0600, 0x0ffc, 0x0000, 0x0000, 0x0000, 0x0000}},
{'2', {0x061c, 0x0c3c, 0x0ccc, 0x078c, 0x000c, 0x0000, 0x0000}},
{'3', {0x0006, 0x1806, 0x198c, 0x1f98, 0x00f0, 0x0000, 0x0000}},
{'4', {0x1fe0, 0x0060, 0x0060, 0x0ffc, 0x0060, 0x0000, 0x0000}},
{'5', {0x000c, 0x000c, 0x1f8c, 0x1998, 0x18f0, 0x0000, 0x0000}},
{'6', {0x07fc, 0x0c66, 0x18c6, 0x00c6, 0x007c, 0x0000, 0x0000}},
{'7', {0x181c, 0x1870, 0x19c0, 0x1f00, 0x1c00, 0x0000, 0x0000}},
{'8', {0x0f3c, 0x19e6, 0x18c6, 0x19e6, 0x0f3c, 0x0000, 0x0000}},
{'9', {0x0f80, 0x18c6, 0x18cc, 0x1818, 0x0ff0, 0x0000, 0x0000}},
{'*', {0x018c, 0x0198, 0x0ff0, 0x0198, 0x018c, 0x0000, 0x0000}},
{'.', {0x001c, 0x001c, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000}},
{'?', {0x1800, 0x1800, 0x19ce, 0x1f00, 0x0000, 0x0000, 0x0000}},
{'!', {0x1f9c, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000}},
{'(', {0x01e0, 0x0738, 0x1c0e, 0x0000, 0x0000, 0x0000, 0x0000}},
{')', {0x1c0e, 0x0738, 0x01e0, 0x0000, 0x0000, 0x0000, 0x0000}},
{'#', {0x0330, 0x0ffc, 0x0330, 0x0ffc, 0x0330, 0x0000, 0x0000}},
{'$', {0x078c, 0x0ccc, 0x1ffe, 0x0ccc, 0x0c78, 0x0000, 0x0000}},
{'/', {0x001c, 0x0070, 0x01c0, 0x0700, 0x1c00, 0x0000, 0x0000}},
} ;

#define NGLYPHS         (sizeof(glyphtab)/sizeof(glyphtab[0]))

void
encodechar(int ch)
{
    int i, x, y, fch ;
    word fbits ;

    /* It looks sloppy to continue searching even after you've
     * found the letter you are looking for, but it makes the 
     * timing more deterministic, which will make tuning the 
     * exact timing a bit simpler.
     */
    for (i=0; i<NGLYPHS; i++) {
        fch = pgm_read_byte(&glyphtab[i].ch) ;
        if (fch == ch) {
            for (x=0; x<7; x++) {
                fbits = pgm_read_word(&(glyphtab[i].col[x])) ;
                for (y=0; y<14; y++) {
                    if (fbits & (1<<y))
                        digitalWrite(radioPin, HIGH) ;
                    else 
                        digitalWrite(radioPin, LOW) ;
                        
                    delayMicroseconds(4045L) ;
                }
            }
        }
    }
}

void
encode(char *ch)
{
    while (*ch != '\0') 
        encodechar(*ch++) ;
}

void 
setup()
{
  Serial.begin(9600) ;
  pinMode(radioPin, OUTPUT) ;
}


void
loop()
{
    encode("K6HX QTH CM87UX TMP 72F PWR 500 MICROWATTS ") ;
}

Let me know if you use this project for anything!

Late night pondering about the micro-power Morse beacon…

Before toddling off to bed last night, I did a bit more tinkering, and a bit of thinking, and then a bit of research.

The YouTube video I made showed that the spurious radiation from just attaching a clip lead from the oscillator to my oscilloscope gave enough signal to inject itself into my RFSpace SDRIQ software defined radio, even without any antenna attached. I hypothesized the signal should be stronger with my regular 40M dipole antenna, so I tested that, and sure enough, my FT-817 attached to the 40m dipole easily is S7, even without doing any antenna tuning. This suggests that for any application on my small property, I could reduce the power significantly (and use little/no antenna) and still have very legible signals.

I used a 3.68Mhz crystal because I have something like 200 of them (I bought them for something like $3 for a big bag) but that’s kind of a ham unfriendly frequency. While it’s not very likely for such a weak signal to propagate significantly at the power levels we are talking about, but it’s perhaps possible that someone within a radius of a mile or so might be able to hear it, and be annoyed. Steve Weber used 4Mhz crystals, which are at the edge of the 80m band, and probably less well trafficked. A good, friendly idea.

Last, I was trying to understand what the regulations actually say about legal Part 15 operation. The regulations allow for experimenters to build five transmitters of this type for experimentation. On the 80m, you are suppose to keep the average field strength at just 15 microvolts per meter at a distance of 30m. Working through the approximations presented in Understanding the FCC Regulations for Low-Power, Non-Licensed Transmitters, this suggests that the product of power and antenna gain should be less than 6.6E-8 or so. While I know the input power, I don’t know how to measure (or estimate) either the output power or the antenna gain. Can anyone point me at a reference which shows how I might calculate the properties of a small 6″ long stub antenna at 4Mhz or so? I know it’s mostly an academic exercise, but it’d be nice to know the rough limits are, and the FCC regulations for Part 15 do say that we are supposed to “employ good engineering practices in order to ensure compliance with Part 15 standards”.

One final thing: as you can see from the oscilloscope, the output is far from a clean sine wave. It’s not horrible, but I was able to detect it at 2x and 3x the carrier frequency. The obvious thing would be to design a filter to clean it up, but most filter designs assume a 50 ohm (or thereabouts) output load, which this clearly doesn’t have. Is that a problem?

A micro-power Arduino Morse radio beacon

My G0UPL QRSS beacon is working pretty well, but is only putting out about 40mw of power, when it probably should be putting out 100mw. I was pondering oscillators in general, and (as I do often) surf for information and inspiration. I found both on Steve “Melt Solder” Weber’s website, in the form of a ATtiny based Wireless Morse thermometer. It was just a cool little circuit, so I tossed it together on a corner of my breadboard.

Works pretty well! I simulated the circuit using LTSpice before I built it, and found that it takes about 2ms for the oscillator to stabilize after powering down. At 12 wpm, each dit lasts 100ms, so it’s pretty clear that you can do a reasonable job of sending morse at pretty much any speed that most humans can use. To test the oscillator, I hooked up a pair of new D cells which were measured at 3.42 volts, and the current draw was a miserly 0.461 milliamperes for a maximum input power of around 1.5mw. The Arduino can supply 20ma, so it’s pretty obvious that you can drive this oscillator directly from an output pin. So, I used the Morse code sketch that I wrote a couple of years ago and voila! Instant beacon.

Regarding the legality, without any antenna, the effective radiated power of this antenna is incredibly low. I haven’t done any analysis of the circuit to state categorically that it falls inside the restrictions of Part 15 wireless devices, but I’d be shocked if it didn’t.

Oscillator with super low supply voltage

I’m beginning to correct some of my misunderstandings re: JFETs and for some reason, oscillators are beginning to become something that I think of as interesting, particularly at very low voltages. Without comment, and for future perusal, I just present this cool link, which shows oscillators which can run on very low voltages (just a few millivolts):

Oscillator with super low supply voltage

Seeing double on QRSS grabber…

Here is a snapshot from my QRSS grabber earlier today. You might want to click it to see it full size:

I’m curious: what phenomenon is causing the strong line doubling of the signals near the bottom? Note: not all the signals demonstrate this phenomenon, and it’s relatively rare, and commonly just fades away. Also note that the signal at the top does not show this line doubling. I suspect all the signals which are line doubled are in New Mexico.

Bonus question: I keep seeing a small wiggle like the one around 10.139975 or so, starting on 10 minute boundaries and lasting for about one minute. Anybody have any idea who that is?

On junkboxes…

I’ve recently begun to try to systematically (if somewhat erratically) equip my home office (it aspires to be a lab) with the necessary parts and tools that I need to assemble projects which interest me. The reason for this is simple: if you have the tools, material and space to do a project, you will much more likely do it than if you have to acquire all three specifically. If, for instance, you want to experiment with RF oscillators or amplifiers, if you have toroids, transistors, crystals, caps and resistors floating around, you can tack one together in just a few minutes. If you toss in some diodes, you can make some mixers. Maybe you want to have some ICs around, such as the LM386s. Toss in some speakers, jacks and the like, and voila: you are building radios.

When you are just starting, each additional part or tool that you “need” but don’t have is stumbling block: it halts your progress, and keeps you from the projects that you truly want to do. So, how do you get from where you are (presumably with nothing) and get to the point where you can build things than interest you?

Here are some simple, and somewhat obvious guidelines.

  • Take a long view. You might know someone who’s garage is stuffed full of cool stuff, and what you envision as highly complex and detailed projects just seem to flow effortlessly off his desk. As far as I know, nobody starts with such collections as they emerge from the womb, so at some point, they were where you are today. Don’t suffer any angst over your relative lack of equipment and expertise. Peter Norvig has an excellent essay on learning to program. People have the expectation (fueled by books with titles like Learn to Program in 21 Days) that programming is easy, and they should be able to become experts quickly. But research shows that it takes years to develop expertise. This is good: it means you can invest modestly in acquiring the tools and materials you need, gathering both simultaneously over time.
  • Invest in tools first, consumables second. Since we are taking a long view, it makes sense to invest in tools. After all, if it takes you ten years to acquire skills, chances are you are going to use those tools quite a bit. On the other hand, components and consumables will probably get used up in projects. Acquire them lazily, as you need them, or as you find them.
  • Consider economies of scale. Often ordering a dozen of a particular part is the same cost as just ordering two or three. As an extreme example: consider the lowly 2N3904 NPN transistor. If you buy these one at a time at Radio Shack, you’ll pay about $1.19 for one. Digikey will sell them for something like $.43 in quantity one, but are down to $.12 if you buy one hundred of them. If you go to companies like Tayda Electronics you can get them for just $0.01 a piece. Consider adding fairly bulk quantities of common components to stock your junk box.
  • Substitute for hard to find components. Most of the rehashed circuits that the ham radio magazines continue to republish seem to need air spaced variable capacitors, which are frankly getting harder and harder to get, and more expensive when you can. Keep an eye out for those components, but also consider making substitutions. Hans Summers made me aware of using LEDs and other diodes as varactors. Varactors are reasonably difficult to find, but LEDs are everywhere. If you dig around, you can find articles like this excellent one on how to design circuits around this idea.
  • Spend time researching and asking questions. It’s easy to spend money, it’s hard to save money. But if you spend some time doing research, you can often learn a lot, and therefore save a lot. DIg around. See what others have done. View everything through the lens of what skills and equipment you’d need to reproduce the same kind of projects that you see.

That’s the general background: in the next few days I’ll try to do a post of what items are making it into my junkbox. Stay tuned.

The “Hello World” of Arduino Programming: Fading RGB LEDs

Allright, I was playing Skyrim most of the day, and didn’t really have my brain firing at it’s highest level when I sat down and decided to try to put something together. We’ve all been there, right? I realized that I had some of this cool RGB LED strip that I ordered from Tayda Electronics, and it was just lying there, mocking me. So, I embarked upon quite easily the simplest things that I have ever done: cross fading RGB LEDs. Going boldly where everyone has gone before: it’s my motto.

First of all, complete credit must go to Lady Ada and her terrific tutorial on this very subject. I shamelessly copied what she did, and it worked out great. So go there, and read everything she had to say. I’ll just add a few comments:

  • The RGB strip cuts very easy, and strips pretty easy too. Be careful to use good ventilation when soldering leads onto this stuff though, as the plastic/rubbery stuff residue doesn’t smell very nice when heat is applied.
  • I went ahead and ordered the STP16NF06 MOSFETs that she recommended when I placed my last Digikey order. Price was about $.85 each, which is quite reasonable.
  • Tayda’s RGB strip seems like a very good deal, and you could easily use this trip for a wide variety of craft, art, or electronics projects.

To experiment, I cut off four segments (a little under a foot) and soldered on some leads, and wrapped them with electrical tape. Rather than swipe Lady Ada’s code, I quickly penned this up:

const int rPin = 3 ;
const int gPin = 5 ;
const int bPin = 6 ;

void
ramp(int pin, int from, int to)
{
  int i ;
  
  if (from < to) {
    for (i=from; i<= to; i++) {
      analogWrite(pin, i) ;
      delay(5) ;
    }
  } else {
    for (i=from; i>= to; i--) {
      analogWrite(pin, i) ;
      delay(5) ;
    }
  }    
}

void
setup()
{
   pinMode(rPin, OUTPUT) ;
   pinMode(gPin, OUTPUT) ;
   pinMode(bPin, OUTPUT) ;
   
   analogWrite(rPin, 0) ;
   analogWrite(gPin, 0) ;
   analogWrite(bPin, 0) ;
   
   ramp(rPin, 0, 255) ;
}
   
   
void
loop()
{

  ramp(gPin, 0, 255) ;
  ramp(rPin, 255, 0) ;
  ramp(bPin, 0, 255) ;
  ramp(gPin, 255, 0) ;
  ramp(rPin, 0, 255) ;
  ramp(bPin, 255, 0) ;
}

And it worked the first time! Here’s the YouTube video:



It’s really easy to get the electronics working, and the Arduino and it’s software environment make it so simple. Too simple. I’m sorry to have embarrassed you with this, but perhaps you’ve had a craft or art project that could use some LEDs kicking around in your head, but you haven’t been kicked into action. Perhaps the easiness of this will inspire. If so, my work is done!

Have a good one.

WA0UWH’s Propeller Beacon received at K6HX…

I could of days ago, I blogged about WA0UWH’s Propeller Beacon. Over the last couple of days, I worked on fixing a few small issues with my old beacon code, and have an experimental QRSS grabber up and running on qrss.info. And, what’s totally cool is that I’m hearing Eldon’s QRSS beacon, just over 700 miles away. Check the screen grab:

Eldon’s signal is the slant-Morse signal just about 1/3 of the way down (right around 10.140050). His signal starts with a propeller, and then has a series of slanted lines. Forward slashes are read as dots, and backward slashes as dashes. You can work out WA0UWH (easier on the signal near the right edge), followed by the letters WA. Pretty neat!

Other callsigns are AE5XI, NM7J, KD5SSJ, KC5EVR (I think) and WV5N, read from top to bottom. Early in the morning (around 4:00AM my time) I also received W0TJ and the flying W of Bruce, W1BW, but as yet I haven’t heard anything from our VK or ZL brethren down under. I’ll keep the grabber up for the rest of the week, perhaps down only intermittently to tweak the software, and then I’ll shift to transmit over the weekend with my G0UPL beacon.

My own lightly modified Arduino Basic

I’ve received a couple of requests for my own Arduino Basic modifications. They are pretty straightforward and small, but might be of some use, and I probably won’t have a chance to do any significant work for a couple of more weeks, so I thought I’d just toss them out there for consumption. This is all based upon Mike Field’s Tiny BASIC, and all the real credit should go to him. I added a few new commands to allow you to do some simple digital and analog I/O, and added a couple of added functions, including one that could be used to figure out how much free space you have left for BASIC programs.

My lightly modified Tiny BASIC source code, for Arduino 1.0

Changes include:

  • MODE PIN,[0|1] works like pinMode(pin, INPUT|OUTPUT). Note: to specify analog pins, you need to add 14 to the analog pin number (for the traditional Arduino, I have no idea what the MEGA does).
  • DWR pin,value and AWR pin, value act like digitalWrite and analogWrite.
  • Two additional functions (ARD(pin) and RD(pin), which should really have been DRD to match DWR) act like digitalRead and analogRead.
  • DELAY ms works like, well, delay(ms), duh.
  • The FREE(0) function returns how many bytes of program storage are left.
  • For reasons which aren’t clear to me, I modified the code to convert all lower case letters to upper case. Change it back if you like.

If you swipe this code and use it for something, let me know below: if someone makes use of my work, it gives me incentive to work on it harder. 🙂

Building a distributed satellite ground station network (or not…)

My twitter intro says that I am an “enthusiast for enthusiasm”. When I wrote that, it was simply because there are some questions that I really think aren’t helpful at all. Questions like:

  • Why didn’t you just buy X instead of building your own?
  • Didn’t somebody do that years ago? Why are you playing with that old technology?
  • Why are you writing a program to do that, when you could just use Y, some program/framework/application that I use.

I hate questions like this because they aren’t really questions at all: they are simply trying to tell you that what you are doing is stupid or pointless. Here’s the thing: I mostly understand why I do the projects that I do, and I’m perfectly okay with you not understanding my rationale, or agreeing with it even if you do understand. The proper answer is “why climb a mountain?” isn’t “because it was there”. It’s not even “because no one has before”. The proper answer is “because I’ve not done it, and I enjoy mountain climbing.” Interestingly, most people won’t try to convince you that you shouldn’t like mountain climbing, but all sorts of people will try to tell you that your technical projects are a waste of time. This kind of conversation actually irritates me.

And with all this introduction, I’m going to now criticize a project, which is going to seem a bit hypocritical. Hang with me to the end, and I’ll try to resolve the apparent hypocrisy, at least partially.

The topic is the plethora of news stories about a talk given at the Chaos Communication Congress (28c3) recently held in Berlin. Some links to news stories:

Hackers aim to launch Internet satellite network, moon mission
Hacker satellite grid to counter Internet censorship??
Hackers Plan Satellite Network to Fight Internet Censorship

So, what’s my beef? After all, any reader to this blog knows that I’m interested in amateur satellite and communications, surely this is right up my alley?

And indeed it is. But the motivation is just… well… it’s stupid. Not stupid because fighting censorship is a bad idea: it’s a very, very good idea. Even essential. But the idea that satellites constructed by amateurs can play any role (much less any significant role) in fighting censorship is fantasy.

First of all, launching satellites is expensive. Really expensive. While the hardware of cubesats can be constructed quite economically, launches have costs which are multiples of ten thousand dollars, for masses which are less than 1kg launched into low earth orbit. Currently AMSAT has a project called FOX to develop a communication satellite that fits the cubesat form factor, but it’s capacity and power are very limited, mostly by the physical size and weight limitations imposed by available launch opportunities. To launch a satellite into MEO or HEO would require costs measured in the millions of dollars.

Secondly, you can’t get spectrum to operate a satellite network like they imagine. Amateur radio frequencies are subject to regulation and treaties just like any other spectrum, and the uses of such frequency are dictated by regulation and treaty. The governing international body is the IARU (the International Amateur Radio Union) and member nations enact local regulations to enforce treaty restrictions to comply with the regulations of the IARU. The purpose of amateur radio satellites must be to “(1) provide communication for the general amateur radio community and/or (2) self training and technical investigations relating to radio technique”. While these topics are fairly broad, they are not broad enough to provide a general replacement for the Internet. In fact, in the U.S. amateur radio is specifically prohibited from carrying “communications, on a regular basis, which could reasonably be furnished alternatively through other radio services.” You can’t get the frequency allocations. Nobody will launch a satellite without frequency coordination.

Third, if your concern is to bypass the censorship of governments, it seems odd to do it by launching a satellite, because governments tend to have very strict and tight controls over satellites and satellite technology. For instance, in the U.S. ITAR regulations essential prohibit the transfer of dual use technologies to other countries, even to our allies. This isn’t just a theoretical concern: American participation in the amateur satellite projects of other countries have been significantly stifled But even more basic than these issues are the fact that access to space is currently under the control of the very governments we are concerned about. While increasing commercialization is eroding that to a certain degree, we cannot rely on commercial entities to operate in defiance of the governments of the countries in which they operate. There is some possibility that an organization such as Copenhagen Suborbitals might be able provide launches, but these operations must operate within the regulations of the countries from which they operate as well, so I think the idea of access to space independent of governmental interference is a fantasy.

Here’s the bottom line though: if your goal is to prevent government censorship, every dollar that you spend could do orders of magnitude more benefit using more conventional earth-bound technology. Funding projects like the FreedomBox Foundation, HTTPS Anywhere or The Tor Project, or working to generate a mesh based Wifi capability in your area are much, much stronger ways to work to combat Internet censorship.

If you want to build satellites, it’s a perfectly reasonable thing to do. But to try to sell the idea by saying that it provides a way to combat Internet censorship? That’s misleading at best.

Addendum: Here’s the actual talk at the Chaos Communication Conference. It’s actually got some cute stuff in it, mostly because it leaves behind the fantasy that a satellite communication network will provide a hedge against censorship in the first five minutes.

Lunch with Ken Boak, the Nanode, and the evolution of the Arduino platform

Today, through a bit of serendipity involving twitter and the web, I managed to have lunch with Nanode designer Ken Boak, who happened to be on an unrelated visit to the Bay Area this week. We exchanged brief messages for the first time a couple of weeks ago, as I was intrigued with his idea of making a version of BASIC that ran on the Arduino/Nanode. He was kind enough to leave me with a couple of his latest version to experiment with. Compared to the v5 version that I got as a gift (purchased from wickeddevice.com) and assembled last week, these have a few cool new additions:

  • The screw terminals have been removed, and a small wireless module put in their place.
  • The board has a 32K static SRAM for storage.
  • It has a micro SD card slot on the bottom for long term storage.
  • It has a real time clock on the bottom.

Pretty darned cool! The new version seems better to me in every way., and I thank Ken for dropping some of them off for me (and also for a couple of coworkers who are interested in Arduino programming). I’ll be working to use them in a future project for sure, and if you are interested in having a highly interconnected Arduino compatible board to play with at a reasonable cost, I can recommend the Nanode (although I’d wait until Wicked Device starts carrying the new variety, the old V5 design lacks some of these cool features).

I see the Nanode as a cool evolution of the basic Arduino platform. The Arduino does a lot right, but there are a few things that bother me.

  • Cost.. Yeah, they are cheap. But let’s face it, they aren’t that cheap. The Uno (around $30) is just an ATmega328 (about $2 in quantity), an ATmega16u2 (again about $2) to provide USB, and then a handful of discrete components. You get a bunch of pins broken out, but no actual peripherals or connectors. No switches. No (or maybe one) LED. No additional memory or RTC. No SD card socket. My rather silly Arduino n’ Gameduino Satellite Tracker costs nearly $100 in parts, which makes the entire project less interesting, because it could be done as cheaply with more capable technology. The Nanode makes it a bit more tractable: it has a real time clock, and can even do NTP to set the time and fetch new elements over Ethernet. Thus, I think the nanode gives you some added value.
  • Flexibility in development environment. When I first started with the Arduino, it bothered me a little that I needed a sixty megabyte download of a programming environment to program this little controller with maybe just 16K of memory. Even if you just wanted to blink an LED, you had to compile and reflash code. Back in the days of my youth, we didn’t have the benefit of cool optimizing compilers, but we DID have the benefit of cool interactive programming environments. Ken’s idea of creating a Tiny BASIC programming environment brings some of that back. Sure, it’s not for everyone, but for simple experiments and education, the interactivity is useful. The technology that enables this for the Nanode is the inclusion of a 32K serial SRAM: we can store programs in this RAM and interpret code directly out of them.
  • Cheap, flexible peripherals. I have some Xbees to play with, but they are a bit spendy really. An Xbee costs about $22 or so last I checked, and to interface them with an Uno, you’ll need another shield which costs around $20 by itself. Tacking $45 onto a $30 board just to get wireless seems excessive. Ditto for Ethernet: the Ethernet Shield costs around $30-$40 (or even more) and basically doubles the cost of the Arduino. The Nanode includes Ethernet (using the rather inexpensive and easy to get ENC28J60 by Microchip) and uses some small and inexpensive RF modules. While these modules are perhaps not as capable as a full Xbee implementation, their cost and benefits are much lower, and their standard deployment on the Nanode board makes them convenient to use.
  • Compatibility with both shields and breadboards. Let’s face it: the Arduino Shield form factor is idiotic. Had the pins been laid out on a 0.1″ grid, you could have made shields with just ordinary 0.1″ proto board. Or, you could put pins on the bottom, and plug it directly into a standard solderless breadboard. The original design was a mistake. Let’s get over it, shall we? The Nanode does a good interim compromise: you can put headers in either position, which is awesome. But shields are already a bit of a compatibility nightmare: depending on what pins your shield uses and/or what voltages, it already may not work with a variety of seemingly compatible Arduino variants. The Nanode also wins on this case, because many of the most common shields that you would add are simply not necessary on the Nanode.

Don’t get me wrong: I don’t think that the Nanode will kill the market for other Arduino variants and form factors. In fact, I don’t think that it should: I like the fact that I can get Arduino Nanos, Arduino Pros, and Arduino Megas, but program them all from the same environment. But I think that peripheral additions that the Nanode provides gives added value, and if the Arduino is to compete in a world where things like the Raspberry Pi exist, I think we need to figure out how to add some additional value to the Arduino platform. I thank Ken and the other Nanode users for thinking about this stuff, and taking Arduino evolution in an interesting direction.

WA0UWH experiments with the Propeller/QRSS.

This link will make my various Propeller loving readers happy: Eldon, WA0UWH received a Propeller microcontroller board for Christmas, and decided to try to use it to create a QRSS beacon. With other microcontrollers you generally just program it to generate a keying signal that passes into a FSK input on some other transmitter/oscillator. But Eldon used a unique feature of the Propeller: it can directly synthesize frequencies using an on chip 80Mhz oscillator and a PLL. In theory all you really need to make a QRSS beacon is a low pass filter (which Eldon also created). There are some potential problems (phase noise, temperature stability) but the idea is very cool. Check it out!

The blog of Eldon, WA0UWH: check out his recent posts on QRSS/Propeller