a nixie-based DIY audio preamp

[linux-works]

having been bitten by the nixie bug, I had to do a build with nixies in it.

I'm into building audio boxes and so the nixies would sit inside a DIY preamp (headphone amp, actually, but makes a good preamp as well):



it uses an arduino (my own design called 'LCDuino') and a relay r2r attenuator (also my design, delta-1 is the name) to give -127.5db thru 0db of adjustment in half db steps.

the nixie board was all hand wired:



using 74141 (russian equivs) and pcf8574 i2c port expanders to give me the 16 bits needed to display to 4 tubes.

volume pot is a motor linear pot that the cpu senses and sends atten commands to the relay board.  there is an IR remote (learning based) and that can move the motor pot; or you can twist the knob directly.  on the back there is a rs232 port and you can web-control this system, as well.

still not finished yet (front button panel not completed yet) but the audio part and controller parts are done.  full code base is about 17k lines of C code (a lot not being used in this build since the lcd display is not present).

I will have this with me at the local 'head-fi' bay area meet this weekend, if any locals want to come check it out (as well as lots of other unique DIY and commercial audio gear brought in by members).

[dannyf]

Nixie or vfd are nothing but tubes. An off-label use would be amplification with those tubes.

[sync]

Nixie or vfd are nothing but tubes. An off-label use would be amplification with those tubes.

How do you do amplification with nixies? They are gas discharge lamps.

[linux-works]

I don't think display tubes are meant for anything BUT display.

there's no grid or anything as a control element.  simply anode and a bunch of cathodes.

I'm sure he was joking though...

[daveshah]

I believe it could be theoretically possible, as they exhibit negative resistance like neon lamps. Whether it is actually possible is another question.

[N2IXK]

I can see a nixie being used as a cold cathode trigger tube (similar to 0A4 cold cathode thyratron), by using a digit at the bottom of the stack as the cathode, an intermediate digit as a trigger electrode, and perhaps biasing a few of the others as "keep alive" electrodes.

[NiHaoMike]

Any reason for the servo attenuator instead of a rotary encoder?

[c4757p]

I don't think display tubes are meant for anything BUT display.

there's no grid or anything as a control element.  simply anode and a bunch of cathodes.

Multi-element VFDs do have grids.

Hmm... maybe I should grab one and see if it will amplify...

[linux-works]

Any reason for the servo attenuator instead of a rotary encoder?

yes, lots of reasons.  first easy explanation is that there are 2 ways (at least) to control volume: in-band and out-of-band.  if you can 'go around' the main way (the knob) via an IR remote, you want to be able to keep them in synch.  if you adjust the volume with the handheld IR and you move the volume down, you want to be able to then use the knob and not have any surprises.  if the knob moves to the right position, then they both stay in synch at all times.

if you used a non-motor pot, they would be out of synch.

now, you can avoid that with a rotary encoder and I have some builds that use that.  the problem with them is that they don't show absolute value (they are not a proper 'valuator' user interface).  if you don't have a remote OOB method then the simple analog pot without motor is fine.

rotaries also need many spins to do the same work as a decent pot.  I can go lock-to-lock at 127db thru 0 range and it works fine.  can't do that with even very good rotaries!

it depends on what style you want.  I do like being able to look at a pointer on a knob and know that I'm halfway up or 3/4 up and that means something to me.  a pointerless rotary is useless for that and needs a bargraph on a display or something (which, on lcd-based builds, I do have).  on this build, there is not even an lcd bargraph and so without the 270degree rotation pot, you can't really know how far up the volume knob is.  yes, the numbers show that but they don't give as much a feel for the -range- that you are in.

long explanation, but a lot of thought did go into it.  there are 2 things I don't love about the motor pot idea: there is some 'lash' or 'play' on the shaft due to gears and motors.  it does not feel as good as a non-motor pot.  the other issue is that you can hear the motor move in very quiet rooms.  most people don't care about that, though; I bring it up as a possible down-side and no one seems to think its a real problem.

[N2IXK]

Multi-element VFDs do have grids.

Hmm... maybe I should grab one and see if it will amplify...

They will...

http://hackaday.com/2013/11/09/vfd-display-becomes-an-amplifier/
http://hackaday.com/2010/04/22/vfd-as-a-sound-amplifier/

[dannyf]

can't do that with even very good rotaries!

256 or 500 line encoders are cheap and widely available.

[linux-works]

do you have a source and part number for those?

what do you mean by 'cheap'?  I'm ok paying a reasonable amount but I have seen only 2 kinds: the dollar kind and the $100 kind ;(  not much in between that I've been able to find.

aside from that, with that many pulses, its going to be VERY hard to keep up with that, even as an ISR.  I know, even the arduino can't keep up and its annoying to over-run the rotary.  consumer electronics rarely keeps up and those controls can be over-run if you spin too fast.  I just don't like that.

the pot, otoh, just needs a fast a/d and that's simple for even the arduino.  I turn the knob as fast as I can and I sense no lag at all.  it *feels* good, and for a high end piece like I'm shooting for, that's a must.

[linux-works]

slightly better photo, with a red bezel lens I cut today on the laser:

[sync]

Beautiful! 
I like using a real pot instead of an encoder. A pot is much better for this IMHO.

[dannyf]

with that many pulses, its going to be VERY hard to keep up with that, even as an ISR.  I know, even the arduino can't keep up

Those encoders are used for motor control and motors probably run a little bit faster than your fingers can.

The isr latency is about 1us on the arduinos. So the fastest the Arduino can process before missing a beat is 1 million pulses per second. At 500 pulses per evolution, that's 2k revolution / second, or 120krpm.

It will take a lot, even for a bad programmer, to get the arduino or other mcus to miss such an encoder rotated by a human.

[linux-works]

have you TRIED what you are suggesting?

I tried using the most efficient running code I could find for the arduino and rotaries.  it just increments or decrements a value in the ISR and that's it.  can't get any faster than that.  and still, I can easily outrun even a slow encoder.

I don't think you've tried it and I'm quite sure its not do-able to the extent you suggest.  but I'm willing to be proven wrong, if you can.

[dannyf]

have you TRIED what you are suggesting?

I have interfaced with encoders for motor controls, typically 1024 lines per revolution ones.

I have never tried with encoders with AVR. But would shortly.

How fast did your code start to lose count?

[linux-works]

I dont' know the rpm limit, but I was using very affordable controls (20 or 24pulses/rev, not high res at all).  and yet, even with such a low freq, I was able to hand turn the pot knob so that the software was not tracking it fully.

I've seen some hardware accel chips to help keep a counter value accurate for rotaries.  never used one but would consider it.  I really hate losing events!  it gives such a cheap feel.  and every sony, panasonic (etc) home theater system can have its main vol control knob overrun, too.  so its a very common problem.  same in car audio with the widespread use of rotaries.

what I was thinking about is a dedicated hardware counter that uses shared memory (of some kind) so that no cycles are needed to read the value from the memory (or port), from the hardware device.  the cpu would just get an instant snapshot (on demand) from that shared memory port and the click counter device would never even know its being scanned by a cpu.  that's the kind of concurrency that I could get behind!

[dannyf]

Here is a 16Mhz atmega328 reading an encoder at 10us per pulse. The pulse count is shown on PORTB.

5 lines of code, entirely executed in the isr, and no optimization of any kind.

Yes, it is very hard to code your arduino (or any other half decent mcu) so it would miss a count from an encoder rotated by human fingers.

[dannyf]

With minimum effort, I can push my code to read 200Khz + pulse trains.

20 or 24pulses/rev

That translates into a 200K / 20 * 60 = 600Krpm.

If you could rotate your encoder that fast, it likely would have disintegrated way before reaching that kind of speed.

[linux-works]

are you USING the data or just incrementing/decrementing it?

if you do anything with the data, I still don't believe (yet) you can process the data and not lose samples.

I'll have to do a test to see if the ISR can even keep up.  I would like to have the option to use an encoder but only if it does not drop counts (ie, the controller dropping samples, while doing actual application work WITH the samples).

[dannyf]

if you do anything with the data, I still don't believe (yet) you can process the data and not lose samples.

I am sure you can answer that question if you know how interrupts work.

[linux-works]

if you have parts of your main code that also need to run atomically, you surround them with 'dont interrupt me' and if that takes too long, you can lose count in the ISR.

its not always 'interrupt mode and user mode'.

anyway, I just was not able to get it to be as smooth as I wanted.  if I didn't use a state-change feature on the arduino and had to poll for the encoder pin changes, it was super easy to over-run.  I wanted  to have 2 encoders and one was ISR based while the other was poll based.  the poll based one was totally unusable and I gave up on it right then.  that left me with the ISR-based one and I continue to use that today as my main preamp.  and I don't do much with its knob, as I tend to do most of my volume adjustment with the IR remote.  the knob is more secondary for my own use, but if I was considering the knob to be the primary, I would still choose an analog a/d sensed pot as the valuator.  I've bounced back and forth between them (and also buttons) and the rotary was always the last one that I preferred.  the only times it won was when the part, itself, was superior to the others in the test.  if I used a crappy pot and a really good encoder, the encoder started to look better.  but put in a decent feeling pot and the pot wins hands-down.

UI is very personal and the quality of the part matters as much as the architecture behind it.  you put the best of each together and pick the one you think feels the best.  that often makes the pot the better choice and those that I've demo'd this to usually agree, as well.

[dannyf]

if you have parts of your main code that also need to run atomically, you surround them with 'dont interrupt me' and if that takes too long, you can lose count in the ISR.

That sounds like holding a low-priority, slow process over a high-prority, fast process (the isr). Exactly the opposite of what you should do.

Generally, you should try to program without disabling the interrupts - there are some processors where you cannot even disable the interrupts. Atomicity can be maintained via other approaches, like double reads, repeated execution and / or shadow variables or flags.

If a 16Mhz mcu is losing pulse count from a human-powered (20/24 line!) encoder, you are doing something beyond seriously wrong.