Tube Curve Tracer design

[pompeiisneaks]

agreed, the more I thought about it, we could trace for a week and probably not use up that card. It's pretty small data just storing current and voltage and the like at a few significant digits.

We don't need .000000000001 or some crazy amount of accuracy and even that isn't very much data. Big data happens when you throw unicode characters or binary datastreams like mp3/mp4 etc.

~Phil

[R.G.]

You're also likely going to need to have some form of calibration for it, since the shunt resistors won't be exactly whatever the design calls for, and some means of testing the volt and amp readings to tweak things. It can likely be a software feature where you take the 'raw' readings and then adjust based on the known variance from true?

Sure. The only tricky part is the two high voltage channels that float on B+. And if you disconnect the real high voltage, you can feed a calibration current through the resistors and tweak the resistors in. I'll mess with some numbers. Likewise, with the plate, screen, and grid voltages, you can calibrate against known voltages to get middle of scale being really middle of scale.

Constructing the calibrators is tricky, but doable. I guess I can build some of those in.

I'm guessing you'll need some kind of sine wave input that you can vary, but that should be easy to do in software, no? I'm sure there are many sound libraries in most languages that would let you create a sine wave, and then vary the frequency as part of the 'test' to get the curves over the response range.

I was counting on it. I know the Pi has this, but I suspect there are 'duino sketches for it too. A trickier part is generating a proper grid signal, as that needs to be about zero to minus 75V for range. The actual sine-ness isn't all that important, I suspect.

Some testing would need to be done to ensure how MUCH data you can easily store. Gotta figure out if we can just use a local sqlite or berkley db or if we need a separate nosql db to handle the volume of the data it pulls. It may not be too big, though, since it is likely to just be a timestamp and some group of floating point data, not large sets of text.

Then there is the question of whether a database is needed at all. My concept is that a tube will trace out its characteristics at near-DC as well as it will with a slow sweep.

Curve tracers were originally built that way because the designers had only analog means to generate control waveforms. So the plate voltage was a linear ramp, and grid voltage was stepped, while screen voltage was a static parameter. Later curve tracers, especially for semiconductors, did the "traces" with short blips of intermittent drive to minimize the device heating.

With computer drive, you can set the screen and grid voltages to "DC" levels, wait a millisecond or so for everything to stabilize, then sample the voltages and currents, and store the readings. I see one data tuple as:

[tube ID Number][Date][Time][Vplate][Vscreen][Vgrid][Iplate][Iscreen][got one more channel, what goes here?]

So you total up the number of bytes to do one of those, decide how finely you want to measure, and start generating rows in an array. The instrumentation as I've envisioned it now can measure these quantities to 16 bit accuracy minus the asterisks and gotchas involved with all analog measurements to 16 bits. I think it's not necessary to generate a quadrillion data tuples to characterize a tube, even if you're trying to draw out the curves.

I think I mentioned this earlier, but this speculation started out as matching tubes, and thoughts about how to do that "well enough". Defining "well enough" is a Big Question.
{...break... I just figured out what the fourth single ended A-D input is - it's heater voltage}
I suspect that getting maybe 256 data points is fine enough for plate characteristics ala a curve tracer. It's certainly finer than my eyes can detect as flat segments between points, and curve fitting would make it even finer. Maybe the same would be needed for screen voltage, although I suspect by then we're off into the design of tubes, rather than selecting tubes. But it could be done.

The tester as defined now can run:
- emissions test, ala the old drug store test machine
- emission s test, the clever way, mapping emission (plate current) versus heater voltage with the grid open
- plate and screen characteristic curves and variation of such with heater voltage
- gm, and variation of this, with plate, screen, grid, and heater voltages
Actually, with an RTC attached, these can all be measured for variance with time of day and phase of the moon.

Maybe it's worth while figuring out what tests are meaningful, and letting these be "test runs" or some such. If you have a group of tubes, you might want to know their bias voltage characteristics, that being what tubes are usually matched for in guitar amps. OK, run the data collection per tube for "bias voltage", which is a set of tuples containing plate current versus grid voltage, maybe with plate voltage varied, maybe only one level. This set of data lets you pick a grid voltage and get out a set of plate currents per grid voltage. That set, sorted in a spreadsheet is a selector for the single point matching done by most tube pickers.

Another set of data might be gain matching around some point.

I could go on, but I think that actual curves may not be the best set of data out of this thing for the original purposes. They're certainly possible, but maybe not the best or only.

[R.G.]

First input side schematics. All the fun stuff happens here. All the measurements are funneled into two I2C device channels. Programmers might want to read the programming considerations in the TI specs for the ADS1115 converter chip for how to set the internal registers and adjust scale and such.

Now a little work on the dull stuff: power supply, drivers and so on.

http://geofex.com/images/Tube Tester Input Side.pdf

[pompeiisneaks]

makes perfect sense, also that data likely can just be json. Makes it easy to dereference in code. also pretty much the norm for standard data interchange nowadays.

~Phil

[R.G.]

Anyone recommend a good tube amp power transformer to use as the basis for the power supply? We'd want B+ to be on the high side, 450 or 500. Heater current doesn't need to be especially large, and a rectifier 5V winding would be useful. Should be cost effective as well.

[martin manning]

http://www.classictone.net/40-18066.pdf Has 660VAC CT w/ 50V bias, 6.3V, 5V, and 120/240 primary. $66.

[R.G.]

First cut at the power, high voltage and such.

http://geofex.com/images/Tube Tester Po ... Stages.pdf

[pompeiisneaks]

I actually really liked the idea of using an existing amp to provide the power and just create sockets you put in between the tubes and the amp, or is that maybe problematic for isolation or consistency?

~Phil

[R.G.]

It's a realistic way to go about it. I'm hacking on the connection into an existing amp now. I was just designing the relay connection inside the octal standoff to electronically substitute the tester's grid drive for the one the amp is trying to send, while preserving the ability to run the amp and sample the plate, screen and grid data as needed.

Using an existing amp is possible, but does require accepting some limitations. For instance - using an existing amp means you simply accept the B+ it has, not what you want it to be, and it means that you either have to tap off the B+ somewhere that's not in the tube sockets to get control of the B+ fed to an output stage, given that you want to run the more general case of characterizing tubes in general, not just in the amp.

I actually see a number of variants of the same data sampling setup. One has its own power supply, and can be used generally for auto-characterizing tubes. Another is to convert some particular amp into the measurement instrument, adapting the data tester to the power available inside the amp, and introducing some custom wiring to get to the amp's power. The least general is where you use the same data reading setup inside any amp with sockets extenders and cable, but this necessarily means you can only get at the pins of the tube socket itself, so you're stuck with the screen voltage inside the amp, the B+ from the amp, any cathode resistors in the amp, and so on. There are ways to be clever about getting the data you'd like, but it's more limited than a tester otherwise unencumbered by the rest of the amp.

Does that make sense?

[martin manning]

First cut at the power, high voltage and such.

A doubler off the bias tap would get plenty of negative voltage.

[pompeiisneaks]

Oh hadn't thought of that, I do guess it may be best to have a specifically set voltage B+ depending on the tubes you're testing, yeah so getting B+ where you want it for one tube isn't optimal for another type. Maybe the standalone is a better idea. At least for the first implementation.

~Phil

[R.G.]

A doubler off the bias tap would get plenty of negative voltage.

Yes, it would, given that the bias tap existed on the power transformer. When I reeled off the schemos, I was trying for as un-limited a setup as I could. Doing -450 and regulating it down was as handy as anything else.

This is involved in the thinking about the bias and grid drive. It's easy enough to get a positive DC voltage out of a Pi or 'duino, and sine waves. But then you have to make zero to minus um, 75V or so to bias and drive the grid. I've designed amplifiers before that could do that kind of output but the LMC6090 is too good. It's a fairly precision device that can run from any supply totaling 3V up to 140V, including asymmetric ones. So if I power it from +15V and minus 100V, it can accept a signal with a common mode/reference of 0V and an input of 0-5Vdc, inverting that to 0 to minus 60V or so in one stage. It's pricey, ($7) but is simpler to debug and set up than an opamp and a clot of other stuff to give it a big negative swing.

That was the thinking at least.

[pompeiisneaks]

WOW!
I have a pi2b v1.1 I would be willing to donate to the project. PM me an address.

cobalt

This arrived today cobalt, thanks!

I'll be playing with it soon. I already downloaded an emulator for my desktop and was playing around.

Cool beans.

~Phil

[pompeiisneaks]

Update, got an sd card, imaged it with latest raspbian, and found a good toolkit for UI. tkinter is a tk python toolset that lets you create UI stuff. So I'll be able to create all the code to talk to the pi in python as libs and then call the methods from the main UI app. Looks like things should be pretty straightforward once I build a prototype of the tester itself.

I also realized I put thi sin the wrong area, as I think this fits more in the PCB Design area than the general 'tech discussion' one, so I'll move the topic there.

~Phil

[martin manning]

Link to something very similar to what is being imagined: http://www.channelroadamps.com/articles/tube_analyzer/