Tube Curve Tracer design

[pompeiisneaks]

Yeah that could be doable. maybe I can hope you'll come up with the schematic for the device and I can do the plumbing to the pi etc. I know how to code them to flip the pins from 0 to 1 etc in arduino, I think it's likely just as easy for the raspberry pi. does that smaller pi not have hdmi out? If not I's probably just pay for the nicer one that does.

Edit: Maybe I should start this as a new thread and move the discussion about this to that thread instead of continuing here?

~Phil

[R.G.]

I do seem to have diverted the thread. It's OK by me.

The Arduino can read I2C devices OK, and I think it can save to an SDHC, so it could work. I just like the idea of the Pi being able to not only send to SDHC, but also send data by ethernet or WIFI. The Pi Zero W is my preference. The Pi 3B or 3B+ would also be fine. The bigger Pi's are about twice as fast, and have more I/O, but the Zero W (the "W" is for WIFI) is less than half the price (especially if shipping is included), and has HDMI out, keyboard and mouse, and quite a bit more.

I did a Pi HAT board for a friend that includes two slots for the ADS1115 that's my target A-D, so I know they work together. In fact, if you want to dive in, I'll send you a bare board in partial payment for the misery of UI software.

[pompeiisneaks]

I'll start the thread now so we can figure out as a group what works best. This started as a discussion between R.G. and myself on a different thread about tube matching.

The idea is to build a simple interface that's easy to use and uses the more common commodity hardware like raspberry pi etc for the interface to the curve tracer.

I'll migrate all parts of that thread here that were 'off topic' from the original thread.

~Phil

[pompeiisneaks]

Here's another specific quote from R.G. that I didn't want to pull from that thread as it was on topic but helps with the thread here as well:

Yeah, it's better to go micro-fine on matching. However, there is the problem of having things to match, as you note with "Wouldn't that be cool? ... When we're done dreaming...".

Here's different thing that's less of a dream. We have computers now. It's not really all that tough to make a tube matching tester. Why not set up a tube test stand with appropriate loading (which will vary a little from tube type to tube type, but is no worse than one amplifier output stage per tube type - maybe three or four) and some current and voltage sensors. Hall effect sensors with multi-thousand voltage isolation between the measured current and the sensor output exist, and can easily enough be set up to measure the plate, screen, grid, etc. currents on a tube being tested, with >100kHz responses. Voltage measurements are easy - use resistor dividers to move the voltages down into A-D range.

Modern PIC (and other uC family) controllers generally have 4-12 channels of A-D available, with sampling times easily able to capture sub-1kHz signals. It's also easy enough to feed the tube an AC signal modulated by a digital pot for amplitude, and to convert the output to digital as well. You'd also need a high voltage opamp to feed the grid bias 0 to -70V or so.

All that sounds fussy, but is probably sub-$100 in parts, exclusive of the output loading, which will involve an OT if you try to do a transformer loading. I think you might be able to use a simple inductor-resistor plate load and fake the tube being used single ended if you like. The whole setup could easily enough be run by a $20 Arduino or a $35 Raspberry Pi.

What you can measure with this (and a little programming ) is:
-Curve of gm for Vgk = 0 to full cutoff for DC conditions. Simply stepping the DC bias from 0 to cutoff gives you the full curve, not single point measurement, of the bias sensitivity of the tube.
-It also tells you screen current, as you're measuring that as well.
- AC gain sensitivity as voltage out/voltage in.
- internal "kinkiness" of the tube, by doing distortion analysis on the captured output voltage
- a whole lot of other things that I'm skipping just because my fingers get blunt from typing

Testing one tube at a time gives you some better idea of the tube's operation than trying to filter out the confounding issues of PI matching, and so on.

I've paper-designed this thing a couple of times, and always stopped before building it, starting back in the 2000s. I'm pretty sure there is at least one of these things available commercially, and maybe a DIY kit or so.

But in a computer era, getting data is easy.

~Phil

[pompeiisneaks]

Ok R.G. I'm game. Send her on over, I'll message you my address. I'll get a Pi when I can, may take a bit, but I'll start working on the idea of the code etc, because I have plenty of linux experience, I'm sure I can get a PI vm running on my machine at home to test the code itself in theory until I get the pi itself.

~Phil

[martin manning]

Sounds good, but it’s a Curve Tracer that is being described here ;^)

[pompeiisneaks]

Fixed the main title, and that should have made it right now, thanks Martin lol.

~Phil

[Synchu]

I can help with the software as well.
Can do Java, C#/.NET (preferred these days), JavaScript, C, VB and quite a few others that probably do not matter
Did some things in Python, can’t say I know it, but I’ve forgotten more languages that some learned (ever heard of Magic, Forth?), so can make my way through, if necessary.
UI is not an issue...

Niki

[tubeswell]

...
Hmmmm... I don't know why this didn't strike me before - you could build a sampling probe head into an octal-socket standoff so you could do the actual sampling for a tube inside a functioning amp. The grid supply would be carried along on the measurement system, so you could insert the sampling head. Hmmm... no, wait - you build two sampling heads, so you can use it in a push pull amplifier and actually test the output stage separately from the rest of the amp. That saves you from having to build the power supply, OT and other appurtenances needed that are not the measurement system. Of course, it still works with a test bed separate from an amp, too.

Dang. More design to do.

Bring it on!

[pompeiisneaks]

This has me pretty excited, I'd love to come up with an open sourced simple tool for this that people could build themselves at home for pretty cheap. I love the idea behind the others but man they're like 3-500 bucks.

~Phil

[cobalt]

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

cobalt

[R.G.]

OK. I guess I'd better get cracking on the schematics.

Let's do some actual high level design work now that we have the beginnings of a team assembled. The big questions to be answered are at least (1) What data points and derivative data/curves are actually useful in characterizing tubes for amps, and (2) what are the best ways to (a) display that data and (b) control the operations of the tester?

Well, OK, I guess there is the question of whether the tester needs controlled. I kind of see this thing having two main modes, a standalone tube characterization mode where the "controls" is one button marked [GO] that goes and collects all the raw data about tube #5237 and stores it off to be sifted later; and an interactive mode where the guy using it plays with the controls for some purpose I'm not all that clear on yet.

The data gathering mode produces a large quantity of data points that a back end display program can present as points, curves, etc., and make final matching suggestions or quality estimates from.

[martin manning]

I suggest doing some benchmarking using available information on the uTracer and eTracer.

[pompeiisneaks]

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?

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.

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.

Graphing it all could be done in software, or setup to export into a format that people could import easily into a third party software setup. I would love to load it into elasticsearch and see it in apps like Kibana or Grafana.

I'm sure I'll think of more, but gotta get coffee etc. ;D

~Phil

[Synchu]

Graphing it all could be done in software, or setup to export into a format that people could import easily into a third party software setup. I would love to load it into elasticsearch and see it in apps like Kibana or Grafana.

I'm sure I'll think of more, but gotta get coffee etc. ;D
~Phil

That's a good point. There are a bunch of libraries that can be used for visualization purposes in a web-based software (besides the benefit of not worrying for client OS, etc.).

An128GB SD card will get as much storage as one can possibly use for tube measurement and tracing purposes.

Niki