Thursday, October 5, 2017

An FPGA SDR HF Transceiver, Part 11 -- Floobydust...

This eleventh and (I hope) final blog post in my FPGA SDR transceiver series is a collection of miscellaneous topics that do not warrant blog posts of their own.

In other words, Floobydust!

Floobydust?  From my copy of National Semiconductor's 1980 Audio Handbook:
"Floobydust" is a contemporary term derived from the archaic Latin miscellaneus, whose disputed history probably springs from Greek origins (influenced, of course, by Egyptian linguists) -- meaning here "a mixed bag." 

With that, let's dive into this posting's potpourri of miscellaneous topics!

The FPGA SDR's Simulink File Download:

If you'd like to get a copy of the the FPGA SDR's Simulink model (Xcvr_SSB_AM_2p5.mdl), it can be freely downloaded from the following site:

Please read the following notes!!!

  • The FPGA SDR design utilizes a Waveshare Xilinx 3s500e Development Board.  (For more information on the design, start here:
  • The Matlab version that I used:  R2009b, along with Simulink.  Note, I purchased the "Home" version of Matlab and Simulink.  Purchasing the current "Home" versions should also allow you to download previous versions, such as R2009b.  At least, I could download (for free) previous versions after I purchased my "Home" version several years ago.
  • The Simulink Model file (Xcvr_SSB_AM_2p5.mdl) is THE design file.  All other files are ancillary files.
  • You will also need the Xilinx ISE Design Suite for the Xilinx blockset required by the Simulink model as well as for the tools to create and load the .bit file onto the Xilinx 3s500e board.  I'm using the "Xilinx ISE Design Suite  12.2".
  • Regarding the Xilinx ISE Design Suite:  Use the Xilinx "Project Navigator" to convert the .xise file into the final .bit file (the .xise files is created by clicking on the Xilinx "System Generator" block that is on the top level of the Simulink model) .  And then use iMPACT (from the Xilinx ISE) to load the .bit file into either the eeprom on the Waveshare board or into the FPGA itself.  (And you might see quite a few "warnings" generated by the Xilinx Project Navigator as it goes through its process -- these were present in W1QG's original version of the design, and, being a neophyte using these tools, I've ignored them).
  • These files are free to all.
  • I am not available to provide help (which is the hidden price of having the files be free to all).  Therefore, if you want to use these files, I recommend that you be already familiar with Matlab, Simulink, and the Xilinx tool set, and that you are comfortable with using them to create FPGA designs and files that can be downloaded into actual FPGA devices.  If you do not have this familiarity, learning how to properly set up and use the tools can be a major major issue.  So, before you spend money on anything, I would recommend that you first know what you are getting into, or that you have colleagues who are familiar with the tools and design process and who are willing to help you.
  • Finally, I might have made a mistake in my designs, equations, schematics, models, etc. Do not assume that the design is bug free!

FPGA SDR Filter Downloads:

Files of Filter Data (including Information Filters of various bandwidths and filters used in the RX EQ stage) can be found here:

From the Readme file at the above URL:

This repository contains some of the Filter Files that I download into my FPGA SDR transceiver from an Arduino NANO used as the UI Control processor.
Note that, in the Arduino code, I store these filters in the Arduino's Program Memory, thus the "const PROGMEM int" in lieu of "static int" used by Dick, W1QG, in his original filter files (Dick used a PIC processor for UI control).
The file "AF_Filters_1.h" contains the filters I use in the audio RX Equalizer stage, while all other ".h" files are Base-Band Information Filters (centered at 0 Hz -- refer to blog post 3 in my FPGA SDR series).

(Again, these files are freely provided, and because of this I again caution that I am not available to provide help.)

Other Floobydust:

1.  FPGA Utilization:

I've highlighted the Xilinx XC3S500E attributes in the following table:

(Click on image to enlarge)

Note that the total number of slices available is 4,656 (four slices form one CLB, or Configurable Logic Block).  Version 2.5 of my FPGA design occupies 97% of the FPGA's slices.  Not much more room is left!

(Click on image to enlarge)

2.  FPGA Power Dissipation:

The FPGA SDR Transceiver, powered with 14V, consumes about 9 watts of power (0.65 Amps).  Originally there was no venting in the case, and its inside could get a bit toasty (imagine a small box completely enclosing a 10 watt light-bulb).

To provide a bit of heat relief, I added a very small fan to the FPGA SDR's back panel and 10 quarter-inch holes on the bottom of the case (I believe I used a 1 1/8 inch chassis punch to make the fan hole).  The fan runs at a low speed (the fan is a 12V fan, but I power it at about 7V using a series dropping resistor from the 14V line).

I haven't made any measurements of the temperature profile within the box.

3.  Fan Speed Control:

The switching power supply has a fan that is constantly on, and it is a bit noisier than I would prefer.  On the other hand, I've set the speed of the PA fan at a low value so that its noise is fairly unobtrusive, but it isn't very efficient for cooling the PA when transmitting at high power.

Wouldn't it be nice if these two fans would go to full speed if their components were getting hot, but otherwise luffed along at a low, quiet, speed (or were off altogether)?

So I decided to add fan speed controllers to both the PA's fan and the Switcher's fan, and I'd like to have the fans start speeding up and a temperature of 40 degrees C or a bit higher (40 degrees C = 104 degrees F).

Which temperature sensors to use?  I've plotted the characteristics of some temperature sensors, below:

(Click on image to enlarge)

To turn ON the fan, I am going to use an MJF122 NPN Darlington transistor (explained further below).  Here's a graph of its Ic versus Vin characteristics, given the test circuit included with the graph:

(Click on image to enlarge)

Note that the Darlington is ON and its transfer characteristics linear when Vtemp is between about 1.16 and 1.28 volts.

And why 100 ohms collector load?  That's approximately what the PA's fan looks like, when it is spinning.

Let's add this information to the Temperature Sensor graph:

(Click on image to enlarge)

Amplifying the MCP9700's output by a factor of about 1.3 results in, roughly, the same turn-on point as I would get with the MCP9701.  Both turn on at a temperature around 40 degrees C and are in saturation (i.e. the fan can spin no faster) by, worst-case (for the MCP9700, amplified by 1.3), about 50 degrees C.

In the case of the MCP9701 you might initially think, given its output voltage at 40 degrees C, that it could drive the Darlington directly, but the MCP9701 is only spec'd for 100 uA output current, which, given the range of the Darlington's Beta, might not be sufficient.  So an op-amp provides enough current to drive the Darlington's base, even when the Darlington is in saturation.

Now let's look at the Switcher's fan-controller, which, of the two designs I'm presenting here, is the simplest:

(Click on image to enlarge)

Notes on the Fan-Speed Controller:
  1. The temperature-sensor is an MCP9700 in a TO-92 package.  Its plastic case (meant for ambient air temperature measurements) will phyically contact the windings of the Switcher's L1 inductor (which I determined, by touch, is the component that becomes warmest) -- thus the need for a plastic case: to provide voltage isolation.
  2. I would have preferred to use the MCP9701 in a TO-92 package, but I didn't have one at hand -- I only have these devices in SOT-23 packages.
  3. The MCP9700 cannot source much current, so I use an op-amp to provide a current boost.  This op-amp also multiplies the sensor's output by a factor of 1.3 so that, at a temperature greater than about 40 degrees degrees C, the resultant voltage is about 1.18 volts, which is (roughly) the voltage at which the MJF122 Darlington turns on sufficiently to start the fan turning (Note that the voltage across the fan needs to be fairly significant to get it to start (e.g. 5 to 6 volts?), but, once started, this voltage can be decreased and the fan will still continue to turn).
  4. An MJF122 was used because of its high current gain and also because it has an insulated package (no insulated screws and/or washers are required when attaching it to the chassis (which acts as its heat-sink)).
  5. Some resistance in series with the base of the MJF122 is required to limit base current when the Darlington saturates.  I'm using 470 ohms, which, when the op-amp output is 2.0 volts (i.e. temperature at sensor > 80 degrees C), results in a (measured) base current of 1.5 mA.  This amount of current can be easily sourced by the TLV271.  
  6. The MJF122's Beta can vary tremendously with collector current and temperature.  At 100 mA and 25 degrees C, per the MJF122 datasheet (figure 8), DC current gain is about 500 (this will vary from device to device), which means base current would be 0.2 mA.  This would result in a voltage drop across the 470 ohm base resistor of about 0.1 volts -- equivalent to a temperature error of 5 degrees for the MCP9701 (19.5 mV/degree slope) or about 8 degrees for the MCP9700 when amplified by 1.3.  If important, this error can be reduced by decreasing the value of the base resistor, with its lower limit being a value that would still allow the TLV271 to adequately source the base current at, say, an input voltage equivalent to a temperature of 80 degrees C.  (Note: I measured a base current of about 0.07mA prior to device saturation in this application).
  7. A 78L05 powers both the sensor and the op-amp with 5VDC.  It's possible that this circuit could be replaced with a zener diode and a resistor, but the 78L05 is a simple solution whose output voltage is constant with temperature (when compared to a zener diode).

The temperature-sensor is mounted on a small board (with bypass cap), and this board sits IN the switcher's toroidal L1 "doughnut hole":

Note that the sensor's plastic case physically contacts the inductor's windings.  (The sensor is black, the capacitor is yellow-brown).  (The white goop was added by the manufacturer).

Here's the entire fan-controller circuit, mounted on the inside of the top of the switcher's chassis, next to the fan:

For the PA fan I wanted to do something similar, but I had two concerns:
  1. There could be a lot of RF within the PA compartment, so the circuit needed to be immune to RF.
  2. I didn't want to use a temperature sensor in a TO-92 package.  I wanted a device with a low-impedance thermal path between its pins and its die-based temperature sensor so that I could connect a pin (e.g. the device's ground pin) directly to the heatsink or some other "grounded" heat source.  So in this design I use an MCP9701 in a SOT-23 package, with the temperature-sensing path made via its ground pin.

Here's the circuit for the PA's fan controller.

(Click on image to enlarge)

Although it appears complex, the "bones" of this circuit are the same as the switcher fan-controller circuit.  But note:
  1. The gain of the op-amp is now 1, rather than 1.3.
  2. There is a 100 ohm resistor which keeps the fan always on, but at a low speed.
  3. There are a lot of additional R's and C's acting as filters to mitigate any possible ill-effects created by having high-power RF near this circuitry.

To create a low-impedance thermal path between the PA and the temperature sensor, I soldered the temperature sensor's "Ground" pin to a Ring Terminal.

Ring Terminal:

 The rest of the sensor circuitry (consisting of the sensor and RFI mitigation passive components) sits on a small PCB.  The Ring Terminal, itself, is screwed to the PA's Q1 mounting flange using the flange mounting screw, as shown below:

Here's a test of temperature in CW mode on 80 meters, operating at 90 watts out, with the key held down for 2 minutes, and then released and the PA allowed to cool for 3 more minutes:

(Temperature was determined using the measured sensor voltage and reworking the sensor's "voltage as a function of temperature" equation to instead represent "temperature as a function of voltage.")

You can see how the temperature rise is fairly steep when the PA is initially keyed, but as the fan turns on the temperature rate-of-change slows down to about 7 degrees per minute.

I tried a similar test in LSB mode of the PA's fan, but instead of transmitting for 2 minutes I transmitted for 6 minutes, continuously talking (reading out loud the text from a QST article).  The PA's temperature started at 29 degrees C and, over the course of the six minutes, never got above 39 degrees, and I had to really work at getting it that high -- lots of yelling into the mic!  (Note that at 39 degrees the fan still hasn't kicked on).

I haven't done any testing of the switcher's fan and under what operating conditions it turns on, but I have noted that, during normal sideband conversations on 80 meters (at about 90 watts out), the switcher's fan does come on after a few minutes of talking.

4.  Codec Output Low Pass Filter:

While using headphones to listen to some local LSB conversations on 80 meters, I thought I detected some out-of-band distortion components (i.e. above the audio Nyquist frequency of 4882.8125 Hz).  I didn't hear these with the built-in speaker (whose response rolls off nicely), but only with the wide-band stereo headphones I was using.

Assuming that these were generated by the codec (note: unverified), I decided to add a low-pass filter between the codec's output and the speaker amplifier to roll off out-of-band audio components.

I chose a four-pole Sallen-Key topology using two op-amps (i.e. a single 8-pin SOIC package), with the cutoff frequency set to about 4.9 KHz.

Here's the design:

(Click on image to enlarge)

You can find additional information on this filter in Part 6 of this series:

5.  External Speaker:

The FPGA SDR's speaker is mounted on radio's top cover, towards the rear, as shown below:

This location works fine -- I have plenty of speaker loudness while I'm sitting in front of the radio, but I have been considering placing my Automatic Antenna Tuner on top of the FPGA SDR.  If I do this, then this speaker's audio would be obstructed by the Tuner.

I had considered this eventuality when I built the FPGA SDR by including an "External Speaker" connector on its rear panel (if an external speaker were plugged into this connector, it would automatically disconnect the speaker in the FPGA SDR).

But where to mount the speaker?  Why not on the PA's front panel?  There is plenty of room, and the speaker would face forward, towards me, the operator.

I would use the same speaker I had used in the FPGA SDR -- an 8 ohm, 2 watt speaker that can be driven by the TPA0211 speaker amplifier.  And this speaker would be mounted within its own enclosure (sealed, non-ported, with a volume of roughly 27 cubic inches).

Here is the schematic:

(Click on image to enlarge)

The PA's front panel has some dimension constraints, so I would need to be creative in terms of how I mounted the speaker.  The enclosure would be held to the front panel with three screws (rather than four -- I wanted to create a "rectangular" pattern on the front panel, with one of the corners of the rectangle being the TX LED).

Two of the nuts for these three mounting screws would be within the sealed speaker enclosure.  But because I would be constructing the speaker enclosure from double-sided PCB stock material, then all of the seams would be soldered to create the sealed enclosure.  This would mean that I would not be able to get to the two internal nuts when screwing the speaker enclosure to the front panel.  So, I "captured" them by soldering the nuts to the PCB copper.

In the picture below, the two top nuts are the nuts internal to the enclosure, and the bottom nut is external.  All three are soldered to the PCB (note: choose nuts that will wick solder -- some won't!).

The image below shows how the front of the speaker enclosure mounts to the front panel (the PCB strip below the speaker has the two PA LEDs (Power-On and Transmit indicators -- note that I notched the speaker's front-panel material to prevent mechanical interference with this LED board).

After the speaker's front panel has been fitted correctly to the PA's front panel, it is time to build an enclosure around it:

Note that a back cover will be added and all seams are soldered to prevent air leaks behind the speaker.

After the speaker is installed in the enclosure but before the back is soldered on (which will complete the assembly of the enclosure), the enclosure is stuffed with polyester fiber (the same sort you can find at fabric stores, used for stuffing pillows) to help dampen out internal acoustic resonances within the enclosure.

And here is the final result:

For completeness, below is a comparison of the new speaker assembly's frequency response (green trace) relative to the speaker in the FPGA SDR (gray trace):

(Response measured with a Heil PR-20 mic placed 3 inches from the respective speaker grill.  Other than that, measurement system uncalibrated -- use these curves for relative response, only).

6.  An ATU-SDR Communications Interface:

After operating the FPGA SDR with my Automatic Antenna Tuner for a couple of months, it became clear to me that it would be nice to add a communications link between the two devices so that the tuner could be more easily set to the transmit frequency, rather than first having to measure frequency from the transmitted RF.

Why do this?  Although the ATU's relays are rated at 20 million mechanical cycles, their contacts are only rated at 30,000 cycles.  Admittedly, the 30,000 cycles is determined with a significant amount of current passing through the contacts (16A), but, assuming the transmit power while tuning is 10 watts and an SWR of 10:1, RF current passing through the relay contacts, while tuning, could be over an amp.

Much better for relay contact life, I thought, if I could tune at a much lower power.

But lower power meant that the ATU could not first measure the frequency of the transmitted RF signal -- it requires that this signal be more on the order of 7 watts (e.g. if operating into a low-impedance load with SWR = 10:1).  This meant that, every time I changed to a new transmit frequency, the tuner would have to go through its complete tuning sequence.  Lots of relay cycles, with contacts carrying current opening and closing!

So...rather than have the ATU measure the transmit frequency from the transmitted RF signal, why not instead have the FPGA SDR send the transmit frequency to the ATU first before it actually transmits any RF?

I had had the foresight to design into the FPGA SDR such an interface: one input from the external ATU to the FPGA and one output from the FPGA to the external ATU, but, unfortunately, because I had designed and built the ATU several years ago, and I had not thought to add a complementary interface at that time.

Instead, I had designed into the ATU two extra output signals (which I have never used), but no inputs.

Why not change one of these outputs into an input so that the ATU had both an input and an ouptut?  It would then be compatible with the FPGA-SDR's existing ATU interface.

It was a simple fix to make.  The physical interface now looks like this:

(Click on image to enlarge)

(Circuit details can be found here for the ATU and here for the FPGA SDR).

As you can see, the two-wire interface consist of two signals: data sent from the FPGA SDR to the ATU and a clock sent from the ATU to the FPGA SDR.

The FPGA SDR sends the transmit frequency to the ATU via a 24-bit packet.  The packet has the following structure (here defined assuming high-true data):
  1. 4 bit header.  Value 0xF.  (Strictly speaking, only two header bits are needed -- the first one always acts as a start bit by taking the Data line out of its IDLE state, and the second bit ensures that there are an even number of bits, and thus clock-edges, in the packet, so that, with the last clock transition, the clock is back in its IDLE state).
  2. 15 bits of binary frequency information, representing the tx frequency in KHz.  Sent LSB first.
  3. 4 bits of checksum, representing the number of zeroes in the 15-bit binary frequency word.  Sent LSB first.  Because the ATU generates its clock transitions irrespective of whether or not the SDR is sending correct data (or even sending data), this field helps the ATU verify that, yes, it correctly received the frequency data.
  4. 1 bit Stop Bit (value 0).  To place data line back into its idle state.
The tuning procedure is:
  1. First, the user depresses the TUNE switch on the FPGA SDR's front panel, which causes the data bit from the FPGA SDR to the ATU to go HIGH. (Here I am defining HIGH = True, or '1'.  Therefore, when idle (i.e. False), this bit sits low, or 0.  This bit is the first bit of the four-bit header whose value is 0xF.  Note that the signaling on the interconnect cable between the SDR and the ATU is LOW (low voltage) = True, due to the inverters).
  2. The ATU (which might be busy with other tasks) will eventually poll this input data bit.  If it sees it HIGH (i.e. the input is no longer "idle"), it knows that the FPGA SDR wants to send the tx frequency.
  3. The ATU then responds by first shoving this input data bit into a shift register and then transitioning its Clock Out bit (sent to the FPGA SDR) from its idle state of low to HIGH.
  4. The FPGA SDR (which has been sitting in a tight polling loop waiting for a clock transition from the ATU) detects this transition and immediately puts the next packet bit on its output line to the ATU.  (Note that if the FPGA sees no clock transition within, say, 100 ms of setting that first bit, the FPGA SDR assumes no ATU is attached and aborts the packet transmission, after which it will transmit the TUNE tx signal for as long as the TUNE switch is depressed).
  5. The ATU, having generated the first clock transition, waits 1 ms (to allow the FPGA SDR to output a new packet bit) and then clocks into its shift register this new bit, followed by a clock transition in the opposite direction.
  6. Step 6 is repeated 22 more times (for a total of 24 clock transitions).
  7. After having received the entire 24 bit packet, the ATU counts the number of zero bits in the received 15-bit "tx frequency" field and compares this count to the received 4-bit checksum.  If the two are equal, the ATU will use the received frequency to address its stored Tuner settings.  But if the two are not equal, the ATU discards the packet.
  8. On the the FPGA SDR side, after it has seen all 24 clock transitions from the ATU, it begins transmitting the TUNE rf  signal (at very low power -- about 0.05 watts) on the tx frequency.  (Note: the ATU can easily tune using this level of power).

(Click on image to enlarge)

  1. The signals in the image above were measured on the cable between the FPGA SDR and the ATU, and are LOW-TRUE (low voltage = logic 1, high voltage = logic 0).
  2. After each ATU Clock transition, the FPGA SDR's places the next packet bit on its output about 350 us later. .
  3. The interval between the first header bit being placed on the FPGA SDR's data-out line and the first clock transition from the ATU can be up to 100 ms, depending upon what house-keeping tasks the ATU is performing at the time.  (In the image above this interval is about 20 ms).
  4. In the image above, the frequency is 3865 KHz (binary 00111100011001), and its checksum is 0x8 (there are 8 zeroes in the 15 bit word).  Therefore, the complete packet is 1111,100110001111000,0001,0 (I've inserted commas to delineate the header, frequency, checksum, and stop-bit fields for the reader).  But because the signalling on the interface cable is low-true logic, the signals in the image above have an inverted sense:  i.e. a logic 1 = low-voltage and a logic 0 = high-voltage.
Here's a photo showing the SDR and the ATU being tuned...

I'm depressing the TUNE momentary-contact toggle switch on the FPGA SDR's front panel, and it is transmitting a CW signal whose voltage amplitude is 2% of the maximum possible amplitude (you can see the "2%" on the bottom line of the FPGA SDR's LCD).

In other words, the TUNE signal is 34 dB down from 100% amplitude, the latter being 50 dBm (100 watts).  The output is therefore about +16 dBm (40 milliwatts).

The ATU's frequency detector circuit cannot measure the frequency of an RF signal at such a low level (it needs roughly 3-7 watts of signal, depending upon termination impedance), and previously this would trigger the tuner to run through its tuning process (usually about 4 to 5 seconds of high-speed relay chatter), but with this interface there is only a single "click" heard (as the relays set once, simultaneously) and tuning is finished.

You can see the 3.663 on the bottom line of the ATU's LCD, which is the frequency sent to the ATU from the FPGA SDR via this interface.  (The numbers to the right of the "3.663" are Forward Power (in this case, less than 0.1 watts), and SWR (in this case, better than 1.1:1).

In this example, the ATU, upon receiving the 3.663 KHz frequency from the FPGA SDR, checked its EEPROM for a valid tuner setting.  Finding one, it set the relays to this setting (with a single "click" sound as the relays were set simultaneously) and voila, the resulting SWR was less than 1.1:1.

Tuning finished!

If a tuner setting has not been stored previously, the tuner would, after checking if there had been a valid setting already stored, initiate its tuning process and then, after much relay clatter, when it finds the setting with the best SWR, it would store this setting into its EEPROM, ready for recall if this frequency is called up again.

(For more information on the Tuning algorithm, go to:

7.  S-Meter Calibration:

I chose the meter for the S-Meter to match the same meter I used for Return Loss measurement on my Automatic Antenna Tuner.

The image below shows where the S-Unit divisions would be (were I to print a meter-face overlay with S-units on it).

Note.  S-units are assumed to be 6 dB apart, and S9 is -73 dBm.

8.  Notes to Self on using creating the FPGA files and programming the Core3S500E board's PROM using the Xilinx ISE Design Suite 12.2:

 (So that I do not forget!!!)

1.  To call up the Simulink model in Matlab 2009b:
  • Find the appropriate model file (.mdl) in the appropriate directory and click on it to launch.
2.  To create compile the Simulink model and create the .XISE file (that will be used by the Xilinx tools):

The System Generator will create a .XISE file (Xilinx ISE Project file), that will be used for the next step:

3.  Create the .BIT file from the .XISE file:
  • Launch the Xilinx (64-bit) Project Navigator program in the "ISE Design Tools" folder (which, in turn, is in the "Xilinx ISE Design Suite 12.2" folder").  
  • Open the appropriate Project (e.g. click on xcvr_ssb_am_2p5_cw.xise in the appropriate folder).
  • Then, to generate the .BIT file, follow the steps in the image, below:

4.  Finally, to program the EEPROM on the Core3S500E FPGA board from the .BIT file:

·         Programmer cable should be connected to the Core3S500E board.
·         Launch Xilinx’s iMPACT (ISE Design Suite > ISE Design Tools > 64-bit Tools)
·         (Close down the two pop-ups which will appear).
·         Double-Click (DC) Boundary Scan, then Right-Click (RC) in main window and select “Initialize Chain”.
·         (Close down the two pop-ups which will appear).
·         In the iMPACT Flows window, DC on “Create PROM File”.
Ø  Select Xilinx Flash/PROM (then Green Arrow).
Ø  Change device to xcf04s and click on “Add Storage Device”, then Green Arrow.
Ø  Enter Output File Name.
Ø  Enter Output File Location (use same location as .bit file).
Ø  Click OK.
·         At Add Device popup, click OK.
·         Select the .bit File.
·         Click NO when asked “would you like to add another device file to”.
·         Click OK to “You have completed the device file entry”.
·         In the iMPACT Processes window, DC on Generate File.  Should then say “Generate Succeeded”.
·         Go back and click on Boundary Scan.
·         In Main Window, select the xcf04s device (it will become Green), then RC on it.
·         Select “Assign new configuration file”.
·         DC on the .MCS file.
·         In Main Window, again select the EEPROM.
·         In the iMPACT Processes window, DC on Program.
·         Click OK in the Popup Window.  

PROM programming should now start.  At its end, “Program Succeeded” should be displayed.

Cycle power to program the FPGA with the new contents of the EEPROM.


...Future topics to be added as they come to mind...

OK.  That's it for this blog post and this series.  I'll close it out with this photo of the station set up at my wife's QTH in Nevada City, CA.

(The scope is a Tek SC 504 that I use for monitoring my transmitted RF waveform.  See this 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 5: Control Interface, Etc.
Part 9: 50 dB HF RF Power Amplifier

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.

No comments: