Quick test in uTracerJS missing the set grid voltage in results file

[Never Mind]

Quick test is a powerful way to match tubes.

Today I was matching with quick test a box of 6P43P-E tubes for a amplifier design I am working on.

When I went to review the results file I could not find the value Vg was set in each result entry.

See the attached file "6p43p-17 uick test.csv" for the results.

Note that the set to Vs is provided two times in the file.

I wondered if one of the Vs entry's should in fact be the Vg entry

The set to Va is provided one time.

The set to Vg is absent.

I noted that the set to Vg shows up nicely in the log file so uTracerJS knows what Vg was used in the quick test.

See "log-6p43p-17.txt" that I attached.

Also attached is screen shot of the setup in uTracerJS file "6p43p-e uick test.png"

Did I miss something here as to where Vg is in the quick test results file?

In my use case for low distortion I need tubes matched for both Vg and S (mA/V) while operating at the same  point for Ia, Va and Vs.

As S varies with Ia to find matched tubes for S you must measure them at the same Ia. To insure the same bias current flows though each tube Vg needs to match when Ia matches.

Having Vg and S  matched output tubes can drive second harmonic distortion down to very low levels in a well balanced P-P design. 

Having Vg and S match at the same Ia also helps insure pairs of tubes enter clipping as close as possible with the same drive voltage.

So I run the quick test while iterating Vg until the target bias current for the design is reached.

Then I save the tubes data file to allow it to be exported to excel to allow a batch of tubes to be sorted based on Vg and S for matching. 

You then pull pairs that match in both Vg and S.

However after testing about 12 tubes when I reviewed the data saved from quick test I could not find the grid voltage used in each saved test result. This made the data of no use as I could not sort based on on Vg and S.

It would be very nice if Vg was added to the results file.

As a aside... 

It would be wonderful added functionality (for some future day) if the quick test software could first step around the set Vg through a range of Vg voltages to find a target Ia. The initial stepping of Vg looking for the target Ia would seem similar to the current functionality used to step Vg in the current quick test code.

When the new target Ia was found the current quick test code would then run based on the newly found target Ia.

That would save iterating Vg manually making quick test faster and more accurate and a superb matching facility.

Bob J.

[Ihor]

Hi Bob, 

Thanks for the feedback. Indeed, apparently I made some changes there long time ago that broke output of that voltage to the log file. I now fixed it, so please download the latest version and check. Also the header line in that qtest_report file was very old, so now I also changed it with correct labels but to see that you have to erase your old qtest_report.csv file.

The second part that you mentioned, if I understood it correctly, that functionality is already implemented in uTracer for actually couple of years. Another user at some point asked for an option to set Ia and get the corresponding Vg for matching tubes. I attached the screenshot. Let me know if that's the one. You have to select that option ((3) pentode...) set Va Vs (and Vg approximately) and then also the desired Ia in Ia_nominal field. Then uTracer will automatically find the optimal Vg.

 

[Never Mind]

Ihor

Great and thanks for the update. I now see the Vg in the quick test data file.

It is really nice to now have a header that labels the data in the quick test data file.

I do still have a question on the file formatting and how best to import into excel.

I find if I simply open the CSV file with excel I get a formatting mess. 

The mess results using a old excel (97) or a new office 365 version.

See attached screen shots. "old excel-97 CSV open.jpg" or "new excel open CSV.png"

In the new excel 365 there is a utility to "fix" the formatting. I gets you part way there.

see "new excel result of data format.png"

The method I have found that works 100% is sort of a kluge.

Step #1 Rename the file to "qtest_report.txt"

Step #2 With a text editor manually remove the carriage return line feed inserted before each line with the screen voltage data.

See attached file "qtest_report.txt"

Step 3 Import the TXT file to the old excel version (97) as tab delineated with duplicate tabs suppressed. The old excel lets you manually specify these details.

The result is a perfect import of the data. 

See "old excel-97 CSV renamed to TXT return edited out of data file.jpg"

However this is a complex process to import a data file and I hope there is a faster simpler way.

I know this is a excel issue but hoped you may have a hint as to a better way to import this data.

In the mean time I am good to go using my kluge import method.

Thanks again

Bob

[Never Mind]

Ihor

I tried  "option ((3) pentode...) set Va Vs (and Vg approximately)"

However I did not get what I expected.

The plate current is very high at 119mA, not the 34mA target I set to.

Vs is very high at 331.85V and not the 250V I set it to.

What am I doing wrong?

[Never Mind]

Ihor

I did a bit more testing with "option ((3) pentode...) set Va Vs (and Vg approximately)" .

I noticed that if the screen and anode voltage are set to exactly the same value then it seems to work correctly and the resulting Ia is close to the target value.

So matching with Va and Vs set the exact same voltage quick test #3 seems to work fine. Good for a UL design.

However if the anode voltage is set at all above the screen voltage then quick test seems to use the anode voltage for the screen voltage set value in testing.

The  result is then Ia at a very high value, no where near the set target Ia.

So not so good for a pentode mode design where Va is higher then Vs.

[Ihor]

I do not think many people used that Append quick measurements option before, so now I slightly redesigned the output and now it is really a CSV, so you can jsut drop it into excel and it will create a nice table. Before using it, delete the previous qtest_report file. It also saves the time to the table when each measurement was taken. The new version is on the website. 

About the type (3) measurement (getting Vg), I will take a look later this week. There might be something with the code. I implemented it initially in C++ for the ESP32 and it was correctly functioning for the person who asked for it. Later I rewrote everything in javascript for desktops. While adopting that part of the code I have never actually tested it in real life. At the same time, I also adapted the code for the quicktest which has about 80% overlap with that other code, and that one works without problems:) I will keep you updated. 

Cheers, 

Ihor

[Never Mind]

Ihor

I rechecked the quick test file format output on the latest version and all I can say is it is perfect.

The date/time stamp is a nice professional addition. I wish all measurement software did this.

I particularly like your YYYY-MM-DD date format as is sorts correctly in software. Nice touch.

See attached screen shot.

Thanks again.

BTW

If you want a software tester of any uTracerJS functions you think need testing I am happy to run a few test cases for you. Let me know.

I know testing can really eat time and I am happy to help make uTracerJS more solid if I can.

Take care.

Bob

[Martin Manning]

Hi Ihor, I'm trying to play along here and I do not see the QT measured data in the csv file, just the setup. I'm looking in the uTracerJS directory, Data, at the file named qtest_tubes.csv. This is on my MacBook as usual.

[Ihor]

@Bob, 

Please download the updated version, I added a bit better debugging and caught one type which was causing your problem. Actually all the steps were good (14 out 15) and only in the last step Va was applied to Vs, which was wrong. So now everything that you did should work just fine and give you the right Vg for the set Ia. As I mentioned, it is good to do some simple quicktest before to know approximately ranges, even thought the method is automatically searching, it can take some time or run out of the range. basically uTracer starts with the given Vg and with the step_inVg (which is also specified in the menu) tries to "bracket" the set Ia. The step should not be too small and also too large, just reasonable, for pentodes 1-2V should do the job but I have not experimented myself :)  

@ Martin

When the quick test is done, one can press the button Append to Report and then in the folder Data a new file will be created, qtest_reposrt.csv If you have it already there, please delete, because the new version uses a slightly different format. 

[Never Mind]

Martin

I think you may still have a older version of uTracerJS as I do not see the newly added date information at the end of each entry.

Take care

[Martin Manning]

I had downloaded the new version, twice! Apparently what I was missing was deleting the old .csv file, after which a new file qtest_report.csv appeared. Seems to be working now, thanks. 

The data record is already long, but it does not include the percent of nominal figures, which would be useful for sorting and matching. Easy to add a column and calculate that in Excel, though.

[Never Mind]

Ihor

I just tested the new code with quick test type #3.

As you said it now seems to work as expected.

One minor detail of test type #3 is if the Vg tolerance is left at the default of 10% the error in matching the target for Ia is rather large for me at about 8%.

I can almost always now hit less than a 5% error in Ia in two tries manually using the type #2 test.

I admit I now have  some practice at guessing the next grid voltage needed after running over 20 tubes today.

Setting the Vg stepping value to 5% in test type #3  gets one much closer at under a 3% error from the target Ia value and that is close enough for me.

A stepping value of 5%  does not seem to affect the accuracy of the other calculated values.

See the attached data file " qtest_report test-type 2 and 3.xls ".

As well for some reason a number of the calculated parameters are not displayed when the type #3 test is used.

They are however all recorded in the quick test report file. I wonder why? 

No big deal as all the data seems saved in the quick test data file in all cases.

[Ihor]

Hi Bob, 

I updated the version once again. Now I added a bit of debug there so if you could run #3 for one of your tubes for example with Vg step of 1V and 5V or so, and share the log files, I could see if the other way of estimating Vg works better. In my simulator (so ideal repeatability) that automatic search works flawlessly. Measuring real pentodes probably has a problem with repeatability of the measurements but also some nonlinearities, which I still take into account but probably not enough. I can take a look at better approximations at some point. Here is how my test setup performs:

http://files.smal.ws/v/BDzO7K

About measuring other parameters, I remember that when that user asked me to implement that #3 functionality, he mentioned that the only meaningful parameter in that case is Gm, which I would also agree as for pentodes ra and mu are useless to measure. Gm is also very easy to measure while searching for Ia_set. For other parameters one has to acquire other points in the Ia-Va space and I did not want to have it in that part of the code. So the easiest is to do the search with option #3 and then get that Vg, set it as new one and run #2 to test the pentode and measure all the other parameters. 

@Martin, 

Indeed it is possible to compute and save the % in the report file for each tube, but most of the time the nominal values are not specified, at least I barely set those, so in the end those columns are a bit useless as well. I also barely pay attention to the measured % because it is more important to know the mA but that might differ per application. I can try to add it but then it will also change the file format for other users. Probably it is good to think if there are other features/values that can be added there, so I would do it in one go.

[Martin Manning]

No worries Ihor, I was just imagining what I might like to do if I were sorting and matching a lot of tubes. It's fine as it is, and anyone wanting to sort and match can easily use whatever criteria they like by creating it in Excel.

I have tried the other QT types and they are working fine. I noticed that one can get different results depending upon the Adjust Va/s setting when doing the type 3 QT. It hits the target Ia nicely with the adjust voltages left un-ticked. Personally I think I prefer to use the type 2 test and adjust to nominal voltages, with the differences between test articles showing up in the Ia, Is, and Gm..

Re the serial/parallel acquisition, I see the following difference in the anode and screen current plots at high current and low voltage, which likely due to the peculiarities of the uT3 circuit and/or differences between the anode and screen channels at those conditions.

 is 

[Never Mind]

Martin said " one can get different results depending upon the Adjust Va/s setting when doing the type 3 QT. It hits the target Ia nicely with the adjust voltages left un-ticked "

I too noticed that the values for Va and Vs and Ia could  wander in previous versions of the type 3 test.

Ihor 

Your last version from yesterday afternoon I see a major improvement in my testing.

It now hits Va, Vs and Ia right on the money basically every time. I set adjust voltages ticked for best results.

This last version of the Type 3 test for me removes any advantage to sticking to type 2 testing and manually iterating Vg to reach a target Ia.

This new type 3 test hits the Ia target faster more accurately for a target Ia than I can do manually irritating Vg.

I also now holds exact values for Va and Vs .

I am going to use the the type 3 version for the next batch of tubes I need to match and see how it goes.

Attached are the log files and CSV data files as requested as well as a screen shot of the setup.

Note  " 6p43p-e Quick test-19 21-23 5-10PERCENT.csv" file.

See in this file how Ia results now comes within a few 1/10s of a mA to the target Ia with Va,Vs right on value even as the starting Vg is set further off the correct value as in the last two entries.

Thanks for this update. I will speculate this is now one of the most capable matching software for tubes out there.

The next batch of tubes I run I will send you the data file for your interest so you can see how it does on a larger batch.

Thanks and take care

Bob

[Never Mind]

Now for something completely different.

Thought I would put the latest uTracerJS software to the acid test.

So here it is. 

I used a 6P36S tube as these things are monsters from Russia and pretty different from most tubes.

Figured if quick test worked on these that was a good sign for any tube working.

A 6P36S can easy output over 1 amp at low voltage. This one makes just short of one amp at about 80V. These and others like them is why I keep harping on low voltage high current accuracy.

LOL so even a uTracer6 can not measure all these can do. Going to need a Utracer6+ some day.

So first I ran the quick test. 

It found the target Ia (120mA) perfectly .

It also and did a pretty good job of keeping Va on target considering on a uTracer6 Va voltage droops a lot at higher currents.

Note S (mA/V) is a whopping 18.5. These tubes really like to oscillate during test needing lots of ferrite and resistance to keep the uTracer6 sane. Lots of fun.

See attached screen shots and data file.

Then I ran a sweep just for fun. Incredible plate current and pretty good if not perfect linearity. 

Four of these will make something interesting some day when I get to it.

[Ihor]

Good to see that things are working as expected! 

Also Martin's plots for the parallel and sequential acquisition look very well match to me, there are indeed some small minor differences, but most likely they are due to hardware "behavior/stability", which is slightly different for two modes. Sometimes even re-running the same sequential procedure second time will create some discrepancies between the measurements. 

[Never Mind]

Ihor

Oddness in the value of Ra written into the quick test file with test #3.

Today I was matching a batch of 6AK5 small signal pentodes used for low level amplification.

These types generally have poorly controlled Ia for a fixed Vg1 and so are rarely (never?) used in a fixed bias arrangement and is generally is used with either cathode bias or a current source to set the anode current to a know value.

Data sheets often will only state the Va, Vs, Ia and Rc values giving no value for Vg1 as use with fixed bias use is not suggested.

In testing these tubes the type #3 test is ideal in that it finds and sets Ia regardless of Vg1 needed.

As these tubes are used primary for amplification one wants to have S (mA/V) and Ra for know values of Va, Vs and Ia.

Vg1 is useful but not a primary target like in power pentodes.

With S and Rp it allows the tubes to be selected for matching in-circuit gain.

Another good use of this type of pentodes is as a current source as the anode current on some types is almost constant over a wide range of Va.

In use as a current source a high Ra become a figure of merit of the current source, the higher Ra the better the current source.

Looking at the data sheet for the 6AK5 the anode current when set to 3mA hardly changes for a anode voltage from 50V to 250V suggesting a very high Ra.

Again knowing Ra is needed to select a pair of "good" current sources.

I noticed that in using Test #3 Ra is not displayed on the WEB interface but is written to the quick test file, I thought ok this fine.

However what I noted is the value for Ra does not change if one intentionally changes the target Ia in the test parameters. It should.

It seems clear the values written for Ra are not always valid.

Here is a work around that produces valid values for Ra every time.

Run test #3 to get the correct value of Vg1 for the target Ia.

Manually copy the found value for Vg1 from test #3 into the set Vg1 box for test #2.

Rerun test #2. The correct value for Ra will then be written out in the quick test file.

I am not sure why the values for Ra in the quick test file are not updated when Test #3 is run.

Take care

Bob

By the way

Test #3 does a perfect job of finding the target value for Ia with this low current tube. 

So from the huge 6P36S to the little 6AK5 your code for finding the target Ia value is very robust it would seem. Impressive.

[Ihor]

Here is a work around that produces valid values for Ra every time.

Run test #3 to get the correct value of Vg1 for the target Ia.

Manually copy the found value for Vg1 from test #3 into the set Vg1 box for test #2.

Rerun test #2. The correct value for Ra will then be written out in the quick test file.

Indeed, this is the procedure that I mentioned earlier as well, because the #3 test was implemented as a shorter version of the full pentode test, where it is only necessary to measure 3 points to get Ia and Gm. In order to measure ra and mu one has to acquire a couple of extra points. Now, in order not to justify those limitations I actually combined those two tests, so not when one runs #3, under the hood, the required Vg is found and the full test #2 is run in order to compute all the required parameters. 

a small screencast is here:

http://files.smal.ws/v/BclBdv

I have not uploaded the newest version because I still have doubts for one part. As you can see in the video, when the Vg is found (displayed in Vg measured), it is automatically set as "Vg center" and will stay there after the future page updates. So it looks logical, but one looses the information what was that initial value for the search. If one tests multiple tubes probably it is good to start with the same initial Vg for the search procedure, than starting from the Vg values from each previous tube. Let me know if there are any good suggestions here. The report file will contain only the found Vg for which all the other parameters are valid.  

[Never Mind]

Ihor

Re:" If one tests multiple tubes probably it is good to start with the same initial Vg"

I have to agree with you this seems more correct. Is coding it to preserve the initial value of Vg1 acceptably complex?

What I am doing is use the data sheet value for the starting Vg1 value assuming real parts should be a statistical spread from the data sheet value.

If one uses the last Vg1 value tested for the next test you could end up with two opposite ends of the average spread coming one after the other resulting in a far off starting value for Vg1.

This does sightly alter the accuracy of the found Ia however it is only a small Ia shift as your code does so well at nailing the correct value. 

I have been watching for this in testing a batch of tubes and the one time I saw this issue happen I manually stepped in and corrected the starting Vg1.

A another issue is you loose the "history" of how far each tube is from the data sheet value. This is always nice to know.

What I can do is simply put the data sheet value for Vg1 in the tube's name field (now that we have more room for naming).

So this seems a small issue.

My workaround also does not keep the Vg1 starting value and I would have to reenter it every time.

Bit tricky to remember every time and I am not 100% sure yet it's required as the code does so well at finding Ia even if the starting Vg1 is far off.

However it "feels" better if the starting Vg1 for test #3 was consistent.

What if the variables for the setting of Vg1 were made independent for test #2 and #3? Does this help?

By the way ....

I have also tested a few high slope triodes the 6S3P-E with S=19 mA/V today. This is a very high slope triode!

Manual iteration of Vg1 to get the data sheet Ia value is tricky with a very high slope tube.

Then I realized that test 3 should work on triodes finding Ia as well as pentodes as the math really is the same.

And indeed test #3 works perfectly to find Ia on triodes.

This however using test #3 on triodes opens a can of worms in the test naming.

The naming of test #1 triode ,#2 pentode and #3 pentode leads you to believe they are more limited than they are.

Test #2 and #3 works perfectly on triodes, you just ignore all the data about the screen.

So now I am using test #3 to find Vg1 for a target Ia on triodes before quick test. Great!

Have to say I am having a a lot of fun with the latest version of utracerJS.

Thanks again

Bob

[Ihor]

Indeed, that was my feeling as well, that it is better to have one fixed (start)value for Vg for all cases. Now I implemented it like that. 

That test could be used for triodes as well, as it was only looking for Vg for which Ia is equal to the set value. After I made that #3 test complete (so all the parameters are computed because under the hood the "pentode" quick test is automatically run afterwards) it would not be possible to run something like that for triodes. In the end, I implemented one more test #4 specifically for triodes. So it does basically the same, searching for Vg and then running the full quick test, but now one should understand what one does, especially with the double triodes (only the one that is connected to Va will be used for searching for Vg, the other will just get Vs and Vg applied, but all the parameters for both of them will be measured at that Vg. Ideally an option can be programmed which "anode" voltage source to use for those double triodes but it is just complicating the code, and I am not sure if that functionality is useful for more than 0.1% of the users :) Right now the solution would be just to swap the "anode" and "screen" wires. 

Now I also added small "help" blocks, indicated with "?" next to those fields, so probably for the future it will be useful to have such pop-up like help/manual in different places instead of having a separate document. The new version is already on the website.  

[Never Mind]

Ihor

I will give it a run tomorrow morning. 

Xmass is coming very soon so hobbies will need be placed aside for family by tomorrow afternoon.

I had not considered dual triodes. I never thought about matching them but yes some must need to do so.

Using the tube's anode connected to the uTracer anode lead as the "reference" Ia seems quite intuitive and perfectly fine.

The usefulness of the current quick test is now far greater than I expected. 

It allows 20 to 30 tubes to be tested and sorted very quickly, with accuracy and solid written records. Very useful in the lab.

Before I would use my old AVO mark iii for a quick test to judge the approximate figure of merit of a batch of tubes.

Being analogue the AVO gave you Vg1 vs Ia as fast as the filament warmed up. S (mA/V) took a few seconds longer.

The numbers were close but nothing on Ra or u and you had to remember to write it all down correctly.

My AVO is mostly now used to "cook" new tubes that are suspected as a bit gassy.

For reasons I do not fully understand some tubes that have been unused for a very long time will perform poorly with the pulse testing of the utracer.

If that same tube is put in the AVO and run hot the characteristics on most will quickly return back into line with the data sheet within 10 minutes running on the AVO.

Retesting in the uTracer will then produce a normal test result. Perhaps I am mistaken but this seems a real phenomenon.

Take care

Bob

[Never Mind]

Ihor

Using a uTracer6 I did some testing of the new quick test #4 on 6S19p triodes. These are high current mid sized power tiodes with a low u of about 2.6.

The target Ia of 120mA was always found within a few mA.

I noted that the values calculated for u, Ra and S varied up and down by about 10% each time the same tube was run through the quick test.

I summarized this may be due to the very low u and that a larger than 10% variation of Va and Vg1 would be needed to gain accuracy in the calculation of parameters.

I set the variation for both Vg1 and Va from 10% to 20%. 

The 20% setting resulted in very repeatable values for calculated Ra, u and S on this low u tube.

I did however get a bit distracted during my testing by some large and strange variations in Vg1 for the target Ia between sample tubes I was testing.

These tubes were from a 1974 dated box of tubes that looked to be in the original packing suggesting these tubes has been sitting in storage for 50 years.

I did some full sweeps on a few sample tubes and found one that had a large loss in anode current compared to other samples in the batch.

The same tube showed higher anode currents for the same Vg1 at lower anode current levels.

So I placed this tube in my AVO and set it to run at about 80% of it's power rating and about 50% of it voltage rating for 10 minutes.

In the first minute the value of Vg1 needed to maintain a stable anode current slowly decreased in negative voltage.

There was some lesser drift down in the required Vg1 in the next few minutes. The required value for Vg1 remained steady for about the last 5 minutes of "cooking"

I then retested the tube in a sweep and the loss of cathode current had been corrected.

The attached chart shows the before and after "cooking" sweep results.

What does this suggest to you? One take away is tubes that have been in storage may need a short "cook" before matching results will have any useful meaning.

Have you seen similar to this with unused old NOS tubes?

I will do some more testing of other quick test functions in the next few days.

Bob

[Ihor]

Once I had a similar behavior with a Russian 6n23p, also measured by 2 different testers, but for a short time, so I have never checked is the cooking would help. I think the problems is that those are Russian tubes of "Russian" quality. I think with those the spread of parameters is always in the range of 10-20% by default, even with the highest "OTK" quality, which also barely means anything and depends on time, 50's 60's or 70's. Those tubes are cheap, so it is better to buy tens of them to get a couple of good ones (I see the local price for NOS is $1.5 per piece, for 6s19p, so I would be sceptical about them :)) ).   

The parameter measurements are indeed depend a bit on the "step" so the % in those corresponding fields. For larger gaps the numbers will be more stable, but jsut statistically, because we roughly compute the ratios, for example (i1-i0)/(v1-v0), but those v's and i's have the same error in the measurement, so when the difference (v1-v0_ for example is larger then the influence of the fixed error will be smaller. It is probably good to take a couple of measurements and see which one is true or stable. As long as you stick to one definition for a batch of tube, it should not influence their matching routing, as we are not intersted in the absolute values (and once again, absolute values for the Russian tubes is just something that I would never took seriously).  

[Never Mind]

Ihor

I saw the same issue in the past with a original in the box unused American NOS GE 6L6GB made in the 1960s that I found in a box of assorted tubes from a repair shop that had closed.

Initial testing show low emissions and after cooking on my AVO the tube then tested perfectly to the data sheet.

I put that 6L6 in a power supply regulator for my lab bench were it has worked fine for several years now.

So this is not only a Russian tube issue. I believe it has something to do with very long storage but am unsure what the exact process may be and why running them seems to correct the issue in many cases.

The Radiotron Designers Handbook of 1954 section 1.1 mentions about tubes characteristics changing when first put into service after storage.

"If a valve has been on the shelf for a long time, it frequently
shows a higher gas current, but this may usually be reduced to normal by
operating the valve under normal conditions, with a low resistance connection between
grid and cathode, for a short period."

A uTracer can not do this so one needs to take that into account it seems.

In my experience yes some batches of Russian tubes are worthless and I just toss them.

However some Russia batches match data sheet values very closely and tube to tube variation is very low.

I typically aim to buy about 30 pieces of the same date code at a time. 

Not so many tubes that if you have a bad batch and have to toss them all it will hurt but enough tubes to be able to match a good number of sets if the  batch is good.

The good batches of old NOS Russian tubes are in my opinion easily better quality than current production from the likes of JJ or electro-harmonix.

 I have found a fair number of defective tubes purchased new at steep prices from both JJ and electro-harmonix.

I also find the price of Russian tubes is driven more by what is a popular part number commonly "know" to be a good tubes for HiFi than any quality level a  tube may possess.

I prefer the challenge of using the the old less common stuff. As they are cheep I do not see getting the odd useless batch of defective tubes as a big problem.

Bob

[Never Mind]

Comparison of quick test between uTracer3 and uTracer6

Wondering about repeatability and accuracy I tested the same sample 6S19C triode using the quick test #4 on both a uTracer3 and a uTracer6.

I used the 6S19P as it is a lower voltage and impedance tube where uTracers tend to have less accuracy and repeatability.

I tested the same tube on the uTracer3 four times to look at test to test consistency within the uTracer3.

I then repeated the same test with the uTracer6.

The spread in results is small on the utracer3 and a bit wider on the utacer6.

This is not a huge surprise to me as the utracer6 has less than 1/2 the Va,Vs resolution of a utracer3 and we are testing at lower voltages in this test case.

I think however with both uTracers the current quick test results are good enough for most uses.

This testing does suggest that a dual voltage utracer6 may have some utility when testing lower voltage tubes to restore the Va and Vs resolution back to utracer3 levels.

I am going to think on how the theory can be can be tested that a increase in uTracer6 resolution will improve results without the ability to set the voltage range in the utracerJS configuration software.

You can easily scale Va Vs results from a sweep in a excel sheet but it is not clear to me right now how I could do scaling for quick test results. 

Perhaps the quick test results from a low voltage version of the utracer6 could be imported into excel, the Gm, u and Ra math reversed to original Va Vg Ia, test values, then scaled and then Gm, u and Ra recalculated to allow the spread over a number of quick tests to be viewed.

Some thinking is needed here and suggestions are welcome.

[Never Mind]

I tested with the quick test #3 10 pieces of old stock GE branded (made in Japan) 6CB6 tubes a small signal pentode using a utracer3.

I could find no data code on the tubes.

The consistency of results was very close suggesting that Japan did a fine job on quality control when they made tubes and quick test can calculate consistent results.

See quick test attached results file.

Note the first entry is at Va=300 and Vs=150 and a seed value for vg1 = -1V

The next 10 entries are with Va=125 and Vs=125 and a seed value for vg1 = -3V

Note how close Gm matches and Vg1 is very close in all but one case.

This suggests to me that the type #3 quick test is useful for matching batches of tubes.

The last entry is in triode mode (screen strapped to anode) Va=100 and Vs=100 and a seed value for vg1 = -3V

One caution with the seed value for Vg1 when using quick test #3.

The seed value for Vg1 is used to find the actual value for Vg1 resulting in the desired target value for Ia. 

The actual found value for Vg1 resulting in the target Ia is then used to calculate the tube parameters.

However the SEED value for Vg1 is used to calculate the Vg1 stepping value used in the calculation of the tube  parameters.

If the seed value of Vg1 diverges greatly form the found value of Vg1 then the stepping value will become much larger or smaller than expected as a percentage of Vg1.

In a extreme case the stepping value can become so large as to drive the tube outside valid grid voltage ranges. 

This seems most likely to happen testing high gain pentodes where Vg1 values in the 0.5 to 1V range are common.

Using the seed value to calculate the stepping value also has the result that Test#2 and test #3 will return slightly different results unless the seed Vg1 and found Vg1 are set to exactly the same value.

I am not sure that above is really a problem if one is aware of the issue and watches for a large divergence between the seed value for Vg1 and the found value for Vg1 during testing of batches of tubes.

Just to make this a tiny bit trickier is that the seed value for Vg1 is not recorded in the quick test data file meaning reviewing your data later will not highlight if a large spread developed between seed and found Vg1 values.

Take care

Bob

[Ihor]

Hi Bob, 

Thanks for very nice tests and reporting! It all confirms reliable functioning of the implemented method. 

Interesting that you found how uTracer can hang while switching the other devices on the same power line. It is good to keep that in mind. In my experience, every time I got those hangs I am pretty sure the problem was something else as it was happening just during multiple runs of curve acquisition while testing uTracerJS and Ronald's software. I could never reproduce those and also could not see the dependency with that I was doing. I have a feeling that some other users who reported hangs also had single unexplained and not reproducible encounters. 

About search procedures implemented in test #3 and #4, indeed in a practice, there will be some small changes depending when you start, and it is partially because of the error in the measurements and partially because of the "noisy" behavior of the tube (hitting it with slightly different Va because of the yTracers HV caps charge, which is measured with limited resolution of ADCs). The underlying mathematics of that search has no errors and completely reproducible. I added a small screencast that shows that:

http://files.smal.ws/v/ouF9Vz

You can see that starting from any voltage from 0 to -50 will result in the same Vg and computed parameters. In the screencast the underlying tube model is the properly implemented Koren's triode. So it is all about the measuring device and the DUT :) But to me, all those excel tables that you shared with multiple runs for a single tube looks more that perfect in terms of reproducibility, taking into account that after running those tubes in practice for hundreds of hours will for sure drift any matching pair apart :)  

[Ihor]

The simplest way to overcome those practical inaccuracies in measurements is to average. There is already averaging happening on the level of PIC during the quick test, but now as a test-feature I added the option to make 5 measurements of the central point during the quicktest average those before outputing the measured va vs, Ia and Is. All those values (5 separate tests) are also shown in the log window of the browser (in the screencase you can see how it is done with Chrome, with Safari and Forefox it is almost the same), see here:

http://files.smal.ws/v/rm2CSn

So, while running the quick test multiple times, one case see the spread of the values for Va Vs Ia Is taken exactly at the same point with the time difference of milliseconds. It would be interesting to see some measurements for real tubes :) 

The updated version is on the website, if it actually produces some useful results I will also modify the pentode test like that as well. 

[Ihor]

I just uploaded a slightly newer version where actually 9 measurements are made at the central point and the standard deviation is automatically computed and displayed in the debug console of the browser, so one does not have to use excel, but just immediately see the accuracy in terms of mean+/- standard deviation.  

[Never Mind]

Ihor said " The simplest way to overcome those practical inaccuracies in measurements is to average"

I agree completely.

I have found the built into the PIC averaging leaves me wanting on a utracer6 as the +/- 1 volt of resolution really affects repeatability below 100 volts on a utracer6.

The uTracer3 seems much better and I have not been troubled by data "noise" issues.

For data used in spice model creation on the uTracer6 I often now run the sweeps three times and average the results in excel to remove some of the data "noise" found in utracer6 results below 100 volts.

This is a excellent addition to the quick test and it will be very interesting to see what improvements it provides with a utracer6.

I propose to use the low voltage 6S19P triode where I saw considerable variation in results on a Utracer6 across several quick tests done one right after the other..

What i will do is run the same tube 5 times with the present revision of uTracerJS and then immediately run the same tube with the latest version you just posted.

The way my computer is setup I can select and run any of the last 5 or 6 revisions of uTracerJS without needing to change any installation details and all logs and results are kept separate to allow comparison.

Makes checking revisions fast and simple.

Your on screen debugging and logging is very cool. Such good functionality for improving the system. I am going to enjoy this function.

I will send you the quick test results and log files for the present uTracerJS version and the last version you just released.

This will be very interesting to see how the averaging provides improvement.

I am impressed by your software skills as evidenced by the fact that your changes are normally 100% clean on the first try and very well though out.

Some day I would love to learn what your "day" job is/was.

I wish I had met you before I retired as such skill I could always find good use for in the high teck design house I ran.

Take care

Bob

[Never Mind]

Ihor

Just wondering about  your utracer software model.

Do you model the limited resolution of the uTracer Va/Vs AD system or do you always calculate simulated AD results based on the resolution of the compiler math functions being used??

A uTracer3+ has a Va/Vs step size of 444.12mV and a uTracer6 a step size of 1.0448V.

So the uTracer6 has only 42.5% of the uTracer3+ resolution and this will have some effect on your simulation results.

At Va=50 volts and the uTracer6 +/- 1.0448V resolution a few mV of random analog noise at the AD input provides a peak-peak error of  I believe 2.0896/50 or 4.1792 %. That seems significant.

Just thinking

Bob

[Never Mind]

Ihor

Here is the data.

This is all the same tube with each test taken a quickly as possible to avoid tube drift.

Exel sheet shows older quick test and latest averaging quick test (yellow).

Note that the stability of Va is much improved on new averaging quick testing as we suspected it would be.

Also tube parameters are also significantly more stable and repeatable in Averaging quick testing.

Nice improvement.

There is a speed penalty for the higher accuracy (the price you must pay for repeatability ) so should this be a option?

Bob

[Ihor]

@Bob, 

Thanks for testing it and for the feedback! The results look good, in a way as they should. I attached your table with computed standard deviations. There is no difference in Vg estimates just because those multiple measurements are not taken at that stage, it is only during the actual quicktest for getting Ia and Is (for predefined Va, Vs and Vg). The spread of measured Va's and Ia's is nicely lower. Those numbers actually reflect the reproducibility of the measurements depending on the uTracers' hardware (so the errors in the process of setting the desired voltages and measuring the currents (through the voltage drops)) and variability of tube parameters in time (but that one probably way smaller). 

For the simulation and tests I use only the mathematical models of the tubes, ia,is =f(va, vs, vg), for example the Koren's triode model (basically the models from Derk's Extract Model document for SPICE simlulations). Those models fake the measurements and send them to uTracerJS either via fake/virtual serial port, or before, I used to have separate arduinos running different "versions" of uTracers, but again it is more about the communication and some responses in order to debug the webinterface or test some features and not to model or reproduce uTracer itself. Those adruinos could actually run with Ronald's software as well and log the whole communication for any type of test. That I was using to have 1:1 reproducibility of the Ronald's software as some of the parts are not documented in his logbook. 

In the latest version of uTracer, which is already on the website I added that option with multiple measurements to the quicktest tab (see the screenshot) so it is there, but indeed it adds to the acquisition time especially if the voltage sinking is high and the caps have to be recharged every time. For the standard cases, I thing the speed of acquiring is about 2-3 measurement per second, so going from 1 to 3-5 is quite reasonable. 

[Never Mind]

Ihor

The data shows the weak point in the utracer6 is the lack of Va/Vs AD subsystem resolution at lower voltages.

I wish Ronald had moved to the 12 bit version of the PIC series he selected for the uTracer6. The cost delta is very small and it should have solved the resolution issue on the utracer6 nicely.

A PGA for each Va/Vs AD to allow ranges could have been added. That would have cost more and been more complex to implement but allows the 10bit PIC to be used effectively.

Keeping in mind the Va resolution error occurs on both setting Va for a measurement and then measuring Va at the end of a measurement the Va resolution error occurs two times per measurement increasing the total resolution induced Va result error.

The data shows averaging of 5 Va samples in the quick test results in near 1/3 the variability of the Va voltage on the uTracer6.

This uTracer6 reduction in Va variability should bring a uTracer6 data stability up to slightly better than a un-averaged utracer3+.

I was never bothered with excess data noise on the uTracer3+ so this may confirm that my main concern with utracer6 data noise levels can be overcome with appropriate averaging when cleaner data is needed.

Tomorrow I am going to rerun the quick test on a utracer3+ to see what data noise levels result. Should provide some insight.

Perhaps some day your quick test averaging functionality can be added into the sweep function for the uTracer6. 

I know the PIC firmware has built in averaging but in past uTracer6 tests the PIC averaging was surprising ineffective in reducing Va data noise on a utracer6.

Maybe PIC averaging is only done on the Ia result and Va is not resampled?

Or perhaps the PIC averaging is only done on the result Va and is not done on the voltage setting of Va. This leaves 1/2 of Va's source of error untouched.

Your way as you check Va before and after each measurement in quick test both the setting and result resolution errors are being averaged.

It seem a good investigation to compare Va data noise levels versus various PIC averaging settings on a sweep.

I think I will run some sweep tests on the utracer6 and the utracer3+ to see the results.

[Never Mind]

Ihor

Here is the data for the uTracer3+ for non-averaged VS averaged quick test data.

I used the same software revision for this uTracer3+  quick test as used with utracer6 quick test for consistency.

Strangely in contrast to the uTracer6 there is no advantage to averaging quick test data with a uTracer3+.

In fact using averaged data with a uTracer3+ shows slightly less consistency in the results.

I do not understand how this can be. 

The results seem statistically invalid yet I did all the testing two times with very similar results of the averaged uTracer3+ data being slightly nosier.

Note the reported values for Vg1 for the target Ia are different between the averaged and non-averaged quick test version.

The non-averaged quick test Vg1 is 1.38 more negative for the exact same reported Ia.

This seems odd and was not the case with the uTracer6. 

I wonder if the Vg1 issue is due to the uTracer3's know issue with Vg1 voltage wander due to PIC ground bounce caused by the high currents supplied to the opto couplers used on the uTracer3+.

I am not sure this is possible as the grid voltage wander increases as you approach zero grid voltage and the 6S19P is operating at about -15 volts well away from zero.

As well this will be very dependent of how rapidly you are taking samples during the averaging process.

I admit I would have to run testing to confirm if this can be a issue.

Perhaps the change in Vg1 is due to higher levels of grid leakage current in the rather large triode being tested. 

The Utracer3+ grid circuit supplies progressively less grid current as the grid voltage is set to more negative values.

On a uTracer6 the level of available grid current at negative grid voltages is independent of the grid voltage setting.

When I first ran the quick test under the same setup values used on the uTracer6 the data I got was not valid. 

A concern was I noted if the uTracer3+ suffers a compliance error during quick no error message is displayed and you still get quick test results in the report file but the numbers are invalid

Early compliance tripping at lower Va voltages is a know uTracer issue.

Looking through the log is how I found the compliance errors.

I had to lower the spread of Va and Vg1 from 20% to 15% to get valid data as the uTracer3+ was failing on compliance errors at only 149mA.

Interesting data

Bob

[Ihor]

Thanks for the update! I will take a closer looks a bit later, but jsut to quickly comment before you might want to make more tests. 

It is strange that you get different values for Vg in both types of experiments, because there is not difference in the code at for finding Vg, there is not averaging used there, so they should be exactly the same. To me it means that the test conditions suddenly changed (heater voltage, heating of the tube and change of parameters and so on). Vg's that are found there should be exactly the same. 

I think to have a bit "cleaner" test, one can use #1 or #2, where Vg Va and Vs are given and fixed and only Ia and Is are measured with and without averaging. (Note that the parameter computation is not changed and the averaging has no influence on that. The averaging only improves the estimation of the central point). Averaging of the parameters would require taking even more measurements. 

I will check the log about the compliance error, but as far as I remember it is also not in the original Ronald's software, and I think the motivation is that with the quick test one has to test a very modest operational point of the tube, where usually Ia is way below MAX_Ia specified for the tube int he specs. So, quicktest in theory should never cause the compliance. Of course, measuring the points with Ia around 150-175mA and high percentage for the stepping will cause the problem. At the same time, for exampe for audio amplifiers, even most powerful tubes 300B, KT88 and so on would operate at the stationary current of 60-110mA max. At the same time, I will see how to notify the user about the problem during the test, right now the indicator is the output which is garbage in that case :) 

 

[Ihor]

I updated the version ot uTracerJS on the website, now it can deal with compliance error during the quicktest. 

[Never Mind]

Ihor said " To me it means that the test conditions suddenly changed (heater voltage, heating of the tube and change of parameters and so on) "

Of course I found this suggestion unlikely as I "was so careful". Experience has taught me being too sure of your lab work is the bane of trustworthy data.

I thought I had better recheck my work.

To do so.

1) I added a second serial port to the PC. 

2) I set up a second instance of uTracerJS at a alternate IP port. The old version at port 9300 and the new averaging version at port 9330.

3) I started up both versions of uTracerJS in different directory's, connected to different serial ports and at different IP ports.

4) I then opened two Firefox tabs for both simultaneously running version of uTracerJS. (This by the way is very cool and now allows me to run a uTracer3 and uTracer6 at the same time.)

Now I am  running two completely independent versions of uTracerJS at the same time.

I call them

 non-averaging, instance "A"

and averaging, instance "B"

I turned on the filament supply and waited 5 minutes making sure the filament current had completely stabilized.

I then ran quick test on instance "A" of uTracerJS, swapped the serial port DB-9 connector to my uTracer3 and then ran  instance "B" of uTracerJS.

I quickly repeated this interleaved testing 5 times with only a few seconds between each run of quick test.

The results show basically the exact same value for Vg1 between averaging and non-averaging versions.

You were 100% correct that the delta between the non-averaging and averaging software in Vg1 was due to poorly controlled test conditions. Good catch!

The results now show reduced deviation for averaged values as expected.

 Average Delta between non-averaging and averaging values of Vg1 = 72mV.

Deviation for non-averaging Va = 0.611653497

Deviation for averaging  Va = 0.247123451

Thanks for the compliance error checking addition.  

I had agreed with you that supplying "bad" data in the report file was a pretty clear indication that something was wrong.

It did take me a bit of time to figure out why I was getting negative values for Ra so this will save some other user from my struggle.

All good fun

Bob

[Ihor]

Hi Bob, 

That's actually a very cool application of uTracerJS, when you can run multiple instances at the same time. I myself never used it but indeed there is nothing to stop it from working. Probably something for massive tests with lots of uTracers in parallel :))

Another interesting usage which I know some people use is to run uTracerJS on some dedicated PC or raspberry pi, jsut next to the utracer but then connect to that PC from your laptop or another home PC, which can be in another room, using LAN. I myself would thnk of such combination when I would not like to risk to connect expensive laptop to a uTracer without galvanic isolation over usb port, even though nothing that bad can happen with utracer (only probably while debugging its hardware and shortening something with the probe). 

By the way, last couple of days I was doing some QuickTests myself, and I noticed that with uTracerJS I can easily hang uTracer jut buy starting a new quicktest immediately when the previous one just finished. I think it is just a standard way of failing utracer because I also had it ling time ago for the curve acquisition mode, when one curve was done and then caps were discharging, one should not start the acquisition of the new curve. There I added a longer delay, because uTracer has now was to indicate when it is ready. So with the quicktest I think I will add an extra delay in the end so one cannot start the quicktest within 10sec after the previous one.

[Never Mind]

Ihor

I  from upstairs sometimes use my desktop system as it has large screen to access the small laptop connected to the utracer in the basement over my lan.

I have the data drive the uTracerJS files are on my Linux samba server so I have access to all the files from where ever in the house I am.

Makes for convent access when later processing uTracer data created.

With two tabs open to different IP ports and two serial ports you can run two utracers at the same time from the same laptop. 

Handy if you have a lot of tubes of two types to test.

Re:" QuickTests myself, and I noticed that with uTracerJS I can easily hang uTracer"

I have noticed this as well.  

For me it is normally not a issue as there is the time to switch tubes and wait for the heater before the next test.

It also seems that by the time data from a quick test is saved the system is ready to run the next test just fine. As I almost always save the data I have not been bothered by hangs.

One thing I note.

If a quick test stops for any reason (like you forgot to turn on the filament supply) or fails for some other reason (wrong stepping values) you get stuck.

Often a refresh of the web page gets you going again. Some times a uTracer power cycle and a uTracerJS restart are also needed but not often.

I really like the current quick test. 

I have now tested many 10s of tubes that have been sitting in boxes for a long time as it was so time consuming to test large numbers of tubes in the past.

I print out the quick test data and put it with the box of tubes making picking out samples now fast and easy.

Quick test  gives a excellent indication of the quality of a batch from the same to sample variation.

Some batches are very good and some less so. See the 6Z5P and the 6Z38P attached.

The 6Z38P are pretty closely matched with two outliers and the 6Z5P are all over. They are made in different factories.

[Never Mind]

Another use for quick test is evaluating different tubes for cascode stages.

In a cascode stage the gain is set by the gm of the lower tube.

 u is not a significant factor due to the lower tube's plate to cathode voltage being held nearly constant.

Bandwidth or gain of a cascode amplifier can be extended with any additional available lower tube gm.

As gm is affected by Va and Ia it is important to evaluate gm for a cascode stage with the actual circuit conditions the tube will operate under.

Using data sheet values that are almost certainly measured under different conditions from your circuit will mislead you in tube selection.

With quick test one can set Va (and Vs for pentodes)  and the target Ia with quick test then returning gm very quickly.

This allows many different triodes, triode wired pentodes and pentodes to be measured for gm under the exact same conditions of the proposed cascode circuit design very quickly.

The speed of comparisons improves the selection process by allowing for far more samples to be tested.

It is very interesting to see what tube type actually will result in the highest gain (or widest bandwidth for the same gain) in a particular cascode circuit.

I found that tubes that are the "know" best like the 6n23p are easily outperformed by odd things like a triode wired 6Z51P.

I found a  triode wired cascode 6Z51P can yield over 48dB gain with 48.7V RMS output swing, THD of 0.4% with no feedback and a output impedance below 28k ohms. 

Makes for a powerful single stage output driver.

Lots of good data opens your design options.

Bob

[Never Mind]

Ihor

Unexpected variations in Quick Test results for 6N15N dual triode.

This is a new one as I have up to now seen only very consistent results for quick test.

I am testing a 6N15N dual triode  and find the quick test returned value for gm and u is varying.

The variation is about 1.5 to 1 and I see this variation for averaging values of 5 set or with no averaging (1) set.

The returned values for gm vary from about 7.2 to 4.9, a delta of about 1.5 in value.

The value for u is also varying from about 46 to 31 also about a 1.5 value delta .

The returned value for Va, Vg1, Ia and Ra are staying near constant.

That u and gm are varying by the same ratio suggests to me this is not a math error in calculation of gm or u.

See attached qtest_report-6N15N-1A5-Va100vg-.xls, qtest_report-6N15N-1A5-Va100vg-.6VIa9mA.png, qtest_log-6N15N-1A5-Va100vg-.6VIa9mA.txt

A sweep for the tube and setup shows very clean data for Va=Vs /Vg suggesting the setup is free of noise or oscillation.

See 6N15N-1-Va20-200Vg0-1.5.uts, 6N15N-1-Va20-200Vg0-1.5.utd, 6N15N-1-Va20-200Vg0-1.5.png

Any suggestion as to what to check next to track this would be great.

Take care

Bob

BTW

I find the uTracer3 only hangs on a fast rerun of quick test if the results are NOT saved.

If I save the results I do not see a uTracer3 hang on a fast rerun of quick test.

If I do NOT save the file uTracer3 seems to hang most times when quick test is run again right away.

This could just be the little extra bit of extra time it takes to save the results is enough for the utracer3 to "recover" or something else.

[Never Mind]

Ihor

I appears that the particular 6N15N tube I was using may have had a bit too much vodka mixed into it's construction.

Values for gm on that tube wandered all around when tested on my AVO. This is a nice aspect of old school analog testers, you get to see the results in real time jump around.

I tried a second sample of 6N15N and it produced consistent numbers that are close in value on both my AVO and the quick test.

I should have checked more carefully before wasting your time.

Bob

[Ihor]

Hi Bob, 

Thanks for sharing all that information, and also that you managed to figure it out. I actually wanted to ask you after that first post if you tested with more tubes :) because my quick answer there would be "it is just a russian tube" :) Another option/guess would be that the stepping was either too small or too large (because Vg is already around 0).

But to clarify a few things and then also show how things can be checked as well: 

- so that changing mu and gm and not so much changing ra are jsut because of the theoretical "very good" approximation that ra = mu / gm 

- making multiple measurements in quick test affects only the accuracy of the central point, so Ia at Va, Vg. For full parameter estimation other 5 or 7 points are acquired and those are not averaged so they are just some random samples which will be figgerent every time things are acquired. 

- to estimate all those parameters one can also use the Full test. You sent the acquired curves and as you see in the screencast, one can activate the Load Line mode and then explore the values of parameters for arbitrary location, interpolated (quite accurately) from the measured curves. As you can see in the screenshot, I sampled a few points and added them to the table(see the screenshot). The results are varying but probably also not so drastically as with QT just because the underlying interpolation does smooth things under the hood. One thing that you can see is that the curves that you call "smooth" when zoomed out (see the screenshot) look quite "bad". To make a proper test using curves, I would just acquired those densely within the location of interest, so Vg from -0.4 to -0.6, Va from 95 to 105V and then see how it might look.  

Screencast: http://files.smal.ws/v/WgWjZe

[Never Mind]

Ihor

Thank you for the tips and screen shot on using uTracerJS.

There is a lot of functionality I have yet to discover in uTracerJS.

In my past professional experience of analogue design with transistors, mosfets and of course the ever present opamp load lines never entered the process.

You started the design from classic basic building blocks like common emitter gain stages that were then linearized with current sources, cascode, current mirrors and differential topologies when needed.

A lump of feedback was usually added at some point.

This was mostly for consumer audio and telecom design where cost is always in the drivers seat.

It is hard to imagine obsessing over a few pennies of cost on a $300 BOM but when volumes are high enough the bean counters get really excited about almost every penny. Sigh.

I  figured out for one design how to use the truly nasty LM324 opamp and get decent audio results by biasing the output stage to the right class A point. 

At 2 pennies per opamp in volume the BOM cost was unbeatable. The bean counters loved it. It stayed in production for over a decade.

So I have to admit I have not used load lines much. There is a lot about tube design I have yet to learn. What fun!

We will see if my heavily spice based design process can be improved with a load line review at the start.

My little differential amplifier front end project the 6N15P was for worked out pretty well this afternoon.

On the bench it provided 24dB gain at a output voltage of 13V RMS and a total THD of 0.015% at 1K. This is before any feedback is added.

Spice said I should get 0.027% THD so I got lucky on tolerances it seems.

But I am way off topic. Perhaps the moderator will come by.

Take care

Bob