ExtractModel with a uTracer6 issues

[Never Mind]

Having used a uTracer3+ and ExtractModel for years to create spice models now I am trying to create spice models with a uTracer6 as the 6P36S can support very high plate currents (about Ia of 1A with Va under 100V) that I want to model in spice.

I am using the ExtractModel 3.0 software from DOS4EVER that I have successfully used for years with my uTracer3+.

The first issue I overcame was the current version 3.0 of ExtractModel does not expect any current information in the data file for G1. 

So I edited my data files to remove the G1 current data column.

Now with the 6P36S tube data I collected with a uTracer6 I get the error in the title, "*** Internal error in DetSweep".
I have so far failed to find this cause.

Does anyone have a list of error codes for ExtractModel that may provide a hint as to what  ExtractModel is not liking in my data?

Has anyone see this "*** Internal error in DetSweep" error before and know the cause?

I attached the data files I am using.

[Ihor]

At some point I reimplemented those algorithms in uTracerJS and just quickly tested. One can also try it online at utracer.boffin.nl but one needs to know what to do, even though the fitting protocol is basically the same as in Extract model. 

In any case, I got some problems with two files, for 100V and 170V but I could load the one with 140V. In my tool one can use the curves only for one given Vs to create a model. If I have time during the weekend I might take a look why those other .utd files are not playing along but there is something there that probably ExtractModel also does not like.

The models that I got are attaged together with some plots.  

[Never Mind]

Thank you for your reply.

I tried  at utracer.boffin.nl and also found only two files loaded the triode file and the 140V file.

I then tried to load a large number of .UTD files I have from past work and found most would not load.

No error messages resulted just the WEB site hanging  in the load state.

The UTD files I tried to load are valid files I had generated with my uTracer3+ and had used ExtractModel to create spice models from in the past.

I noted that some files that had different data column numbers due to compliance errors or removed columns utracer.boffin. would not load them.

In one file after editing the file to have all  the same size columns lengths resulted in utracer.boffin. now loading that file.

However other files that loaded fine if I removed columns to create different data column lengths that file still loaded fine. This seems inconsistent and contradictory behavior.

It is unclear why so many apparently valid UTD will not load. 

There seems some possible fragility in the code used to parse and load data files in  utracer.boffin. 

The lack or any errors massages is a disappointment making debugging the issue difficult.

[Never Mind]

  Ihor

Playing with this web site it is a impressive bit of coding you have created. I envy your skill.

Unfortunately I failed to find any help files just a few simple animations.

Loading one file at a time was pretty easy. Also creating a triode spice model from one file was easy.

What I was unable to understand is how to import and  retain all 4 files required to create a pentode model.

I was also unable to understand how one selects the files to process and create the pentode model.

I am sure it is there I just need some helpful text to show me the way.

Bob

[Ihor]

Hi Bob, 

Indeed those two other curves do not work and it is because the Curve Number in the file does not start with 1, but 2 or something else. I will try to find time during the weekend to change that. The assumptions that were implemented is basically cover the situation where everything as it should be:) I see that you probably get curve 2 as the first one because of the compliance issues, I also get that sometimes, but most of the time I would stop, change the parameters a bit and rerun everything properly, to have one nice file for a tube.

By the way, you do not have to use the online version, you can also install or run uTracerJS just on your computer, you can get it here: www.boffin.nl

There is not much documentation at this moment, I was always lazy to sit and write, and I am not sure if I will find time for that in the near future, but on the Help page there (one of the menus on top) there are Screencasts showing how things can be done, and that also includes Spice modelling. 

There are indeed not much error notification for the users, but in any browser it is possible to open a Console (right mouse click i chrome and then Inspect and then console) and then all the error and also useful debug information are displayed during the execution. The nicely GUI-like error handling probably will be done in the future :) 

The curve fitting that I re-implemented uses exactly the same algorithms as Derk, but it was done for quick modelling inside GUI, so the functionality that one can load several curve-sets for different Vs's is not implemented. The procedure to model a pentode is basically one has to load triode curves, model it by choosing the the Triode model in the popup menu, then estimated parameters will appear on the webpage, then load the pentode curves and select model for pentode. Those parameters from triode will be used as initial guesses that pentode model requires (that's also how it si done in Derk's software). 

Cheers, 

Ihor

[Never Mind]

Ihor

I installed uTracerJS this morning. It went easily with only one glitch. I tried Win7 first but it seems win10 is required.

Installation on win10 was perfectly easy.

It is correct that many of my data files have uneven  data sample numbers. 

This is due in some cases from trimming out data samples that ExtractModel has flagged as having "saturation effects"

This is also due to compliance errors stopping further data samples when the maximum anode current I wish to test to has been reached.

So yes a missing data sample is very common. Also varying numbers of data samples is very common.

Nether seem to have been a issue in the past for ExtractModelor or Ronold's GUI in my experience

Perhaps your software is not effected by ExtractModel's saturation warnings. That would be a nice improvement.

Ronold's GUI limits the uTracer6 abilities.

When testing power tubes with high current abilities at low anode voltages, for example the 6P36S I posted the data files for the current GUI from Ronald does not allow effectively use of the capabilities of the nuTracer6.

Why is this? It is due to a few issues with the uTracer6 itself and the reality of testing high power sweep tubes like the 6P36S tube with the present GUI.

First the uTester6 hardware issues.

The hardware design of the uTester6 has a large droop (about 50V) in output voltage during a test pulse at 1 amp current.

The voltage droop in a uTracer6 results from many different sources within the uTracer6 design. 

If you have interest I can send you my detailed analysis of all voltage loss sources in the uTracer6 that results in the large voltage droop. 

The uTracer6 droop voltage in my experience is about 10 times that of the uTracer3+. 

This can be easy seen by trying to testing a 50 ohm resistor up to 1 amp current with a uTracer6. 

One is required to set the GUI sweep voltage to over 100V to reach a 1 amp test current in a 50 ohm resistor showing the 50V loss in test voltage.

Only about 1/2 of this droop voltage (storage capacitor) is captured by the measurement system. 

The other 1/2 of the voltage droop (fuse, switch, inductors, current limit sense  resistor, C44 voltage rise) has to estimated and modeled in the GUI and this limits total system accuracy at low impedance.

It would be nice to lower these estimated losses by for example replacing the switch with a lower on resistance part.

Unfortunately I have been unable to do so as the estimated losses seem to be hard coded into the GUI and so the user can make no improvement to the uTracer6 estimated losses.

It would be far better if these loss values were part of the config file in my opinion.

My impression of Ronold's response when I approached this issue with him was first you should not really want to test such low impeadances. 

Then he seemed to suggest you really are expecting too much from the uTracer6 to be able to accurately measure low impeadances at high currents.

But wait my suggesting that the uTracer6 should be capable and accurate at low impedance and high current does not seem unreasonable.

A sweep tube like the 6P36S can sink about 600mA with a anode voltage of about 40V. That is a 66 ohm load.

There are lots of larger sweep tubes that sink even higher currents at very low anode voltages and so even lower load impedances.

This is exactly what sweep tubes are designed to do. Somehow excepting the Utracer6 to be useful and accurate with type of tube does not seem unreasonable.

Perhaps I am wrong. If so caveats should really be placed in the uTracer6 specifications about limited low impedance test capabilities.

Ok to solve the large droop voltage just set the anode test voltage to at least 50 volts over what is needed in the data right? I understand the uTracerJS can do this automatically.

But even then a second issue comes into play.

The compliance circuit and measurement is done at the start of the 1.25mS pulse before the large voltage droop has occurred. 

Going back to our 50 ohm test resister example it become impossible to test at over about 500mA before compliance trips even at the highest current setting.

Well just turn compliance off. Yes this works and yet leads to more issues.

First now there is no protection if a tube shorts during test. The poor uTracer6 will keep banging into a dead short until the operator stops the test. Och!

So you must watch all sweeps constantly ready to stop the sweep if anything goes wrong.

Second you must carefully watch all results to make sure the test current does not rise to over 1 amp as that will overload the AD converter and result in bad data.

Yes this can all be done and it is how I currently collect data with my Utracer6 but is far from the smooth experience I had for years with my uTracer3+.

A feature I requested some years ago for the uTracer is the ability to specify in the sweep setup the maximum test current separately for the anode and  the screen.

This makes most of the above difficulty go away.

The sweep will now run until a test result reaches or exceeds the set test current. The sweep will then move on to the next test series. 

So for example testing with grid voltage -10 when the anode target current is reached in the test results the sweep moves to the next grid voltage in the series. 

This repeats until all grid voltages are tested.

No errors result and user intervention is not required. 

Watching the tester all the time is no longer needed. 

A lot of time playing with sweep voltage  parameters to reach a desired maximum test current is eliminated.

With settings for test current limits for anode and screen as part of the sweep setup one can simply specify what current levels one wish to test to and let the computer sweep up to the desired currents automatically.

Seems a natural behavior for a automated data test system.

I hope you did not find my detailed explanation too long.

I really want to like and use my uTracer6 as I have my uTracer3+. I think Ronald's designs are very creative and excellent in execution.

The uTacer3+ set a high standard and I was caught of guard when i expected the same standard with my uTracer6.

My experience suggests to me the uTracer6 deign as a system is not  yet finished. There is still much room for improvement much of that on the GUI software side.

A good part of that unfinished business in my opinion is the GUI for the uTracer6.

Take care

Bob

[Never Mind]

Ihor

Today I tried to acquire new data with my uTracer6 and utraceJS.

I had no difficulty setting up the serial port and getting communication between the PC and the uTracer6.

Under configuration I set the the device to uTracer6. See attached screen shot.

I saved to eeprom.

I switched to acquire.

 However under compliance level I found only uTracer3+ current levels NOT uTracer6 levels. See screen shot.

I can acquire data however the results are invalid.

It seems clear that uTraceJS has not yet been set to a uTracer6.

What have I missed here?

BYW

I note the port number for local host is set in the config file.

Can a whole IP address (the local PC's) be specified along with the port number? That way could I access the PC connected to the uTracer from any machine on my local network. 

That would be very handy indeed.

Take care

Bob J.

[Never Mind]

Ihor

I answered my own question on localhost and the answer is yes!

You can access the utracer6 and host machine from any machine on the network just by specifying the host's machine full IP address and port number..

This is very cool and how thing should work.

Thanks

Bob

[Ihor]

Indeed, if you know the IP address of that machine in the network, you can connect to it even with an ipad and run your tests from there via web:) 

uTracerJS works with uTracer6 basically from the very beginning, including the positive grid extension module for uTracer6 and so on. Whn you change to uTracer6 in the calibration menu, you also have to change the "sensing resistors". There is suggestions there in red, when you switch from uTracer4 to uTracer6 for the first time, so they should not be 18 Ohm but 4.7 Ohm. Only those resistors define the scales with currents. 

[Never Mind]

Ihor

As this thread title notes when I acquired data using Ronald's GUI and used ExtractModel.exe in a attempt to create spice models ExtractModel.exe exited with the error message "*** Internal error in DetSweep"

Today I reacquired the same data set for the 6P36S tube using your utracerJS software in place of Ronald's GUI on a uTracer6.

These files are attached.

With the reacquired data of the 6P36S tube using your utracerJS software in place of Ronald's GUI on a uTracer6  ExtractModel.exe was able to create both the triode and pentode spice models without any errors.

This seems a large improvement using utracerJS over Ronald's GUI on a uTracer6 to acquire data with a utracer6.

I am however stuck in my understanding of how to create spice models from withing utraceJS.

Using ExtractModel.exe and the command line one first creates the triode model with the command ExtractModel.exe  triode.ini

In the INI file one specifies the triode data file to be used. 

ExtractModel.exe then creates the triode spice model.

This is straight forward.

Next with ExtractModel.exe and the command line one first creates the pentode model with the command ExtractModel.exe  pentode.ini

In the INI file one specifies the triode data file to be used and any pentode data files to be used. 

I normally include 3 pentode data files with a range of three screen voltages.

ExtractModel.exe then creates the pentode spice model.

Again this is straight forward.

I have however failed to understand the process flow in utracerJS to create spice models.

Any models triode or pentode I have created with utracerJS so far are very poor representations of the data files.

I have watched the help movie over and over and yet can not see how the 4 data files needed to correctly represent a pentode are selected to be processed for the spice model.

Nor can I seem to understand how to creat a valid triode model

I need more of a hint than the movie to understand the process flow that utracerJS uses to create spice models from multiple data files.

A finial note.

I know from detailed testing that there is at least one major bug in Ronald's GUI for a uTracer6 that corrupts data results when measuring I(Va=Vs, Vg) with Vh constant for a triode data file.

The amount of data corruption and it visibility in the data result is dependent on current levels in testing and the anode and screen voltage during data acquisition.

The amount of data corruption  is also strongly influenced by the ratio of screen current to anode current during data acquisition.

Under some condition the reports data results can be in error by up to 100%. Ouch!

Is your code a recompile of Ronald's code or is it the result of starting from a clean sheet?

I have not tested uTracerJS yet with a utracer6 to see if the same data corruption is present in utracerJS.

If you have interest in more detail on this corruption issue let me know and I will supply a detailed test procedure to make the data errors easy to see.

I reported this issue to Ronald in January of this year and so far he has not provided a correction.

Thank you for all your help and contribution to the community.

Bob

[Never Mind]

Ihor

Good news.

I have just tested utarcerJS with a uTracer6 for the data corruption issue with  I(Va=Vs, Vg) with Vh constant for triode data I found in Ronald's GUI .

With a uTracer6 and utracerJS correct anode and screen voltages and currents when measuring I(Va=Vs, Vg) with Vh constant are always stored correctly into the data file.

Unfortunately it seems utraceJS reports incorrect test data values on the GUI screen even though the underlying data file is correctly recorded with a  I(Va=Vs, Vg) with Vh constant sweep. 

This is a bit disappointing but as the underlying data is recorded correctly very workable.

I have now tested three uTracer6 GUIs for this issue.

In Ronald's GUI with a utracer6 both the data recorded and the GUI graphs displayed are incorrect for screen voltage.

In the utraceJS GUI with a utracer6 the data is always recorded correctly. However the utraceJS GUI can graph incorrect data for the screen voltage I(Va=Vs, Vg) with Vh constant sweep.

See the attached files.

I have also tested the UTmax software for the utracer6 and I(Va=Vs, Vg) with Vh constant sweep .

Errors are not present in the UTmax GUI with both the data files and the GUI graphs always being correct. 

All tests are done into a 50 ohm load with the maximum sweep voltage set to 90V, one port at a time using a utracer6.

Anode voltage test values and GUI graph

Note the maximum anode voltage test value reported is 48.47V in the data file and this matches the voltage values show on the anode graphs of the utraceJS.

Screen voltage test values and GUI graph

Note the maximum screen voltage test value reported is  51.59V in the data file and this DOES NOT match the voltage values show on the graphs of the utraceJS.

The data file for the screen test reports a maximum screen test voltage of 51.59V yet the graph in utraceJS shows the maximum screen voltage at something over 88V

The data file is the correct value. The graph on the utraceJS screen voltage is incorrect.

I have attached the data files from a uTracer6 using the utaceJS GUI measuring one port at a time, first a 50 ohm resistor on the anode port and then on the screen port.

Note the sweep in both attached data files was set to a maximum sweep voltage of 90V.

Compliance is turned off.

[Ihor]

Thanks for the feedback. It is a lots of information but I will try to answer a bit and then try to dig into your explanations which I do not clearly understand:)

The uTracerJS was written from scratch without any access to Ronald's code, just but reading Ronald's logbook on the website. It exactly mimicks the behavior of the original windows software, sending exactly the same commands and values to the uTracer for a specified by user parameters. It also produces exacly the same numbers back, from the values that it obtains from uTracer's hardvare. So, all the inconsistencies or errors in some of the cases are because of bugs in those softwares, but most likely there are totally independent bugs. At the same time, both softwares are tested.a lot and I am not aware of any bugs at this moment. 

Fitting of the pentode in uTracer is done only for separate curves, which are visible in the plot window, so it is not possible to do fit of multiple curves at the same time as it is done in the Extractmodel software. The idea in uTracer was a bit different, to load the curves and create model which help to get interactive lines more easily, I use that mostly for triodes. For pentodes for me was enough to have a curve for one Vs, most of the time I needed a model just to have an extended model for higher voltages, because I have uTracer3+ and for real amp one need to go further in terms of voltages. So, working with multiple curves is not possible, and then it is still better to use ExtractModel. For fitting with uTracerJS, I will try to make a small screencast once again, the the routine as I described, first the triode curves are loaded (one has to activate  the option "Ia+Is" which is a proper way i this case, but even without that things will work just fine because fitting of the triodes before the pentodes is done jsut to estimate a couple of parameters which is helpful for further fit).

I will try to reread your last post, because it is not clear what exactly does not work. I myself use Va=Vs option all the time, and I am pretty sure there are no errors there, it is just something with navigating uTracerJS. If the .udf file contains all the values as you say then they can be properly displayed in the plot for sure, it is just some options that are probably not correctly chosen in the menu.    

[Ihor]

OK, I think I see your point I think. The Va=Vs mode is useful or used mostly for the triodes, Va and Vs are changing very much in the same pace. There is small voltage drop possible but usually it is small and one can also chose "Voltage correction" in uTraceJS menu during the acquisition so in the file one gets not the measured Va and Vs but set ones (without drops). Sp the story that it is enough to use one scale (of Va voltage values) to plot Ia and Is (and not to use separate Vs values for Is values). 

In the files that you attached, even though they were probably acquired in Va=Vs mode, they contain only Ia values or Is values. It is not a problem but for such high current the voltage drop is huge, so when you set 0-90V, you only get 0-50V. So, by using Va=Vs, plotting Ia and Is are using only the Va range. 

To properly visualise the files that you set, one has to use I(Va, Vg) and I(Vs, Vg) modes. Right now Va=Vs will produce the effect as I mentioned. I will see if it will not take too much time to take care of that. It is a good suggestion, to I will definitely take a look at it. If you run those tests with two resistors at the same time, all the voltages will sink in the same manner and the results will look more or less correct. It is a more conceptual problem and I do not expect it to be solved in Ronald's software for example, because there it writes not the measured values of Va and Vs but set ones (so you probably get plots in the whole range between 0 and 90V) which are incorrect in both cases. 

[Never Mind]

Itor

Re:" I myself use Va=Vs option all the time, and I am pretty sure there are no errors there"

Ronald took the same opinion for many many months until I sent him my simple test. 

First he said I should not want to test low impedances anyway.

Then he said I expect too much accuracy from my Utracer6 at low voltages and high currents. I noted I see 80% to 100% errors in reported values. Seemed too high to me.

Then he finally saw the issue but has not been able to provide a fix. 

I has been so disappointing at almost 9 months waiting to be able to use my utracer6 to test sweep tubes and get solid results.

I have not seen this issue in years of use with my utracer3+. Perhaps it is present with a uTracer3+ but does not manifest to a degree large enough to be notable in the results.

I am not sure.

The issue is clearly uncovered  with a utracer6 at high currents and low voltages I believe due the large voltage droop in test voltage on a utracer6 at high currents.

utracerJP passed my tests in terms the data in the file is always recorded correctly in all cases. This is key and most important. Thank you for that.

utracerJP failed my test in terms the GUI graph for screen voltage incorrectly reports the screen voltage to be much higher that the real value used in test and recorded in the data file.

The large droop in the utracer6 at high test current is not being taken into account in the screen voltage GUI graphs.

Bob J.

[Never Mind]

Re:" If you run those tests with two resistors at the same time, all the voltages will sink in the same manner and the results will look more or less correct. "

Yes you are correct.

If you want to see weirdness.

Use Ronalds GUI and a utracer6.

Put a 50 ohms resistor on the screen port and sweep it. Note the calculated resistance value based on reported screen voltage and screen reported current.

It will be incorrect and calculate out to about 100 ohms, high by about 100%

Now add a second 50 ohms resistor on the anode port.

Now the reported data for the screen port voltage will change drastically will now the screen resistor will calculate to the correct resistor value at 50 ohms.

Vary the anode port resistor and the data reported on the screen port varies all over the place. Not correct al all.

I spent a lot of time thinking this was a noise issue in AD section of the uTracer6 until detailed scope photos proved everything in the hardware worked correctly.

Then I narrowed it down to the the GUI as the utracer6 serial stream reported different screen voltages values than what Ronalds GUI reported.

All this took many days of time over weeks or work. 

I admit Ronald's apparent lack of interest in someone working very hard to help him correct a basic error in his product and make it a much better product was not a happy experience.

[Never Mind]

Ihor

BYW

 I sent you 10% of the purchase price of my utracer6 as a donation as finially I can use my utracer6 and get valid results with utracerJS.

I hope you will see this as acceptable.

Thank again

Bob

[Ihor]

Hi Bob, 

First of all thanks for the donation! I really appreciate that!! 

After my previous answer I went to the code and actually "fixed" that behavior for Va=Vs case. You can download the newest version from the website. It now properly handles your case. I still have to double check the issue with the .utd files that start with CurveNumber 2 or 3 and not 1. I have to simulate the compliance errors in the code, but it is doable. By the way, that solution is still leaves another conceptual problem, because uTracer6 can measure Vg as a function of Va or Vs as well, and here it becomes not clear if Ig is a function of Va or Vg if those are totally different :) But again, it is all because in theory there is only one single swiping voltage for all types of test....

By the way, uTracerJS also has a so-called option "Double Acquisition" in the Acquire menu. What it does it forces uTracer to make 2 measurements for each point on the curve, first for a specified Va (e.g. 90V) then measure the voltage drop, then compute the boost in Va or Vs (for example making it 140V) so when it applied, it will measure exactly as specified, 90V. The implemented algorithm works nicely for small voltage drops (5-10%) but I have never tested it with drops of 40% as in your case, so would be even curious to see how it works:) Actually with the resistor as a load it should work very nicely, because it actually uses Ohm's law to extrapolate Va or Vs to get the right one back. 

[Never Mind]

re:" The Va=Vs mode is useful or used mostly for the triodes, Va and Vs are changing very much in the same pace "

And in measuring pentodes in triode model for ExtractMode. 

A situation where with large sweep tubes wildly varying large currents with large and changing deltas between the anode and screen port current happen and this data is very important in the calculation of secondary emissions.

Bob

[Never Mind]

Ihor

Re:" Double Acquisition"

Good to know I will give this a try. The large droop in the utracer6 at large currents and low voltages does cause some weirdness and sweeps.

Re:" but I have never tested it with drops of 40%"

This large droop also causes compliance to be pretty much unusable below 100 volts test voltage at high currents when you approach 1amp as to get a 50 volt test result you must start with a 90v sweep voltage.

 As compliance is measured at the test pulse start it will report about 2 times the actual test current available at the end of the test pulse.

So with compliance on below 100v test voltage testing above 500mA is not really possible.

This is why i suggest a feature that will move on the the next test series after a certain value of test RESULT current for the screen or anode has been reached.

This  current value would be a setting in the GUI setup screen.

Bob

[Ihor]

If it is for acquiring triode characteristics of pentode I myself would probably just go via more practical route and wire a pentode as triode :) (connecting anode and screen pins together) and using I(Va, Vg) mode with disconnected Vs.

"This is why i suggest a feature that will move on the the next test series after a certain value of test RESULT current for the screen or anode has been reached."

Something similar is already implemented in uTracerJS. There in the Aquire menu you can specify a maximum power value, Pmax (= Ia * Va or Is * Vs), so if uTracer goes over it, no more points are acquired for that curve... It works nicely with some test that I have done. 

[Never Mind]

Ihor

Re:' Double Acquisition ....drops of 40% as in your case, so would be even curious to see how it works:)"

It does reduce the sweep shortfall by a fair amount as you can see for the attached data files.  DBA is short for Double Acquisition

Without Double Acquisition a 50 volt sweep into a 50 ohms resistor will reach about 24.07V.less than 50% of the specified sweep voltage.

With Double Acquisition a 50 volt sweep into a 50 ohms resistor will now reach about 40.72V. So about 80% of the specified sweep voltage, a good improvement.

Bob J.

[Never Mind]

Re:" If it is for acquiring triode characteristics of pentode I myself would probably just go via more practical route and wire a pentode as triode :) (connecting anode and screen pins together) and using I(Va, Vg) mode with disconnected Vs. "

I am unsure ExtractModel will support correct results if the data is acquired this way.

The ExtractModel procedure tells you to use  Va=Vs and this yields separate data for screen and anode currents in the equivalent "triode" being measured. 

So i have not tried  I(Va, Vg) mode myself. 

Have you experience modeling power pentodes this way where secondary emissions are large and important?

Having a utracer6 work simply work correctly and collect accurate data seems a better way to go in my opinion. This seems a completely possible goal using utracerJS.

Bob

[Never Mind]

Re" There in the Aquire menu you can specify a maximum power vale"

Yes there is the power menu however power control is not the same as current control.

What I am trying to do is to prevent bad data by having the test current go off scale or pounding into a dead short (no power but a lot of current!). Remember compliance can not be used!

Remember due to limitations in the design of utracer6 hardware compliance can not be turned on in testing high current low impedance tubes. It must be turned off.

With high power tubes one is often skirting the maximum test current for the test system to get data at as high a current measurement as possible without getting bad data from AD saturation.

It would be good as well if the system would stop pounding on and on into a shorted tube with compliance off.

So I would like to be able to set a maximum test current of lets say 900mA and have each sweep test up to a maximum RESULT measured current level of 900mA. 

Then go on to the next series. There would then be no bad data due to AD over load. As it is I have to review all data for AD over load.

Also a shorted tube with current control on the test result would only result in a single measurement into a dead short per sweep voltage series. Much better that pounding through the whole series into a dead short.

As it is now I have to watch the system carefully ready to hit abort if a tube fails during test as compliance can not be used.

It is just the utracer6 was designed to test high power/current and the present GUI software was architected for the lower power/current testing of the original utracer3.

The current GUI design that stems from the original utracer3+ low power/current perspective holds back the capability of the utracer6. 

I find this disappointing.

Some new functionally is needed to full use a utracer6. Current control based on the test result current is one and voltage droop correction is a second one.

Take care

Bob

[Ihor]

As I completely reimplemented those fitting procedure, I know what they actually do but there is still a possibility that ExtractModel implementation requires some specific input, at the same time it does not mean that it needs that. The fit of the pentode models is done with the help of triode. This is a purely computational requirement. Pendote models (especially those with the secondary emission require estimation of 14 parameter values (just from a couple of curves). Mathematically it is a tricky operation which leads to lots of different combination of those parameters which will lead to more or less the same "curves" when modelled. There is no way around it. The optimizaton algorithm also starts from some values which might lead the whole optimization problem to dead end. So, in Derks approach, he first takes the triode curves for the same tube and fits a model with 5 parameters, which is easier and more or less unique. Those 5 parameters are very good guesses for other 5 parameters from those 14 of a pentode. Thast why the pentode model can start even with bad initial guess for the rest of the parameters and converge nicely to a good solution. 

So, to get the initial triode parameters, Derk uses Ia and Is curves, but in fact those are just summed up to one Ia value of a new "triode" and the model is fitted there. One can also wire together anode and screen and acquire Ia then, and Is=0 and that should also work. Even more, one can even just give Ia curves, with Is=0. All the Extract model does if finding the initial guesses, those are never the final values, so no worries. 

Another thing to keep in mind is that those model fitting problems are very high dimensional and quite difficult in terms of uniqueness, so with slightly differetn implementations or even curves one will get different sets of values for the parameters. There is also nothing wrong with that. Those parameters should not be treated as "absolute truth". All those sets will model the final curves accurately, it is just that multiple combinations of those parameters will lead to the same curves (within some small error).     

[Ihor]

"So I would like to be able to set a maximum test current of lets say 900mA and have each sweep test up to a maximum RESULT measured current level of 900mA. 

Then go on to the next series. There would then be no bad data due to AD over load. As it is I have to review all data for AD over load."

In principle, this would be a very straightforward extension in uTracerJS, just specifying Imax as Pmax. I would jsut have to implement the corresponding GUI fields to palce those values and then carefully make other modes. Cannot promise anything but if I have time during the next weeks, I might take a look at it. Here again a few choices are popping up, do we need max.current threshold both for Ia and Is, or only Ia and so on. Also the current Pmax is implemented only for anode current and not the screen (it is still possible by I myself never do such tests where the screen power or current are limited).

[Never Mind]

Ihor

RE:" Here again a few choices are popping up, do we need max.current threshold both for Ia and Is, or only Ia and so on. Also the current Pmax is implemented only for anode current and not the screen (it is still possible by I myself never do such tests where the screen power or current are limited)."

The current limit test in the test data results setting MUST apply to both anode and screen current.

Remember compliance is often turned off on a utracer6 when testing at high currents and lower anode or screen voltages due to the 50 volt droop.

Without compliance turned on there is nothing stopping a utracer6 with present GUI implementations from pounding on and on into a dead short.

I could certainly live with a single setting of the test result current limit that applied to BOTH anode and screen currents if this is all that is practical to implement.

However testing of both screen and anode port currents is required for this to be useful.

Currently there is nothing but a attentive operator to protect my utracer6 from pounding into a dead short or severe over current situation on the anode or screen port. 

Not ideal as sometimes I drift off into a day dream while testing grinds away.

I believe it would be preferred to be separate settings for anode and screen. 

This provides maximum flexibility in covering all use cases including ones we have not thought of yet.

Yes separate values for anode and screen current will be two things to set.  

I do not however think a user of a device like a utracer6 would be confused by having anode and  separate screen current limits to set.

Default could be "off"  or no current testing.

Or default could be set to the maximum current capability of the device, 200mA for a utracer3+ and 1000mA for the a utracer6. This I believe is a much safer way as by default even if compliance gets turned off the operator gets a second chance if there is a dead short. 

With compliance off admittedly the likely hood of damage to a utracer6 into a dead short escalates with the test voltage as the MOSFET switch Ronald used does not have a safe area on the data sheet for 1KV at 1A for 1mS of energy absorption.

It should survive for 1mS up to about 250V test voltage by the data sheet.

I sourced a alternate MOSFET for the switch with a data sheet guaranteed safe area covering 1KV at 1A for 1mS of energy absorption. Unfortunately as it has lower on resistance and the GUI provides no way to adjust the fixed loss model correction factors and so it can not be used. 

Using a better switch that is tougher and lower loss causes a large loss in accuracy as the loss factors for the MOSFET seems hard coded into the software. 

Pity another software blockage to making the utracer6 a better product.

I use my utracer3+ for all smaller tube testing where is has higher accuracy that the utracer6. 

My utracer6 is only being used to test large power tubes and so I have not had a single test case where I could get the data I needed with compliance still turned on with a utracer6. 

That 50v droop at high test currents causes compliance to trip at far lower currents than the resulting data measurement current with a utracer6.

Typically below 100V you can only reach 500mA test result current on a utracer6 with compliance turned on.

None of the above is really a issue with a utracer3+ as there is only about a 2 volts loss in the test voltage at 200mA so compliance can normally be left on almost all the time.

The utracer6 is a very different hardware implementation with its 50 volt droop at maximum test current. As a result compliance is not really a very useful function in my experience during most utracer6 testing

I personally rarely use the power limiting feature during test as the 1.25mS pulse does not contain enough energy to cause local heating or damage with most medium to large tubes.

It is the maximum test current I focus on.

I can understand however why others may wish to use power limiting on smaller or delicate tubes.

BYW

One use case I now plan to use my utracer6 with is testing dual power rectifiers to create spice models.

In the past I tried this use case with a few dual rectifiers but received wildly inaccurate results. 

At the time I did not understand and Ronald advised the utracer6 was not really capable of this sort of testing with high accuracy.

Later I found the large errors I reported was due to the interaction between the anode and screen voltage reporting vs current with a utracer6 and Ronald's GUI errors.

It was not a intrinsic limitation of the utracer6!

Now with utracrJS I can go back to this testing and collect accurate data to model rectifiers from. 

Good fun to be had!

Take care

Bob J.

[Ihor]

Hi Bob, 

I just updated the website with the new version of uTracerJS that can deal with current limits for Ia and Is independently (see the screenshot). Please let me know if it works as expected. In my simulated tests it works, but there might be some inconsistencies, even though I do nto expect them :) Currently, if a limit for Ia or Is is secified, one still will get one measurement above that limit before stopping. In order not to just too high, one has to use lots of points for Va so the increments are small, both with voltage and current. 

[Never Mind]

Ihor

Incredible. This is great. 

I will try to find time tonight to try it out otherwise I will give it a test tomorrow morning.

Doesn't seem to have cluttered the GUI at all. Still looks very clean and simple.

Bob

BTW

Do you know where the fixed corrections factors to correct voltage loss vs current  for the hardware series resistances is stored?

For example the fixed correction factor for the MOSFET resistance or fuse induced loss?

Are these hardware series resistance correction factors stored in the PIC or are they part of the GUI?

Just wondering.

Take care

Bob

[Never Mind]

Ihor

Congratulations.

I tested the anode and screen current limit setting today and they both work perfectly. See attached screen shots.

For both the screen and anode port testing now stops reliably just past the set maximum current limit.

This is a game changer for the uTracer6 when testing low impedance sweep tube or rectifiers.

I admit for the year I have owned a utracer6 it has spent almost all its life in my lab collecting dust.

I was just unable to find any work around to the shortcoming in Ronald's GUI for the utracer6.

Now we have correct voltages stored in the data file for both screen and anode currents in testing during I(Va=Vs, Vg) with Vh constant.

We also now have settable I limits for anode and screen to allow safer and most importantly accurate testing with compliance turned off into a low impedance.

I see the above transforms the utracer6 into valuable piece of test equipment that will now fit a number of use cases that theTracer3+ did not cover.

This is a excellent development.

One point to note.

In I(Va=Vs, Vg) with Vh constant testing the GUI screen graph results still reports incorrect voltage values for the X axis of screen voltage.

I minor issue but I thought to point it out.

The data file for screen voltages contains the correct screen voltage values. This is what is most important.

Thank you for your excellent contribution to the utracer6 community.

Take care

Bob

[Ihor]

Thanks Bob, 

I just updated the uTracerJS on the website once again. I fixed showing correct Vs values in Va=Va test for loading of the .utd files but forgot to do that in another place, where the online acquisition is happening, thanks for pointing it out, not it should work for as well. Let me know if you experience any other issues with that. Also, now uTracerJS is more "robust" in dealing with immediate compliance errors, happening at the very first point to be acquired :) 

"Do you know where the fixed corrections factors to correct voltage loss vs current  for the hardware series resistances is stored?

For example the fixed correction factor for the MOSFET resistance or fuse induced loss?

Are these hardware series resistance correction factors stored in the PIC or are they part of the GUI?"

There is nothing stored on the PIC or transferred to the PIC during or after the calibration. uTracer just does what it does depending on the soldered electronic components with all their inconsistencies and random parameters (around the averages from the datasheets) and then all the calibration is done purely in the software, by matching all those reported measurements to the expected values. The calibration procedures are well described. At the same time it is possible to compute own calibration curves for those cases, a sort of look-up-tables, that will properly boost the specified Va voltage to some higher values, so after applying those to low resistance/high current modes would result in the correct set Va voltages, for example. 

At the same time, theoretically the sinking voltage is not a problem: even though one gets lower voltages, for example not 90V but 40V, the current is still measured correctly, it just corresponds to 40V on the real datasheet curve. So simply by running the test in the range of 0-150V, lets say, one could get correct curves in the region of 0-90V, without any errors or any tricks with the calibration.       

[Never Mind]

Re:" There is nothing stored on the PIC or transferred to the PIC during or after the calibration. uTracer just does what it does depending on the soldered electronic components with all their inconsistencies and random parameters (around the averages from the datasheets) and then all the calibration is done purely in the software, by matching all those reported measurements to the expected values. The calibration procedures are well described. "

There is nothing in the user calibration process that measures or takes into account current dependent voltage losses in a utracer.

So I assume the correction of current dependent voltage losses is a fixed correction factor hard coded somewhere.

On a utracer6 there are a number of losses that are current dependent that are not and can not be captured by the measurement system AD.

They are for the anode side R62, T65, R73, Z1, LA1, LA3 and C44.

As they are after where the measurement system picks up the measured anode voltage at C60 they must be estimated by the measurement system.

In a utracer6 they are all current dependent losses. In the code there needs to be a current dependent voltage correction factor calculation for these unmeasured losses.

The results of this current dependent loss correction factor calculation must be subtracted from the AD measured anode voltage to realize the real anode voltage during the pulse.

Ronald's web site discusses this correction calculation and does say it is in the GUI code the correction calculation is done.

I quote

"With this simple formula the GUI software can easily compensate for the voltage drop over the transistor, as well as of course for the voltage drop over the current sense resistor and the current limit resistor."

This correction calculation must be tailored for the uTracer3+ and the uTracer6 as the losses are by both type and magnitude very different.

In the uTracer3+ some of the loss,  the one in the darlington switch is a nearly current independent voltage loss and the other losses are resistive and so current dependent.

In a uTracer6 all the losses are current dependent as a MOSFET switch is  basically a current dependent resistive loss along with all the other loss I noted above.

I when I changed the MOSFET for a lower resistance part the voltage returned at low anode test currents did not change. This is to be expected.

Calibration for anode voltage did not change. Measured results for the anode voltage a low current stayed the same. This is also to be expected.

What did change with a lower resistance MOSFET was at high currents and low anode voltages the reported anode voltage becomes very much in error. 

Anode voltages now reported by the GUI during the test pulse were now significantly lower that the actual higher applied anode test voltage.

Is is exactly what is to be expected if a lower on resistance MOSFET is used and the current dependent correction factors are not adjusted.

This suggests there must be a fixed current dependent correction factor applied to in the utracer6 some where in the code.

Again as the losses are so high in a utracer6 it becomes far more important that the current dependent voltage correction factors be as correct for each unit as possible.

I just wonder where in in code this happens and would like to see the correction factors exposed in the calibration file.

If the correction factors were to be exposed in the calibration file the user could measure and then adjust the estimated resistive losses and greatly improve the low voltage accuracy of a utracer6 at high currents.

Take care

Bob

[Ihor]

I can only talk about the software part, because I know exactly how both uTracerJS and Ronald's software convert the responses from the uTracer to real voltages and amps and also back from physical units to the corresponding codes for uTracer's hardware and there is for sure no dependency of MOSFETs nonlinearities and so on. the reported by the ADC values converted to physical units by multiplying with the corresponding calibration coefficients that one sees in the Calibration dialog (in combination for the sensing resistors, where it is applicable), there is nothing more to that. There is a bit of piece-wise dependency modelled (with some hardcoded thresholds) for the Vgrid, in the calibration but that's it. It might happen that there is some dependence on MOSFET characteristics and behavior hidden in the assembler code for the PIC but that we cannot access. 

For example, most of the calibration procedures are like here https://www.dos4ever.com/uTracerlog/tubetester2.html in the sections "anode and screen voltages" and "anode and screen currents"  

[Never Mind]

Re:" It might happen that there is some dependence on MOSFET characteristics and behavior hidden in the assembler code for the PIC "

Ihor

Thank you for the reply.

Are you saying that the correction factor voltage verses current for the darlington switch loss of

"V loss = I test current + 0.65" 

in the case of the uTracer3+ is NOT in the GUI as Ronald's notes indicated?

If not it becomes a bit of a mystery as where this correction is taking place.

In a uTracer6  the MOSFET switch has a typical data sheet specified on resistance of 7.1 ohms.

This is a typical 7.1 volt loss, a very big number when measuring 50 volts.

The data sheet also states the maximum on resistance of 9 ohms a 1.9 ohm delta.

That represents a 1.9 volt tolerance on the switch resistance loss or 1.9v/50V =  3.8% error at 1 amp test current. 

A 3.8% error  seems a unnecessary and significant loss of accuracy that can be corrected by software calibration and correction.

I am going to conduct some more experiments on my uTrace3+ and utracer6 to see if I can discover anymore about these current induced voltage measurement errors.

If these factors are not being fully and carefully taken into account on a uTracer6 this will be part of the puzzle of why low voltage accuracy at high currents on a uTracer6 is so compromised.

Bob

[Ihor]

In uTracer3 but also uTracer6 the pipeline of measuring Va and Ia for example is rather straightforward, so all the components in the schematic set the values of the corresponding voltage at the ADC input, the ADC output is just a HEX number that is send to the software via the serial. On the software side the physical values for Va and Ia are obtained according to 
Ia = IaHEX * 5.0 / 1024.0 * calIaGain / (resistorAnodeSense / 100.0)

Va = VaHEX * 5.0 / (1024.0 * anodeDivR1 * calVaGain) * (anodeDivR1 + anodeDivR2) * 1000.0 - pVsupp_cal 

where all the other names are really the calibration values from the calibration dialog that everyone knows, and I am afraid there is no "higher" order thoughts that you mentioned implemented there. 

[Never Mind]

Ihor

Re:" Va = VaHEX * 5.0 / (1024.0 * anodeDivR1 * calVaGain) * (anodeDivR1 + anodeDivR2) * 1000.0 - pVsupp_cal "

I am sorry but I think I have not been clear enough when I say what correction is used when Va is measured.

Let me see if I can do better to be more clear in explaining my concern.

There are 3 Va results needed in any Utracer6 test result.

1) Measuring VA to charge the storage capacitors to the correct voltage.

In that case I agree with

Va = VaHEX * 5.0 / (1024.0 * anodeDivR1 * calVaGain) * (anodeDivR1 + anodeDivR2) * 1000.0 - pVsupp_cal

2) Measuring VA on the the storage capacitors at the end of the 1.25mS test pulse.

This is done when the discharge switch has been switch opened and current has stopped to measure the actual end of pulse voltage remaining on the storage capacitors.

This is when the storage capacitor droop is determined.

Again I agree with the measurement above in #1.

3) Calculation of VA to be reported as the actual test result voltage for any one test point.

This is where I believe there  is room to improve the accuracy of a uTracer6 below 100V into low impedance.

This calculations starts with the voltages determined in measurements taken in step #1 and #2,  the actual start and end of pulse voltages on the storage capacitors .

To calculate the VA to be reported as the actual test result voltage the test current must be taken into account to correct for the series resistance voltage losses in the test current path as the actual Va on the tube can NOT be measured in the presence of test current. This is due to the hardware design of the the utracer6.

So all voltage losses due to the series resistances of components in the test pulse current path must be estimated by the software.

In the case of a uTracer6 these loses are all resistive in nature except one loss that is capacitive and are composed of the following.

Resistive losses.    R62, T65, R73, Z1, LA1, LA3, C44's ESR, C60+C61 ESR and external wiring losses.

Capacitive loses.   C44

The resistive voltage losses are simply the sum of the resistance of ( R62, T65, R73, Z1, LA1, LA3, C44's ESR,  C60+C61 ESR, external wiring losses) * the test pulse current measured.

Or simplified to Rlosstotal * Ia = Vrloss

R62 = 4.7

T65 = 6.5

R73 = 0.56

Z1 = 0.335

LA1 = negligible

LA3 = negligible

C44 ESR = 0.3

C60+61 ESR = 6

external wiring losses = 0.2 (estimated)

Total resistive losses, Rlosstotal  = 18.595

The capacitive loses for  C44

C60, 61 and C44 form a capacitive voltage divider that lowers the test pulse voltage across the tube during test by raising the cathode voltage.

This is calculated by...

Initial Va before test pulse - Remaining Va after test pulse = V droop, the droop voltage in the storage capacitors during the test pulse.

((C60 * C61)/C60 + C61 ) / C44 * Vdroop = loss due to C44 charging during test pulse current and raising the cathode voltage.

Or simplified to (50/1000) * Vdroop  = Vcloss

The fully corrected, the actual test result voltage for any one test point becomes

(Va measured in #2 ) - (Vrloss + Vcloss) = actual test result voltage

Testing of a utracer6 into low impedances shows a significant loss in accuracy below 100V at test currents up to 1000mA that I believe are due to sub-optimal modelling of resistive and capacitive losses.

With a uTarcer6 when I take measured V/I curves from a 50 ohms test resistances I see errors of up to 12% between about 200mA and 1000mA on a uTracer6.

When I apply alternate corrections for external losses the data errors in the reported results drop to 2% or less. 

This seems a valuable improvement in accuracy with measurements of power rectifiers or sweep tubes below 100v at high currents.

For now I am pasting my data files into a spread sheet for post processing to reduce these errors with low impedance devices. 

It is a workable but cumbersome process and a allowance to incorporate a more a complete and user definable calibration into the uTracer6 would be a meaningful improvement I believe.

Series 1 shows before added correction and series 2 is after correction is adjusted in measuring a 50 ohm test resistance.

Take care

Bob