Analysis of the Tube Screamer

November 18, 2012, 3:43 am

Recent fun-and-games with copies of the Ibanez Tube Screamer guitar overdrive pedal have got me interested in its function to the extent that I've made an analysis of its small-signal frequency response...

Anybody who is discouraged by maths can scroll past ugly equations - there are results of measurements and Spice simulations lower down in this post! You might also find this excellent description of Tube Screamer behaviour more to your taste.

Readers might find the suggestion that linear circuit analysis of the behaviour of an inherently non-linear device is worth performing or reporting ironic. However, one of the defining and differentiating features of the Tube Screamer is precisely the filtering operations it applies to the guitar signal (and non-linear functions thereof). Accordingly, understanding the linear aspects of this "urban legend" is useful - we start with consideration of the "Tone" stage...

This circuit is a (fairly) conventional first-order HF shelving network - adjusting the tone control boosts or lifts the high frequency content of the input signal. However, the presence of the 220nF in the low-pass filter seen in the dashed red box above complicates the circuit - so my analysis is needed. To keep the algebra tidy, I've simplified the picture somewhat (by replacing the paralleled 220nF and 10 kOhm resistor on the input by a single impedance Z_S and by replacing the series 220 nF capacitor and 220 Ohm resistor between the potentiometer wiper and ground by a single impedance Z_P).

It is also necessary to name some nodes and currents, to which the analysis will refer...

The first step in analysing the tone filter is to establish a relationship between the voltage on the tone control potentiometer wiper and the op-amp input(s)...

This relationship will be used in the subsequent solution, so we're giving it a name: "X"...

Notice that X includes some fixed elements (like the impedance Z_P and the total resistance of the tone potentiometer, R_P. However, X importantly includes a variable element, R_p1R_p2 ; X is a function of tone control setting.

Our analysis proceeds by considering the currents at the op-amp inputs...

which leads us to a solution for the frequency response of the Tone stage...

Notice that this solution includes 'X' (which we already know to be a function of tone control setting). The solution in the form above is also itself an explicit function of tone control setting, through the presence of R_p1 and R_p2.

The response of the tone control stage alone is shown in the Bode plot below (produced in MATLAB, by evaluating the solution shown above). The result shows the tone response with the tone potentiometer in extreme positions...

Having solved for the response of the Tone stage, it is simple to go on to develop a solution for the overall frequency response of the Tube Screamer (at least in the small-signal context below the signal amplitudes that start to introduce distortion). Analysis of the "Clip" stage is actually easier than that for the Tone stage...

In the analysis which follows, we assume that the voltage over the diodes is lower than their forward turn-on threshold, in which case they can be ignored. The high-pass filter in the dashed red box of the figure above is loaded only by the very high input impedance of the op-amp's non-inverting input. We can, therefore, obtain its frequency response using the potential divider rule. Thereafter, the op-amp is in standard non-inverting configuration, such that its response is given by a familiar simple rule. The Clip stage small-signal behaviour can be written immediately as...

Various commentators have spoken of the action of the Tube Screamer being largely derived from the fact that the clip stage passes a mixture of the un-processed guitar sound plus the distorted sound - this is seen in the sum in the square bracket of the equation above. I confess that I'm not sure how useful this distinction actually is to understanding the system - particularly as Z_f/Z_in> > 1.

Now we have small signal responses of the Clip and Tone stages, we can multiply them together to get the overall response of the Tube Screamer (as shown in the equation at the top of this post). But who's to say my analysis is right?

Fortunately, there are ways to check it...

First, we can follow the lead of others and perform Spice analysis of the system...

Second - and much more interestingly, we can make measurement of an actual Tube Screamer (or, at least, one of my new clones) and compare the result. The graph below shows the magnitude frequency response of the Tube Screamer's small-signal (linear) behaviour, at extreme tone settings. Three traces are shown - one for my analysis, one for Spice modelling and one for actual measurement. You can see they overlay each other, equal (to within expected errors)...

The "Analysis" result in the graph above also includes a few high-pass responses, not described in the text. These are associated with (e.g.) the input and output buffers (implemented by emitter followers in the Tube Screamer) and have very low frequency corner frequencies.

Having spent effort avoiding non-linearity (such that Fourier and Laplace have something to contribute to a small-signal analysis), I took the opportunity presented by having the Tube screamer (clone) connected to some heavy-weight analysis gear to record some of the system's non-linear behaviour...

I generated a 440Hz sine-wave test input. Non-musical readers may remember that 440Hz is an important frequency reference that used to be broadcast on BBC2 with the test card, before wall-to-wall daytime television crowded out the schedule. More musical readers will know that 440Hz is "Concert A"...

With the drive control and tone control on minimum, the output produced in response to the 440Hz input is little different...

Turning the tone control to "Max" allows strong odd-order distortion products through to the output...

With the drive control on "Max", but tone backed off to "Min", there are still strong odd-order overtones produced...

Finally, pushing everything up to eleven boosts the strong odd-order products and also allows some even-order distortion products to be seen...

OK - that's enough building, simulating, analysing and measuring. I really ought to be playing.

...-.- de m0xpd

↧

Phasers to Stun

December 2, 2012, 3:01 am

≫ Next: Tube Screamer goes digital

≪ Previous: Analysis of the Tube Screamer

Like her ovine eponym before her, Dolly the Tube Screamer has triggered an avalanche of cloning activity. Only a small avalanche. In fact, only one further clone. This time, the object of our sincere flattery is the MXR Phase 45.

I always wanted a phase pedal as a youngster, but somehow never got round to doing anything about it (the m0xpd wallet having been infamously dusty for a very long time). Now, however, flushed with the success of previous stompbox cloning activities, I decided it was time to take the plunge.

You can find the Phase 45 schematic all over the internet (I don't intend to stomp all over MXR's intellectual property by reproducing it here). The junk box dictated that I should replace the original 2n5952s with my default J-FET; the 2n3819. Whilst I was about it, I decided also to replace the two dual op-amps of the original with a single quad package - in my case a TL074 - making the PCB layout simpler...

The red line is a wire link on the component side.

Here's the single copper layer at 600dpi (for my records only - I can't possibly condone any of YOU people making a copy!)...

The assembled PCB looks like this...

It is a very tight squeeze to get it all into a Hammond 1590b-sized box (faithful to the MXR original). To be honest, I had to replace a couple of the caps shown above on the PCB with ceramics on the opposite side - don't tell anybody.

Anyway, after a good deal of cussin' and shoe-hornin', I got it together - here's a POV shot of Dolly the Tube Screamer (right) and her new friend...

The Phase 45 (in common with most similar effects) uses all-pass filter networks (two, in the case of the Phase 45) to achieve the phase shift implied in the name and sums the original and phase shifted signals together. This summation introduces constructive and destructive interference at different frequencies, which are swept around by the action of a low frequency oscillator modulating the phase shift.

In an idle moment, I found myself wondering how the all-pass network works and so, with the popularity (or at least, large number of page hits) of my recent Tube Screamer Analysis ringing in my ears, I decided I'd post the results of that idle speculation...

We start off with the generic active all-pass circuit...

Then we use the potential divider rule to solve for the voltages at the op-amp's inputs...

At this point back in the analysis of the Tube Screamer, I glibly said "the action of the op-amp is to drive the voltage difference at its inputs to zero" (or words to that effect). This time, I'll be slightly less glib and argue that the op-amp multiplies - amplifies ! - the voltage difference between the inputs by a positive constant, "A"...

Now we can do a little algebra to simplify things, before asking what happens if the amplifier gain is very large - in fact, what happens as it approaches infinity. The mathematicians might call this sort of question "limiting behaviour"...

Once again, we'll keep tidying up the algebra and then we'll make the important assumption (as in the MXR Phase 45) that R_f and R_in both equal 10kOhms, in which case some further simplification is possible...

The final result (that result which is published all over the place) is then available after another piece of trivial algebra...

The numerator and denominator of the right-hand side of the equation above (i.e. those bits above and below the horizontal line), being complex conjugates of each other, have equal magnitude frequency response. Therefore, the magnitude response of their ratio is unity (all the changes in the numerator are exactly balanced by equal changes in the denominator). That is to say, all frequency components are unchanged in amplitude as the pass through the all-pass filter - it does what it says on the tin!

However, the network has a non-trivial phase response. In the Phase 45, this phase response is exploited by implementing "R" in the two cascaded all-pass filter stages by a network including a FET (one of my 2n3819s) in ohmic mode, with its gate voltage (and, so, the equivalent value of "R") modulated at a low frequency. This frequency is controllable by the external "speed control" seen on the original MXR product and on my clone.

I included a shopping link for the Phase 45 above because it really is cheaper to buy one than to build a half-decent copy. By the time you've gathered together all the bits, made a PCB and accounted for your own time at anything above the minimum wage, you have already spent more than the GBP 60 or so they want for a "real" one. Perversely, there will always be a few fools, like yours truly, who prefer to make one just for the interest and the fun of it!

...-.- de m0xpd

↧

Tube Screamer goes digital

December 16, 2012, 8:26 am

≫ Next: Breadboarding Refinements

≪ Previous: Phasers to Stun

Having enjoyed playing about with the "Tube Screamer" guitar overdrive effect, I decided to experiment with a digital version. Purists need not panic - I don't mean anything vulgar like an embodiment of the effect in digital signal processing. Rather, I mean a digitally controlled analog Tube Screamer. This way, I get to keep the architecture and (hopefully) sound of the original "urban legend", but add flexibility of control, easily recalled presets and - one day perhaps - external control by MIDI.

Here's my initial experimental version, which I completed today...

The breadboard includes a standard Tube Screamer circuit (here implemented using two single (NE5534) op-amps to spread things out a bit) with the potentiometers replaced by digitally controlled resistor networks.

The whole shooting match is under the control of a big fat PIC 16F887 micro-controller - chosen because it has LOTS of IO lines.

Instead of the "knobs" there is a user interface comprised of a simple "keypad" and a 16*2 LCD Display. The keypad allows the user to move around a menu system, giving access to the "Drive", "Tone" and "Level" controls. One day (though I haven't implemented it yet) there will also be some default settings.

Here's some (poorly photographed) views of the menu structure...

The keypad and menu system were borrowed from that I developed for the m0xpd multi-mode beacon project.

At the moment, I'm experimenting with two alternative means of implementing the digitally controlled resistors, both of which emerged from the m0xpd "junk box". First, for the "drive" control, I'm using a 4066 quad bilateral switch, the elements of which can short a ladder of resistors in a "base 2" sequence of magnitudes (in so far as E12 resistors can approximate such a sequence), giving 16 different drive levels.

Here's the bones of the schematic...

The tone and level controls use pukka AD5220 digital potentiometers (the junk box does have some pretty high-class junk), with the level control made to have a log-like characteristic using Rod Elliott's "Better Volume Control" trick.

The whole thing works surprisingly well - more reports later when I add more sophistication!

...-.- de m0xpd

↧

Breadboarding Refinements

December 21, 2012, 8:20 am

≫ Next: Digital TS Rocks!

≪ Previous: Tube Screamer goes digital

Those who have idled away their lives reading these ramblings on previous occasions will know that I'm a fan of "Solderless Breaboards". Here's a tale of two little refinements made recently to straighten the path of my breadboarding.

The next steps of my digital implementation of the "Tube Screamer" require some different digital potentiometers. One of these was available only in SOIC packaging - hardly the thing to plug into one of my beloved breadboards. Unfortunately, I am too cheap to consider exchanging my shekels for a commercial solution to this problem. Fortunately, making one is the work of only a few pleasurable moments...

Here's a copper pattern if you want to make one of your own...

I etched a few onto a scrap of FR4...

and drilled and sawed them...

Now for the hard part - soldering one of these microscopic devices onto the new carrier...

It went surprisingly well, given my poor eyesight. All that was then needed were some legs to fit into the breadboard...

Why - it is nearly as good as a chip in a DIL package!

Whilst we're on the general subject of breadboarding, I may as well tell you about my new jumper wires...

I had always admired those nice flexible jumper wires you can buy in little sets - but once again, my healthy reluctance to spend money on old rope (or little lengths of wire, in this case) has prevailed. Until recently...

I cut up a few lengths of wire...

then I prep the ends...

... and gather together the other ingredients for this simple recipe.

These are terminal "pins" made from pieces of chopped up header plug and little lengths of heatshrink...

I solder on one end, add two lengths of heatshrink, then solder on the other end.

A little judicious stretching with the ends of a small pair of needle nosed pliers helps the heatshrink over the body of the "pin"...

... before it is shrunk down using that old cigarette/cigar/pipe lighter we no longer have any use for...

In no time at all, you can make a batch...

I enjoyed doing it so much that I went out to the local "cheap shop" and got a box for the new collection...

Looks nice, doesn't it. But it doesn't have the homely, "lived-in" quality of my old box full of bits of blue solid-core wire that I will continue to use on my solder-less breadboards...

Making breadboarding easier accelerates projects and makes more ambitious ones tractable. Now its time to get on and USE the new SOIC chip and the swanky new jumpers.

...-.- de m0xpd

↧

Digital TS Rocks!

December 24, 2012, 4:54 am

≫ Next: Keyer on RPi

≪ Previous: Breadboarding Refinements

I ended my last post saying "time to get on and USE the new SOIC chip and the swanky new jumpers". I've been true to my word...

Here you can see a 1MOhm Analog Devices AD5242 digital potentiometer serving as the "Drive" control in my Digitally Controlled Tube Screamer.

Yes - I know the original had a 500k potentiometer in this position - but you can't buy 500k digital Pots for love or money, so I'm just using the first 128 positions of this 256 position 1M part. What's worse, this is a dual device, so I'm using less than a quarter of the resources I paid good money for :-(

Zooming out, here's a view of the m0xpd experimental Digital Tube Screamer in its current incarnation...

As you see, I'm still using two single op-amps (NE5534s). This is for two reasons; firstly to spread the circuit out on the breadboard so as to make things more accessible and secondly (and much more importantly) to irritate all those aficionados who believe that the only op-amp to use in a Tube Screamer worthy of the name is a JRC4558.

The other digital potentiometers are Microchip MCP4131s - a 100k part for the level control and a 10k part for the tone control. Again, I know that the original Tube Screamer had a 20k part in the tone control but my analysis of the Tone Control Network convinces me that a 10k substitution won't make a blind bit of difference. These new digital pots are better to work with than the AD 5220 parts I used in the original Digital Tube Screamer, which had a clunky "increment/decrement" control interface. Now with the MCP4131s I can load up desired numerical settings explicitly.

Also visible in the photo above (at the right-hand side) is a plug-in module built on Veroboard. It contains the input and output buffers and the Tube Screamer's electronic "Bypass" switching...

I know there are a lot of purists, flat-earth theorists and obsessives out there who like (what they judgementally call) "True" bypass switching. I admire the FET switching circuit and I might use it again in some other stompbox experimentation, which explains why I went to the trouble of knocking up the module.

If others want to follow suit, here's my schematic...

Now it is all running, I have the digital pots under control of the PIC, communicating through a common I2C bus (turned out I didn't need all the IO lines of the 16F887 after all).

I have all the variable parameters of the Tube Screamer - including the bypass switching - under the control of the PIC, via its keypad-based user interface.

Most excitingly of all, I have a range of PRESET configurations, which can be called up at the press of a button, allowing me to call on the full range of sounds the Tube Screamer can generate without fumbling with knobs! It is much better than having more than one Tube Screamer.

Now I need to decide on how I'll arrange some footswitch control.

...-.- de m0xpd

↧

Keyer on RPi

December 29, 2012, 1:33 am

≫ Next: Morse Code Gmail Notifier

≪ Previous: Digital TS Rocks!

This Christmas, along with other fine gifts, Santa gave me a Raspberry Pi.

In this brief lull in hostilities between Christmas and New year I've stolen a couple of hours to play with my new toy. I have to say I'm impressed!

It has been a pretty steep learning curve, because I didn't really know much about the whole Linux universe when I started. I've used a MAC at work for the past couple of years - but MAC encourages such a superficial engagement with the computer that you don't need to know anything about the nuts and bolts!

I was greatly helped by another present from Santa - the Raspberry Pi User Guide by Upton and Halfacree. That has been a good little book, which gave me a useful kick start. However, I didn't want just to light an LED or detect a button push as my baptism on the GPIO - so I decided to make a keyer...

I approached the project with a little trepidation, because Eben says in the User's Guide referenced above ...

"If true real-time operation is required for your project, the Pi may be a bad choice. Instead, consider using a microcontroller platform such as the popular open-source Arduino..."

That bothered me, because it was exactly the availability of the GPIO interface that attracted me to the Pi in the first place, promising a convergence between real computing and the PIC-based fun-and-games I've been describing on these pages. I hoped that the "real-time" warning (repeated on the Project Home Page for the GPIO module I used) wasn't going to threaten that promised convergence. Yes - I know that a morse keyer isn't exactly pushing the boundaries of real-time operation - but I also know from experience that a surprisingly small latency (of only 80 milliseconds) in a keyer is enough to make operation difficult.

Here's the circuit I hooked up...

You can see that three GPIO lines are used for interface; one for each of the paddle's switches and one to key the transmitter (through the open collector). I started development with some little momentary action push-button switches which I left on the breadboard in parallel with the interface to the twin paddle, as you see in this picture...

Talking of interfacing to the RPi GPIO lines, I really like this solution - I shall have to buy one or make a copy!

Before we go on to describe the code, a warning. Remember that I started this knowing NOTHING about programming in Python, so what follows is an account of how something can be done, rather than how something should be done.

My code uses a Python module to access the GPIO port and I chose to use the module recommended in the User's Guide.

The code is seen in the windows below - I have been connecting to the Pi through SSH using the PuTTY SSH Client . The windows below show the Keyer program listed in the Nano editor. You don't have to work in this rather spartan way - I chose to do so in order to learn more about console/terminal interaction with Linux.

The first window shows some configuration stuff and some initial functions...

The second window shows the main operating "loop" of the code...

I don't know just how bad a piece of Python the above code is. All I know is that I learned a bunch from writing it and that the resulting keyer works perfectly. Having said that, it is utterly pointless as I already have my own Keyer solution and its more Rhythmically sophisticated derivative!

...-.- de m0xpd

Update:

Perhaps this wasn't just a Raspberry Pi learning exercise - it could be a tool for wireless telegraphy. To prove it (to myself, at least), I just used the keyer and my Funster Plus rig (which ironically already has a keyer built into it!) to have a quick QSO with Wally, operating the GB0YAM station on 40m at the Yorkshire Air Museum. Reminded me just how sloppy my CW has become!

↧

Morse Code Gmail Notifier

December 30, 2012, 3:03 am

≫ Next: MIDIfied Tube Screamer

≪ Previous: Keyer on RPi

After the fun-and-games with Morse and the Raspberry Pi yesterday, I decided to turn my hand to something a little more subtle - something which couldn't have been done more easily on a PIC!

Following on from the inspiration provided by Michael at MitchTech, who described a Physical Email Notifier using the RPi, latterly picked up by the good folks at Adafruit, I mixed in some Morse ...

My code uses Michael's technique to parse an Atom feed from a Gmail account every minute and then announces the name of the senders of all unread mails by Morse Code on GPIO 11 of the RPi.

You saw earlier how this can flash an LED or key a transmitter. You could use the same open-collector interface to switch a buzzer / sounder to let you hear the Morse.

The code uses a neat feature of Python (and other languages too, for all I know) to make the mapping between alphanumeric characters and their Morse representation: "Dictionaries". These were a new discovery for me yesterday - makes learning new programming languages actually worthwhile!

I generate a string of 0's and 1's for each Morse character; 0 for a dit and 1 for a dah. The rest is pretty self-explanatory.

You'll need to edit the code to insert your username and password - I don't want you reading my emails!

The code tries to announce only the first name of the sender (by searching for the first space in the "author" field). If there isn't such a space, it will just encode the entire author string as Morse - even including the new "ac" bigraph for "@".

As well as trying to get "GISTS" running on this post, I also uploaded both the Gmail Notifier and the iambic keyer Python code to a site for your easy downloading convenience...

The Gmail notifier is available here
The iambic keyer is available here

Enjoy!

...-.- de m0xpd

↧

MIDIfied Tube Screamer

January 4, 2013, 11:02 pm

≫ Next: RPi GPIO Breakout for Cheapskates

≪ Previous: Morse Code Gmail Notifier

My Tube Screamer clone (Blogs passim) now sports a MIDI interface and can be controlled externally by MIDI "Control Change" messages...

I've played with sending MIDI from PICs a lot - that being the essence of my Virtual Organ Project; both in generating Note On / Note off messages from my MIDI bass pedals and various Control Change messages from organ drawbars, switches and other controls. But MIDI Tx is easy. It turns out that receiving MIDI is only slightly more tricky but interpreting and acting on MIDI messages is a whole lot tougher!

In the aerial photograph above, you can see the new MIDI elements at top right. There's another Breadboard Module with the obligatory 5-pin 180 degree DIN socket. There's also a little bit of electronics to squeeze MIDI into the PIC. MIDI is a current loop interface and needs an opto-isolator to terminate the Rx end correctly. I had some 4N25s in the junk box, but couldn't get these to work sweetly. Fortunately, I also had some CNW 136s and these worked very well.

Here's my MIDI Rx schematic...

After this simple circuit, the MIDI signal goes to the Rx pin on the 16F887 at the heart of my Digital TS. Of course, masochists can use bit-banging methods to receive the serial MIDI data (just as I continue to use Ross Bencina's code for sending MIDI in the Virtual Organ). However, for MIDI reception, you really need to use the PIC's UART (or EUSART, as Microchip insist on calling it).

There are any number of experts out there who will explain how to set up the UART for MIDI reception (standard 8-bit at 31250 baud). They will have you looking at the RCIF flag bit of the PIR1 register to see when data has arrived. You'll soon appreciate that you need to do this in an interrupt service routine, such that you can get on and do other things in the meantime (such as servicing the local control interface with its buttons and display). After some messing around, you'll get a MIDI stream into your controller - but what do you do with it?

The hard part isn't the reception of MIDI data (despite what you may think if you're struggling to get it going). The hard part is making your system react to it. Here's how I went about it...

Currently I have four "controls" in the digital tube screamer, matching exactly the user controls of the original guitar effect pedal. These controls are 'Drive', 'Tone', 'Level' and 'Bypass'. I want to be able to send values for each of these controls via MIDI from a control device.

MIDI has a feature exactly matched to this requirement (no surprise, since this is exactly what MIDI was conceived for), called "Control Change Messages". These messages identify a particular control on a particular MIDI channel (together constituting an "address" for that control) and pass it a numerical value (an integer between 0 and 127). It is the job of the receiving hardware to understand the message and to apply the value to the control (equivalent in this case to setting the position of one of the knobs on the Tube Screamer or operating its Bypass switch).

Here's my interrupt service routine which does the job...
You can modify this code to parse a MIDI stream for your own application - the only thing it doesn't (try to) do at the moment is handle "System Exclusive" messages. In my case, I'm happy to take the (very small) risk that one such message might mess with the controls of my Tube Screamer.

I tested my MIDIfied Tube Screamer by generating MIDI using the superb MIDI-OX software. I guess the next step is to make a little controller to replace the computer and MIDI-OX.

Wait a minute - wouldn't it have been easier to just put knobs on the Tube Screamer? Now there's a thought...

...-.- de m0xpd

↧

RPi GPIO Breakout for Cheapskates

January 6, 2013, 2:58 am

≫ Next: MIDI Controller on the RPi

≪ Previous: MIDIfied Tube Screamer

I told you in an earlier post how much I admire Adafriut's Pi T-Cobbler breakout for the Raspberry Pi. I got as far as finding a UK reseller who listed them (for more GB Pounds than Adafruit charge in US Dollars) but they're on long-term back order - good thing, given the price! I resorted to my native parsimony...

I soon had a copper pattern laid out for a "straight" version which, although it didn't have the elegance of the Adafruit "T" configuration, was (like the T-Cobbler) only 0.3 inches between pin rows, thereby preserving as much breadboard area as possible.

Unfortunately, the XYL smashed my nice old laboratory thermometer over the holidays - serves me right for leaving it in the kitchen (she says). The thermometer is important in my new photo PCB process (to check the temperature of the photoresist developer), so PCB processing is on hold until the replacement arrives from eBay. Undaunted, I looked around for alternatives...

The junkbox yielded up a scrap of stripboard and I stock single and double row headers, so I quickly collected the key ingredients...

I cut the break in the copper tracks using a dental burr in my pre-historic horizontal milling machine, but I'm sure you could do the same job with a knife (it is between holes, you see - so you can't rely on the usual track cutter / drill). A little judicious soldering (after forceful re-arrangement of the pins in the single row headers to make best use of available length) and you have it...

Here's the new baby on the breadboard (still hosting the LED for myMorse Code GMail Notifierand test buttons for myRPi Keyer)...

All that's needed now is a ribbon cable and some IDC connectors - fortunately, the junkbox came up trumps again, serving up an old IDE disk cable...

However, that cable is bigger than the Pi and the breadboard together, so I broke the habit of a lifetime and dusted off the m0xpd PayPal account to order something more appropriate (£2.99, delivered in moments, fromPC Supplies Limited - usual disclaimer)

Now the whole shebang looks a lot neater...

Next I've got to figure how to get the UART to send MIDI to my latest monstrous creation at 31250 baud - ~~the widely touted solution of suppressing the console UART (in cmdline.txt), getting rid of the getty (in inittab.tcxt) and modifying the UART clock speed with a line in config.txt of the form:~~

~~init_uart_clock=2441406~~

~~isn't working for me. In fact, it isn't doing anything - serial is coming out resolutely at 38400 baud.~~

~~Any reader who sends a solution ( to shack.nasties "at gee male dot com") will get a prize. A very small prize of zero monetary value and no physical substance - but a prize none the less!~~

Update: The competition is closed - and I claimed the prize (I'm beginning to regret the "zero monetary value" status). I now have the RPi sending MIDI and controlling my MIDI Tube Screamer - I'll tell you all about it in a later post

...-.- de m0xpd

↧

MIDI Controller on the RPi

January 11, 2013, 12:01 pm

≫ Next: RPi GPIO Breakout for High Rollers

≪ Previous: RPi GPIO Breakout for Cheapskates

Here's the story of my attempts to squeeze MIDI out of my new RPi. The How To's and Gotcha's concerning configuration, the hardware interface details and the full code examples make it something of a tutorial, which will allow others to build their own Raspberry-flavoured MIDI controller (should they be foolish enough to try)…

It started with my newly-MIDIfied Tube Screamer, which was all ready waiting for a controller. Of course I could continue to generate control signals in MIDI-OX, but I wanted to make something a little more specific to the Tube Screamer. Sat there on the bench was my new RPi waiting for a new application - so why not kill two birds with one stone?

Unfortunately, the RPi can't generate MIDI straight out of the box, for a few good reasons;

the UART is doing something else by default - it's configured to serve up Linux Kernel messages
the UART doesn't offer the correct baud rate for MIDI serial comms
MIDI needs a hardware interface layer to implement the current loop

Fortunately, all these problem can be overcome, more-or-less simply…

In what follows, I'm referring to the standard, "Mini UART" accessible on the GPIO pins. There are dark whispers about a second, more flexible UART buried within the Broadcom device, but that's not for newbies like us. Also, there is the possibility of plugging in a USB - MIDI device to one of the USB sockets but that's not in the hack/knack spirit, so we're staying with the simple UART…

First job is to kill off the messages squirting out of the serial port by default. You need to edit the cmdline.txt file to remove (that's to say delete) the parameter:

console=ttyAMA0,115200 kgdboc=ttyAMA0,115200

Easy.

Next, you'll also want to disable the serial login ("getty") in /etc/inittab, by commenting out the line similar to this one:

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

just by prefixing it with a hash.

After a reboot, you shouldn't have any more unwanted stuff squirting out of your Mini-UART Tx pin. There's any number of detailed tutorials explaining how to achieve the steps above, including this one .

Next, you need some software to allow you to interact with the UART - I was intending to program in Python, so I installed the pySerial module, which is available for download here as a tar.

Once you have pyserial installed, you can try to use the UART to send MIDI data - only you'll hit a problem…

The Mini-UART only supports a few baud rates and the MIDI rate of 31250 is not one of the available set! If you set the baud rate to 31250, it will send serial data happily - but at a higher baud rate (of 38400 - the nearest available "standard" value).

Fortunately, this is a mountain that has been climbed by others before us, so there's a trick that we can use…

We can fool the UART into sending serial data at the correct speed by changing its master clock. If we saw our intended 31250 baud data actually being output at 38400, that is an error ratio of 38400/31250 - it is sending 23% fast. So , if we reduce the master clock speed by the same ratio, everything should be fine.

There's opportunity to edit the config.txt file by adding a line of form…

init_uart_clock = 3000000

This line is shown above in the default clock rate of 3 MHz - we can change it (by taking 3MHz * 31250/38400 = 2441406) to:

init_uart_clock = 2441406

I did it and - guess what - it did ABSOLUTELY NOTHING! The serial data was still pumping out at 38400.

It turns out that you also need to add another parameter to cmdline.txt, as taught by Dom in this important post. Dom, who's a moderator at RaspberryPi.org and obviously knows what he's doing, suggests

"Can you try adding :

bcm2708.uart_clock=3000000

to cmdline.txt"

I tried and - guess what - is still did ABSOLUTELY NOTHING! The serial data was STILL pumping out resolutely at 38400 baud.

I thought about it (for quite a long time, involving caffeine, alcohol etc) and eventually started to wonder if there was a clue lurking in the filename 'cmdline.txt' …

I wondered if the addition had to be part of ONE LINE, rather than just part of a file. Sure enough, it does - adding Dom's suggestion to the ONE LINE in cmdline.txt suddenly made everything work as intended - serial was being produced at 31250 baud.

I can hear all the Linux experts laughing at me. But, in truth, the joke is on them - this is a piece of legacy code from the days when Linux/Unix expected me to be a bearded, cardigan-wearing geek, typing lines on a serial console. OK - so I have a beard. OK - so I often wear a cardigan. Linux still includes some dumb, laughable, pre-historic features.

Now we've got the UART running, we need some code to generate MIDI. I'll show you three species of increasing complexity.

First, a simple command-line Python program …

This program prompts the user for a MIDI channel and a controller number, identifying a unique controller. It will pass a sequence of values to this controller (values are like function arguments for the controller), until you break the program with a "ctrl-c" input from the keyboard.

Here's a screenshot of my console when running it…

In the case above, I chose the MIDI channel 9 and the controller 12, which corresponds to the "Level" control of my Tube Screamer (I arbitrarily assigned these values in writing the PIC code for the Tube Screamer).

The Control Change Message format contains three bytes; the first has 0xB as its high nibble and the channel number-1 as its low nibble. 0xBn is the code for "Control Change" on channel n+1 and the channel can run from 1 to 16, so channel-1 (=n) will fit into the lower nibble's four bits. The second byte is the controller number, which can run from 1 to 127, encrypted as the seven least significant bits - in my case this is 12 (0x0C). The final byte is the value selected. In the screenshot above, I entered two values; 20 and 127.

Here's the signal that appears on the UART Tx pin (GPIO 8) for the first Control Change Message (value = d'20' = 0x14)…

You can see that MIDI message bytes have a "0" start bit and a '1' stop bit. Also, the data is transmitted LSB first, so 0xB8 (=b'10111000') appears reversed as b'00011101 (=0x1D) etc. You can also see that the signal is switching between 0 and 3.3 volts - we need some hardware…

MIDI is a serial protocol, much like RS232. It uses a current loop to transmit and receive data and we need to ensure that we are capable of sending the correct currents, without damage to the RPi. Luckily, it's easy - the current required is just a few milliAmps, having only to light an LED in the receiving device's opto-isolator - we all know that the GPIO pins of a RPi are well able to turn LEDs on and off! This implies that we just need a current-limiting resistor and an appropriate connector (which, for MIDI, is a 180 degree 5-pin DIN socket). However, we'll be a little more "proper" than that and transpose to the correct working voltages using a level converter to switch from the RPi's native 3.3 volt signals to the more common 5V.

In my case a 74HCT14 was staring at me from the "junk box", so I pressed it into service, just as others have done before me…

You can see the realisation of this interface in the photo at the top of this post.

At this point, having confirmed correct operation of the command-line interface program above, I decided to try to build a GUI interface, so I installed 'tkinter' (other fine GUI programming toolkits for Python are [no doubt] available) and started to learn something about GUI programming in Python. It is easy!

Here's a little program that generates a GUI to send data to a single MIDI control in response to movement of a slider…

The comments in the program listing should be sufficient for you to figure out how it works - here's how it looks when it runs (you open the program from the terminal and the GUI window appears)…

This is all very well - but most MIDI devices have more than one control (why, even a simple device like the MIDI Tube Screamer has four!). This ought to be reflected in the controller - so we need to think about how to work with number of controls. Hang on a minute - that sounds like an opportunity to get involved in some "Object-Oriented Programming", which is just the sort of thing Python ought to be good at. Let's see if we can make an object-oriented controller…

The Tube Screamer has three controls which take input argument 0:127. These "continuous" controls (which are called "Drive", "Tone" and "Level") correspond to the three potentiometers on the original device (and on Dolly the clone). I assigned control numbers 13,14 and 12 to these controls in my PIC code.

There's another control - associated with the footswitch - which switches the effect On or Off (actually, its on all the time - it just bypasses the effect for "off"). This "two-state" or "Boolean" control really only needs a single bit input - but the MIDI Control Change Message doesn't support this, so we still take the wasteful approach of sending a whole byte. Some controllers interpret 127 as on and 0 as off (or vice-versa). Heaven knows what they do if they receive anything other than 127 or 0!

I took the approach of interpreting anything greater than 63 as "On" and anything less than 63 as "Off" (in other words I just look at the highest bit of the seven bit "value"). These "continuous" and "Boolean" controllers sound rather different - but they can both be handled as instances of one class of MIDI controller...

Here's the resulting GUI, offering remote access to all the MIDI Tube Screamer's controls...

With the object-oriented structure it is easy to set up more instances of controllers - and GUI widgets to operate them, whether sliders or buttons. In fact, the greatest problem is arranging the widgets in the window!

Let me know if you construct any MIDI applications using these building blocks.

Today I ordered a DDS module hosting an AD 9850 chip - perhaps the next RPi application will be at RF rather than AF !

...-.- de m0xpd

↧

RPi GPIO Breakout for High Rollers

January 14, 2013, 10:38 am

≫ Next: Rotary Encoders on RPi

≪ Previous: MIDI Controller on the RPi

Having described the initial low rent version, I'm pleased to announce the arrival of an upmarket edition of my simple connector...

Notice how I've dodged the possibility of inadvertently connecting something unhealthy to the proscribed pins by the simple expedient of pulling out the corresponding pins from my device. I couldn't now "connect" if I wanted to!

The Cheapskate's version might not look so classy, but it wins hands down - drilling fifty two holes is a chore!

...-.- de m0xpd

↧

Rotary Encoders on RPi

January 18, 2013, 11:11 am

≫ Next: Multi-mode Beacon on the RPi

≪ Previous: RPi GPIO Breakout for High Rollers

I've been playing with an incremental rotary encoder on the Raspberry Pi - for no better reason than the mountaineers' lame excuse "because it's there"...

The incremental rotary encoder produces two quadrature square waves (as you can learn by reading any of a number of descriptions including this one). By detecting the relative phase of the square waves, you can figure the direction of rotation and (if you are really keen to encode angular velocity accurately) the speed of rotation too.

I settled for a clumsy attempt to decode direction alone, using this circuit...

Of course, you need some code too - I wrote the following simple demonstration in Python. It detects positive-going transitions on "PinA" and looks at the state of PinB during these transition events to figure the direction in which the encoder has been moved.

After the fun-and-games with the MIDI controller, I'm really excited about object-oriented software for the RPi, so here's an elaboration which includes a class for Rotary Encoders, connected to any two GPIO pins on the RPi. There's also facility to read a push-button (which some encoders - including mine - feature).

Here's a screen shot showing me running the second program ...

The code works - but only just...

It is important to sample a rotary encoder at a sufficiently high sample rate to avoid aliasing which - in this case - results in missed "moves" or even moves of incorrect direction.

I cannot get the RPi to sample fast enough to guarantee that every movement is perfectly observed, whether in the "while" loop seen in the programs above, or in a tkinter ".after()" command with a delay argument of 1 millisecond. What's worse, the little graph of processor utilisation at the bottom right of the RPi desktop (like the PC's "Task Manager" or the Mac's "Activity Monitor") reveals that the processor is working hard to sample the encoder at this rate (as you can just see in the screenshot above). I don't know enough about RPi to know if an interrupt-driven approach, such as would be easy and obvious on a PIC, is possible or desirable.

Having said all that, the code above works well enough to let me add a "knob" to my simple RPi MIDI controller, making it much more user-friendly than the original mouse drag-able sliders.

Next, I hope to use the rotary encoder to control the frequency of the DDS generator module from eBay that's just arrived on my doormat - watch this space!

...-.- de m0xpd

↧

Multi-mode Beacon on the RPi

January 20, 2013, 5:26 am

≫ Next: Raspberry Whispers

≪ Previous: Rotary Encoders on RPi

Inspired by some comments from Jim on Bill Meara's Soldersmoke Blog, I dusted off the m0xpd PayPal account (again!!!) and splashed out on one of the AD9850 DDS Modules from eBay...

Of course, you also need some kind of controller to make any use of these little synth modules. Fortunately, inspired by their beer-budget price, the modules are generating quite a buzz at the moment, so there's a lot of supporting software out there.

Andy Talbot, g4jnt, has written about the eBay modules in the current number of RadCom (but the dear old RSGB hasn't got around to updating their website at the time of blogging, so the link points to the previous edition - funny how the paper copy can be more up -to-date than electronic news!).

You can find Andy's PIC-based controller on-line - start with his description here .

Rather than follow the rest of the flock with a PIC controller (having already played with a PIC controller for DDS devices), I thought I'd like to use my new Raspberry Pi, so I had a further sniff about the 'net and found Ron, nr8o's blog, where he presents an Arduino sketch for setting up the AD9850.

I hacked that Arduino sketch into a piece of Python code for the Pi, which might be useful for others...

Having got the synth to run, I wanted something to do with it - so I built up a "beacon" transmitter...

You can see (from the left) my GPIO breakout (here in the "High Rollers' edition"), then a quad bi-directional level converter module I made to couple the 3V3 signals from the RPi into the 5V world. Next there's the eBay module.

Its signal goes to a little QRP PA I knocked together (drawing on the PA stage in my "Funster Plus" rig) and a low-pass filter for 40m. Currently, I'm measuring 5.8V RMS at the output of the filter which (if we were to allow ourselves to be comforted by the delusion that the load thereafter is 50 Ohms) implies that I'm throwing a rather healthy 600mW at my half-g5rv. I'll throttle back to more sociable power levels when I get a chance.

Here's the amplifier...

and here's the filter...

See how my obsession with Plugin Modules is getting worse!

With the work I'd already done on sending Morse Code from the RPi, it was easy to get the system to send my call (this time at QRSS speeds, with a 3 second dit length).

Here's the first spot (in the red box) of my transmissions at pa9qv's "Double Dutch" grabber...

With all the processing resource of the RPi, it was also easy to transmit Hellschreiber messages making this a multi-mode beacon (in the spirit of my original).

Here's my multi-mode signal arriving in the Netherlands...

I've added the annotation in red to help you see it! I only transmitted the rather flamboyant "Raspberry Pi" element of the message for fun. After the buzz subsides, I'll go back to sending just my call!

I guess the next step is to get the RPi beacon to send WSPR as well - but first, I must get onto 30m - there are more grabbers on that band - so more chance of seeing my Raspberry Pi proclaim itself to a waiting world!.

...-.- de m0xpd

↧

Raspberry Whispers

January 25, 2013, 11:54 pm

≫ Next: What do I know?

≪ Previous: Multi-mode Beacon on the RPi

After success with the "human readable" QRSS modes of FSK Morse and (my version of) "Hellschreiber", as seen here received by Steen Erik, la5goa up in arctic Norway,

I decided to add WSPR to my RPi Beacon's repertoire, to make it truly "multi-mode". I don't mean porting the WSPR code onto RPi (though doubtless this can be done - a Linux version is available). I mean cooking up my own WSPR signals in Python and transmitting them from inside the beacon previously described.

For anybody that doesn't know, WSPR is a true digital radio mode (in the sense that it is intended to be read by machines, rather than humans), developed by Joe Taylor, k1jt. I have enjoyed sending WSPR signals from my PIC-based multi-mode beacon - so I know the steps required. However, things have changed since the first time I trod the lonely path - so here's a description of how to do it today.

When I first played with generating WSPR signals, back in the summer of 2010, the secret was to use the command line version of k1jt's "WSPR" program. However, typing "WSPR" into a DOS command line these days just brings up the standard WSPR GUI. Fortunately, there's an alternative path...

The program "WSPRcode.exe" exists specifically to generate the WSPR message, which encodes the transmitting station's call sign, locator and power (in dBm). The locator is four symbols in the Maidenhead System which - for my home - is "IO83". The power is given in dBm (i.e. dB relative to 1 mW) and - as I'm producing around 200mW, I entered "23", making my message "m0xpd IO83 23".

Simply appending this string as an argument for the WSPRcode executable does the job...

The channel symbols describe which of the four frequencies which constitute the WSPR signal must be transmitted in each sequential interval. The WSPR "standard" tells us these frequencies must 1.4648Hz apart and that each interval lasts a little over 682 milliseconds. Also, a WSPR message must start 1 second into an even minute (that's to say the 0th, 2nd, 4th ... minute of the hour) in order to be received and understood.

It is clear that not only good timing - but accurate synchronisation to ABSOLUTE time is required.

Most WSPR transmissions come from computers, which keep good time (and may even be synchronised to time servers on the internet). Simple little beacons (like my PIC-based system) need to be started at precisely the top of the hour and keep good time thereafter. My PIC beacon hacked the timing framework developed by Gene Marcus, w3pm, who even included features required to synchronise to a GPS-derived timecode (though I haven't used that option recently).

In the case of the new Raspberry Pi beacon, timing remains the critical aspect of WSPR operation. Fortunately, unlike most PIC or AVR/Arduino alternatives, the RPi usually lives hooked up to the 'net, so absolute time is readily accessible.

Here's the simple additional lines needed in my Python beacon code to transmit WSPR...

'WSPR_Message' is the vector of channel symbols (obtained from WSPRcode.exe, above). WSPR_freq is the desired transmission frequency and WSPR_df is the frequency spacing between the channels ( = 1.4648 Hz). My code has a main timing loop which waits for the start of each minute and calls either FSK-CW, Hellschreiber or (now) WSPR routines at the appropriate point in a 10-minute cycle, by setting the "Proceed" variable to non-zero value. Proceed = 1 initiates a WSPR transmission.

I tried the Raspberry-flavoured WSPR signal on the 30m band and was immediately spotted by the University of Twente's 'Experimentele TelecommunicatieGroep Drienerlo', pi4tht and by Jorgen, oz7it.

Here are the reports of these spots from the WSPRnet reporting system...

WSPRnet also has a map report...

Here's a snapshot of the map taken as I write, showing the last 24 hours of spots (the thickness of the line between me and a receiving station indicates the number of times that station reported receiving my signal - so it's a measure of the quality of the link to that receiver). The map includes the Raspberry Pi's best "dx" (distance) to date - the 2552 kilometers to Alexander, ua3arc's receiver in Moscow.

Please let me know if you detect a whiff of raspberry on 30 or 40 metres over the next few days

...-.- de m0xpd

↧

What do I know?

February 2, 2013, 10:02 pm

≫ Next: KEYERduino

≪ Previous: Raspberry Whispers

Here's the story of a notorious late adopter's first foray into the world of Arduino.

As a long-term PIC advocate, I've been generally disinterested in matters Atmel and particularly put off by the statement that Arduino is intended for a bunch of wierdos (sorry - that should read "is intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments"). However, things have changed...

I guess it started when I looked at Ron, NR8O's use of an Arduino to drive the eBay AD9850 DDS module. The Arduino looked pretty neat in that application - and you program it in a real programming language! Then I read Limor Fried's comparison between Microchip and AVR microcontrollers. Interesting. Given the enjoyment I'd had with my new Raspberry Pi (Blogs Passim), I though perhaps it was time for me to join hands with all those liberals who have sewn Arduinos into their gaily coloured clothing.

Of course, that wasn't going to see me exchange my shekels with an authorised Arduino shop - particularly as I'd noticed that you can buy a kit of components for an Arduino clone for pennies on eBay. I got me a kit and started to think about how I could put it together on something more permanent than a solder-less breadboard.

Credit where credit's due - Arduino does publish a homebrew design for cheapskates like me on the Arduino pages but that didn't float my boat. So, after some searching around, I found Johak von Konow's design for a DIY Arduino - the Nanino.

Johan publishes a copper pattern for the Nanino, but I wanted to have the flexibility to change things - so I brewed up my own design in Eagle.

Here's my (current) copper pattern (seen from the component side)...

and here's the first board...

You can see the Nanino's influence in positioning the chip at a jaunty 45 degree angle!

I used Limor's (/LadyAda's) excellent Arduino resources within her extensive Eagle Library to simplify the design of the board, with its standardized profile and connector positions.

The board is programmed via a USB to serial adapter which implements a Virtual COM Port. You need to connect to the DTR ("Data Terminal Ready") pin on the adapter to access the "auto reset" functionality in uploading "sketches" to the board - otherwise you're into all sorts of nonsense about manually pressing the reset button. Don't be fooled by the RTS pin - this means "Ready to Send" in the language of UARTs and isn't a misprinted abbreviation of Reset.

You can see the adapter (and the connection to the DTR pin) here...

If you are wise enough buy your Arduino kit from 4Tronix, the USB adapter arrives already modified so as to bring the DTR line to the header plug that connects directly to my board's serial programming port, saving you from the messy hook-up in the photo above. Beauty!

I call my new board WOTDUINO (pronounced "What do I know"), making it particularly suitable for people with little confidence and low self-esteem. It is also possible to build a similar version (pronounced "What do WE know"), which is suitable for groups of people who don't think they measure up HI HI.

Now let's see what it can do.

...-.- de m0xpd

↧

KEYERduino

February 2, 2013, 11:05 pm

≫ Next: Arduino DDS Shield

≪ Previous: What do I know?

Now I've broken my duck with Arduino, it's time to look at some applications.

Having already got the "made a keyer" T-shirt for PIC and Raspberry Pi, the implementation of a Keyer seems to be turning into my "Hello World" example for microcontrollers, so off we go again with the "KEYERduino"...

Here's the program (what the illuminati call a "sketch" in Arduino-speak):

It is all simple enough - three input "buttons" being read and generating a digital output - just an extension of the button tutorial on the Arduino website.

In the present case, not only does the LED associated with pin 13 light up - we're also thinking of the same digital output driving the base of an open-collector transistor to key the transmitter. Also, only the straight key input works precisely like the button tutorial, simply "lighting the LED" when pressed. Closing any of the other two "buttons" triggers generation of the "dits" and "dahs" of Morse code, making an "iambic keyer". Oh yes - I nearly forgot - I also included a nasty, square-wave sidetone generator.

Here's the circuit, expressed in the unique format of Fritzing, much beloved of the Arduino community...

Fritzing isn't really my cup of tea - its OK for generating the sort of easily-accessible images above but it seems very much harder to make proper schematics with Fritzing than with a tool like Eagle.

Of course, nobody in their right mind would permanently implement a Keyer on an Arduino - it simply isn't worth burning the value (~£14) of the Arduino in something as trivial as a keyer. But there are some cases where it might just be excusable:

As a learning exercise - beyond the button tutorial
When part of a more complex application - such as a MEPT beacon
When you are just using the bare chip in a home-brewed board - cheap as chips!

Anyway - here's my keyer, running on the cheaper-than-chips WOTDUINO...

Not only is my implementation reasonably cheap (~£4). Not only was it an interesting learning exercise. But also, it might be the start of a more complex ham radio application of the WOTDUINO. Watch this space!

...-.- de m0xpd

↧

Arduino DDS Shield

February 9, 2013, 7:41 am

≫ Next: Arduino Beacon

≪ Previous: KEYERduino

Following the fun-and-games I had with the little eBay AD9850 DDS module in Raspberry Pi land, I decided to follow Ron's inspiration even more literally than before and team up the module with an Arduino.

Or, at least, with my homebrewed "Wotduino".

Here's the schematic I developed in Eagle...

I represented the DDS module as a component in Eagle and was intending to upload the library to the CadSoft site for you to share, but CadSoft claim not to recognise my email address (despite the fact that there's another library of mine already there, proudly displaying said email address). Stuff it then - collaboration can wait 'til another day.

The module only took up a small fraction of the available area on the shield, so I added a couple of dual flip-flops to generate a quadrature squarewave output for future games with Tayloe detectors.

Here's my copper plan...

Here's the finished board, seen from above...

You can see where I had to gnaw away a little of the Module PCB (lower right) to fit with the DIL package - there wasn't quite so much space in real life as my Eagle board layout suggested!

This being my first ever experience of a Wotduino shield (much less an Arduino shield) I was interested to get some pukka "stackable headers" to allow the new shield to ride shotgun atop the Wotduino...

The board works a treat - the picture above is actually part of an impromptu 40m QRP CW rig I've lashed together today using the Wotduino. It works nicely - well enough to raise Terry, g4ayr, on the rig's first shout. But just as Terry and I started to talk, the band erupted with a crowd of speed freaks sending - . ... -, so I'll wait until things have calmed down before I strike up my genteel iddy umpty again.

Perhaps I'll use the wait to start writing some Wotduino beacon code.

...-.- de m0xpd

↧

Arduino Beacon

February 24, 2013, 1:35 am

≫ Next: Arduino QRP Transceiver

≪ Previous: Arduino DDS Shield

Here's the story of my new multi-mode QRP radio beacon built around the Arduino - or, more properly, around my homebrew clone, the Wotduino^TM.

I ended the post on my Arduino DDS shield with the words "perhaps I'll use the wait to start writing some Wotduino beacon code". Well, despite more than the usual volume of traffic of distractions keeping me away from leisure activities over the past few weeks, I've managed to steal some moments to keep me (nearly) sane...

The beacon started with the usual lash-up on the bench, hooking the previously reported Wotduino and DDS Shield up to a driver and a transmitter module, as previously used for the Raspberry Pi beacon...

You can see that - in addition to the usual culprits - there is also some evidence of a receiver, a key interface and a tuning control in the picture above (so you can guess what will be appearing in future posts).

The experimental beacon was soon pumping out its tidings of great joy and getting rewarded by acknowledgements on QRSS Grabbers, such as this very first spot, seen at PA9QV...

(I've added the red text annotation to help those new to viewing these images - first to decode the Morse Code in my FSK-CW signal and then to emphasize the italicized text version of my "Hellschreiber" call).

Simultaneously (or, at least, at different points in its 10 minute operating cycle) the Arduino Beacon produces WSPR messages and these were decoded and reported automatically by reporting stations all over the place. Here, for example, is a map showing good performance to the US on 11 and 12 February...

In the spirit of work that elevated the humble eBay DDS module to a fancy Arduino "Shield", I wanted to formalize the Arduino Beacon and so I have produced a "Transmitter Shield", which takes my QRP Tx Module (with its "Ugly weekender" heritage) and places it in the familiar "Shield" format...

This new shield includes a driver stage to amplify and distribute the DDS signal, a power stage (mainly used to provide 5V for the rest of the system from the "12V" supply used for the Transmitter), a Keying Stage which allows the Arduino to turn the transmitter on and off to without switching transients (which radio folk call "keying" - from the action of the telegraph key) and the RF power stage itself.

The power stage is simply two 2n3904 transistors which are driven to produce 500mW. This involves dissipating a fair amount of energy in the little transistors - so I treated them to a homebrew heatsink, hewn out of a scrap of Aluminium (apologies to our North American readers for the spelling lesson)...

The similar power stage in my "Funster Plus" rig doesn't have a heatsink - but the beacon spends a lot more of its duty cycle transmitting, so I felt it had earned the luxury of more effective heat management!

The Transmitter Shield sits on top of the existing layers to make a nice "Beacon Sandwich" (pun intended)...

To celebrate the new hardware, I took the liberty (and bandwidth) to send a more lavish (or, at least, more verbose) sequential multi-tone "Hellschreiber" proclamation, here seen at g3vyz

The beacon is still multi-mode; in addition to the modes seen above it also sends "m0xpd/arduino" in (QRQ) Morse and participates in the WSPR mode, as seen here achieving my best-ever westward QRP beacon dx to nj6d in Arizona...

As the Arduino does not provide such a rich programming environment as the Raspberry Pi, there were a couple of points at which my attempts to get m0xpd beacon operations running on the new Arduino platform threw up some issues...

Firstly, readers may remember my delight on discovering "Associative Arrays" - or "Dictionaries" as they are called in Raspberry Python land. I used these to look up the Morse code equivalent of a character in my messages back on the RPi beacon.

Arduino does not offer native associative arrays. You can, of course, use C libraries to pull in this functionality, but I decided to take a different tack...

My code on the Arduino looks for the ASCII value of each character in a Morse message, then uses this ASCII value to point to the appropriate element of a "char" array of strings of 0s and 1s, which represent the Morse equivalent of the character (0 for a dit, 1 for a dah). I started the array at the ASCII value (decimal) 40, as there's no character send-able in Morse before that.

The process is shown here in my routine to send FSK-CW (the straight CW routine uses the same resources)...

As an example, the comma has ASCII value 44, so its the fifth element in my array (Arduino arrays start from index 0)...

The second little wrinkle in the Arduino Beacon code was unexpected. The RPi has the luxury of an internet-derived clock, so timing for a beacon is supremely easy. By contrast, Arduino only has a counter which runs from the instant the program is started and from which time relative to that start instant can be computed. The counter is ultimately derived from the 16MHz crystal-controlled oscillator.

Once I had my beacon up-and-running, I noticed that it was running slow - it would lose a few seconds every six hours, indicating that my 16MHz crystal was actually 15-and-a-bit MHz! I fixed it by telling the Arduino that there are only 59995 milliseconds in a minute and that - to the level of accuracy required - has done the trick. You can see the lie in the code excerpt below, which shows the (start of the) main timing loop of the beacon...

Now its time to try to find space - amidst all the distractions - to do some more work on the receiver side.

...-.- de m0xpd

↧

Arduino QRP Transceiver

March 9, 2013, 2:42 am

≫ Next: Arduino Honeymoon Over

≪ Previous: Arduino Beacon

Meet my new rig - a QRP CW Transceiver for the lower HF bands, built around the Arduino "open-source electronics prototyping platform".

Readers have seen in recent posts how I developed a multi-mode beacon using the Arduino - but that was only a waypoint on the journey towards a full ham radio transceiver.

We started the journey with my homebrew version of the Arduino - the "Wotduino" and then wrote code to make the Wotduino work as a Keyer. Then the Wotduino was given the ability to generate radio frequency signals, using an AD9850 DDS chip on an inexpensive module from eBay, mounted on a homebrew DDS shield. Then we added a QRP transmitter, enabling the system to work as a beacon. The last leg on the journey is a receiver, as seen in the photo above.

My new receiver is derived directly from the Rx stage of Roy Lewallen, w7el's beautiful and definitive Optimised Transceiver for 40m.

I've used this as a start point before, both in the Rx for my "Funster Plus" rig and as a QRSS/WSPR receiver.

My new circuit is implemented on an Arduino shield, as seen below...

The signal path from the antenna goes to a double-balanced modulator, where it is mixed with the LO signal from the DDS module. This generates audio frequency (by direct conversion), which is amplified in a common base stage and then passed through a 2nd-order Sallen-Key bandbass filter. Next, a further gain stage controls volume and limits the voltage swing (ironically using the same back-to-back diode method exploited in the Tube Screamer). The receiver is muted during transmission by a FET pass-gate, under the control of the Arduino. Finally, a little audio power stage drives headphones or small speakers.

The receiver sits in the stack of "shields" on top of the Wotduino...

All this adds up to a viable transceiver, as explained in the block diagram of "architecture" below...

The Wotduino controls everything through what we might call a "control bus" formed by the stackable header plugs on either side of the boards.

To this bus is connected a paddle and a straight key, interacting with the keyer code. The DDS module also sits on the control bus, through which it is instructed to generate the appropriate frequency. This RF is carried on an additional "RF bus", implemented on a line of 6-way stackable headers which link the DDS, Tx and Rx shields. The DDS signal is amplified and buffered by a circuit on the Tx shield, from where it is passed to the new Rx shield by another line on the RF bus.

Also hanging off the control bus is a display to show the operating frequency. This is an old 12-character, 7-segment serial input LCD module which I picked up at some long forgotten rally for pennies.

The frequency is adjusted using a rotary encoder - which also selects the band. The rotary encoder has a push-button, which allows me to adjust the frequency in 10Hz, 100Hz or 1kHz increments (10Hz is the lowest resolution necessary, whilst 1kHz lets me scan across the band - or change bands - quickly). When you adjust the frequency above the top band edge (more exactly above the top of the CW segment of the band), it automatically steps up to the next band. Similarly for downward QSYs.

Here's the rig in the habitual lashed-up state (perhaps I should say "Kludged" or "Kloodged" state) on the bench, back in the day when I was still using a potentiometer for frequency adjustment...

It is connected to speakers from a roadkill computer and an old straight key for testing. I don't know about you, but whenever there's a viable rig testing on the bench, I just can't keep my hand off the key and the antenna coupled to a dummy load - I always end up having a QSO. So much for testing!

In spite of all my high intentions of making a case, etc, etc, I couldn't stop myself from answering Andy dm5mu in Leipzig and getting a 559. Then Miroslav, yu1dw, in Cicevac, Serbia for a 579. Not bad for my first two attempts on 40m with my 500mW. After these initial QSOs I added a "send/return" connection so I could route the audio signal through my variable bandwidth CW filter (SPRAT v.146 p20), which makes the rig much easier to use when the bands are noisy or congested. The rig is set to cover top band through 20m - but so far I've only had QSOs on 80 (including Ian, g3roo's QRSnet) and 40.

Right - now let's see about some kind of enclosure to pretty the whole thing up a bit...

...-.- de m0xpd

↧

Arduino Honeymoon Over

March 17, 2013, 6:08 am

≫ Next: Arduino VFO

≪ Previous: Arduino QRP Transceiver

After a long and enjoyable honeymoon period with the Wotduino, in which she could do no wrong, I woke up this morning to see her for what she is - warts and all...

The problem was that I had made some modifications to the code (what the Arduino community call the "sketch") for my little QRP Rig and I had committed the ultimate sin - I hadn't saved it!

Go ahead - laugh at me. Call me all sorts of names. Tell me I should never do that.

Fact is - any other IDE for a micro-controller I've ever worked with (as far as I can remember) saves the code when it is built. So, naively, I expected Arduino would do the same. The sort of assumption you are likely to make in the first flush of romance!

No sir! Not the Arduino!

Turns out that this is a weakness which trips up many newcomers - a quick search on the net returns reassuring comments like "Lots of people ask this. Quick answer - no." (on the Arduino forum, no less). Fortunately, the quick answer is that its IS possible to recover code that has been uploaded to the Arduino, even when you didn't go through the stone-age step of saving the sketch at the time (or even when you closed the Arduino IDE).

I was put onto the scent by Robert's useful post, which had me searching for a folder of the form "buildxxxxxxxxxx.tmp" and which, in my case turned out to be:

C:\Users\Paul\AppData\Local\Temp\build6490475155612533273.tmp.

You need to remember the (approximate) date at which it was created / modified to find out which is the correct folder.

Then you look for the file with the same name as your sketch and a C++ extension - in this case, the file highlighted...

Opening this file (in Notepad, if on a windows machine) will reassure you that you're on the right track...

Then, it can simply be copied and pasted back into the Arduino editor window where it belongs...

Here I changed the name of the sketch and made damned sure to save it - I won't be going through this fiasco again!

So - there IS a way to rescue all your typing and escape the disappointments and inadequacies of the Arduino "Development Environment". Perhaps she's worth sticking with for a little while longer!

...-.- de m0xpd

↧