Wednesday, 19 November 2014

Swedish Encoder Taming

Leif, sm7mcd, has sent me some great photographs of his experiments using capacitors to tame the output of rotary encoders - and he has given given me permission to publish them here...

Leif starts by showing that the encoder is capable of generating perfectly clean output in clockwise rotation...


However, the same encoder can also generate "glitches" in its output as the switch contacts bounce, clearly seen here...


Similarly, in counter-clockwise rotation (notice how the bottom quadrature trace now lags the top trace, indicating the different sense of rotation), clean output is possible...


but the switches can also bounce with the resultant glitches...


Leif has added some (enormous) 100nF Mylar capacitors...


and this generates the sort of pulse shape I suggested in the previous post...


Leif shows how the capacitors "eliminate" the glitches caused by the contact bounce...


Notice that the switch's bouncing closure does not have chance to discharge the capacitor and pull the voltage down to zero - we would need to include a discussion of the (small) switch contact resistance and the equivalent inductance in the circuit to describe this behaviour.

Certainly, as I commented in my last post, and as Leif's photos beautifully demonstrate, the capacitors "modify switch bounce". They also add the clear exponential shape to one side of the pulse which (with the addition of the threshold operation in the logic) gives the pulse width increase. 

I remain unsure of the exact mechanism that is taming the encoders - I do not know for certain if it is about switch bounce or pulse width. But I quote from Leif: 

"I experienced the same problem with reading errors from the rotary encoder and it's nice to see that we found the same cure. I did some testing in rapid spinning of the encoder and I found 100 nF almost optimal also for real rapid spinning."

Leif is a member of den Kalmar Radio Amatör Sällskap (Kalmar Amateur Radio Society), who are using some of the m0xpd / Kanga shields in their projects this year. I'm looking forward to any excuses for collaboration with Leif and his fellow members of KRAS.

Tack så mycket, Leif 

...-.- de m0xpd




Saturday, 15 November 2014

Taming the Rotary Encoders

My Rotary Encoders have had it easy - it is time to introduce some tough love...


Ever since the earliest days of the Occam's Microcontroller project, the Arduino QRP transceiver that preceded it (or even the earliest games with the Raspberry Pi) I have used a simple software interface to my rotary encoders. Critics could (with some justification) call it a lazy software interface - but I will defend the word "simple"...

All my (Arduino) code observes the state of the rotary encoder switches once per "loop". This has the considerable benefit of simplicity (as advocated by the KISS principle, by our belovéd Franciscan, etc). It also has the considerable risk of inadequacy!

If the encoder is to be read accurately, it must be sampled sufficiently frequently. One danger of my "simple" approach is that the "one observation per pass through the loop( )" will not constitute a sufficiently high sample rate to satisfy Shannon's sampling theorem, such that neither direction nor speed of the encoder can be deduced. Errors will result.

Both the "correct" solutions (fast, interrupt-driven sampling of the encoder or explicit connection of the encoder to inputs with edge transition detection capability which can trigger interrupts) feel way-too complicated to me and offend against my sense of "appropriate engineering". But the simple approach was always known to be standing on thin ice - that ice has just melted, forcing me into action. Two things prompted my activity...

Firstly, I was getting errors from the Rotary Encoder in my own rig.


I could understand this - my rig was running way-bigger code than anything I'd released to the public (there's more in there than I've told you about - YET!), so my own "sample rate" was even lower than that of any of my "customers". Also, I had a rather long cable run from my board to my Rotary Encoder and I had a pretty hostile operating environment. Most importantly of all, I could readily ignore complaints from this source - even though the errors from my encoder were getting to be pretty bad!

The second thing that happened was much more significant - it really catalysed ACTION. A real, live reader of this blog, named Richard, came up to me at the Rishworth mini-convention and described the problem. He didn't complain - but he could (and perhaps should) have done.

In response to Richard's input, I've finally done something, which has fixed my own rig (above) and which seems to offer a useful "taming" of the Rotary Encoder - I've added two capacitors!


The capacitors are placed in parallel with the two "switches" in the rotation sensing part of the encoder, as shown in the schematic above.  In fact, I had tried this previously (in building the encoder system for the "VFO" for the SI5351-based BITX), where I found it to work very well.

Action of the additional capacitors is understood if you remember that there are resistors (shown dotted in the schematic above) - either fitted explicitly as extra components or embodied as internal pull-ups in the microcontroller. The combination of these resistors and the additional capacitors are going to define a time-constant (making appropriate choice of the capacitor value dependent upon the resistor) which modifies the switching action as sensed by the microcontroller...

The sketch below shows one switch closure with- (bottom) and without- (top) a capacitor fitted.


The downward transition isn't changed. But when the switch opens, the capacitor has to be charged to build up the voltage, introducing a time delay Δt before the voltage read on the microcontroller input pin reaches the logic high value. This "stretches" the pulse width. If the pulse is stretched wider, it can be observed successfully at a lower sample rate.

The capacitors also modify switch bounce (although I think this is irrelevant, given my lamentably slow sample rate) and suppress high-frequency noise which might be induced on the otherwise high impedance line.

I can't confirm the exact mechanism that is taming my Rotary Encoders - all I can report is that the addition of the 100nF capacitors, as shown, is doing an excellent job. I recommend that you add them to all the m0xpd rigs, VFOs, etc that use Rotary Encoders read by Arduino software.

Thanks Richard!

...-.- de m0xpd

Update (16 Nov)


Fred, wa1dlz, has been experiencing problems with my code, including the problem with the Rotary Encoder - see his comment below. In subsequent private correspondence, Fred told me that the capacitors described above made no difference at all on his system - in fact "the 100nf caps actually made things worse".

This information from Fred prompted me to try to visualise the "stretch" in the pulse from the rotary encoder to confirm that it actually exists.

I set up a system (running the "Double DDS" code) and instrumented the rotary encoder pins using my ripoff logic analyser. This claims to interpret VHIGH as being anything greater than 1.4V.

Given that the pulse widths from the encoder are controlled by the rotation speed - which itself is controlled by my hand - the entire experiment is rather difficult to construct. I decided to use one "side" of the encoder as a reference and to add the capacitor to the other "side", as suggested in this schematic...


The resistors (as shown dotted above) are the internal pull-ups in the ATmega328P microcontroller.

I made several measurements, in which I sought to rotate the encoder at roughly similar speed, with and without the capacitor Cx.

The following results are representative...


Whilst I don't suggest this is marked by rigor, I do think there is indication of an increase in the relative width of the "off" phase of the B signal as the capacitor Cx is increased.

Fred's findings show that the capacitors are - by no means - a panacea. They haven't helped him at all -but they have transformed my rig's tuning control from a frustration to a joy.

The "stretch" seems real.  But it may not stretch to solving your problem - please let me know, one way or the other!

Saturday, 8 November 2014

Dodgy Si5351s

Dodgy (for the benefit of international readers) is an informal British adjective meaning "dishonest or unreliable", with further connotations of "potentially dangerous" and "of low quality". I have recently had a batch of dodgy Si5351s foisted upon me - caveat emptor!

You will have seen my infatuation with the Si5351 developing whilst she was clothed in the Adafruit Breakout Board. I was - quite naturally - keen to undress the device and play with her in the flesh.

Fortunately, a batch of naked Si5351s arrived. Unfortunately (given my poor eyesight and cack-handedness), I had first to deal with the "terrible miscalculation of scale" and mount the bare devices on MSOP-10 to DIL carrier boards...



Credit where it is due - I had the devices MOUNTED on the carriers - thanks, Nigel and Dennis!

With objects that I could now both see and handle, I could contemplate making an operating environment for them - I chose (not surprisingly) the environment of an Arduino shield...



Here (above) you see a socket ready to receive the Si5351, a 25 MHz crystal to clock it and a level converter circuit to translate I2C signals from the Arduino UNO lurking beneath the shield to 3v3.

The level-converter circuit is - ironically - the same circuit I used to perform the same role for the earlier, much beloved, Silicon Labs RF generator (the Si570). The same circuit I have used many times in my modular level converter plug-ins. Most ironically of all, it is the same circuit her Ladyship uses on the Adafruit Si5351 Breakout board.

Yes - dear reader - underneath those big labels there are some more pieces of circuitry which I am deliberately concealing from you. It isn't time to show you yet -  Pete calls this the "Fan Dance"!

I put the new Si5351s in the socket - my heart pumping slightly faster than its normal resting rate - and - nothing happened.

I tried all my code (which I knew worked, from experience with the Adafruit board). I tried all the "test" example programs (from Jason and Adafruit). Nothing.

In the end - in desperation - I tried running an I2C "scanner" program, which searches for the presence of any I2C device, and reports what it finds.

Here's what happened...


No wonder nothing was happening - the Si5351 code was anticipating a device at I2C base address of (hex) 60. Instead, the actual device appeared at 6F.

Let's be clear - this is WRONG. This is OUT OF SPEC. Here is an extract from the Data Sheet that defines what an Si5351 IS...



The extra commentary (in the red box) is from your humble servant. Our little 10-pin device only has one I2C address : 0x60. Fancier devices (with more pins) can use one of those pins to give an optional choice of 0x60 OR 0x61. But our little Si5351A is just specified to be there on 0x60. End of.

I knew that my shield with its level converter circuitry was working fine, because I could put the Adafruit Breakout board into the socket and the I2C Scanner could see the Si5351 at the correct address..,



Then - I discovered that the dodgy Si5351s would actually respond, as long as I modified the base address in the libraries to correspond to the (incorrect) 0x6F value that their hardware embodied. This is achieved easily enough in Jason, nt7s' library by an edit of one character of the si5351.h file. But it does nothing to recover the dodginess of the batch of rogue devices...

I want to use Jason's library with ALL my Si5351s - I'm not prepared to have two different versions of software "drivers" to handle some real devices (on the Adafruit boards) and some dodgy ones. This has to be about interoperability.

Finally, I got a second batch of Si5351s and had them mounted on DIL carriers. I put them into the shield and ran the scanner...



At last - the real thing!

Batch 1 came from Mouser (UK). Batch 2 came from Digi-Key.

Jason, nt7s, has previously blogged:

"it seems obvious that Mouser has some oddball parts; perhaps they were custom parts that inadvertently escaped Silicon Labs. I'm still waiting to hear back from Mouser about the issue, but in the meantime, I would recommend you order from a different distributor until they fix this problem."

The evidence above shows that parts from Mouser in the UK also display the same dodgy behaviour.

At the time of writing, Mouser have kindly agreed to refund the purchaser of the Batch 1 devices.

I can continue my romance with some pukka Si5351s.

Pukka, (for the benefit of international readers) is a informal British adjective, meaning "first class" or "genuine" and having Hindi and Urdu origin, (where it originally meant "cooked, ripe").

...-.- de m0xpd

Monday, 27 October 2014

Rishworth, SDRduino and the Si5351

Just back from the 25th G-QRP Mini Convention, where I disappointed the punters by presenting again. I broke up the monotony of my talk with some examples of "QRP" TV test cards and thought it would be nice to design a new one, featuring our beloved Franciscan...


My subject took the simple ideas of last year's "Occam's Microcontroller" project and stretched them to embrace Software-Defined Radio, whilst keeping it all within the Arduino family.

The idea was embodied in the SDR rig which you see below, mounted on a piece of scrap plywood from my youngest daughter's house renovation project...


This project will, henceforth, be known (with apologies) as SDRduino.

Those fortunate enough to have missed the talk can see my slides here.

The Si5351 generated quite a lot of discussion at the Convention and I promised to put up some code. There is now a version of the "RF for Superhets" code available from this Github repository. I've tested it on 40m on my modular BITX - but would appreciate any bug reports from early "beta test" users!

...-.- de m0xpd

Sunday, 26 October 2014

Julian, g4ilo, SK


Julian Moss, g4ilo, died peacefully on Friday evening.

His website and blog taught us all so much about radio.

His other blog taught us all so much about living.

Rest easy, Julian.

...-.- de m0xpd

Sunday, 19 October 2014

QRP HomeBuilder QRT

Those of you who monitor the QRP-L list already will know that Todd Gale, ve7bpo, has taken down the QRP HomeBuilder website


This excellent resource has been a site of special interest to me over the years as the home of the Funster 40, which motivated my own Funster Plus rig.

Todd's work has always been of the very highest quality, being solid, evidence-based, honest engineering. It has been coloured in recent years by the introduction of some new dimensions of "comedy" or "character" which I don't claim to understand - but that doesn't change the core quality of Todd's offering.

Fortunately - although the website is no more - Todd has generously made an archive of the site available for download as a PDF. I don't know how complete that archive is - but it is there for all to capture, as I have done. Ironically, given that I referred to his excellent library for the Si5351 recently, Jason, nt7s is one of the people hosting the archive here.

Of course, QRP HomeBuilder is now removed from the links at the right hand side of is page - and the space that it has made in 'M0XPD's LINKS' has been occupied by Jason's 'Ripples in the Ether'.

We all owe Todd an enormous debt of gratitude for all he has done at QRP HomeBuilder - but, as Benard Ighner's song says,

Everything must change 
Nothing stays the same 
.... 
Nothing and no one goes unchanged 

Todd hasn't stayed the same - he has started a new initiative: Popcorn QRP , which takes its place in the links.

I look forward to continuing to learn from Todd's experiments.

...-.- de m0xpd

Sunday, 12 October 2014

Si5351 in the BITX

Having played with the little Si5351 device in the Adafruit breakout board last weekend, I took the opportunity to build it into a VFO system and attach it to a receiver...

The new VFO was functionally a re-work of the dual DDS system I put together for my BITX at the tail end of last year, even sharing the same breadboard and Arduino NANO controller I used in early experiments...


On the breadboard you can see (from left to right) the NANO, a rotary encoder for tuning and the Si5351 breakout board. The LCD reveals that the system is running a modified version of my dual DDS code, which led to the SPRAT article with Pete Juliano, n6qw, "RF Generation for Superhets". This code generates both "BFO" and "VFO" signals - thereby making use of two-of-three of the available oscillators on the Si5351.

The system worked FB - so I hooked it up to my experimental "Breadboard BITX" receiver for a test. Again, everything worked perfectly (once I had set up the code's implementation of the BFO to the correct frequency for the particular 10 MHz IF filter I had mounted at the time).

However, the implementation of the "VFO" system on its own separate solder-less breadboard, seen in the photo above, was all a bit clumsy - so I exploited the simplicity and small physical size offered by the new Si5351 signal generator and tidied things up...


Above you see a complete BITX receiver (that's to say - only the parts required to operate as a receiver are present but all of them are fully bi-directional) on a single plug-in breadboard. Antenna input at "top left", speaker output at the bottom.

An annotated picture will save a thousand further words of description ("BA" = Bidirectional Amplifier)...


As you see, I made a new plug-in tuning module, hosting a rotary encoder. What is not so clear from the picture is that on each side of the tuning knob are push buttons that drive the remainder of the user interface (moving the "cursor" to select tuning rate, navigating the menu structure, etc).

The system seems to work every bit as well as before (as far as I can judge from a few minutes subjective listening in rather noisy band conditions on 40m) with the exception that there is a rather strident "noise" when it is tuned to 7.143 MHz the origin of which I can't explain. Also, I haven't yet done anything to optimise the level of the input to the amplifiers (and / or adjust their gain) I provided for the mixers I just stuck the signals from the Adafruit board straight in and saw what happened. Whilst the system is already working well, I suspect things can only get better.

There will be a release of the "Double DDS" code for the Si5351 - but I'm not yet ready for that. When it is suitable for public disclosure, you'll be the first to know.

This little Si5351 certainly is living up to expectations - I want more.

...-.- de m0xpd