Tuesday, December 2, 2014

Windows Batch File High Ping Datalogger

There comes a time in every internet user's life where they realize that their internet connection isn't all it is cracked up to be. For me, living out in rural mid-west USA, this is a constant struggle. I only have access to a singular phone and internet provider, and because I live more than three miles out from their one and only server center, I have to pay considerably more, and accept a far lower standard of internet service. It costs me roughly $90/mo for a 15mbit down / 1.5mbit up DSL line. bandwidth isn't usually the issue though, unless I need to upload a file, where if I exceed 125kbit bandwidth it swamps the line and terminates any downstream data streams. That can't be helped, it is a product of the hardware systems in place. The issue that plagues me most... is latency.

What do you do to check latency statistics? You run the ubiquitous Ping (ICMP Echo Request) diagnostic. Here, you select a target IP address, and your system will send a packet off to that address, tell you if it was delivered, and how much time it took to get there and back. You can go to just about any windows machine, open the command prompt, enter "ping" followed by a standard IP address, or even a domain name, and hit enter, to see the results of four packets being sent off. You can also run the Tracert or Trace Route ping utility, which sets the Time To Live (TTL - a limit of how many hops a single packet is allowed to make) to 1, which means you get a ping response from every single hop along the route consecutively.

Both tools are indispensable in network troubleshooting, but by the very nature of tracert it can only be used as a spot-check tool. You run it when you think there is a problem, or when you know there isn't one, and then compare the results. You can run a very light weight single ping anytime you want, and you can even make a batch file to run it continuously, once every set amount of time. This helps to keep connections that are prone to failure or timeout alive. It is simple to do, simply use the option "-n #" after the ip address, remember to remove the quotations, and replace the # with a number. Running continuous pings can be done with the "-t" option, but this can easily contribute to network congestion, both in your LAN and at the destination server. Some servers will even consider this a form of attack and block off communications with your IP address, not good, and thus not advised. You can get around this by adding a delay and automating the ping process in a batch file. A simple GOTO command and a TIMEOUT delay command are all that are needed.

Here's where the fun starts....

What if you want to record the results of the ping tests to catch intermittent latency issues. You probably want to run the ping commands relatively often, perhaps once every second or two. It's trivial to output the results from Ping.exe to a text file using the append operator ">>". Wait though, this is going to make a HUGE file that no IT professional is going to want to look over. Well, you could write up a text file parsing script to extract only the unusual ping results and place them in a new file. That would solve it. but now you're still eating system resources by continuously writing to a text file on your hard drive. Also, you now need to periodically run the parsing script to trim down the text file. Not very user friendly, and certainly not elegant.

The Programming Considerations.

You have a few choices.

1) You fire up your favorite language's IDE and start writing a from scratch program that will execute the functions that Ping uses and processes the resultant data and logs it accordingly. This will be tens of hours of coding, at the very least. If you take a look at Ping.c or Ping.cpp for example, they're rather huge works of programming.
2) You fire up your favorite language's IDE and write a from scratch program that will call on Ping.exe to do its thing and then grab the results. You'll have to deal with advanced systems like windows sockets, pipes, and all kinds of nasties.
3) You throw in the towel and find some end user program that probably isn't free that will datalog ping results, and hope it is good enough. Yeah, I'm not the kind to do that either.
4) You start learning a scripting language like Perl of Python to do what options 1 and 2 would but far easier. Yeah, still not going to do that.
5) Jump into the deep end of windows batch scripting and try to trudge through the muck of a poorly explained, foreign looking language with rather inaccessible documentation because you KNOW it can be done, and the results are likely to be the easiest to implement. Guess that's what we have to do.

The Windows Batch (.bat) File

Basically, batch files are a script of commands to be executed autonomously by the windows command line interface once the batch file is executed. Any command that can go into a CLI can go in a batch file, though you will usually need to modify the syntax and structure some.

Thankfully there is a website called SS64.com which is run by Simon Sheppard of the UK. This is a truly valuable resource when it comes to windows CLI and Batch files. If you have any experience with programming, especially in C/C++, this site will get you going writing useful and efficient batch files as long as you carefully read the information presented and apply some elbow grease.

The hardest part will be recognising the required syntax and wrapping your head around the fact that you don't have the structure to fall back on that most languages have. You don't declare/define variables at the top, and there are many hidden limitations when working with variables and data input/output. Getting things right in terms of structure and syntax was the most difficult part by far. Notepad makes a pretty piss poor programming IDE, haha. I know at least 90 minutes were swallowed up by forgetting to wrap a variable in % signs and having a line break after a DO command that it didn't like.

My Batch File

The heart of this 'program' is fourfold;
1) Call and save the date and time in an appropriate format to variables.
2) Ping the supplied IP address.
3) Find the relevant data in the Ping.exe output, save it to a variable,
4) Process the variables' text strings into usable chunks and then perform an IF THEN conditional check to discard all of the useless data points. Export the saved data to a log file.

Written within comments (lines preceeded by double colons) is the syntax and command structure basics, as well as links to their pages on SS64.com At the top of the file is my generic header that explains what the program is and what it does, as well as how to contact me. It goes on to explain what to change in what lines to repurpose this program for your own needs. I've gone ahead and generalized the output file names and filepaths, as well as the target IP address so that this program will just simply run on just about any modern windows machine. Feel free to use it as you like. To use, simply rename/SaveAs the file as a .bat instead of a .txt file in any text editor. If you have file extensions showing enabled you can just right click and rename as well. Note that with the default settings for the output file (C:\ directory) you might need to run the batch file as an administrator (right click, run as admin), depending on your operating system and account privileges. Simply change the directory to another place where you can easily write files to if this is an issue.


P.S. for what it is worth; my internet connection is far less stable than I thought it was. I am getting many spikes above 500ms roughly every hour, throughout all hours of the day and night. Less frequently there are spikes above 1 second. There are spikes between 200ms and 400ms roughly every couple of minutes. The "normal" ping time is 58ms for reference.

Thursday, July 17, 2014

Arduino Pulse Counter

Today I decided to create a computer interface for the geiger counter I repaired several years ago. It is a Black Cat Systems GM-45 that takes in 12V and outputs 12V pulses for each incident detection. It uses a russian mica window pancake tube, which is very sensitive. There were some issues with the HV inverter circuit when I bought it second hand, and they were easily fixed by simple component swaps. It was originally designed for RS232 communication, but this unit did not have a DB9 or DB25 connector on it, just flying leads. Likewise, it did not have the window exposed from the housing. I did the housing modifications when I first got it, but I'm debating remounting the board into a better enclosure and leaving the excessively fragile window enclosed and protected.

The hardware is simple, a 100nF dc blocking cap to block the ~2.4V DC bias on the output and a 10K:10K voltage divider to step down the ~9.6V to <5V suitable for TTL/USB communication. Corrected output is fed into the Arduino's pin3 and a ground/return wire is run between the arduino and GM detector for continuity.

The software was relatively straight forward for the counter. It simply increments a variable each time a pulse is detected and sends the total to the serial monitor at a set interval. Note that no delay command was used since it needs to count pulses while timing. I also programmed in an indicator LED to pin13 which had a built in led on the Uno. I had to code in hysteresis, which took me several hours, for this LED as the ~<10mS pulses are too short for our eyes to see well. This involved an entirely separate timer routine and some creative coding to toggle states efficiently.

Here's the links to download the .txt files with the arduino code.
General Purpose Pulse Counter

Note that the LED will appear continuous above about 30Hz. You can set the time period and make adjustments to better suit your needs, but remember that I'm only transmitting data from the arduino via the serial port, not to it, so you'll need to push new code for each change.

As well as this works I may look into picking up a cheap USB-RS232 converter and DC-DC converter to step up the 5V from USB to 12V so that I have a more compact all in one, always on radiation monitor. I don't want to tie up my only arduino, and as is this is taking my best breadboard and bench supply to power!

7/20/14 UPDATE: I noticed that when used for a geiger counter scaler that the readings were a bit high. When I was writing the program I was concerned that the entire loop might be executed so fast as to have multiple triggers for the same pulse. This was confirmed with single pulse testing. I revised the code to include a delay line that prevents multiple triggering. There is now a user changeable variable that sets a dead time before the arduino will count an additional pulse. This is set to 100uS by default but easily changed to suit your needs. For non square pulses keep in mind that the arduino's digitalRead triggers on about 2.0V, so just have it for as long as the waveform is above 2V. I've also revised the serial output code for better visuals when used as a geiger counter and added in the function of dose rate conversion. Simply put in the counts per microRem into the GMsensitivity variable and it will do the math for you. To not clutter things there are now two .txt files, one for generic counter, and one for geiger counter. Enjoy!

Wednesday, July 16, 2014

DIY Arduino Stepper Motor XY Laser Scanner

I've recently worked on a project that I had the parts for for quite some time, but never got started on. I salvaged this XY stepper head from a cheap chinese "laser show" which had no programmable inputs and a nonfunctional "auto sound" mode that would only repeat the same three patterns over and over again. The laser that was built into it had its pump diode die a thermal death a long time ago so I shelved it and planned on modifying it eventually.

I decided to look into stepper motors and their control schemes and found that it would be rather simple to code the subroutines for single coil per step movements on an arduino. Once I realized this, it was time to start work.

Now, steppers aren't particularly fast or accurate, especially at the upper limits of their speed, as they start to miss steps. I can get these cheap ones to about 2.75mS/step and no further without losing steps, but that's good enough for me.

Instead of driving the motors with an intermediary IC (or even an entire dedicated board) designed for stepper control I decided to just go discrete electronics with NPN bipolar transistors and small signal fast diodes for flyback recovery. I'm only driving one coil at a time since I don't have the pinout for the motor coils and it is a 5pin unipolar motor with common ground. It doesn't appear that it is two center tapped coils with common CT., but rather it looks to be four individual coils with tied ends. I know there are ICs that can use the two center tapped coils in a bipolar drive method to allow microstepping and such but I don't think that is possible with these steppers. The reason for the NPN BJTs is that the arduino can only sink or source 40mA maximum per I/O line and these steppers draw about 90mA @ 9V (and they're 12V steppers, but run down to 5V min).

I experimented with increasing the motor voltage in hopes of gaining speed, but no increase in accuracy or speed was measured between 5.7V and 12V. I found that I got the best results with a 2.75mS ontime and 250uS offtime.

Unfortunately the mechanical issues of rotor inertia, jitter, and flicker could not be eliminated. Only the simplest of designs could be reproduced without a large degree of error. Attempting to reproduce a number 8 results in two vertically stacked squares with a space in between them, tethered in the center. (see video #3).

For the amount of work it takes to get this poor result it isn't worth continuing further. It was a good exercise and a fun experiment if you ignore the 12hours or so of coding. I wrote nearly 2500 lines of code for this, and while most were just edited copy/paste, it was still a nightmare of a job. There are 64 subroutines written for motor advancement: 1 to 16 steps forward, 1 to 16 steps backward, each for two axes.

The code is straight forward; manually pulse each coil for a set time in grouped ordered bunches to produce movement. The Achilles heel is that this is completely open loop. There is no way to detect or remember what the last coil used was so when you go back to the same axis you have to manually insert code to bridge the gaps to ensure it doesn't inadvertently reverse steps or miss steps entirely.

For example:

void loop(){

Thus pulses coils as such: 1 2 3 4 4 3 2 1. Notice the double pulse of coil 4? This means the rotor will sometimes make 4 positive movements and then three negative ones, and other times it will make three positive and three negative, depending on where the rotor was when the first pulse to coil 1 hit.

If we wanted to fix this we would have to do as so:

void loop(){
  digitalWrite(1, HIGH);
  digitalWrite(1, LOW);

This pulses as such: 1 2 3 4 1 4 3 2 1. Now we'll always get four positive and four negative steps, but occasionally we'll get five positive initially, again depending on rotor position.

Consequently, the subroutine for xplus5 looks just like 1 2 3 4 1, so I would have just used it instead, but I wanted to illustrate the process more precisely. This example has a pre-written subroutine that fits in as a correction, but most transitions do not.

The hardware circuitry is simple, as this schematic and picture show:

Here's a link to the arduino code: 

Saturday, February 8, 2014

A Treatise on Audio Modulation of Solid State Tesla Coils

The question of audio modulation often comes up in the discussion of Tesla Coils. In the solid state world using conventional topologies for Tesla Coils there are a few methods of achieving audio modulation. It is important to explain the most common ones and contrast each in order to answer the question accurately. The short answer is YES IT CAN BE DONE.

1. Direct feedback signal modulation; FM: This is the method used in all VCO based designs such as the popular 4046PLL type. The frequency of the drive signal is varied around a set point, thus frequency modulating the drive signal. FM modulation of the drive signal relies upon the bandwidth of the resonator to perform slope detection to impose amplitude modulation on the output arc as the drive frequency moves away from the resonance point.
a) closed loop: Here the driver auto-tracks the exact resonant frequency of the secondary coil and uses this as the set point that the drive signal is FM modulated around. As the coil is always run at resonance, this has the best output power achievable. I’ve tested this but not published the results as they are unsatisfactory to my standards. The issue is that at exact resonance the Q of the resonator is so high that you don’t have adequate bandwidth for the audio signal. The result is that you get a highly garbled audio output as there is a different phase shift between the positive and negative half cycles of the audio. I found that by artificially lowering the Q of the resonator you can increase the bandwidth of the resonator to the point that clear audio is produced. By artificially lowering the Q I mean place a grounded object in close proximity to the toroid. Unfortunately my main TC that I used for this kind of experiment is still awaiting repairs after a primary overheat while running at 3200Watts. I’ve done some -almost equivalent- testing on my small coil which runs open loop, but since it is open loop I can’t tell if the bandwidth increase is completely from the lowered Q from the increased loading or if it is because the increased capacitance seen at the topload which consequently drops the resonance point, in effect raising the drive point above resonance.

b)open loop: Here the driver is basically just a VCO where the user adjusts the set point manually. This drive method is the most reliable and easiest to reproduce. This is the method used for my 4046PLLMod modulator. It has the inherent benefit that if something were to come in close proximity to the toroid that the resonance point will shift further down from the set point reducing output power further. This is a user safety benefit, not a user enjoyment benefit. Due to the way the phase shift between voltage and current occurs in multiple switch topologies used in the inverter (half or full bridge) the set point must never be allowed to be set below resonance. This results in an overly capacitive load which causes massive current commutation through the body and/or isolation diodes on the switches.
  •  Build consequences: The inverter must thusly be built to withstand occasional operation under these conditions. This requires the use of two high current ultrafast schottky diodes per mosfet. One diode is in series, forward biased, with the diode’s cathode connected to the fet’s Drain. The other diode is antiparallel with the series diode/fet combination; anode to the fet’s Source and cathode to the first diode’s anode. This blocks off the internal diode and reroutes reverse polarity current literally around the fet. If this is not implemented running the inverter in a capacitive environment will cause a quick and spectacular death of all the silicon involved.

Running the coil where set point equals exact resonance has the aforementioned affect of inadequate bandwidth for audio reproduction. As it is open loop attempting to manually lower the Q and increase bandwidth also lowers the resonant frequency, so one can’t be sure which and how much of which effect is actually yielding the increased bandwidth. In my own tests a very minimal frequency shift was seen and the equivalent shift is not enough to produce the increase in bandwidth seen. This confirms the theory that adding loading will reduce the Q of the resonator, and that such a drop in Q increases bandwidth. The one benefit that suggests further developments are required here is the same for the closed-loop method; the highest output power of any modulation scheme is seen.

Running the coil where the set point is a set frequency above the resonance point drops the Q of the resonator (at the actual drive frequency, the Q of the resonator to the resonance frequency is unchanged) to yield enough bandwidth for adequate audio reproduction quality. The distance above resonance needed is related to the slope of the frequency response of the resonator, and is thus a function of the resonator Q. Testing on my own coils have yielded that approximately 6.5KHz above resonance yields the best results. If you adjust the set point too far above resonance the slope appears more and more nonlinear, like adjusting a grid/gate/base bias down into cutoff. This has multiple results, primarily there is reduced power transferred to the secondary so there is a smaller output corona which is less able to reproduce the lower frequencies of the audio. The user will primarily notice a low frequency roll off as the set point is set higher. Secondly due to the decreasing linearity of the slope response of the resonator there will be reduced change in amplitude for a given change in frequency; less and less modulation is seen in the output corona. It is thus that the user should determine the resonance point by running the coil in closed loop mode with a stable, reliable, repeatable feedback network and record the resonant frequency. Then a transition should be made to the open loop FM modulated drive signal and the user should adjust the set point to where the audio quality sounds its best. It is best to use a high bandwidth selection of audio/music for this process. The user must take care to observe proper high voltage high frequency/RF isolation practices if the adjustments are to be made while the coil is in operation. Moving the set point into the capacitive region below resonance can be identified by a harsh tone in the output corona when no modulation is present. An at-resonance or above-resonance (inductive) environment can be identified by a near-silent hissing coronal output. Good DC bus filtering of ripple is thus necessary to eliminate any hum from the bus input rectification. As the set point is adjusted up from resonance the bass frequencies will strengthen and begin to reduce in distortion. The optimal set point can be identified as the point where bass response is still strong yet there is little to no distortion. If the output is observed on an oscilloscope one can set the time base to where the RF envelope is displayed and bass frequencies will stop appearing to be clipped (flat-topping). At the optimal set point there will still be a noticeable drop in output power compared to driving at exact resonance, but this is not always a detriment, as it allows for longer run times. After all, what good is perfect audio modulation, if you can’t even play a whole song on it!?

2. Drive signal gating - a.k.a. PWM Modulation: This is the method most often employed as it requires the least difficulty in implementation, and the coil is inherently run at a lower duty cycle than CW. This method requires the use of gate drive chips which have an enable input. As the feedback signal is effectively interrupted to produce the amplitude modulation in the output there are times where feedback is lost. This requires the use of a self-starting or self-pinging driver. This is why discrete gate drive cannot be used unless a complex network of logic gating is used to detect when no feedback is present and then ping the discrete gate drive to reinitialize oscillation and feedback. Thankfully Texas Instruments offers complementary gate drive chips which will operate at very high frequencies and very high peak currents that have enable inputs; the UCC37321 and UCC37322. The PWM modulation can be implemented by a number of methods, but the TL494 and SG3525/KA3525 chips are the most commonly used. I’ve successfully used the KA3535 chips in my own tests. The PWM carrier frequency must be chosen to be sufficiently high enough as to render it inaudible to human ears and also be high enough that accurate reproduction of the audio signal’s harmonic content is achieved. If the frequency is too low the effective bandwidth is insufficient for quality audio. This in practice means that the carrier frequency must be above 48KHz or so. Now, as we are interrupting the CW operation of the SSTC we will see a greatly reduced output corona, and in fact if one were to try such a "low" carrier frequency like 48KHz there would be little to no human-detectable output. As the carrier frequency approaches reciprocals of the resonant drive frequency the output of the SSTC will begin to increase. For example, for a 340KHz resonant drive frequency an output maxima will be observed around 113KHz PWM carrier frequency. The exact carrier frequency will need to be adjusted manually to shift IF (intermediate frequency) and BF (beat frequency) harmonics out of the range of human hearing, or loud squealing will be heard in the output. The trick is thus finding a carrier frequency that has enough bandwidth to reproduce the audio with sufficient quality, while having harmonic content of unwanted frequencies outside the range of human hearing, and simultaneously producing a strong enough amplitude corona output to get faithful and audible reproduction of the modulation signal at the output. In my own tests with a 340KHz resonant SSTC and a PWM carrier frequency range of 48KHz-250KHz there were several maxima nodes between 80KHz and 180KHz (which correspond with reciprocals of the drive frequency), and at the "best sounding" of them the audio reproduction quality was significantly less than that achieved by FM modulating the drive signal. Likewise, even when at the strongest power output maxima in that range, the actual output power was less than seen by the FM modulation scheme. More experimentation and developments are required in determining the effect and optimal pulse width set point that the PWM modulation uses. The optimal set point for pulse width depends on how much of a pulse width increase a full scale deflection input signal produces, but the biasing of the set point would be similar to the biasing in a class-A amplifier, where you want to use the highest set point that keeps the signal within the linear region. Given the relationship between secondary resonance frequency and PWM carrier frequency one can postulate that higher frequency SSTCs would benefit more from this topology, except in the case in which the PWM carrier frequency can be made to be the resonant drive frequency, but then we are no longer performing feedback/drive signal gating! In that circumstance it would be best to use a 50% duty cycle PWM set point and keep the modulation to acceptable limits so that the inverter is not driven far from 50% duty cycle pulses.

3. High Level Bus Modulation - Class-H: In this methodology we AM modulate the supply rail via a modulation transformer, as was done in the old days of Tube AM transmitters. The trick here, is to find, or make, a modulation transformer that has the required low impedance to current at the resonant drive frequency of the secondary, yet can handle the large DC current draw of the primary. This is NOT an easy task. I have yet to succeed in this method because of the difficulty in locating a sufficient transformer. Also, because of the large voltage swing needed on the supply rail to produce a sufficient modulation of the output corona a relatively high power amplifier must be used to drive the modulation transformer. Unlike with thermionic valve technology where the vacuum tubes were inherently high impedance devices, the modern SSTC is a low impedance device, so transformer parameters used in the olden days will not suffice, even though the concept of the overall topology is the same.

In the end all methods of audio modulating the tesla coil are all endeavors of AM modulating the output, either directly, or by utilization of slope detection by the resonator. More complex and less common methods are often employed in such topologies as the Single-Ended Class-E or Class-D/E Half-Bridge, but their operation is too complex to discuss here, and is often considered esoteric by most tesla coilers. I’ve even read about an experiment where audio modulation of the output was produced by placing a variable resistive load (class-A operation transistor) in parallel to the primary coil. Such methods always remind me of the quote by Einstein in reference to nuclear power technology: "Hell of a way to boil water!". Though the subjects are far removed, the idea is the same; extreme lengths are taken to do simple things, with efficiency often overlooked.



Wednesday, January 15, 2014

Sig's ATTiny85 SSTC Interrupter

In preparation for offering an interrupter kit to go along with the USSTCC (sstc controller kit) I got the first batch of ATTiny85 chips in today. So, I spent the day porting my program over to a standalone ATTiny85. I'd tested and proven my code on both Digispark and Arduino, so I knew it was solid, but there's always glitches when changing processors. It turned out to be the same naming glitch that pops up with the Digispark; ADC 1 is real pin 7, which is pin 2 in datasheets, which is actually pin "A2" in code. Aside from the code aspect I had to build an ISP programming board to mate the Arduino UNO to the ATTiny85. Simple stuff but still needed doing.

Everything checks out and things are a GO! I only ordered 3 MCU chips, and I have need of one myself. I accidentally bricked one by making a dumb mistake on the breadboard and connected ADC3 up to V+ instead of the regulated Vcc line, DOH! No worries, they're cheap, the code is solid, and my ISP (programming tool) is all set. So, only one will be for sale, much like with the first three USSTCC boards, lol (3rd board wasn't bricked there, but given to my design partner).

Here's the ArduinoIDE (C++) code for the Interrupter program. https://app.box.com/s/93dt6fso6wj3tvx13m7b
Here's the application schematic: https://app.box.com/s/qilqivytxbots3hxummh

Here's the BOM (Bill of Matierals): https://app.box.com/s/zn1vb0li8lxpviw0a9cn

Video showing low power testing with the Digispark version:

Tuesday, January 14, 2014

Building a ca.1928 Dual Triode Class-A Audio Amplifier

This is another recap of a previous project.

Basically the task came to me to clean up an old Victrola Radiola audio cabinet from 1928. The phonograph worked fine so it was left be, but the radiola (the AM radio) was toast. I figured I might at best get a few tubes to play around with or just a couple of inductors. It turns out nearly all of the tubes were good, and the PSU worked fine, but the tuning coils and caps were wrecked. I spent a bit over a week going through various experiments with the old tubes and modern tech to see just what all I could do with the parts I found. Here are the data files and the videos of progress:
Power Supply and Output Coupling:
RF amp, tuning, and AF amp "final" sections:

Simplified schematic:
Modified schematic showing rebuild as dual triode Audio Amp:
Videos detailing the various incarnations and progress:

Final Result:
The trickiest part, which is not on the last schematic shown, was finding a good negative feedback scheme (NFB) to try to balance the frequency response (enhance bass response by impeding treble's gain) and cut down on some of the hum. Unfortunately not all of the hum can be removed without remaking the entire power supply section, because these triodes are directly heated cathode tubes (filament valves) powered by AC, so since the filament IS the cathode the AC on the filament is imposed on the output by design. One has to remember that back in 1928 having sound come out of a box without a little man inside it was AMAZING, and having hum was of no consequence.
NFB on thermionic amplifiers simply involves taking some of the antiphase output from the output transformer and feeding it in to either the grid or the cathode (most often the cathode) of first amplifier stage. This is as simple as a resistor and a capacitor in series between the antiphase leg of the output or impedance matching transformer and the pre-amp triode's filament. I can't remember the values I used, but that info is of little consequence really.
What all this really shows is that triode class-A amplifiers are SUPER SIMPLE if you can find the right parts. The real unspoken hero here is the interstage transformer that takes the output of the first triode and couples it to the grid of the second triode. This is a job of both precision impedance matching and voltage transformation. There are no modern equivalents to get off a shelf. Interstage transformers were abandoned in the 30s for the most part when capacitive coupling was chosen as its successor. Using capacitive coupling is far cheaper, but it does require the engineer to figure out a proper value of anode resistor. The resistor forms a voltage divider with the tube, think of it this way; the tube becomes a variable pull-down resistor. The capacitor then couples off the dV (change in voltage) seen at the voltage divider output node. This scheme may be much cheaper to implement but there is a marked reduction in gain to having a series transformer directly couple the output. Such is the way of technology progression though.


How to Phase your Gate Drive Transformer (GDT)!

My video on the subject pretty much explains it. Simple stuff, but none the less needs to be learned from somewhere. https://www.youtube.com/watch?v=blQ9o7bRZd4

Monday, January 13, 2014

Arduino: High Quality Audio Modulated PWM

This project shows how to increase the clock speed of the Arduino UNO's ADC Analog pins to allow for a 77KHz sampling rate (up from the default ~10KHz), and increase the PWM carrier frequency on the PWM Digital Output pins to 64KHz on pins 5 and 6, or 32KHz on the other PWM outputs. This sampling rate is higher than your PC's audio card inputs!

This allows one to use an arduino UNO as a high quality audio PWM modulator. For the purpose of demonstration I have terminated the PWM output into a Low Pass filter to show the demodulated data, but in practice one would feed the output from the arduino to a Class-D type amplifier for amplification, and then feed that output into a Low Pass filter for data/signal recovery. This lends itself well to audio modulating a flyback transformer, as most flybacks perform well around 60KHz. One could simply feed the arduino output to a BJT totem or MOSFET gate drive chip like the TC4420 or UCC37322/UCC37321 pair or the dual inverting/non-inverting UCC37325 to attain the needed voltage and current amplification for driving power transistors (MOSFETs or IGBTs). Such an implementation of Arduino -> UCC37325 -> Half-Bridge Inverter -> Low Pass Filter is the basis for a super simple high powe audio amplifier. In this way the arduino emulates such chips as the SG3525 or TL494 without the complicated wiring needed to actually use one of these chips, as most of the work is done natively on the arduino.

The only components needed to get high quality audio modulated PWM out of the arduino UNO are two (2) 10k ohm resistors and one (1) capacitor. For the capacitor the higher the capacitance the better, and if you can get a nonpolar one all the better. The reason for nonpolar is that depending on what audio source you are hooking the arduino up to you need to know which has a higher DC bias; the arduino's 2.5V DC offset bias formed by the 10k resistors or the output of your audio source in order to properly install a polarized capacitor. If you can find a nonpolar capacitor, it doesn't matter which way you orient it. The larger the capacitance the better the bass response.

Example 1: iPod audio source.
Your iPod has no DC offset on its output so the arduino's 2.5V DC Offset Bias is higher, thus the positive terminal of the capacitor has to go towards the arduino, and not towards the iPod.

A -+2Vpk (4Vp-p) maximum audio signal can safely be input into the arduino, and the software is built around this. The code is dead simple though so it can easily be tweaked in software to allow for stronger or weaker modulation, but it is even simpler to just turn up or down the volume of the audio source.

Here is the input/output schematic detailing the resistor divider and DC-blocking capacitor on the arduino input, and the Low Pass filter on the output needed for signal/data recovery. You will find that this filter attenuates frequencies within the normal range of hearing. To get a better high end response simply reduce the value of R3 in the schematic. I experimented with values between 100Ohms and 1Kohms but found that too much carrier frequency (actually lower sidebands) was present for my liking below about 300Ohms. https://app.box.com/s/9vmqh8t2sistwftvd2qx

Here is the arduino code for this program. Most of the magic happens in the void setup() block, as this is where the I/O speeds are increased. The void loop() block just has some basic signal processing math and feeds the processed data to the output pins. https://app.box.com/s/3rjij1fn8aurobbg10ve
Here is a video I uploaded showing it all in action. Forgive the poor audio quality shown; it is an artifact of the audio amplifier used, not the arduino. I didn't have a spare speaker or amplifier laying around other than my 1928 Dual Triode Vacuum Tube Audio Amplifier I built, which has a nasty 60Hz hum and nonlinear frequency response. https://www.youtube.com/watch?v=KNjaSJa6mf4

The nice thing about using a real SG3525 or TL494 is that you can easily set the carrier frequency with external components. In the case of the SG3525/KA3525 you have a range of up to 400KHz. The arduino emulation works great for when the carrier frequency doesn't really matter (other than being high enough to easily filter out) like with audio amplification. 

Sunday, January 12, 2014

Blog Inception!

Hey everyone, this blog is brand new. Over the coming [insert period of time] I'll be updating this blog with the results of my various projects and experiments. This will be a place to find out what I've been up to as well as get the important data and information on things I've developed.