Slightly more organized

My work has been making unusually high intrusions into the more important aspects of life recently, with the pressures of moving to new premises and trips to The Netherlands and Italy in the last two weeks. Although little has been achieved in matters which might interest you, dear reader, I have at least been able to move slightly forward on the Virtual Organ (Blogs passim)...

Specifically, the organ has acquired another set of Hammond drawbars (giving me a full complement of 9 drawbars for each of the swell and great manuals), a dedicated PC and an old monitor.

This past weekend, I finally got round to transferring the main controller (in which a PIC16f873 reads all the drawbars and switches and sends their settings to the PC over MIDI) from a solderless breadboard to a couple of PCBs...

The main controller board still has a 16*2 display, which one day will move from the board to a visible position on the outer case of the organ. There is also a separate "decode" board, made to correct my own stupidity in not incorporating sufficient decoding on the drawbar interface boards (the action of which is described here), one of which is seen in the photo above.

Also visible in the photo are a couple of small boards which provide interface to assorted analog controls (at the moment, potentiometers for percussion and key-click level). These boards also interface to switches but this is a waste for simple "Boolean" controls - one day I'll use the matrix interface I've built into the new controller board to read the switch settings.

The photo below shows the organ in a corner of the shack, with the software running in the new small form factor PC I "won" on eBay just for this project.

The pedal-board "woodwork" needs completing - in fact the entire organ needs a new enclosure. Still - at least it is now working, playable and self-contained. Next task is to sort out the bug in the new PC which is making it very difficult to turn on (without apparently random resets, visits to "Safe Mode" etc). Perhaps I should have relied on traditional tone-wheel technology rather than a computer!

...-.- de m0xpd

Bit Set - or not

I've been playing with a simple PWM application on PICs...

The final application will use an 8-pin PIC (the 12F675) but I chose to start code development on the 16F676, partly because I had some in the junk bin and mainly because I also had the special 20-pin PIC16F676-ICD device which allowed me to do debugging (I'm too cheap to buy the PIC12F675-ICD).

All was working FB until I tried to translate the code to the 12F675 - I had one of my two PWM signals running, but couldn't get the second to appear on the appropriate I/O line, no matter what I tried.

Here's what turned out to be the offending lines of code...

It is part of the interrupt service routine, which establishes the two (phase-opposed) PWM signals on GPIO pins 1 and 2. The signal on GPIO2 was fine, but there was nothing but a glitch on GPIO1.

Can you see anything wrong with the code? I couldn't - despite staring at it for an hour!

I assumed that I'd made a mess of setting up the GPIO port and spent ages staring at different pieces of the program and making changes just out of desperation. Everything appeared logically consistent and I just couldn't see where I'd gone wrong.

Eventually, I searched for anybody else who'd suffered the indignity of PICs behaving badly.

Fortunately some Kiwis have trodden this path before me and written it up .

It seems you can't just perform bit-wise operations (like bit-set or bit-clear) on the port of the 12F675 without errors (perhaps I should say without "unexpected results"), despite the fact that you can on other PICs - like the 16F676 on which I did my code development!

The fix is simple - don't use bit-wise manipulations...

I feel a little better that I couldn't see a logical error in the code (there wasn't one) but the fact that the 12F675 "doesn't obey its own instructions" still galls!

...-.- de m0xpd

Gyrator analysis

Your humble servant's article in this spring's number of SPRAT (pp 20 - 23), "A(nother) CW Filter", uses a circuit called a Gyrator to implement an inductive impedance. I was thinking ahead to a scheduled talk on the CW Filter at the Warrington club and realized it would be nice (that is to say "it would please me") to include an analysis of the gyrator.

This is a pretty standard circuit configuration, but a quick Google ((v) search the internet (for information) using the Google search engine) revealed that such analyses aren't exactly falling over one another - so here's the m0xpd story...

The circuit in question is shown below...

The voltage at the non-inverting input to the op-amp is related to the input voltage by the potential divider equation:

Ideal action of the op-amp (which is configured as a voltage follower) is summarised by:

We're now in a position to identify the currents i₁ and i₂ - we start with i₁...

Substituting for the voltage at the non-inverting input gives (with apologies for the contribution of the "Microsoft Equation 3.0" equation editor):

i₂ is simpler:

The input impedance to the circuit is:

which is solved by substituting for the two currents above...

There (in the box) it is!

The input impedance is the series combination of a resistor and a "virtual" inductor (in the sense that an inductor presents a positive reactance, proportional to frequency), with the inductor taking the value of the product of the two resistances and the capacitance...

Next time you need a big coil, try one of these instead!

...-.- de m0xpd