An FPGA SDR HF Transceiver, Part 9 -- A 50 dB HF RF Power Amplifier

In this ninth blog post in my FPGA SDR transceiver series I will describe the RF Power Amplifier used to amplify the FPGA SDR's 0 dBm (1 milliwatt) output signal up to 50 dBm out (100 watts).

(Part 8 of the series is here: Part 8).

The HF RF PA is shown above, below the K6JCA FPGA SDR transceiver.

Before I begin, let me again acknowledge Dick Benson, W1QG.  Dick is the father of this FPGA SDR design, and although I've made some modifications to the FPGA logic, the underlying architecture and the vast majority of the Simulink implementation is Dick's.

A note regarding the schematics...

These schematics were drawn using the Lite version of Cadence's Orcad Capture.  This is the free version of the program, and it limits a schematic's number of nets to 75 and the number of parts to 60 (limitations which apply if you want to save the design, which I always do).

Because this radio design has many more nets and parts than the 75/60 limit specified by Cadence, I have broken the overall design into smaller "bite size" schematics, each  independent of the others and each drawn on a single A-size sheet.

But because I've broken up the design into smaller independent pieces, I can not use Capture's Design Rule Checker to check the overall design for design flaws.  Therefore, there is the possibility that errors have crept into the schematics.  So be aware!

Note:  This Post in a Work in Progress and thus

Not Yet Finished!

Summary:

The HF RF PA amplifies the FPGA SDR's 0 dBm output signal up to 50 dBm (100 watts) in two stages.  The first stage is a PA driver amplifying the TX signal by about 30 dB (from 0 dBm to 30 dBm), and the second stage is a Power Amplifier that amplifies the 30 dBm signal from the driver  by about 20 dB (depending upon band) to achieve the final output power of 50 dBm (100 watts).  This second stage consists of a Flexradio SDR-1000 PA Module from an SDR-1000 transceiver.

PA voltage is 14 VDC (or, if one prefers, 13.8 VDC).

You might be wondering -- why did I install the 30 dB driver stage in this amplifier chassis and not in the FPGA SDR transceiver chassis?

The main reason is: control of the 30 dB driver's load impedance.  The SDR-1000 PA's input impedance is not 50 ohms (at least, not on the higher bands).  Thus, if there is a length of 50 ohm coax between the driver's output and the SDR-1000 PA input, the 30 dB Driver's load impedance will change as a function of coax length.

So, I thought it better to have this length of coax be fixed, rather than be some unknown length, so that system performance would not vary depending upon whatever random length of coax I might happen to use to connect the FPGA SDR transceiver to the PA, if the 30 dB driver were in the transceiver rather than PA chassis.


Block Diagram:

(Click on image to enlarge)

Notes on Block Diagram:

• 50 dB of amplification is achieved with a 30 dB Driver followed by a 20 dB PA.
• The 20 dB PA is an SDR-1000 PA Module (Flexradio transceiver).
• The FPGA SDR transceiver controls the driver and SDR-1000 PA module via an 8-wire (plus shield) parallel interface, implemented with an RJ-45 connector.  This interface selects the appropriate band-specific low-pass output filter and also carries the T/R signal.
• The 30 dB driver is switched in-line during transmit.  During receive this driver is bypassed, and the RF In and RF Out connectors are connected together without any amplification or filtering in-line -- the receive signal pass directly from the "RF Out" connector to the "RF In" connector (and to the FPGA SDR) without modification.
• 14VDC from the rear panel goes directly to the SDR-1000 PA, where it is fused (25A fuse).  Following this fuse the 14V can power external devices (such as the FPGA SDR) as well as internal circuitry within the PA chassis.

Schematics:

Back Panel Schematic:

(Click on image to enlarge)

Notes on Back Panel Schematic:

• Several connectors are not used (at this time), but have been installed in anticipation of their incorporation.
• At the moment, the fan voltage is set to about 7 volts (via the resistors) to ensure that it isn't too loud.  In the future I would like to add a temperature sensor (to the PA heatsink) and use that sensor's output to control the fan's speed.

RJ-45 Control Interface Schematic:

The FPGA SDR controls the HF RF PA via a parallel interface, implemented with an 8-pin shielded RJ-45 connector:

(Click on image to enlarge)

Notes on RJ-45 Control Interface Schematic:

• The RJ-45 cable must be shielded, as this shield carries the ground-return for the control signals.
• All 8 wires are connected, although only 7 are used to carry signaling at this time.  (The unused eighth wire is there in case I need to add additional functionality in the future -- for example, if, for some reason, I need to differentiate between between bands that, in the SDR-1000 PA implementation, are paired to share a common low-pass filter at the PA output (e.g. the band-pairs  60/40, 30/20, 17/15, and 12/10 meters).
• All control signals have simple 1-pole RC low-pass filters to help block external RF from the internal circuitry.  ESD control is also handled with 5V TVS devices (note that the R in the RC filters will current-limit ESD hits on any line).  ESD protection isn't really required in a "one-off" design, but adding such protection was required in a number of commercial products that I designed.  I believe it is a good design habit to have, and I've carried this practice forward into my personal designs.

PA Interface Schematic:

The PA Interface provides the necessary circuitry to allow the RJ-45 interface signals (from the FPGA SDR) to control the PA and PA Driver.  It also provides an interface for internal control to allow this amplifier to be used in stand-alone applications -- control would be handled via front-panel switches (i.e. selecting low-pass filters) and an external T/R input on the back panel -- but note that, at this time, "internal control" of the amplifier has not been implemented.

(Click on image to enlarge)

Notes on PA Interface Schematic:

• The "External Control" connector attaches to the RJ-45 Interface (see earlier schematic) via a 16-pin cable, and it is the port through which the FPGA SDR controls the PA.
• The "Internal Control" connector can connect "local" (front-panel) controls to the PA and thus could allow the amplifier to be used in stand-alone applications without the FPGA SDR transceiver being attached to its "External Control" interface.  (At the moment, though, there are no "local" controls).
• Given that there are no "local" controls at this moment, J16 should be shorted -- this signal, when low, tells the FPGA SDR transceiver that it is connected to the PA.  (If there were local controls, this signal would be forced high if the PA were placed in "local" mode, rather than in "FPGA SDR" Control mode).
• The nPA_EN signal at J8 is not used -- I had intended to have the FPGA SDR drive this signal, to turn ON the bias regulator on the SDR-1000 PA Module (via J5 pin 9), but there was too much current, and thus too much voltage drop, through the various 100 ohm resistors in my EMI-mitigation low-pass filters that I decided to remove this function.  Instead, J5 pin 9 now connects to the drain of Q8, a 2N7000 that, during Transmit, pulls J5 pin 9 low and turns ON the PA bias.  Header J18 is there in case I want to force the PA Bias to be ON (by shorting the two header pins).
• At J5, the PAF0 - PAF2 bits select the SDR-1000 PA module's output lowpass filter (per the table shown on the schematic page), while PATR is the T/R signal (high = transmit).  These signals are driven by a ULN2003 IC in the SDR FPGA radio -- an open collector driver which inverts them from their "high-true" sense, and these signals are inverted here again (back to their original sense) using 2N3905 PNP transistors.  Bypass caps across the transistors' base-emitter junctions, as well as from the collectors to ground, to shunt RF off of these lines (or junctions) and thus help mitigate any issues caused by RF pickup.
• At J8, nEXT_CTRL is meant to allow the FPGA SDR transceiver to force the PA into "FPGA SDR" control mode, if it had been set to "local" control mode via the PA's (currently non-existent) front panel controls.
• At J7, nDRVR_BYPASS is meant to allow the 30 dB Driver stage to be bypassed (when in "local" control mode), in case this PA were to be used in a stand-alone application for which that extra 30 dB of drive was not needed -- for example, to amplify a 1 watt QRP transceiver's output.
• At the moment the 5V connector, J17, is not used.  It is there to power any "Internal Control" circuitry that I might want to add to this design in the future.
• I'm not using the FlexRadio PA's directional coupler (with its on-board ADC), so the three control pins for this ADC (located at J5, pins 4, 5, and 6) are all pulled HIGH.

PA Driver Interface Schematic:

The PA Driver Interface switches the PA Driver into and out of the signal path.  During transmit it is in the signal path, and during receive it is bypassed.

(Click on image to enlarge)

Notes on PA Driver Interface Schematic:

• The PA Driver (discussed below) is powered by 12 VDC (the OPA2674's "Absolute Maximum" power supply rating is 13.0 VDC) , and I use an LM2940 low-dropout regulator (LDO) to create 12 volts from the 14 volts used to power the PA.  But note that this LDO is actually mounted on the PA Driver board heatsink, not on the PA Driver Interface board.
• LDO regulators can suffer from loop instability and usually require that the ESR of their output capacitor(s) be within a certain range (refer to section 8.2.2.1.2 in the LM2940 datasheet).  I'm using a Kemet T491D476M016AT 47uF, 16V, Tantalum cap, whose ESR is spec'd at 800 milliohms.
• 1N4148 diodes clamp the back-voltage across each relay coil when that coil is "released".  

PA Driver Schematic:

The PA Driver provides 30 dB (or so) of low-distortion amplification of the FPGA SDR's 0 dBm output signal.

(Click on image to enlarge)

Notes on PA Driver Schematic:

• The PA Driver is based upon the driver in the HPSDR Pennylane board, designed by Phil Harman (VK6APH) and Lyle Johnson (KK7P).  Link to the Pennylane schematics:  https://openhpsdr.org/wiki/images/3/31/Pennylanea1.pdf.
• Refer to the other notes my schematic, above.

Front Panel Schematic:

The front panel is simplicity itself and consists only of two LEDs.  A green LED illuminates when the PA is powered up, and a red LED illuminates during Transmit.

(Click on image to enlarge)

(No notes on the Front Panel Schematic.)


FlexRadio SDR-1000 PA Mods:

While testing the PA Module in my chassis I discovered that the FlexRadio PA's LPF-select relays would chatter (or erroneously turn ON) on some bands, at some power levels.

To help quench this RFI issue, I stiffened up the filtering on the three PAF bits (used to select the LPF to be used for a specific band) by paralleling the existing 10 NF caps with 100 NF caps.  (These signals can be heavily loaded with capacitance because their timing is not critical -- they only change when the user selects a new band).

The modification is shown, below.

(Click on image to enlarge)

Implementation:

I built the PA into an old HP 37203A HP-IB Extender chassis (this is the same type of chassis that I used for the FPGA SDR transceiver).

Top View:

Notes on Overall Implementation:

• The PA Interface board and the SDR-1000 PA Module are mounted on a piece of PCB copper-clad board that serves as a bottom mounting plate.
• The PA Driver and PA Driver Interface are mounted to the side of the chassis.

Driver and Driver Interface:

Notes on Driver and Driver Interface Implementation:

• The LM2940 LDO is at the left of the picture above, soldered to a copper sheet used as a heatsink.
• The copper sheet also bends up and is soldered to the PA Driver board -- several pennies are soldered to the copper plane on the backside of the Driver board (under the OPA2674 drivers) to conduct heat from the back of the board.  The copper sheet is soldered to the other side of these pennies.  Thus, heat is conducted from the back side of the driver board, through the pennies, and to the copper sheet which is screwed to the HP chassis side rails.  (Note that pre-1982 pennies have a much higher copper content than later pennies, and thus I prefer them for their heat transfer characteristics).

Back Panel:

(No notes on the back panel.)


PA Interface:

Notes on PA Interface Implementation:

• There are some surface mount LEDs visible -- these are not used.
• This picture was taken before I added the three PNP inverters for the three PAF signals.

Notes on Performance:

1.  DAC rolloff:

The frequency response of Digital to Analog Converters (DACs) is not flat, but rolls off according to the following sin(x)/x formula:

H(f) = sin(πf/f_s)/(πf/f_s)

Given the FPGA SDR's sampling rate (f_s) of 80 Mega-samples/second, then the DAC output will be down 0.5 dB at 14.35 MHz, 1.0 dB at 21.2 MHz, 1.4 dB at 24.7 MHz, and 2.1 dB at 29.7 MHz.

 (For more on DAC sin(x)/x rolloff, go here: https://www.maximintegrated.com/en/app-notes/index.mvp/id/3853 or here:
http://www.atx7006.com/articles/dac_frequency_response


2.  PA IMD Measurements:

(Click on image to enlarge)

(Click on image to enlarge)

Notes on PA IMD Measurements:

1. I'm only going to measure 3rd order IMD, not higher orders.
2. The value "% of Max SDR Drive" is the amount of "possible" drive (in terms of voltage level) from the SDR's transmitter that, with this SDR-1000 PA, results in 100 watts out (roughly).  Note that the maximum output from the SDR FPGA is 0 dBm (and this drops slightly as frequency increases due to sinx/x rolloff).
3. "Power Out" is measured with an LP-100 Digital Vector RF Wattmeter.
4. The "Two-Tone Fundamental" is the measured amplitude of one of the two two-tones on the HP 8568B Spectrum Analyzer.
5. The "Delta to 3rd Order Spur" is the delta in amplitude from either of the two-tone amplitudes (the value in the previous column) to the 3rd order spur.
6. TX IMD, referenced to two-tone PEP power (the latter being 6 dB above either of the two-tone amplitudes).
7. Measuring "120 VAC Input Power" from the AC line gives me a rough idea of PA efficiency.  (Note that this value also includes power to the FPGA SDR as well as the LP-100 Wattmeter).
8. IMD generally worsens as frequency increases except for 160 Meters, which has significantly worse IMD compared to 80 - 15 meters (note that the 120 VAC watts is quite high, too).  This might indicate a problem with the 160 meter Low-Pass Filter, for example.
9. 100 watts of two-tone PEP power, fed through a 50 dB attenuator, should result in the level of each of the two-tone signals, at the 8568B Spectrum Analyzer, at -6.0 dB.  But they aren't -- this error might be due to 8568B calibration error, LP-100 calibration error, the 50 dB attenuator not being exactly 50 dB, or something else.  But the measurements are close enough to -6 dBm for my purposes.

You will note that I measured 10 meter IMD at an output power of 80 (rather than 100) watts to keep the IMD from worsening much more compared to the other HF bands.  The table below shows how 10 meter TX IMD worsens with output power:

(Click on image to enlarge)

For the same reason, I limited the maximum power on 12 meters to about 90 watts.


3.  Driver IMD Measurements:

Which functional TX block contributes the most to TX IMD -- the driver or the PA?  Let's verify.

Here's the test setup:

(Click on image to enlarge)

(The "Homebrew Directional Coupler" is described here: http://k6jca.blogspot.com/2015/01/building-hf-directional-coupler.html).

And here are the measurements.  The Driver's IMD is shown in the very last column.

(Click on image to enlarge)

Clearly, IMD performance is limited by the PA, not the driver, even on 10 meters.


Future Additions:

Some future additions that I plan to incorporate in...the future:

1. Fan controller and temperature monitor
2. External Speaker on the Front Panel.
3. Local controls for stand-alone PA applications

OK.  That's it for this blog post!

Background Notes:

SDR Notes:  Weaver Modulation and Demodulation
SDR Notes:  The Mixer Mathematics of Digital Down Conversion


Posts in this Series:

Part 1: Overview
Part 2: FPGA Modulation and Demodulation
Part 3: Interpolation and Decimation Filters

Part 4: RX and TX Audio Paths

Part 5: Control Interface, Etc.

Part 6: Schematics, Main Board

Part 7: Schematics, RX and TX Chains
Part 8: Front Panel, Rear Panel, and Other Schematics

Part 9: 50 dB HF RF Power Amplifier

Part 10: 30 Amp DC Switching Power Supply

Part 11: Floobydust (and a pointer to the files!)

Standard Caveat:

I might have made a mistake in my designs, equations, schematics, models, etc.  If anything looks confusing or wrong to you, please feel free to comment below or send me an email.

Also, I will note:

This design and any associated information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Flex TX Audio...

I've made an MP3 containing two recordings. One recording is the TX audio from my SDR 1000, the other is the TX audio from my Flex 5000. To obtain this recording, send an email to jca1955 "at" sbcglobal.net and request the Flex 1 July 08 Audio test file. I'll send you the mp3.

Once you've received this file, take a listen. What do you think - is there a difference between the two? If so, which sounds better (first or second recording), and why?

The recordings were made using the same WAV file as the audio source for the transmitters (using the playback feature of the Flex Console WAVE tab), so this test is really just testing each radio's output from DAC through the TX mixer and the Driver and Final stages.

I used a second SDR 1000 to receive the RF from each of the two radios "under test" (by connecting each test radio's output to the input of my second 1000 via a BIG attenuator), and I made the recordings using this second radio (again, using the WAVE tab of the Flex Console - this time in Record mode).

TX setups were the same for the 1K and the 5K (EQ, etc.). TX Bandwidth was 100 Hz - 5 KHz.

Receive bandwidth (on the second flex 1000) was 100 Hz - 5 KHz. No RX EQ.

By the way...if you listen to the recordings, please do so before reading the comments (so that you're not prejudiced one way or the other). And I haven't identified which audio is from the 1K and which is from the 5K, because, again, I don't want to prejudice any views beforehand.

Thanks!

Console can now be resized.

(Click on image to enlarge.)

OK, as of 15 Jan 08, my branch (k6jca) of the SVN repository contains code to allow the Console (well, actually the Display) to be resized. The Console can be "stretched" horizontally and/or vertically (the controls are independent). When stretching, only the Display will increase in size along with the overall Console (and the Pan trackbar will increase in size horizontally, not vertically). All other controls maintain their same size.

The image above shows a Console that's been resized from 1024 x 624 to 1280 x 700. Note the wider and taller display.

The Pan trackbar increases in size to give users better "resolution" when moving the trackbar (it's very sensitive at its stock size).

The Console can be stretched from its stock size of 1024 x 624 (h x v) to a max size of 1920 x 1200). Changes can be made in single pixel increments. Note that the Display size when the Console is 1024 x 624 is 704 x 240. For every step in Console size change, be it vertical or horizontal, the Display changes by an equal amount.

As the Console grows, the controls don't change size, but the spacing between "groups" of controls does change, which (I hope!) gives the Console a more pleasing look than if the groups had been left clumped.

Also - increasing Display size results in higher CPU usage!! If you start experiencing pops or other weirdness, drop the size back down to its original size of 1024 x 624 !!

Give it a try and let me know if you find any bugs or problems. And please vote in the poll for this new feature (see top of this blog).

Thanks!

Selectable Sizes?

Several people have asked me if the Console size can be made selectable. At the time I thought not, but I did some experimenting, and I discovered that, after launching the PowerSDR application, sizes can be changed. Here's an example (click on it to enlarge):


OK - it's still crude (I only added 8 lines of code). But this image shows a Console that is 1280 pixels wide (the max width of my monitor), instead of Flex's current 1024 pixels wide. For experimenting purposes, I changed the width (and the location of various controls) at the end of the initialization routine. The next thing to do is to add a control to the Setup menu to let the user select between 1024 and 1280 (and perhaps other size) wide. Going wider than 1280 is a bit more difficult for me to do, because I don't have a wider screen, and thus seeing how the overall Console looks, when taken as a whole, becomes impossible.

Also - I could just as easily change Vertical Size, too, but at the moment this isn't my main concern - I really wanted to get more horizontal display pixels onto the screen.

And...several people have asked me if I can scale "everything" to fit larger screen sizes. Although possible, it looks like I'd have to go through and individually change, literally, *everything*, (including, for example, the Font size for every button, etc., on the Console). I might be missing some obvious way of doing it (what I don't know about c# would fill the ocean!), but it looks like it'd be a tremendous amount of work, so frankly I can't see doing it.

However, stretching the Horizontal size (and perhaps Vertical), looks like it should be fairly easy to do.

Let me know what size(s) you'd like to see, and I'll see if I can add them...

New Skins for the SDR Console...

I thought I'd try modifying the code to give me more flexibility in choosing how my Console looks. Here's a result of these mods:


(Click on image to enlarge)

I've added four new Color buttons to the setup menu (go to Setup>Appearance>General). The four buttons allow you to change the overall Console background color, the "unselected" button color, the "text" color, and the text "background" (that is, the background in the combo boxes, the text boxes, and the up/down boxes upon which the text for those boxes sits).

And these buttons only change the color of the main Console itself. Colors on other menus, such as the Setup menu, don't change (at least, they aren't suppose to change. Please report bugs!)

I've uploaded the files to the SVN server. If you do an SVN update (you need to get the branches along with the Trunk), you'll find the files in my branch: .../branches/k6jca/Release/bin. Simply click on the PowerSDR.exe file in this folder to launch the new console.

Let me know if you come across any bugs (some of the code is a bit kludgier than I'd like). And let me know what you think!

Thanks...

SDR & Edirol FA-66, spurs etc.

Per reports of spurs when using the SDR1000 with the Edirol FA-66, I thought I'd check them out with my system.

I'm using a Toshiba laptop, and my latest version of k6jca code from the SVN directory (this version has a "Freeze" button which is very useful when making comparisons, as we'll shortly see).

I set up the Console as follows:

o Spur Reduction: OFF
o VFO A: 3.797 000 MHz
o Preamp: MED
o DDS Clock Offset: 0 (Go to "Setup>Hardware Config" tab and click on the "expert" box)
o Waterfall High Level set to -80, and Low Level set to -150.
o Display "Average" turned ON.
o Edirol Sample Rate set to 96 KHz.
o SDR's antenna connector attached to dummy load.

The spurs are shown below (you can click on the image to enlarge it).






The waterfall contains three different configurations. I merged them into one Waterfall display by "freezing" the display while I changed cables (thus the utility of the Freeze button (it's the 'F' button on the display)). The three configurations are:

1) The bottom 1/3 is with the SDR turned OFF (I also get the same thing with the SDR ON and the cables between it and the Edirol disconnected). Note the spur at 3.796 MHz. That's from the Edirol itself.

2) The middle 1/3 is with the SDR ON, and the SDR audio connected directly to the Edirol. Note the numerous spurs. Interestingly, the only spur that moves as I change the VFO in 1 Hz increments is the bright green spur to the right (at about 3.7948 MHz). All of the others are static! I don't know how to explain this - but I suspect that these are generated within the Edirol. My best guess is that this is a ground loop between the Edirol, the PC, the SDR, and their interconnection with the firewire, audio, and parallel port cables. But frankly, I don't know what the cause is, and it could easily be something else. It'd take *alot* more work to figure that out.

3) The top 1/3 is with a Radio Shack Ground Loop Isolator (p/n 270-054) in series with the cable from the SDR's "To Line In" signal and the Edirol inputs (3 & 4). Note that most of the spurs (with the exception of the spur at 3.796 and one further to the right at about 3.7948 MHz) are attenuated.

One test you can do is to tune the vfo in 1 Hz steps (that's Hz, not KHz), and watch if the spurs move, and how much they move by.

Spurs that are picked up by the SDR from external sources will follow in 1 Hz steps, and you can easily follow their movement in the waterfall.

Spurs that jump around crazily as the vfo is stepped from Hz to Hz are most likely DDS spurs.

Spurs that remain stationary are most likely spurs related to the Edirol itself, although I don't have a satisfactory explanation as to why they disappear if the cables are disconnected.

By the way - I also ran the tests with the two switching supplies removed (I turned them off and ran the laptop from its batteries and the Edirol from a bench supply (linear, not switcher)). No change in the spurs.

The above image is presented as an example of what I'm seeing. Others can use it to compare their system(s) to mine, if they think they have a problem.

For the moment, that's it.

Running Log, PowerSDR Console Mods...

15 Jan 08:
1. Added Console resizing (both horizontal and vertical dimensions can be sized independently). Controls are in Setup>Appearance>Display.

13 Jan 08:
1. The "long-tailed" cursor vertical tail now shows in both windows when in "split screen" mode.

2. Added the Peak Needle to all of the "Edge" style meters. And some of these meters have different ballistics (attack and decay times) for their 'normal' needle, because with some meters it's more useful to *not* have the needles behave like normal analog meters.

3. Added four new buttons in the Setup>Appearance>General tab to allow greater customization of the Console look (background, unselected buttons, text, and text background). Might have bugs: some parts are a bit kludgy.

9 Jan 08:
1. Added a "Freeze" button (Look between the Average and the Peak buttons - you'll see a button labeled "F") to freeze display updating. Press it once, the display freezes. Press again; it unfreezes. It also unfreezes if the frequency is changed, filters are changed, go to transmit, or any of a number of other actions (which would normally cause a change in the display) are performed.

Note:
A) When Freeze is pressed, the button turns 'orange'. I use this as a visual indicator to identify controls that are ON (or "activated") which I might want to quickly find later.
B) You cannot take a 'snapshot' of a frozen picture (this might be useful, though - so I'm going to think about how I might be able to do it).

2. Changed the label on my 'Peak Search' button from "Pk" to "PS" (for Peak Search).

7 Jan 08:
1. Added a trackbar in the Setup>Appearances menu to allow setting of Panadapter size when in the combined Panadapter/Waterfall mode. When in this mode, the Panadapter size can be adjusted from 20% to 80% of the display size.

Cool Fading Visual...

The waterfall half of my new Console displays some interesting things of which I was completely unaware. Recently I was talking with some friends on 75 meters, and I noticed an interesting effect...

On some stations, the waterfall looked, over time, as though a "comb" had been dragged through it. That is, it looked as though the tines of a comb had been run diagonally through the signal. I assumed that what I was seeing was due to the pitch (and harmonics) of the talker's voice changing with time, and I didn't think much more about it, except to note that it looked interesting.

Several days later I was monitoring a local boatanchor AM net, and I noticed the same thing. Again, it looked like comb tines had been dragged diagonally through the entire AM signal. What was unexpected, though, was that the direction of the drag was the same on both sidebands. What did this mean? Well, it meant that my initial assumption that the drag marks were due to voice pitch changing was wrong, for if they had been due to voice pitch changes, then the drag marks would have had the opposite slope on the other sideband. That is, if the drag marks were moving towards the carrier (with time) in one sideband, (indicating pitch lowering over time), then they should also be moving towards the carrier in the other sideband (that is, the sign of the slope should have changed in the other sideband).

But, surprise! The drag marks continued in the same direction across both sidebands!

What did this mean?

After watching the signal for a bit, I noticed that the carrier on the panadapter display would drop slightly as a "drag mark" reached the carrier. Bingo! I suddenly realized that what I was seeing was an example of fading - specifically, "selective fading"as it moved through the AM signal (this is a phenomena anyone who has listened to shortwave AM broadcasts is familiar with).

Below is a screen shot showing the fading with time on a shortwave AM broadcast station. (Click on it to blow it up). Looks like a comb was dragged through the spectrum, doesn't it?

Pretty cool, eh?

(What was also interesting, but not shown well in this image, is that the AM signal to the left also has "drag marks," but that these drag marks have a different slope and spacing, indicating a different selective fading pattern due to the different propagation path.)

PowerSDR with combined Panadapter & Waterfall

After I saw John Melton's combined Panadapter/Waterfall display on his Java Console for the SDR, I thought I'd give it a try, too (but on the normal Console code, not Java). So I spent a couple of hours this morning and came up with this...

(Click on the image to enlarge it)

It's not quite finished (I want the cursor to show time if I place it in the waterfall area), but it gives you an idea of what can be done, fairly quickly, with the existing code.

You can also see some "enhancements" that I've made to the Console. For example, there's a red "Peak" needle in the s-meter. Also, the "Restore" button toggles between the stored frequency and the VFO frequency (this allows you to easily return to the frequency you were originally listening on before clicking Restore).

And there are "Record" and "Play" buttons on the front panel, too (they're in the same box as the MOX & MUT buttons). I added these at the request of a friend of mine to simplify the Record and Playback functions. We found the "stock" setup a bit confusing to use (and set to the incorrect defaults), so I added these two buttons to let me quickly record (during receive) & playback (during xmit) an off-the-air signal. The pre/post Rx and Tx settings are "correctly" set automatically, and the user doesn't need to enter (or select) a file name - it's all handled automatically, too. Just press REC to record, and then, to playback during XMIT, simply press PLAY. That's all there is to it.

I also added some features that I wanted to have when/if I use the SDR as a spectrum analyzer. For example...

1. There's an inverted triangle shown on the display. This is invoked by pressing the "Pk" (peak) button. The triangle locates the peak signal between the two "dotted" vertical lines, and displays frequency and amplitude where the "cursor" frequency and amplitude are normally displayed. Please note that the two "dotted" vertical lines are always -10 and +10 pixels from the cursor X position, so, as you move the cursor across the screen, the triangle will jump from peak to peak as new peaks enter into the 20 pixel region. (You'll instantly recognize this feature if you've ever used an SRS spectrum analyzer (e.g. the SR760)).

2. A "snapshot" of the panadapter (or spectrum) display can be taken (by pressing "Snp") and displayed simultaneously with the ongoing display. The snapshot is displayed in a different color (in this case, red), as can be seen in the following image:

This "snapshot" feature is similar to a feature in the SigLab spectrum analyzer (designed by a friend, W1QG), and is very useful for making comparisons between old and new signals. (The "Clr" (clear) button is highlighted as Orange when the snapshot is displayed on the screen, and clicking it will erase the snapshot.)

(Note that in the snapshot mode, the "Pk" triangle sits on the peak of the snapshot signal that lies between the two dotted vertical lines.)