In developing my own precision tuner and being interested in strobe tuners, I found a working-but-needs-refurbishment Peterson Model 400 inexpensively on ebay, so I bought it with the intent to fix it up, calibrate it, and use it. I replaced a few parts, made a couple modifications, and added an internal mic to make it quicker to setup and use.

How a strobe tuner works:

A strobe tuner, at least traditional ones, is an electromechanical tuner that relies on the strobescopic effect (surprise surprise!) for its display. What that means is that a strobe tuner converts an audio input into a blinking light - neon lamps in this one - and shines it on a wheel with patterned markings that a motor is spinning at a constant speed. When the rotation speed of the disk, which has its speed precisely governed by a separate circuit, and the speed of the flashing of the light match up in the right way, it looks like the markings on the disk are moving very slowly, or not at all. This is the same sort of effect you can see watching a video of a driving car's wheels, where the wheel seems to rotate quite slowly, but in this case, the designers have done all the math needed for the speed of the motor and the patterns on the disk to look like they stop moving when the incoming audio frequency is in tune. It sounds complicated, and I suppose it is, but the circuitry involved is comparatively much simpler than other electronic tuners, so when electronics were comparatively primitive, it could be an extremely accurate instrument without too much electronic complexity.

You set the note you want to play, make sure the vernier knob is set to the right reference pitch, and then play your note - when close to the right pitch, you will see some of the markings on the disk get darker. If the markings are moving to the left, your note is flat, if they are moving right, your note is sharp, and if they appear but are not moving at all, you are perfectly in tune. The rings on the disk match up to different sounding octaves, so the higher the pitch being measured, the higher up on the disk the pattern will seem to slow or stop moving, and because the tuner measures all of the incoming audio, you will typically see multiple rings looking active - higher harmonics in the sound will show, usually more faintly, on the other rings of the tuner disk. Because the motor speed has to be precisely controlled to measure against a fixed reference, you have to change the note dial (centermost large dial) when tuning other notes, but because the harmonics show, you can still get good tuning information on the perfect fourth and fifth of whatever note the tuner is set to - the patterns will still be visible and will stop moving when the note is in tune. Interestingly, when playing the major third below the note the selector is set to, you will see one ring telling you that you're playing flat, even if you are playing the correct pitch. This is an artifact of equal temperament and the harmonic series, so if you play your note 12 cents sharp, that ring will stop moving, because you will be fitting in the just intonation of the major third. Conversely, if you set the vernier to 12 cents low, when you play your not a major third below and see the ring stop moving, you'll be playing the note in tune with equal temperament. The reference pitch vernier is marked in cents, but you can use it to play with a non A=440 reference pitch, for example, if you set it to be just over 7 cents high, you will be effectively playing with an A=442 reference pitch.

It helps in understanding the design and troubleshooting or refurbishing to have the schematic available, and it is available online, including here. The schematic even shows which board each part is on (dotted outlines), which is especially useful because there is no silkscreen or part markings on the boards, and it includes some of their design considerations - using low current noise resistors on the audio input line and using high stability, low leakage capacitors on a few key components used in keeping tuning frequency stable. To control motor speed, the tuner uses a high stability oscillator (at least, for the time) that drives a bipolar stepper motor, and each note on the selector has an individual resistor to trim the speed exactly. The audio processing goes through an optional low pass filter (the image clarifier switch) which I like to leave on, and then to the lamp driver board - to get that relatively small signal to drive neon lamps which have a 400V power supply. Later model 400s included an internal mic, but this one and this schematic do not include one, the input connector also does not supply any sort of bias voltage or phantom power.

Refurbishing the tuner:

If you're planning on trying this yourself, if you have some experience working with electronics and mains voltage electrical appliances, it's a fairly straightforward job - but even if you are, please be careful. Not only is there exposed mains wiring inside, there's also a high voltage 400V rail for the neon drivers and there's spinning parts thanks to the motor and disk, so there are a number of bits to be careful of. My unit's capacitors discharged fairly quickly when unplugged, but be sure to check them with a multimeter before working inside, even when powered down and unplugged.

I powered the unit up using the included mic and while it lit and whirred, it was entirely unresponsive. I used another external recorder's line out to run into it and suddenly the tuner sprung to life... but it was something like a fourth off of what the note was actually sounding. I knew it needed some help, so I went to work. Checking out the obviously dead mic I took it apart. I tried to get the element back on the little bar in the middle of the copper cup housing it, but since the mic wasn't dynamic, I'm not sure it ever could have been used with the tuner alone as no bias voltage was being supplied. I couldn't find any information on the mic model and wasn't expecting much, so I ended up tossing it.

Taking it apart, there are four screws in the wooden road case style housing and then the entire tuner chassis slides out. There are boards everywhere (the top is the power supply, the internal board drives the motor, the board on the side processes the audio, and the board that drives the lamps is tucked right next to the disk up front) and wires that fly all around, but because they are divide on the schematic and color coded, it's not too hard to find your way around. On the main board under some masking tape was a cluster of capacitors, and these turned out to be the tuning cap and one of the bunch had one leg not attached - probably broken because of vibration at some point. Reattaching it instantly fixed the problem of the tuner being very far off from the right note, now it was only a little bit off on some notes, which I think should be expected given the aging of components over more than 30 years - some part date codes suggest a manufacture date for this tuner around 1974. The first fix is an easy one!

I decided that the tuner would be much more useful with an internal mic, so I found a spot on the front place where you could add it, looked through the parts bin, and put together a little circuit. A switch connects the mic to the input line (if it were located differently, you could switch in the input or mic, but that would have required more cable and everything going right by the high voltage lamp driver board), then a small electret microphone is biased by a couple of thin film resistors and is powered off the 20V rail from the audio board. A couple holes in the front plate and a little bit of assembly later, it fully works and shows up well on the tuner's screen. Not as nice looking as some options, but plenty effective. I used a shielded cable for the signal and ground and the original design uses one to the input jack, but when I went to attach it to the jack, I discovered that their shielded cable used a foil shield which wasn't soldered to the jack, but just wrapped around. The jack was looking dirty and the cable going to the board needed to be replaced, so I just swapped all of it.

At this point, I thought I was done, but in giving the motor a second shot of contact cleaner, I noticed a slight tingle touching the front panel of the unit. I brought it upstairs (was in the basement) and tested again with no tingle, but hooked the multimeter between the chassis of the tuner and an earth terminal on a function gen, the chassis was at 60VAC. That potential was very, very low current, one microamp on the same meter (which is also one least significant digit), but it was enough to be felt, so I wanted to fix it. Reading around, I checked the capacitors on the primary and secondary sides of the transformer and while they measured well, one of the large filter caps on the secondary side had electrolyte bubble up from one terminal when testing it with the multimeter... so it needed to be replaced. I ordered up a proper three wire earthed plug and two replacement filter caps. Earthing the chassis was simple because there were already a few options as tie points, and replacing the caps meant trying to figure out how to hold them in place, but was quite easy to wire up. That eliminated the voltage on the chassis and prevented the incoming failure of those filter caps.

Calibrating the tuner:

I actually did the calibration before finding the 60VAC issue, but only because I had thought I was nearly done before I felt that tingle! Calibration of the unit is done with 12 potentiometers on the motor control board, one for each semitone of the scale, and most of them were slightly out because of the age of the thing. Procedure for calibration is fairly simple, but you have to have the wooden case off while it's powered up, so you do have to be a bit careful.

First, you feed a reference tone into the input. A simple sine wave will do, but any completely stable, completely accurate signal will work, and work out the math for the frequency of each with this formula: frequency = reference tone * 2 ^ (half steps from A / 12). The reference the machine states is A = 440 Hz, and the number of half steps can be positive or negative, the resulting number will be different, but the pitch will be the same, just in different octaves.

Then, locate the adjustment potentiometer for the corresponding tone and adjust it with a screwdriver (or better yet, a nonconductive trimmer screwdriver) until the darkest pattern on the display stops moving left or right. I like to let it run for a few seconds to see if there is very slight movement, but it will take some trial and error to get the adjustment right, the potentiometers are fairly coarse adjustments.

Repeat this for all 11 other semitones.

Since the board doesn't mark which adjustment corresponds to which note, I wrote in sharpie for each and included photos. It's not difficult to determine in testing, but it's handy to know in advance. It's also worth being absolutely sure that your pitch vernier is centered exactly at 440 Hz for calibration, as you can see in the earlier picture, my first full calibration was done 7 cents off until I realized it wasn't set right.

Now I've got myself a working, calibrated, vintage strobe tuner. The original spec list it as accurate to 1/3 of a cent, which is about as a fine as a person can hear and a bit better than my normal electronic tuner. There's a little bit of noise from the motor (which matches the pitch of the note you're set to!) and it's large for a tuner, but it's a well made bit of gear and a useful tool all the same. The visualization of a strobe tuner is definitely an improvement vs. your standard needle tuner to me.

December 6, 2016

Not Your Average Nixie Clock is just what it sounds like, a nixie clock with more functionality than just a standard clock. This 10-tube display reports time, date, temperature, humidity, and pressure and can be controlled directly over serial to display anything that the tubes used can display. The clock uses a single Arduino Nano to run the backplane with all of the sensors and controls 10 display driver boards which each run a discrete ATMega328 processor to drive a single tube.

Update! 4/4/2017

Another small update to fix a couple of quirks. I noticed that very occasionally, the clock would display 100.00kPa as the barometric pressure, but added an extra space before the number that misaligned the units and didn't display them. After some considering and digging around, as well as witnessing some properly formatted 100.00kPa displays, I found out the issue - an odd rounding error with the way arduino processes floating point numbers. The normal default is to display two digits of precision and round, so what was happening is that when the pressure was 99.995kPa or more, it would round up to display 100.00kPa, which is fine for accuracy's sake, but which meant the calculations to add leading spaces to get it positioned right added one too many until the value actually hit 100.00kPa. This is now fixed, and on other ranges where I never saw the problem, but where it should theoretically exist.

The only other significant change was in the calculating of the displayed relative humidity. Because there's no active ventilation for the clock, the interior (where the temperature sensors are) heats up somewhat above ambient. To fix this, I measured the outside temperature with a thermocouple and set a fixed offset assuming no forced air from an outside source. It works fine, but it means the relative humidity value read at the higher temperature is actually a ways off from the real one, and it measured about 6-7% low consistently. Rather than just add another offset and accept whatever error that made, I decided to convert relative humidity to absolute, then convert back to relative factoring in the displayed (adjusted) temperature. Unfortunately, there's quite a few variables in the calculation of relative and absolute humidity, so I found a formula with a set of constants that was accurate within about -35C to +35C and only requires the other humidity and the current temperature. So now the clock converts the sensor-read relative humidity to absolute humidity at the same temperature, and then back to relative humidity at the adjusted temperature. As a result, I can see an increased humidity display right in line with the offset I had measured, but which is calculated rather than just manually offset.

There were a couple of other minor changes and a couple modified EEPROM settings, but I also found that the RTC module kept extremely accurate time - the last time it was set to internet time from the computer was almost two and a half years before, before the backplane was even finished, and it was only 15 seconds off of internet time when I resynchronized it as part of this update. The updated code can be found on github!

Update! 3/17/2016

Daylight Savings Time in the US rolled around and I realized I never wrote anything into the code to compensate for it... so within a few days I had an update coded up to do just that. I also wrote in a handle to set the RTC module via serial (I originally used a separate sketch to set it, and I hadn't need to set it since I built the backplane), and modified the provided processing sketch to send the needed code. There was a bug that after a month or something of run time, the short press for the capacitive sensor stopped working (long press still worked), so I've swapped a variable type and added an additional check - I believe this broke when the uptime in milliseconds overflowed the signed long variable it resided in. All this should make the clock a more robust platform, but the testing for all the new code has consisted of about an hour of runtime, so if something shows up down the line, I'll tweak it and reupload. The revised code only effects the backplane and is uploaded to the GitHub page!

Original page:

Development time for this project is just about two months, and it totals almost 1400 lines of code and uses 473 electronic components by my count. It is intentionally overbuilt from what a clock would normally need to do and very similar functionality can be done with less, but I wanted to make some modular and swappable elements (every driver module is the same and be inserted in any order to drive any one of the four tubes). I also wanted to include lots of debug and status options that would be entirely unnecessary in a final product. I think the 10 vertical riser boards that drive the display look pretty nice too!

The backplane houses the main Arduino Nano controller which manages everything and acts as the interface to an external device. For sensors, it uses a DHT22 for temperature and humidity, a BMP180 for temperature (the two are averaged) and pressure, and a DS3232 RTC for timekeeping. It reads the value of a variable resistor to drive the NCH6100HV high voltage step up converter from with a PWM signal to control display brightness. Each of the 10 driver modules uses an ATMega328 with custom firmware to control 11 MPSA42 high voltage transistors and drive each pin of a 12 pin nixie tube - designed for Soviet IN-12 and IN-15 tubes in A and B variants. Each driver has a switch to choose IN-12 or IN-15 and detects the A or B portion automatically, and each driver communicates to the backplane processor through an I2C bus, deriving its I2C address from a resistor in the backplane to control ordering without having any difference in software. An aluminum bracket holds the tube sockets and tubes in place while an aluminum band around it which is electrically isolated from it acts as a capacitive touch sensor for a simple one-button input. Any tube can be connected to any socket or left unpopulated and driver modules can be inserted and configured in any way - the normal clock display won't work right with a totally different configuration, but the display can still be driven properly through the serial port in any combination.

I ran into countless problems developing it as I was working with several things I hadn't worked with before and because the scale was fairly large, but I'll run through a few things I worked through and how I fixed the problem, because it could be useful to someone using the same sorts of parts or general design.

The tube datasheets for the IN-12 and IN-15 tubes indicate a pinout and specify cathode and anode, but they are somewhat misleading. Pin one on the tube data sheet is actually pin 7 on the number written on the back of the sockets - which are intended for these tubes - and counts up going clockwise. What makes this more confusing is that you can actually power a cathode pin and ground the anode and still light the display... but for certain pins the entire tube will light somewhat instead of seeing a normal digit or symbol. It was a headache to deal with until I figured out just hooking up the socket leads in a different order made things act as I expected.

Making things work on the I2C bus seems straightforward, but it gets more complicated when you're sharing the bus with commercial sensors. Making sure the addresses don't overlap helps, but you also have to build in some replies to differentiate between types of things on the bus. It helped me to display the data that was coming back from the I2C scan, and then I configured the module code to reply in ways that didn't interfere with or get confused with other sensors on the bus. It's also worth checking the solder joints, with the pullups and the capacitors over the power, probing the connections could give incomplete information and early on I had a bit of trouble with some high-resistance shorts between the SDA and SCL lines that made the initial scan just lock up.

While I expected it going in, when I added the capacitive touch sensor, I was surprised at how much noise the tubes made. I originally used the socket mounting bracket as the sensor, but it auto-triggered itself when there were many tubes enabled (like in test mode where everything is running). While the sensor would increase in reading by a thousand or more when you touched it, if in some modes the noise was 300-400 and some it was 2000-2500, it would take some serious data analysis to determine whether it was actually touched, and you'd have to factor the number of on tubes and the lengths of the cathodes in use to eliminate the noise from the reading. Instead of that, I put a thin insulating layer on the edge of the bracket and surrounded it with another strip of aluminum, then grounded the bracket. This provided some noise isolation (not a huge amount since the tubes were still close and a straight shot through open air), but also increased the sensor value when pressed because of the close proximity ground.

Dimming the display was more complicated than I expected, after realizing the power supply module could be toggled with a logic level drive to the SHDN pin it seemed like a simple PWM would suffice. I got that PWM from an analogRead() of a pin connected to a voltage divider and a potentiometer, but I should have used a single turn potentiometer, the 10-15 turn one in place now simply takes forever to adjust the brightness of. You then scale down that value, factor in a minimum and maximum duty cycle to let the display be lit even at lower brightness settings, then invert it to drive an analogWrite signal. The defauly PWM frequency is 490Hz, though, which means an audible hum from your high voltage circuitry. Configuring timer prescaler bits you can go to 980Hz and a step much higher, but 980 is still quite easily audible and the only option was to go well above that and the 20kHz human hearing range, but the circuit in the power supply stopped responding at such a frequency. My solution was to go the other way, around 30Hz meant visible flashing, but 122.5Hz was much less audible and was still a fast enough signal to keep from seeing the flicker of the display. There is still some noise, but I believe at least a little is from the tubes themselves and would be impossible to eliminate.

Finally, right as I was writing the last few features into my program, I ran into memory overflow issues. The ATMega328 software doesn't really have overflow protection, so if you've got most of the SRAM used and you enter a function which allocates more than is available, it just reads or writes over existing data. I managed to get to more than 90% usage in the compiler before issues sprang up, but ultimately to get all of the serial communication stuff working properly, I had to optimize memory management quite a bit - unsigned ints instead of longs, bytes instead of ints (even in for loops), and surprisingly, reducing the length of Serial.print commands. As it turns out, returning a long string of text over the serial port actually allocates a good bit of RAM, so moving from returning "Invalid command" to "Bad command" saves a few bytes of RAM when you're running. I wanted the serial commands to be a direct user interface - no computer-side software and plaintext responses to queries, and I had to go over every line and swap for shorter synonyms or other tweaks to get more memory. When the memory was overflowing some of the symptoms included: entire lockups of the system, partial writes to drivers, garbled serial replies, missing received data, valid command strings being read correctly but then misinterpreted... memory problems are intermittent and hard to guess at a lot of times, so they can be particularly nasty to troubleshoot.

I made a short video showing the clock in operation and demonstrating some of the features:

Full source code and schematics are available on github: Not Your Average Nixie Clock on Github

December 7, 2015