I have been away for a while from being active at the forum and from building anything related to tubes.
Yet, I have had this idea for quite a while to build a microcontroller-based computer which monitors vital parameters of a tube amp or preamp while they are used.
Why? To monitor change of parameters in near real time i.e. Ia, Ua, Ub, Uf, If statically and dynamically. To monitor differences between channels, to see how an amp behaves under load, what difference tube replacement makes, etc.
It would also monitor if given levels of SOA are exceeded and perform actions to i.e. prevent damage to an amp, turn the amp off after inactivity period etc.
Two variants to be considered:
A. a bare board computer with / without display which is built-in the amp itself;
B. a "socket" inserted between a tube and a socket in the amp with wireless transmission to, say, smartphone app or a standalone control unit.
Variant A could server makers, variant B - for users of amp not intersted to change anything in an amp.
Feedback is warmly welcome.
Thank you.
Pawel
Yet, I have had this idea for quite a while to build a microcontroller-based computer which monitors vital parameters of a tube amp or preamp while they are used.
Why? To monitor change of parameters in near real time i.e. Ia, Ua, Ub, Uf, If statically and dynamically. To monitor differences between channels, to see how an amp behaves under load, what difference tube replacement makes, etc.
It would also monitor if given levels of SOA are exceeded and perform actions to i.e. prevent damage to an amp, turn the amp off after inactivity period etc.
Two variants to be considered:
A. a bare board computer with / without display which is built-in the amp itself;
B. a "socket" inserted between a tube and a socket in the amp with wireless transmission to, say, smartphone app or a standalone control unit.
Variant A could server makers, variant B - for users of amp not intersted to change anything in an amp.
Feedback is warmly welcome.
Thank you.
Pawel
Basic question is, what kind of data and update rate. We´re talking few kB/MB or much more. It depends..
i have some labview experience. It could be done with building a measurement system from PC and a DAQs (optically isolated) but cost would be huge.
This is cheap, actually tested with RPI3 + some I2C adc´s 12bit created a simple RPI DAQ (i2c isolators come handy)
https://www.labviewmakerhub.com/doku.php?id=libraries:linx:start
cheap i2c adc have refresh rate like dmm, not fast.
But since you want statistically gather data, you cant refresh much often..
Think as how many GB/year ,you can to save.
What kind of cpu power to go tru so much data...I do not see it possible without PC power
i have some labview experience. It could be done with building a measurement system from PC and a DAQs (optically isolated) but cost would be huge.
This is cheap, actually tested with RPI3 + some I2C adc´s 12bit created a simple RPI DAQ (i2c isolators come handy)
https://www.labviewmakerhub.com/doku.php?id=libraries:linx:start
cheap i2c adc have refresh rate like dmm, not fast.
But since you want statistically gather data, you cant refresh much often..
Think as how many GB/year ,you can to save.
What kind of cpu power to go tru so much data...I do not see it possible without PC power
Last edited:
Good Idea.
Just decide which parameters of the tube to test, like Cathode current.
A 12 bit A/D would have resolution of 0.0244%.
Just make sure that the mains power has a very special regulator in front of the amp,
or make sure the amp has special regulators for B+ (and filaments too, because changing filament power changes the tube parameters).
Also, you may want to only test during quiet sections of the music, or the current will change by far more than 0.0244%.
An 8 bit A/D would give resolution of about 0.4%, which is much more suited to analysis of failures, quicker to transmit data, quicker to calculate, quicker to check multiple parameters, and collate and analyze them as a group in an artificial intelligence mode, etc. It would not be busy checking extremely small changes, that are more like "noise" of real world operating conditions with real world power line and real world music.
Just decide which parameters of the tube to test, like Cathode current.
A 12 bit A/D would have resolution of 0.0244%.
Just make sure that the mains power has a very special regulator in front of the amp,
or make sure the amp has special regulators for B+ (and filaments too, because changing filament power changes the tube parameters).
Also, you may want to only test during quiet sections of the music, or the current will change by far more than 0.0244%.
An 8 bit A/D would give resolution of about 0.4%, which is much more suited to analysis of failures, quicker to transmit data, quicker to calculate, quicker to check multiple parameters, and collate and analyze them as a group in an artificial intelligence mode, etc. It would not be busy checking extremely small changes, that are more like "noise" of real world operating conditions with real world power line and real world music.
Last edited:
For reference: in 1940-1970 Broadcast Audio, the "update rate" was: every night, the junior engineer flipped switches and recorded cathode current in most tubes in the main signal paths. Pushbutton or rotary switches connected the meter to the various cathode or plate current-tap resistors. These resistors were scaled so the "normal" current read about half-scale on the meter. If a tube started around 50%FS but drifted down to 40% and 30%, it would be replaced at the next sign-off. If audio just quit, a quick scan of the readings might show a 0% tube, replace that now (much faster than opening the chassis and shoving a VOM at it).
Since a PIC works far cheaper than a jr eng, and can make notes faster, you could scan more often, but I would not put any premium on speed. Except for gross over-current. Even then, some seconds of delay is no big deal.
Since a PIC works far cheaper than a jr eng, and can make notes faster, you could scan more often, but I would not put any premium on speed. Except for gross over-current. Even then, some seconds of delay is no big deal.
Thank you for your remark, Petertub.
By arduino you mean Atmel / Microchip MCUs, don't you? Atmel chips have been popular for quite a time indeed and I have had some experience with them.
I've decided to use another vendor - TI - and their CC1350. It can also be programmed using arduino toolchain (Energia) and is more versatile, i.e. it has built in BT radio, independent sensor controller, RTC among others. Thus number of external devices can reduced which in turn reduces costs of parts and labour.
TI designed Simplelink series MCU and suppoerted tools so one can deploy applications to other MCUs easily.
With arduino i mean the original :
https://www.arduino.cc/
With proper chioces you might avoid creating any hardware, just software
and some cabling. ( there is a large assortment of "shields" that would
help interfacing and talking to surrounding world)
The arduino route is best suited for low volume production where
availability for spares globally is needed. If heading for larger volumes
then of cource a custom board is better suited.
I thought about checking tube ageing and if tubes in both channels are matched well.
I am aware that B+ changes impact other parameters change. I assume no changes to an amp PSU due to using the computer.
I am in the early design stages of a 1KW vacuum tube amp. An amp of this magnitude needs to have some type of protection, monitoring and auto bias system. The system could also monitor the health of the output tubes by keeping track of the bias voltage necessary to achieve a specified idle current. I also envision different operating modes and the ability to shut down some output tubes when full power operation is not required. Some type of display is also needed.
There are certainly plenty of Arduino compatible SBC's out there with the needed I/O and CPU power. I will likely use this one:
https://www.pjrc.com/store/teensy36.html
I have used them for music synthesis applications already. The A/D provides 13 bits of usable information, and the DACs are 12 bit. There are only two DACS per board, so I will either use a MUX with a sample and hold circuit, or an external SPI or I2C DAC chip.
There are certainly plenty of Arduino compatible SBC's out there with the needed I/O and CPU power. I will likely use this one:
https://www.pjrc.com/store/teensy36.html
I have used them for music synthesis applications already. The A/D provides 13 bits of usable information, and the DACs are 12 bit. There are only two DACS per board, so I will either use a MUX with a sample and hold circuit, or an external SPI or I2C DAC chip.
RPi implementation
I am using a RPi 3 version microcomputer to do the control of my amp. It is still a work in progress but the core of the design and implementation is complete. I wrote a note earlier http://www.diyaudio.com/forums/tubes-valves/304606-pics-your-random-experiments-5.html#post5016622 to describe some of the characteristics.
The objective was to be able to control and vary the bias current of the PP amp output tubes. This is a UL configuration using torroid OPTs.
The RPi uses 4x DACs and 8x ADCs for the basic control and monitoring, plus the rest of the RPi available output pins to control power etc. The programming language is Python 3
The 4x DACs control the individual grid voltages via a analogue 741 opamp based level shifter that ensures a predictable transfer curve between the DAC and Vg.
The ADC's are used to measure the following:
- VB+ - this is used to dynamically ("real time") adjust Vg due to drift in VB+
- Vg (supply, not individual grids) - this is used as a go/no-go test before power up and during operation (shut down if Vg varies outside range)
- Left and right channel audio output - measured via a peak detector. The main purpose of this measurement is to only calibrate bias current when no audio is present but is also used to display audio level when music is playing
- 4x output tube current, via a 10 Ohm resistor in each case
RPi outputs are used to control switches: 4x audio input selectors, HT & Vg supply on/off; filaments on/off; red status indicator; blue status indicator.
I use a simple 2x16 character white on blue display for all the control and monitoring
The bias current is continuously variable (for the 6550) from 20 to 90mA. Control is within 0.5mA.
I use the Koren triode model embedded in the program to predict the new grid voltage when the bias current needs to change. This ensures an efficient convergence to the new value, or to adjust the value when calibrating. Convergence is within 1-3 iterations maximum.
Koren parameters are uploaded via a copy of the SPICE model in the uTracer format. I use uTracer measurements and/or data from Paint using published curves.
I have also added a tube "efficiency" measurements. This is the measured bias current per tube relative to some chosen 'standard' tube, expressed as a %. This allows a crude method of checking relative tube performance and see the tube ageing. The 'standard' performance is determined via the chosen Koren model. So given the individual tube Vg, I calculate the theoretical bias current, and compare that to the measured bias current. Via the display you can load any reference tube you want, the programme will extract the Koren parameters needed for the calculations.
Auto calibration is achieved every time audio is not present for more than 5s (but only once during the silence period)
Other features include monitoring the individual tube "power on" hours, as well as a no-music timeout/shutdown feature going into standby.
This method of control may be an overkill but has the flexibility of the RPi and works extremely well.
I am using a RPi 3 version microcomputer to do the control of my amp. It is still a work in progress but the core of the design and implementation is complete. I wrote a note earlier http://www.diyaudio.com/forums/tubes-valves/304606-pics-your-random-experiments-5.html#post5016622 to describe some of the characteristics.
The objective was to be able to control and vary the bias current of the PP amp output tubes. This is a UL configuration using torroid OPTs.
The RPi uses 4x DACs and 8x ADCs for the basic control and monitoring, plus the rest of the RPi available output pins to control power etc. The programming language is Python 3
The 4x DACs control the individual grid voltages via a analogue 741 opamp based level shifter that ensures a predictable transfer curve between the DAC and Vg.
The ADC's are used to measure the following:
- VB+ - this is used to dynamically ("real time") adjust Vg due to drift in VB+
- Vg (supply, not individual grids) - this is used as a go/no-go test before power up and during operation (shut down if Vg varies outside range)
- Left and right channel audio output - measured via a peak detector. The main purpose of this measurement is to only calibrate bias current when no audio is present but is also used to display audio level when music is playing
- 4x output tube current, via a 10 Ohm resistor in each case
RPi outputs are used to control switches: 4x audio input selectors, HT & Vg supply on/off; filaments on/off; red status indicator; blue status indicator.
I use a simple 2x16 character white on blue display for all the control and monitoring
The bias current is continuously variable (for the 6550) from 20 to 90mA. Control is within 0.5mA.
I use the Koren triode model embedded in the program to predict the new grid voltage when the bias current needs to change. This ensures an efficient convergence to the new value, or to adjust the value when calibrating. Convergence is within 1-3 iterations maximum.
Koren parameters are uploaded via a copy of the SPICE model in the uTracer format. I use uTracer measurements and/or data from Paint using published curves.
I have also added a tube "efficiency" measurements. This is the measured bias current per tube relative to some chosen 'standard' tube, expressed as a %. This allows a crude method of checking relative tube performance and see the tube ageing. The 'standard' performance is determined via the chosen Koren model. So given the individual tube Vg, I calculate the theoretical bias current, and compare that to the measured bias current. Via the display you can load any reference tube you want, the programme will extract the Koren parameters needed for the calculations.
Auto calibration is achieved every time audio is not present for more than 5s (but only once during the silence period)
Other features include monitoring the individual tube "power on" hours, as well as a no-music timeout/shutdown feature going into standby.
This method of control may be an overkill but has the flexibility of the RPi and works extremely well.
Attachments
An alternative idea is to connect a bunch of inexpensive LED Panel voltmeters to whatever needs to be measured. They are available for about $1 each on Ebay.
Then monitor them with a webcam using motion detector software. If the sensitivity is too great, the software can mask out the right most digit or you could simply use masking tape.
ray
Then monitor them with a webcam using motion detector software. If the sensitivity is too great, the software can mask out the right most digit or you could simply use masking tape.
ray
I have been working for some time on a similar project. My idea was to use an inexpensive PIC (18F4550 in this case) with minimal external components, working in a quasi-RTOS form, on which a Finite States Machine has been implemented. The coding also has lots of pre-compiler directives in order to include or exclude some parts of the code depending on the capabilities of the PIC and the availability of external peripherals.
See documents below for a general overview. Coding is 50% done and for the time being works very well.
View attachment EVACS Architecture.pdf
View attachment EVACS FSM.pdf
See documents below for a general overview. Coding is 50% done and for the time being works very well.
View attachment EVACS Architecture.pdf
View attachment EVACS FSM.pdf
This is serious !!
I assume you also have logic to prevent reapplying power in the event of
power failure ?
Interesting point; this matter has not yet received the required attention.
At the moment the RPi boot sequence is to go into standby mode, so the amp will not power up.
This is probably fine for complete power failure. Ideally the RPi should have enough PSU storage to go into controlled shutdown when the power fails.
However, at present the RPi PSU has some holdover time (TBD) that is probably quite short, so this may be a problem in a "brown out" situation where one loses power for 100's of milliseconds.
I will need to give this some thought, but it is solvable.
The idea is to build a flexible computer and then embed more logic in following iterations inorder to corelate events from different sources.
That is a good one! I thought I'd be measuring tube characteristics and compare the to some standards. My goal is to build a tool which will give a user to input parameters via smartphone app and display reading there as well. That is why an MCU with BT. Moreover I think about 300B monoblocks which will communicate with each other via BT or Sub-GHz radio. For many reasons.
where you want to store such amounts of data?
---------
arduino? really?
berry PI3 is a Quad Core 1.2GHz, this will keep well, when you hang several i2c or spi chips on it.
But still, are you sure what kind of detail you want? PXI is another possibility
PXI-5922 - National Instruments
This is a key constraint and where most auto bias mechanisms fall short.
Power loss is quite common here since we are out in hill country. The usual scenario is loss of power for several seconds then usually 3 retries and power returns if the short is cleared, or the shorted branch drops offline. Otherwise the power is out for several hours until the power company crew fixes the problem.
The 3 retries are what will blow up a tube amp, so the big amp must shut down and do a total restart upon loss of power. The power supplies will have enough capacitance to ride out small glitches, but a drop of voltage by more than 10% in any supply triggers a restart.
My restart routine starts up the power supplies with the output tubes held in full cutoff. If all voltages check out there is a 30 second wait for warmup, then the output tubes are slowly ramped up to normal current, while the individual bias voltage is measured and stored. Once every 50 startups or so the bias voltage will be moved 1 volt and the change in cathode current will be measured and stored (tube Gm).
As stated on a period of extended silence, the bias current will be checked, and adjusted if necessary. Tubes that exhibit excessive adjustments will be flagged. I have had issues with 'LW6's running away in the past, but this was a triode wired amp where the screen voltage rating was abused....a lot.
As stated, it's all a work in progress and changes to the plan are inevitable.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.