Improving the basic accuracy of the uTracer6

[Never Mind]

The basic accuracy of a uTracer6 is under many conditions lower than the uTracer3+

A uTracer6 accuracy at low anode voltages and high current can be surprising low.

Ronald when contacted suggested this was primary due to the utracer6 hardware design and I should consider a modified uTracer3+ would be more accurate at low voltages and higher currents.

I had purchased my uTracer6 mainly for it's published ability to measure 1A current from 2V and up this did not sit well. My application is the measurement of sweep tubes and rectifier tubes and that requires low voltage, accuracy down to about 15V at up to 1amp current.

For a time my uTarcer6 became a paper weight.

This summer I though to have a second look. After much testing and many measurements of my uTracer6 I have come to the happy conclusion that the majority of accuracy issues I experience with use of the uTracer6 is due to the inadequacy of hardware correction and calibration factors implemented in available GUIs for the uTracer6.

Measurement errors do not seem due to intrinsic shortcoming of the uTracer6 hardware.

I collected data from 3 precision resistors.

49.749, 120.99, 989.75 ohms measured with a 4 wire precision resistance meter.

Data was collected from 2 volts up to as close to 1000mA as possible.

Compliance has to be turned off to measure high currents on a uTracer6 but that is a issue for some other time.

My investigation shows there are two unaccounted for types of errors in the uTracer6 GUI that are available.

1) Uncompensated fixed voltage offset errors in the anode and screen AD circuits

2) Uncompensated voltage errors that are current dependent. 

A fancy way to say circuit restive losses that current calibration code in GUIs do not account for.

Attached are 3 .XLS sheets showing uncorrected and corrected data

Note on the most left chart the meaningful reduction in errors as a % of results above about a 15V test voltage.

These measurement were all taken on the anode channel where the stock MOSFET was replaced with a 3 ohm on resistance MOSFET. I found the stock  MOSFETto easily damaged in use.

1) The uncompensated fixed voltage offset error correction was 3.25V

2) The uncompensated voltage errors that are current dependent correction was 5.25 ohms. 

This value is strongly dependent on the MOSFET switch on resistance tolerance.

In the XLS sheet attached for the screen channel that still has the stock 6.5 ohm MOSFET you will see the uncorrected errors are even larger and the correction more important. The stock MOSFET required a 9 ohm value to currect for uncompensated voltage errors that are current dependent.

The following is I believe what is required to correctly calculate and compensate the values of Va and Vs as reported by the GUI for a uTracer6.

I am not a math expert so please excuse any strangeness in presentation.

Vadc = VadcRAW(DEC) * 5/1023 * Vadc correction / (Rbot+Rsence) / (Rbot+Rsence+Rtop)   - Vsupp_cor

Vs =   Vadc - (Rsence * Iadc * I calibration factor )  +  Vfixed + ( RIdep * Iadc * I calibration factor )

Bob J.

[Ihor]

I've implemented those formula and updated the uTracerJS on the website. Now you can specify those two parameters int eh calibration tab. At this moment they are not stored in the config file, as I did not want to change some other pars of the code, but they are active and working within one session of running uTracerJS. Only after the restart of the whole program they will be set to 0 and not remembered. If it does what it is supposed to do, then I will fix the rest, but right now one has to put them manually. 

[Never Mind]

Ihor

This is great. No need to code any more until this can be confirmed as correct.

I will try out the changes in the next day or so and see if it gives the same results as the spread sheet.

That would confirm the math you implemented and I extracted from my spread sheet is a correct reflection of what is needed.

I felt my corrections seemed valid as the same correction numbers held firm for 49 ohms, 120 ohms and 1K ohms.

The correction numbers were also consistent between the two channels anode and screen and correctly reflected the difference in the 3 ohm MOSFET in the anode channel and the 6.5 ohm MOSFET in the screen channel.

I believe they will be correct and applicable to any uTracer6.

For uTracer3

The same math should provide full correction for a uTracer3 with appropriate values for Vadc fixed and Ri depend.

Vadc fixed, should nicely correct for the Darlington  switch fixed Vbe and cathode diode loss as well as any Va,Vs ADC offset errors on the uTracer3+.

Ri depend, should correct for the series resistive portion of the Darlington switch, the fuse and the cathode diode , the storage capacitor ESR and any other stray resistive losses.

The total error is much smaller on a uTracer3+ and many not be a issue for most measurements but if errors can easily be removed why not do so?

Once we get the uTracer6 sorted I will retest this on my uTracer3+.

Fingers crossed and thanks for all your help.

Bob

BYW

On the uTmax there is a the allowance to set the voltage divider ratio for VA and VS to allow custom voltage ranges to be implemented by the user.

This adds a lot of flexibility and increases accuracy of the uTracer when lower voltages are used in testing.

You could consider to bring Rtop and Rbot variables out into the CAL file when you do the changes to allow Vadc fixed and  Ri depend to be exposed in the cal file.

I am also working on a more rugged switch circuit for the uTracer6 to allow it to survive at full 1 amp current testing into low impedance even with compliance turned off.

I see a number of weakness in Rondal's original design for the uTracer6 switch that do not meet worst case numbers for the present design.

My intention is a provide a simple modification that will by the data sheets survive all test conditions.

Then only your I max option to limit current will be need in over current situations and allow full 1 amp testing.

This should make high current testing up to 1 amp at any voltage with a uTracer6 a more safe and practical capability.

[Martin Manning]

Bob wrote: 

"The same math should provide full correction for a uTracer3 with appropriate values for Vadc fixed and Ri depend.

Vadc fixed, should nicely correct for the Darlington  switch fixed Vbe and cathode diode loss as well as any Va,Vs ADC offset errors on the uTracer3+.

Ri depend, should correct for the series resistive portion of the Darlington switch, the fuse and the cathode diode , the storage capacitor ESR and any other stray resistive losses.

The total error is much smaller on a uTracer3+ and many not be a issue for most measurements but if errors can easily be removed why not do so?"

I've also wondered about possible corrections for these losses in the uT3, where the sag seemed to be accepted with no attempt to compensate. From the beginning 

I have been manually dialing in voltages for the quick test, but realized that the typical Ia f(Va, Vg1) with constant Vg2 anode curves were not exactly correct due to sagging screen voltage, and worse, the transfer curves Ia f(Vg1, Vg2) were not correct due to sagging screen and anode voltages. 

Once Ihor's uTJS with the double acquisition option came along that has been largely solved. Rectifiers are still problematic, but a Quick Test with manually adjusted voltage targets has been an acceptable work-around, but I agree, if something can be done to improve the performance why not?

[Never Mind]

Ihor

All I can say is WOW. This last version of utracerJS rocks. (as does your coding)

The improvement in uTracer6 accuracy is transformative in my opinion.

In my opinion this is a game changer for the uTracer6 at low voltages and high currents, right where that all important knee in the power pentode curve lives!

Now high current rectifiers can be measured and modeled to excellent accuracy.

This is great.

These measurements were taken on a stock uTracer6 with the stock MOSFET switch and driver circuit

Next week I will improve the stock switch and driver circuits when some new parts arrive. The result should  be even greater accuracy and blowout proof uTracer6 switch as a bonus.

See the screen shot of the last uTracerJS you sent me with the calibration improvements I suggested.

The values I used are  Vfixed=3  RIdep=-9.5

These values should make a reasonable default for a stock utracer6

There is one small math error that was my doing. Sorry I am no math expert. LOL. I lost track when writing out the formula that Ridep is in fact a negative resistance.

So the sign for RIdep in the formula I wrote was incorrect.

Math should be ...

Vs =   Vadc - (Rsence * Iadc * I calibration factor )  +  Vfixed + (-RIdep * Iadc * I calibration factor )

Everything else was perfect.

This mistake of mine did not affect my testing of your new code as I just entered RIdep as a negative number under Calibration.

Having to enter RIdep as a negative number is perhaps not terribly intuitive for many users so fixing the math in your code may be worth the effort.

Bob

BTW

I noted that the auto average function can result in really large errors in some samples taken. Think random 50~100% errors below 50 volts.

Using the 32 average function reduces them but still leaves pretty large errors on random samples at lower voltages.

What worked really well was setting average to 32 and then taking the full curve sweep 3 times.

Then averaging the full 3 sweeps into a single average sweep. The resulting accuracy improvements were huge.

A lot of utracer low voltage errors are driven by the limited number of bits at low voltages. Ronald's opinion was there is nothing to be done about this limitation.

On that I disagree.

Sample theory shows that resolution in low bit systems can be improved by repeated sample taking in the presence of random noise and averaging the resulting values to obtain high resolution.

The low bit count used at low voltages in the uTracer design and resulting measurement errors can as my testing shows be removed by the careful application of sample averaging.

If you have any interest in working on this together I believe there is a opportunity to greatly imporve the uTracer accuracy by changes to the sample averaging algorithm.

Perhaps resulting in a "high accuracy" setting for curve tracing.

[Never Mind]

Ihor

I should have posted the XLS sheet with the underlying data in it.

Here it is.

[Ihor]

Good to hear that everything worked as expected and the results are now more trustworthy! :) 

I already thought that the value of R enters with the positive sign while other loss is properly negative, but I thought you might want to have it like that. I will change the sign in the next version and also make saving of the parameters persistent from one session to another. 

The suggestion to put the Rtop and Rbotom in the userinterface is doable but I think it is only useful for one person so far :) and majority will start messing up with it or will be confused. I will put it on my TODO list for minor improvements and will implement in the future.  

I am not sure if you know about some useful option in uTracerJS in terms of visualisation and comparison/matching of the tubes for example, but you can acquire all your curves and then visualise pairs to see the differences, for example something like this:

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

About the autoaveraging, it is actually done PIC in a firmware (so it is not about the software control). It is possible to make something like thatfrom the software but it will not be the same. From the software I would have to send multiple commands and they would charge and check capacitors every time and so on, on the firmware level, the capacitors are not charged, there are just streams of measurement pulses going. I would have to check it once again but it is described by Ronald on the website.  

[Ihor]

Probably it is interesting to see on your oscilloscope how those multiple measurements are acquired and how the voltage drops look like. 

The ADC in Auto mode is also controlled by PIC and automatically adjusted to cover the whole range depending on the measured voltage on the sensing resistors, so it is not like only a few bits are used, but in any case, measuring multiple times and averaging is just a plain statistics and it will always be more accurate, reducing the error in the mean to almost zero, but not the bias if present:) 

[Never Mind]

Ihor

re:" adjusted to cover the whole range depending on the measured voltage on the sensing resistors, so it is not like only a few bits are used,"

That is correct for current measurement. Current measurement accuracy seems fine. It is VA and Vs where the issues are present.

In my discussions with Ronald about the lack of anode and screen voltage accuracy he noted that the PGA113 was never implemented in the measurements of Va and Vs.

Va and Vs measurements are taken only from the direct connection the the PIC ADC at AN6 and AN7 (utracer6).

I expect this is a real time issue as the PGA113 is shared between the Va and Ia channel and switching between the two channels would take time.

This  means for Va and Vs at 31V you are dealing with about a 5 bit resolution, a +/- 3.25% error.

At 15 volts it is about 4 bits and a  +/-6.25% error. At 7 volts we are down to 3 bits and a error of +/- 14.3%.

So at lower voltages reaching even moderate performance levels in Va and Vs accuracy relies heavily on over sampling and sample averaging.

I am just very confident that with some work results could be greatly improved over how the system currently acquires Va and Vs data without having to change the PIC code.

The fact that I can greatly improve consistency of measured results by a simple spread sheet average of only 3 runs suggests a GUI software solution is likely very possible.

Re:" Probably it is interesting to see on your oscilloscope how those multiple measurements are acquired"

I agree it would be very interesting to see exactly when the samples for Va and VS are acquired.

Since the ADC device is internal to the PIC and we have no source code I can not see how to discover when a read from the internal ADC occurs.

Take care

Bob J.

[Never Mind]

Ihor

I noted that anytime the WEB server that runs on the PC losses commutations with the Utrace6, the WEB server stops running on the PC.

Then after the utracer is reset the WEB server must be manually restarted on the PC.

Is this the intended operation for the WEB server? I only ask as utracers all too often "stop talking" for no apparent reason.

In past PC controlled remote data acquisition systems I have developed we experienced the same issue. 

What to do when the remote system stopped talking. Making the user manually restart and reset everything was never popular.

What we arrived at for a solution on all future systems was to connect DTR from the RS-232 converter to the remote system -RESET line.

Then whenever the remote system stopped talking the GUI would simply toggle DTR on the PC serial port and recover instantly without the user have to do anything.

Just a suggestion to make utracerJS more solid than other GUI for the utracer. It also adds some protection in cases of utracer crash and burn situations.

Of course I have no idea how difficult this would be to add to your code. Perhaps "Easy" or perhaps "are you kidding".

I know the uTracer is a "hobby" system and I admit this is perhaps overkill. Still it would be nice.

Take care

Bob J.

[Never Mind]

Re:" The suggestion to put the Rtop and Rbotom in the user interface is doable but I think it is only useful for one person so far :) and majority will start messing up with it or will be confused. I will put it on my TODO list for minor improvements and will implement in the future."

I agree adding  Rtop and Rbotom to the GUI seems unnecessary clutter and possible confusion for most users. 

I was not really thinking it would be added to the GUI interface.

What I had been thinking is  Rtop and Rbotom should simply be put into the calibration text file in place of being hard coded into the software.

No GUI display or access to Rtop and Rbotom.

Software flexabilty and adaptability without added complexity to the GUI.

Bob J.

[Ihor]

What I had been thinking is  Rtop and Rbotom should simply be put into the calibration text file in place of being hard coded into the software.

No GUI display or access to Rtop and Rbotom.

Software flexabilty and adaptability without added complexity to the GUI.

That would be possible and probably would make more sense. At the same time it would be also good to display those values somewhere on the calibration page so the user would know which values are used, ideally with a small uTracer circuit diagram showing them. Something to try in the future ;) 

 

I noted that anytime the WEB server that runs on the PC losses commutations with the Utrace6, the WEB server stops running on the PC.

Then after the utracer is reset the WEB server must be manually restarted on the PC.

Is this the intended operation for the WEB server? I only ask as utracers all too often "stop talking" for no apparent reason.

It was intended to work like that, basically crash and quick so to say, forcing the user to start everything from scratch. It is possible to implement something like waiting and trying to automatically reconnect.. but in my case, my uTracer3 always hangs and breaks the communication leaving the High Voltage LED on. Just switching the power off and on, even for 20-30 sec does not help, HV LED is typically still on. So, after the reset I always restart uTracerJS and then the first command it sends is 30.... which means to discharge everything roughly speaking. Writing and testing a good watchdog for recovery of serial communication is yet another time consuming activity, which was not in my mind but it makes sense especially when uTracerJS is running on a separate machine. I used to use the same uTracerJS kind of software with ESP32 but that one connect to the same power and PIC so in the case of hanging, they both are physically reset at the same time :) 

In past PC controlled remote data acquisition systems I have developed we experienced the same issue. 

What to do when the remote system stopped talking. Making the user manually restart and reset everything was never popular.

What we arrived at for a solution on all future systems was to connect DTR from the RS-232 converter to the remote system -RESET line.

Then whenever the remote system stopped talking the GUI would simply toggle DTR on the PC serial port and recover instantly without the user have to do anything.

Just a suggestion to make utracerJS more solid than other GUI for the utracer. It also adds some protection in cases of utracer crash and burn situations.

Of course I have no idea how difficult this would be to add to your code. Perhaps "Easy" or perhaps "are you kidding".

I know the uTracer is a "hobby" system and I admit this is perhaps overkill. Still it would be nice.

it sounds like an interesting challenge but it would also involve modifications depending on the implementation, which would require hardware solution additionally to the coding. As far as I remember, in uTracer6 Ronald implemented several watch dogs that a stopping some deadloops in the firmware. It was described in his logbook. For example in uTracer3 there is now watchdog to stop charging of the caps if the desired voltage cannot be reached, the PIC will be just trying and trying, which can lead to several bad situations. 

I think just showing the dialog that please restart uTracer and then automatically reconnecting would be already a good solution. When the uTracer hangs and continue burning a tube, reseting just the PIC will not be of much help probably, it is better to cut off the power as soon as possible.

  

  

re:" adjusted to cover the whole range depending on the measured voltage on the sensing resistors, so it is not like only a few bits are used,"

That is correct for current measurement. Current measurement accuracy seems fine. It is VA and Vs where the issues are present.

Indeed, Va and Vs are using fixed voltage reference for ADC conversion as far as I remember. 

I am just very confident that with some work results could be greatly improved over how the system currently acquires Va and Vs data without having to change the PIC code.

The fact that I can greatly improve consistency of measured results by a simple spread sheet average of only 3 runs suggests a GUI software solution is likely very possible.

Implementing repeated measurements in the software is also straightforward, it is a bit of logistics in the code to handle all those averaging correctly. 

 

Re:" Probably it is interesting to see on your oscilloscope how those multiple measurements are acquired"

I agree it would be very interesting to see exactly when the samples for Va and VS are acquired.

Since the ADC device is internal to the PIC and we have no source code I can not see how to discover when a read from the internal ADC occurs.

Here I meant to see the traces similar to what you showed before, just to see a couple of pulses for one set point with averaging. To see if the caps are recharged every time during the averaging or multiple measurements are taken with one initial charge of the cap. With such large voltage sags that you observe it should be easily visible (the variability of reaching the set Va by those caps).  

The measurement routine fro averaging is described here:

https://www.dos4ever.com/uTracerlog/tubetester2.html

section "The program flow for a single measurement"

 

[Ihor]

I updated uTracerJS, now the resistor for losses can be entered as a positive value and also those parameters are now saved in the calibration file. Also added limiting the acquisition depending on the max. power for the screen. 

[Never Mind]

Ihor

Thanks for the excellent reply. It is a pleasure working with you.

I can say I am enjoying using my utracer6 for the first time and can now see it has a good future in my lab.

The utracer6 now seems like a good investment in my time.

I will characterize the uTracer3+ in a week or so to see what if any improvements are possible with your new correction code.

I also hope to publish a "how to" for improving the switch and drive circuits for much lower losses and better reliability in a uTracer6.

This will greatly reduce unmeasured losses that need to be estimated and should prevent switch failures at high current testing.

I have wanted to do this for some time but Ronald's software made improving the hardware impossible as different calibration values are required. 

Now they can be easily changed in the setup file.

 I also plan will publish a document on how to increase the storage capacitor and cathode bypass capacitor and why you may want to do this to improve uTracer6 accuracy by lowering the droop.

I once had to recompile old code in a old legacy design where the software programmer was long gone, using a obsolete processor, with a old unsupported software development system and hope the code all come out functionally unchanged just to tweak a hardware correction value because some hardware had drifted over time in production. 

Then add in that the production run was millions of dollars in value, was in Asia and was 30 hours travel time to the factory if the recompile was "wrong".  It was a true nightmare

Simple to edit setup files for all hardware corrections became very appealing after that experience. LOL

Bob

[Martin Manning]

Bob wrote: "I will characterize the uTracer3+ in a week or so to see what if any improvements are possible with your new correction code."

I'm very interested in this, and look forward to following along with my uT3+.

[peet willemsw]

Can you tell us please which 3 Ω MOSFETS (type, brand) you used to replace the standard ones in the uT6?

Op zondag 8 september 2024 om 20:49:39 UTC+2 schreef bobblue...@gmail.com:

[Never Mind]

pwill

The 3 ohm MOSFET was only a temporary past from my junk bin. A far better part is what I used for the mod.

I will provide all the details of my mod in a few days.

Until then if you have interest have a look at the new scope pictures I posted for my utracer6 mod in posting  "Utracer6 waveforms"

Many of the issues that have limited the usefulness of my uTracer6 look to be resolved. The latest version of uTracerJS is needed to be able to take advantage of these changes.

More testing is needed to confirm the total system accuracy is also improved. That will take a few days time to get done.

When improved accuracy is confirmed I will post instruction and all parts needed for the mod.

Bob

[Never Mind]

The following is a comparison of three different version of Utracer6's for accuracy at high current and voltages below 100 volts.

This is a test area of concern to the measurement of sweep tubes and power rectifiers.

In each case I used a 49.749 ohm resistor as the device under test so measurement errors can be easily displayed.

1) Stock hardware with no changes.

The charts show the accuracy with and with out the newly added corrections available in uTraceJS.

Accuracy of a stock uTarcar6 and most GUI is limited for measurements below 100V at high current.

Newly added correction factors now available in uTraceJS are in my opinion needed for the uTracer6 to provide sufficiently accurate measurements below 100V at higher currents.

However a stock utracer6 hardware when used with the new correction factors provided in uTracerJS  will provide useful accuracy for measuring devices like sweep tubes or high current rectifiers.

I set Vfixed=3  RIdep=9.5 in utracerJS calibration menu for best accuracy with a stock uTracer6. This gives pretty good results with a stock uTracer6.

See 49.749ohm correction factors-SCREEN-after repair-240907-6.5 ohm MOSFET.jpg for test results.

Due to hardware limitations of the uTracer6 best accuracy results from selecting 32x averaging, taking the curve measurement 3 times and then taking the average of the three curves.

This is because the very low bit count of about 1V per bit in a uTracer6 requires many samples to be averaged to provide good voltage resolution and accuracy at lower voltages.

For me trading lab test time for good accuracy is acceptable for a DIY tester. You get there, it just takes some time and effort.

2) Replacement of MOSFET switch, MOSFET driver transistors, adding on Dv/Dt control resistors, C44 increased to 4300uF.

I found the stock MOSFET and driver circuits fail too easily in high current testing. This got me thinking on how it can be improved not only for reliability but for accuracy at high currents and lower voltages.

The stock MOSFET switch on resistance is about a 6.5 ohms and this represents a 6.5V loss @ 1A test current that is not accounted by the measurement system.

This 6.5V loss must be estimated by the GUI. As MOSFET on resistance can vary a lot the lower this value the lower correction errors will be.

The stock MOSFET has a safe area of only 1A for 1mS at about 300V maximum. This seems too little in light of failures in my opinion.

The replacement MOSFET I selected has a safe are of about 2.3A for 1mS at 1000V. 

So even if compliance is turned off and a full 1Kv pulse is applied to a dead short the data sheet tells us the device should survive as the hardware current limits the MOSFET to about 1.2A.

I also updated the MOSFET drive transistors from 100mA devices to 600mA devices and added series resistors as the stock transistors were in my opinion at risk of failure during high Dv/Dt current events.

Also C44 was increased to 4300uF to reduce the cathode "bounce" during pulse measurements.

The result was improved accuracy at very low voltages down to the 2 volt level.

Again utracerJS must be used to take advantage of these improvements.

I set Vfixed=3  RIdep=3.2 in utracerJS calibration menu for best accuracy. Note how the value of "RIdep" has dropped due to the lower MOSFET losses.

See CORRECTION-average_49.749 anode-MOSFET-0.62-C44-4300uf.jpg

3) The changes made in point #2 plus the energy storage capacitor are increased from 50uF to 180uF.

This continued to improve results at very low voltages from the modification in step #2.

Looking the the results with the increased storage capacitors we now usable accuracy measurements down to under 2 volts. Pretty impressive for the utracer6 hardware design.

I set Vfixed=2.2  RIdep=1.8 in utracerJS calibration menu for best accuracy. Again the latest uTracerJS must be used. Note how the value of "RIdep" has dropped again due to lower C60,61 ESR losses.

See CORRECTION-average_49.749 anode-C60,61-180u-MOSFET-0.62-C44-4300uf.jpg

It is reasonable to argue that these finial improvements in #3 will be of little value to most users of the uTracer6.

The large size and cost of the increased storage capacitors and the inherent reduction in safety with all that extra stored energy is something to consider.

The changes in #2 are in my opinion the most bang for the bucks and quite suitable for most uTracer6 users.

#3 provides "all you can get" from a uTracer6 if you need that little extra.

I will in the near future write up instructions on the mods I used for anyone interested.

[Never Mind]

Here are the details of the changes I made to my utracer6 to improve low voltage high current accuracy and to prevent MOSFET switch and driver transistor failure.

I have done my best to make the instruction accurate a clear and carefully tested my uTracer6 with these changes. 

Use at your own risk however and let me know of any issues you find.