![]() |
| Figure 1: Power/VSWR meter using ИН-13 neon bar-graph indicators. This was taken prior to installing the dark plastic to improve contrast Click on the image for a larger version |
In this - the final installment - we'll see how it all goes together.
* * *
As I'm wont to do, I used a PIC microcontroller for this - chosen because I'm more familiar with it than something like an Arduino - and something more "powerful" (an ESP or similar) would be overkill and arguably more difficult to implement as we'll see.
In the PIC environment I have used - for decades - the PICC compiler by CCS (Custom Computer Services) having started out with a very early compiler of theirs. Programming in K&R C allows me to get pretty close to the "Bare Metal" of the microcontroller where I tend to write in low-level code and extensively use the interrupts and state machines to get things done.
Before delving right into details about the code, let's first look at the remainder of the schematic - and rather than make you, the reader, go back and look at previous installments, I'll include them all below in their entirety, starting with the controller and power supply.
![]() |
| Figure 2: Schematic of the controller and LV and HV power supplies. Click on the image for a larger version. |
The controller that I chose for this is the PIC18F1330 - an device in an 18 pin package that sports a built-in clock to permit operation at 32 MHz with no external crystal, PWM generators and a multiplexed 10 bit A/D converter.
High voltage control
As can be seen, "PWM1" is connected directly to our high voltage transistor, Q301 which is used to do a voltage boost, with R301 - a pull-down resistor - used to turn it off when the processor is in an indeterminate state. As mentioned before, I tend to use state machines and interrupts heavily in my microcontroller code and with a PWM frequency of 31.25 kHz to generate the high voltage, I also have the interrupts occurring at that same rate, driven by the same clock source as the PWM.
Within the ISR (Interrupt Service Routine) there is a state machine that reads the A/D inputs - namely the high voltage, the forward power and the reverse power - but there's a catch here: There is only ONE actual A/D converter - and this poses a problem. Generating a stable high voltage requires a closed loop feedback - and with a processor there's always going to be a bit of delay, but what's worse is that since we have only a single A/D converter we must constantly switch it between the three voltage sources that we must measure - but this has several steps:
- Set the A/D channel. After doing this we must wait for a time for the A/D MUX switch to settle - but we can't afford to sit and "spin our wheels" in the ISR as we don't have the time: While we are in our the ISR we really can't do much else.
- Start the conversion. Once our MUX has settled we can safely start our conversion. This takes much longer than setting the A/D channel - but much shorter than our ISR period.
- Get the result. On the next ISR cycle the A/D converter will have finished and we can put the result in memory and set flags to indicate to the rest of our code that it's ready to be processed.
- Note: At this point we can conserve time a bit and upon getting our result, we can set the A/D channel for the next conversion: This means that we get a new A/D reading every other ISR cycle.
To minimize "lag" in our closed loop voltage control, I do the following "gets" of analog data:
- Get the HV reading
- Get the Forward power reading
- Get the HV reading
- Get the Reverse power reading
By alternatively grabbing the high voltage reading every fourth ISR cycle we can use this information to "tweak" the PWM duty cycle: If the voltage is too high, we reduce the duty cycle slightly and if too low, we increase it - and this adjustment, within the ISR, is triggered by a flag that is set every time we get an update of its voltage.
Before we leave the discussion of the high voltage generator I'll note that it's triggered by the detection of RF:
- Immediately on the detection of RF from the transmitter, the high voltage generator is activated.
- About 3 seconds after the last detection of RF from the transmitter, the high voltage generator is turned off.
According to the specifications, these neon tubes have only a limited lifetime - as is the case with any gas discharge tube that is glowing - so it makes no sense to "wear them out" unless there's information (e.g. a reading of RF power) to be displayed. Additionally, the high voltage generator in my unit produces a just audible bit of RF interference in the form of weak "birdies" spaced at the 31.25 kHz PWM interval - and shutting off the high voltage generator soon after transmitting has stopped prevents their being heard.
Backlight control
Let's now look at the diagram of the backlight drivers.
![]() |
| Figure 3: Tube and LED drivers - along with buffering from the power detectors. Click in the image for a large version. |
As can be seen there are three LED backlight drivers: One for the Forward power using white LEDs, one for the Reverse power power using blue LEDs and another for the VSWR using Green LEDs. In order to adjust the brightness, these are also driven by a PWM signal that is smoothed and fed to a the same sort of "precision current sink" circuit using an op amp and transistor as the Neon tubes themselves.
While there are other PWM channels on the PIC18F1330, I chose to use a "software" PWM as I already had available a rather fast ISR (31.25 kHz) that would be able to provide a smooth enough control voltage: As can be seen in Figure 3, a 150k resistor and 0.1uF capacitor (e.g. R501 and C501, respectively for the "FWD" channel) are used to smooth the PWM signal - the two components providing a time constant of about 15 milliseconds (67 Hz). In the ISR the "software PWM" uses 128 steps and at the 31.25 kHz rate this yields a frequency of about 244 Hz - about 4 times that of the R/C filter making it pretty much flicker-free while allowing a fast response time.
The way the "software PWM" works is that in the ISR there's a counter that goes from 0-127, and the value of this counter is lower than or equal to our desired PWM (brightness) value, the corresponding PWM output is turned ON - otherwise if it OFF.
Dimming LEDs in a "believable" way
Before moving on from the LED brightness control, it's worth mentioning something about the way the human eye perceives brightness. While the actual LED brightness varies quite linearly in proportion to the PWM setting of 0-127 (off to fully "on"), if we wanted to slowly dim the LED from full brightness to off - and we simply decremented the value from 127 down to 0, our eyes would perceive it as dimming slowly at first - and then suddenly going out. Perhaps it's my OCD kicking in, but I prefer a dimming LED to seem to fade out to nothing - and do so gradually without it perceptibly "snapping" off.
My intent is that when RF power is detected, the relevant backlight LEDs (always the "Forward" LED and the "Reverse" or "VSWR" as selected) are immediately turned on - but 30 seconds after RF is detected they are turned off. As I found a "sudden turn-off" to be visually jarring, I decided to dim the LEDs slowly - but based on past experience with driving LEDs I knew that to make them visually dim "evenly" would require a bit of extra math.
The trick here - to set the dimming so that it seems to gradually fade out to nothing - is to use a fourth root and a bit of multiplication as follows:
- Start with the brightness value of 0-127
- "Invert" this value by subtracting it from 127 (now it's 127 to 0)
- Multiply by 128 (this can be done by shifting the bits left seven times if using an unsigned integer)
- Take the square root
- Multiply by 128 again
- Take the square root again
- Subtract that value from 127
Calculating the RF power and VSWR
One advantage of using the AD8307 logarithmic amplifiers is that it gives us a reading in db per volt to the tune of about 25 millivolts per dB - and we can calculate return loss very easily - simply by subtracting the reverse from the forward readings.
Return loss - while representing reflected power - is not how most hams think about reflected power - and VSWR is voltage - not power. What we need to do is to translate our return loss to VSWR and the easiest way to do this is with a table - rather trivial to do in a microcontroller. As we don't really need a lot of resolution on our VSWR meter (it's enough to represent "tenths" of a VSWR reading between 1.0 to 3.0 - and subsequently lower resolution than that at higher VSWR) the table need only consists of a couple dozen entries in the form of cascading "if-then" statements that spit out the VSWR directly.
We could do it with logarithms and floating point math, of course, but that's overkill!
As for calculating power in watts, there's no need for this: If you look closely at the Forward Power scale in Figure 1 you'll note that it is already logarithmic: The A/D values are simply offset and scaled to the PWM values needed to drive the tubes to the designated markings!
Peak and average values
As the power level of an SSB waveform is very "peaky", most analog meters only provide something roughly resembling an RMS value since they cannot move fast enough to capture the peak. As we get new forward and reverse values every eight ISR cycles our update rate for the power readings is around 3.9 kHz.
As the bandwidth of a standard SSB signal is on the order of 2.5 kHz, we are sampling our power more frequently than its fastest rate-of-change and this means that not only are we likely to be able to capture a reasonably accurate representation, but also be reasonably assured that our forward and reverse power reading samples - which are about 128 microseconds apart - will also represent the same part of the the waveform: Were this not true the VSWR readings could be "smeared" with the power changing between the instants that the forward and reverse power samples were taken.
As it happens, we really don't need the ultimate in temporal resolution for VSWR, so the calculation of "return loss" can be averaged a bit with no ill effects - and, in fact, the VSWR reading is quite stable at the widely disparate power levels intrinsic to SSB, anyway.
The code itself does have "peak" and "average" modes and the former uses a "sliding peak" detection - that is, it has a bit of a "hang time" on the output sent to the forward and reverse power displays to better-indicate the peak value and visually hold it. The "average" power is more of a "sliding average" over the past hundred milliseconds or so and results in a "busier" display, with more movement.
Tube calibration
A quick look at the data sheets for the ИН-13 tubes will reveal that they are not well calibrated in terms of "milliamps-per-millimeter" with a fair bit of variation being allowed. The ИН-13 tubes have lines painted on them at the factory indicating the "low" end (near the wire pinch) and the "high" end (near the tip) and these represent the useful and linear range over which the current can be represented.
The firmware thus includes - for each tube - a set of calibrations, accessible by the "mode" buttons in Figure 2 - that can be used to set the bottom and top of the scale. This process will yield the needed PWM values - and thus the current - for the low and high end of the display and in so-doing, our microcontroller will "know" how to scale each tube to indicate with the best-possible accuracy.
Having been using this device for several years, now, I have observed that the tube sensitivity changes more with temperature than aging - but as it's not intended to be a "precision" indicator of power: I only check the bottom/top scale calibration every year or two and have resisted the temptation of including temperature compensation.
Final comments
The only change that I made to this device after its construction was to add a sheet of 70% (dark) theater gel in front of the display to improve contrast. While the neon tubes themselves and the laser-etched plastic look cool on their own, the display looks a bit "cluttered" unless a somewhat dark piece of plastic covers everything: While this does dim the display a bit, the dark plastic - since it affects both the incoming and reflected light - offers the illusion that the display is brighter as the contrast is improved.
If you have any questions about this project (including underlying code and/or hardware) please let me know via a comment, below.
* * * * *
This page stolen from ka7oei.blogspot.com
[END]




No comments:
Post a Comment
PLEASE NOTE:
While I DO appreciate comments, those comments that are just vehicles to other web sites without substantial content in their own right WILL NOT be posted!
If you include a link in your comment that simply points to advertisements or a commercial web page, it WILL be rejected as SPAM!