QS1R Status

QS1R Receivers are now shipping within 7-10 business days after order. The current revision of QS1R is RevD. The future QS1T Transmitter board and RFFE1 front end board are both still at the pre-production stage.

Future projects, HPSDR, etc...

New QS Transceiver Projects:

http://www.philcovington.com/qs1r_latest/Documents/QS_TRX_04_23_2009.pdf

http://www.philcovington.com/qs1r_latest/Documents/QS_Minimal_SARX.pdf

http://www.philcovington.com/qs1r_latest/Documents/QS_Antenna_Board.pdf

http://www.philcovington.com/qs1r_latest/Documents/QS_Bus_Board.pdf

http://www.philcovington.com/qs1r_latest/Documents/QS_Display_Board.pdf

HPSDR:

I am sad to say that I can no longer participate or support the HPSDR project. Please see this for an explanation as to why this is.

RFFE1 Why you may (or may not) need it

RFFE stands for "Radio Frequency Front End" and the "1" stands for the first version (0-62.5 MHz coverage).

When I was designing the QS1R board, I had to decide whether to include bandpass filtering and RF amplification on the board. In fact the initial prototypes "RevA" included RF amplification on the QS1R board. Unlike another DDC based direct sampling receiver "Perseus", QS1R was designed to be more than a SW receiver. In addition to a SW receiver, QS1R was meant to facilitate experimentation in the RF spectrum up to at least 300 MHz. I finally settled on a 55 MHz low pass filter (which can be bypassed) and no active components in front of the ADC on QS1R. Any active devices, bandpass filters, or attenuation would be added by a separate board such as the RFFE1.

The antenna that I use for my QS1R is a center fed, non-resonant dipole at 50 feet. The total wire length is about 240 feet with only about 100 feet of that running horizontally. It is fed with 450 ohm ladder line connected in the house to a 4:1 balun. The last 10 feet of feed line is coax to the QS1R from the balun. I do not use a tuner with this antenna for receiving. In my neighborhood, all of the utilities are under ground so the noise level is typical or maybe a bit less than the noise level of a suburban area. With this antenna and the QS1R, I find that band noise is always greater than the QS1R's noise floor until about 21 MHz. I arbitrarily have assumed (possibly incorrectly) that my antenna installation is average. Any amplification in front of the QS1R's ADC (below 21 MHz) is only a detriment in this case. The QS1R typically overloads at +9 to +10 dBm so amplification would degrade the strong signal handling capability of the receiver. The largest signal level that I have observed at my location has been about 0 dBm in the 0 - 62.5 MHz region. Contrary to what some may believe in the above case for the QS1R, bandpass filtering will improve nothing and, because BPFs typically have some loss, degrade the sensitivity slightly. As long as the atmospheric or band noise is greater than the noise floor and the signals levels in the 0 - 62.5 MHz region is below +9 dBm, bandpass filtering and/or amplification does not gain anything.

By providing RF front end add-on boards such as the RFFE1, a front end (if even desired) can be tailored to the specific application of QS1R and will not impose a significant cost increase to the QS1R board for those who do not need the RFFE(1) boards. The QS1R is capable of under sampling up to ~ 500 MHz, so it will be possible to design RFFE(x) boards that will allow coverage up to ~ 500 MHz. For example, RFFE2 would provide low noise amplification, bandpass filtering, and attenuation of the range of 125 to 187.5 MHz ( including 2 meter ham band coverage). There is some interest by individuals in FM band Dxing which could be provided by a RFFE(x) board.

The RFFE1 board is designed to fit within the existing QS1R Aluminum enclosure by replacing the front and rear end plates with new end plates (supplied with RFFE1). RFFE1 has switchable attenuation, two stages of switchable low noise amplification, and switchable filtering. It is controlled via the QS1R's I2C bus and derives its DC power from QS1R. The RF amplifiers provide up to 26 dB of gain (noise figure ~ 2 dB). With the attenuation switched in, the QS1R can handle signal levels up to +29 to +30 dBm without overload of the ADC. Each RF amplifier provides ~ 13 dB gain. With both amplifiers switched in and attenuation switched off, the QS1R can handle signal levels up to -17 dBm (or -4 dBm with one RF amp switched in) without overloading the ADC. The QS1R's IP3 is > +50 dBm so the RF amplification was designed to not degrade the IP3 excessively. With the amplifiers switched in, the IP3 is ~ +32 to + 33 dBm. Contrary to what some have speculated elsewhere, the RFFE1 does not use the LTC6400-20 ADC driver that HPSDR Mercury uses for a preamp. In HPSDR Mercury, the 20 dB amplification provided by the LTC6400-20 is always present - the preamp is bypassed by switching 20 dB of attenuation in front of the LTC6400 ADC driver providing a net gain of 0 dB. In the RFFE1, the two RF amplifiers are individually switchable in and out of line and have their own impedance matching and filtering networks for enhanced performance.

With any amplification in front of the QS1R's ADC and without filtering, the whole 0 - 62.5 MHz region is amplified equally - so any signal within this range could possibly overload the ADC if its signal strength amplified by the gain of the RF amp exceeds +9 to +10 dBm. This is where band pass filtering is an advantage. It is not easy to design the filtering so that adequate attenuation is provided out of band as well as not degrading the IP3 performance of the receiver. Luckily we are not dealing with an analog radio, so the assumptions about exactly what is needed in a conventional receiver does not necessarily apply to direct sampling receivers such as the QS1R. I spent a very large amount of time in experimentation and testing to come up with a filtering system for RFFE1 that does not degrade IP3 performance. I was surprised in what I found and eventually decided on, but that is a subject for a future blog entry ;-). I did a lot of modeling of various filter networks to determine the RF current in each inductor given the physical and electrical characteristics of each type of inductor. This helped me chose the best filter arrangement and inductor type for the RFFE1 without degrading IP3 as much as other competing receiver's bandpass filters degrade IP3.

So who needs a RFFE1? Here are my guesses:

1. Anyone who wants to use QS1R above ~ 18 MHz with an average antenna system. This includes 10 and 6 meters.

2. If your antenna is less efficient and you have determined that the noise floor of QS1R is above the band noise at some point below 18 MHz. An easy way to determine this is by disconnecting your antenna while watching the noise floor or s-meter in SDRMAX(II/III). If the noise floor increases by at least 6 dB when you reconnect your antenna then you have adequate sensitivity at that frequency.

3. If your antenna does not provide a 25 - 75 ohm impedance to QS1R. Antennas that deviate far from 50 ohms will manifest as severely reduced sensitivity with QS1R. In my case with my non-resonant 450 ohm ladder line fed dipole, a 4:1 balun is all that is required for me to have adequate sensitivity up to about 21 MHz.

4. Signal strengths in your location in the 0 - 62.5 MHz range exceeds +9 dBm at the antenna input to the QS1R receiver. In this case the switchable filtering and/or attenuation provided by RFFE1 will eliminate the overload. QS1R and SDRMAXII provides the nice capability of viewing 50 MHz of spectrum at once - it is easy to see the maximum signal levels your are receiving in that range.

5. RFFE1 has two switchable antenna inputs as well as additional static/surge protection. RFFE1 also provides a connector for external receiver mute input, two protected general purpose IO lines, as well as an external connection to the QS1R I2C bus for external relay control and/or switching. While these options are not necessary for the functioning of QS1R, they are nice to have in some cases.

Who does not need a RFFE1?

1. If your operation is below ~18 MHz and your antenna system is adequate (see 2 and 3 above) and you have no overload problems (you don't see your "clip" LED on the front of QS1R illuminating) then you won't gain much with RFFE1. This generally includes using QS1R with transverters and for an IF receiver with other receivers/transceivers.

Exact performance numbers for RFFE1 will be posted in the near future as well as pricing. Hint: The price of QS1R and RFFE1 together will not exceed the price of competing direct sampling receivers!

SDR Discussion

Please subscribe to the QS1R yahoo group at:

http://groups.yahoo.com/group/qs1r/

for the latest news and discussion on SDR topics and the QS1R.

Regards,

Phil N8VB

Production QS1R RevC Pictures

QS1R Webpage is up:

http://www.philcovington.com/QuickSilver/

Orders for the first group of QS1Rs from assembly will be taken very soon. Please keep checking the website.

See the latest news at:

http://groups.yahoo.com/group/qs1r/

Here is a picture of a production QS1R RevC board:

QS1R Rev B Picture and new Yahoo group

http://groups.yahoo.com/group/qs1r/

QS1R REVB Picture

http://www.philcovington.com/SDR/PICS/qs1rt_revb.jpg

History of HPSDR Mercury and Quick Silver

History of HPSDR Mercury and Quick Silver

Philip Covington, N8VB

Early HPSDR and XYLO

In 2005 I started a High Performance SDR (HPSDR) project which was to consist of a motherboard carrying a FPGA/USB 2.0 interface and power supply with the provision for plug in modules through 40 pin headers. I had planned a narrow band high dynamic range module based on a QSD/DDS/PCM4202 audio ADC and a wide bandwidth module based on a high speed 16 bit ADC:

http://www.philcovington.com/SDR/PICS/HPSDR_FPGA_USB_Board_top1_800600.jpg

http://www.philcovington.com/SDR/PICS/HPSDR_FPGA_USB_Board_top4.jpg

I soon selected the LTC2208 ADC from Linear Technology. A representative from Linear Technology came across my blog (http://pcovington.blogspot.com/ ) and offered evaluation boards and samples to support the project.

At about the same time my HPSDR project came about, Phil Harman, VK6APH and Bill Tracey, KD5TFD were interested developing a sound card replacement to be used with the SDR-1000 and had started developing with a FPGA development board (XYLO) that had a high speed USB 2.0 interface. They formed the XYLO SDR group to support this. In March 2006, Phil Harman proposed that we merge my HPSDR project and XYLO SDR group into a common project since our goals were similar. By the middle of March 2006 an announcement was made that the groups would merge and the HPSDR.org website was set up.

HPSDR ATLAS and OZY

One of the first tasks was to define a backplane since various backplanes, such as passive PCI, were being proposed. I volunteered for the task which became the ATLAS backplane:

http://www.philcovington.com/HPSDR/ATLAS/REVA/atlas_1_REVA_BW.pdf

http://www.philcovington.com/HPSDR/ATLAS/ALPHA/Atlas_assy.pdf

We had an early volunteer to design an ATLAS plug-in FPGA/USB board to replace the XYLO board, but unfortunately the volunteer was not able to follow through with the task. I agreed to do the design for this board which became the HPSDR OZY board and to provide for the possibility of controlling a SDR-1000 through the OZY’s IO ports that simulate a PC parallel port:

http://www.philcovington.com/SDR/OZYREVA.jpg

Early HPSDR Mercury

Soon after the OZY design was done I began to pursue Mercury. I initially used the Linear Technology supplied evaluation board for the LTC2208. In May of 2006 I became very busy with a work project so I asked Phil Harman if he would like me to send him one of my LTC2208 evaluation boards to play with. I also sent Phil a Crystek low phase noise crystal oscillator that I had chosen as a candidate for driving the encode clock of the LTC2208 ADC. In the link below you can see the Mercury breadboard connected to the OZY. The LTC2208 evaluation board can be seen plugged in vertically to the breadboard with the RG 174/U cable running to the top of it:

http://hpsdr.org/wiki/index.php?title=Image:OZY_MERC_TEST.JPG

Quick Silver Version 1

In late 2006 I decided to design a board that I called Quick Silver (related to Mercury) which would become the initial prototype for HPSDR Mercury:

http://www.philcovington.com/SDR/PICS/QS1R_proto.JPG

http://www.philcovington.com/SDR/QS1RA_12012006.pdf

The initial thought about the design of HPSDR Mercury was that it would use either an Analog Devices AD6636 or AD6620 Digital Receive Signal Processor chip. The ADC6636 was only available in BGA packaging so I chose to use two AD6620 DDCs on the Quick Silver (also called QS1R REV AB). I wanted to investigate whether the AD6620/6636 was suitable for use with the LTC2208 in a HF receiver and also to test the choice of low noise Crystek oscillator encode circuitry which would be critical in determining the LTC2208 ADC’s performance.

It quickly became clear that the AD6620/6636 devices were not suitable from a dynamic range perspective for use in the HPSDR Mercury. About 90% of the DDC functionality was moved from the AD6620 into the Cyclone II FPGA on the QS1R REV AB prototype. There was not enough room in the FPGA to implement a useful final FIR compensating filter to correct for the passband droop of the CIC filters used in the FPGA implemented DDC. I then investigated using two external FIR filter chips made by a company called QuickFilter Technologies:

http://www.quickfiltertech.com/files/QF1D512%20SavFIRe%20Datasheet.pdf

Two of these chips were soon grafted on the QS1R board in place of the AD6620 parts for testing. These chips worked very well but I was concerned about their availability. I made a decision at that point to “bite the bullet” and wrote a one-tap-per-clock FIR filter in Verilog to move all of the DDC functionality into the FPGA. I was easily able to fit two 256 tap FIR filters into the remaining space in the Cyclone II FPGA which eliminated the need for the external QuickFilter FIR chips. During this time Altera also announced the availability of the Cyclone III FPGA in a QFP240 package with enough logical elements and hardware multipliers to be very interesting to SDR work – this also prompted me to develop the one-tap-per-clock FIR filter in Verilog since space would no longer be a concern with this FPGA.

The QS1R REV AB prototype allowed me to also test a Hittite HMC472 0-31.5 dB attenuator, a Sirenza SBF-4089/5089 RF Amp, Phil Harman’s 1.5 MHz BPF stage, and a 30/60 MHz LPF stage that is planned to be used in the HPSDR Mercury design.

The Quick Silver was the testing grounds for ideas that will be used in HPDSR Mercury. Without experience gained from the QS1R REV AB prototype, we would have probably ended up with multiple alpha releases of the Mercury as we found these problems later.

Quick Silver QS1RT VERB

During the development and testing of the QS1R REV AB prototype, the Altera Cyclone III FPGA became available in a QFP240 package with enough logical elements to do some interesting SDR work. I wanted to investigate using a PCI or PCIe connection to the PC to allow much wider bandwidths to be processed than the USB 2.0 interface would allow. This is how QS1RT VERB came about. The VERB contains both the LTC2208 ADC and a TxDAC with a fiber optic or copper connection to a PCI/PCIe board in a PC. The high speed serial interface between the QS1RT and the PCI/PCIe card in the PC is made by a TI TLK2711 Serializer/Deserializer chip that transfers at 2.5 GbPS:

http://www.philcovington.com/SDR/PICS/QS1RT_VERB_MED.JPG

As of October 2007, I am in the process of testing the PCI end of the interface. This board uses some expensive components and is only really meant to be a demonstration of a high speed interface and for experimentation. I want to investigate the ultimate achievable bandwidth to the PC from the VERB and also configuration of the FPGA over the high speed fiber optic link.

Quick Silver QS1R REVB

Taking what I learned from QS1R REV AB prototype and QS1RT VERB, I set about designing a third (and hopefully final!) iteration of the Quick Silver board in October 2007. In previous boards, the RF section of the PCB was routed by hand and the digital sections were done by an auto router. In QS1R REVB, all routing was done by hand to optimize trace lengths and minimize vias in the digital sections of the circuit. The board was simplified with applications such as a HF receiver, VNA, spectrum analyzer, and digital oscilloscope in mind:

http://www.philcovington.com/SDR/qs1r_10112007.pdf

http://www.philcovington.com/SDR/qs1r_revb_sch.pdf

Included on the board is a 192 kSPS Stereo DAC for audio output. There are provisions to allow an expansion BPF/RF AMP/Attenuator board, an on-board 55 MHz LPF, a direct ADC input connector that bypasses the LPF, an I2C control bus, etc… See the schematic above for details.

The QS1R REV B PCB is completed, assembled, and now undergoing testing as of October 30, 2007.

QS1RT Soldered

QS1RT VERB Soldered:

(Click on picture above for a larger version)

QS1RT VERB Bare PCB

(Click on picture above to see larger version)

Boards were received 07-20-2004

QS1RT VERB PCB

QS1RT VERB (VErsatile Radio Board) Project:

(Click on picture above for a larger version)

ADC: Linear Technology LTC2208
DAC: Analog Devices AD9744
CODEC: TI TLV320AIC23B
FPGA: Altera EP3C25-QFP240 Cyclone III
CPLD: Altera EMP240-QFP100 MAX II
USB: Cypress CY7C68013A FX2
SERDES: TI TLK2701
EEPROM: Microchip 24C128

• Internal encode clock is 125 MHz.
• Board interface is through:

1. USB 2.0 or,
   
2. Optic Fiber SFP Module at 2.5 Gbps or,
   
3. Copper Cat6 cable at 2.5 Gbps.

• TI CODEC provides 48/96kHz audio in and audio out
• FPGA can be programmed via USB or Fiber/Copper interface in Fast Parallel Programming mode (byte wide transfers per clock cycle).
• JTAG interface for FPGA and CPLD
• Connectors:
• ADC IN
• DAC OUT
• EXT ENCODE IN
• MIC IN
• L&R AMPLIFIED AUDIO OUT
• L&R LINE IN
• L&R LINE OUT
• DC POWER IN
• JTAG
• USB 2.0
• RJ45 (2.5 Gbps serial over copper)
• SFP (2.5 Gbps serial over fiber)
• TTL Level Serial from FX2
• SPI and I2C to RF external RF board

Status: Prototype boards are scheduled to arrive from PCB manufacturer on July 19th.

RF Front End/BPF Board:
An external RF board will determine the frequency range and will allow home-brew RF front ends. The QS1RT VERB provides an SPI and I2C bus for controlling the RF front end board.

2.5 Gbps Serial Link:
The other end of the 2.5 Gbps interface will be a PCI and PCI Express board for the PC. This interface board will have a matching TI TLK2701 SERDES, a CYCLONE II EP3C25, a TI CODEC, and a PLX PCI or PCIe-to-local bus interface chip. The two boards can be connected by Cat6 copper or optical fiber through the SFP module interface.

The USB 2.0 interface allows the use of the QS1RT VERB with PC laptops or if the copper/fiber interface is not desired.

The ADC IN and DAC OUT ports are transformer coupled using Minicircuits T1-6T transformers which gives 15 kHz to 300 MHz coverage. The external RF front end board will determine the actual frequency coverage of the system.

I am having good luck with Picolight SFP modules for the fiber interface which cost about $50 each. I have successfully tested the optical interface though 100 meters of fiber.

QS1RT Prototype 06272007

QS1RT:

Please click on the image to see a larger version.

TI PCM4222 ADC Now Available

PCM4222:

TI's 24 bit, 216 kHz, 2 channel ADC is now available. 122 dB dynamic range is claimed. The part comes in a 48 pin TQFP package. It is available from Digi-Key in single quantities at $22.42 each.

Here is the link: PCM4222

This is a FFT plot of the PCM4222 at 192 kHz with no input:


The rise in amplitude at about 65 kHz is a concern, but for SDR use a bandwidth of 130 kHz would still be useful.

The PCM4222 is definitely easier to get in single quantities for experimenters than the AKM AK5394 is, but the AKM chip is still probably the winner.

Quickfilter QF1D512

QF1D512

Here is a link to useful FIR engine chip:

http://www.quickfiltertech.com/html/qfilter_page.php?content_id=45

They offer a DIP version for experimentation:

http://www.quickfiltertech.com/html/qfilter_page.php?content_id=59

Mouser stocks the parts.

QS1R:

The current status is that I am working on integrating the QF1D512 part into the QS1R receiver prototype. I have no new projected availability for QS1R. In fact it appears that interest may be somewhat limited - enough so that it would not be worthwhile to offer assembled units. In that case the design files will be posted from anyone who wants to build a board.

QS1R Block Diagrams & Software news

QS1R Diagrams Posted:

Architecture - PDF diagram of QS1R overall architecture

RF Front End - PDF diagram of QS1R RF Front End

Supporting Software:

QS1R/QS1T supporting software will be an open source application called QSRunner. It will support both Windows and Linux. In addition to supporting QS1R/QS1T, QSRunner will also support the SoftRock and HPSDR JANUS-OZY/MERCURY projects.

QuickSilver QS1R Software Defined Receiver Prototype

QS1R Software Defined Receiver:



(Click on picture above for larger version.)

Features:

16 bit 130 MSPS ADC
HPF, LPF, RF AMP Switchable Front End
0-31.5 dB Attenuator in 0.5 dB steps
Cyclone II FPGA
Two AD6620 DDC co-processors
USB 2.0 480 Mbps High Speed Interface to PC
0.1 to 33 MHz coverage (0.1 to 65 MHz extended)
RX bandwidths from 33 MHz to 1kHz
Two independent RX channels anywhere in 0.1 to 33 MHz
6.00" X 4.00" board size
Single +12V 1A supply
Open Source Software and Hardware

Availability:

Projected late January to mid-February 2007

vSound Update

vSound Status

I have been able to get a prototype of the vSound driver to work on Windows Vista beta. I am now waiting until the official release of Vista to continue development on a driver that will work on both XP and Vista. As it looks now, vSound will support Vista and XP only. There will be no support for W2K, NT4, or Win9X/ME operating systems. My main concern is trying to make sure that the vSound driver is compatible with both XP and Vista so I don't have to maintain two different versions based on operating system.

There are a lot of changes being made to driver development under Windows and I have been waiting until it stabilizes a little bit more before releasing a beta driver. My best estimate for availability of vSound beta is early next year after Vista systems hit the streets.

New QuickSilver QS1R Group

Support and discussion group for the new QuickSilver QS1R SDR:

To sign up go Here

Some Interesting Links for Decemeber...

Links

DSPLINKS - great for learning DSP interactively

QUCS- circuit simulator for Linux and Windows

LTC SWCAD - circuit simulator for Windows

Cell Processor - the processor that power the PS3

SciLab- open source numerical computation

Maxima - open source computer algebra system

Octave - open source GNU numerical computation

Mono - open source .NET

Coming Soon!

QuickSilver QS1R SDR Receiver/Scope/Spectrum Analyzer Board

• Based on Linear Technology LTC2208 130 MSPS 16 bit ADC
• Cyclone II EP2C8 FPGA for DDC processor
  
• High Speed USB 2.0 Connectivity
• Two DDC Co-processors
• External Clocking capability
• 6.00" x 4.00" (15.24 x 10.16 cm) board size
• 0.1-65 MHz
• Open Source Software
  

A SDR based on some K2 design ideas

Here is a diagram of a SDR that uses ideas from the K2 RF front end and PLL synthesizer:

K2LikeSDR.pdf

It would use the K2's RF front end. I would substitute the TUF-1 mixer of the K2 with a switching mixer based on a FST3125 bus switch. The QSD would be at a fixed IF of 5 MHz. The LO for the QSD would be derived from a fixed 20 MHz oscillator divided by 4 to generate the quadrature signals needed to driver the QSD switches. The K2's PLL would be modified by eliminating the variable reference oscillator (resulting in the PLL tuning in 5 kHz steps) and substituting one of the LMX National PLLs for the MC145170 PLL used in the K2 design. The K2's VCO design is good, but I would also eliminate the VCO AGC circuit of the K2.

SDR LO Ideas

SDR LO Ideas:

There has been a lot of discussion of using DDS or PLLs for the LO generation for HPSDR and SoftRock like receivers. In the current SoftRock series the LO is generated by a crystal oscillator. The downsides of the above approaches are:

1. DDS: spurs and cost of a decent low jitter/low noise clock source. Some of the 400 and 500 MHz DDS chips are on the expensive side.

2. PLL: phase noise. A scheme using a microwave VCO/PLL and dividing it down into the HF range has been discussed. The latest feeling is that the phase noise reduction even after dividing down is not enough to provide a high performance system. A dual PLL loop approach has been proposed to improve phase noise performance but it is likely to be expensive. There are also PLL/DDS approaches of varying complexity.

3. Xtal: limited frequency agility, you are limited to tuning within the passband of your computer sound card.

There is a forth method that might work for lower cost SDR circuits like the SoftRock. It involves the method used for many years in which a VFO is mixed with a crystal oscillator. It is not hard to make a pretty stable and low noise VFO. The output of the VFO/Xtal oscillator could be fed into a microprocessor (like Microchip PIC18F2455/2550/4455/4550 series) or a FPGA/CPLD. The microprocessor or FPGA/CPLD would count the frequency of the VFO/Xtal oscillator and feed the frequency information to the PC for display in one of the SDR programs like PowerSDR or Rocky. This way you would have an indication of your true operating frequency as well as a real tuning knob that is coupled to the VFO (like a real radio!).

Since there is already a microprocessor or FPGA/CPLD involved in measuring the LO frequency and transmitting that information to the PC, VFO stabilization (like Huff-n-Puff techniques) could be also done in the microprocessor or FPGA/CPLD to tame drift in the VFO. This scheme would also work well for the real sampler with AD7760 I describe in the previous blog or when the ADC is integrated on the QSD board when eliminating the sound card. The frequency information would be transmitted to the PC over USB like the audio stream.

In the case where you would want to use the PC sound card but transmit the frequency of the VFO/Xtal oscillator to the PC, provisions could be made in the USB PIC (or you could use a FTDI chip) to control the bandpass filters also.

Possible QSD/ISD Switches/ ADC Idea/Misc

QSD/ISD Switches:

Here is a link the PDF data sheets of analog switches that can be investigated for use in QSD/ISD circuits:

http://www.philcovington.com/HPSDR/QSD_SWITCH/

Interesting ADC:

Here is a link to an interesting ADC by Analog Devices:

http://www.analog.com/UploadedFiles/Data_Sheets/AD7760.pdf

It is a 24 bit, 2.5 MSPS ADC. Here is the circuit idea:

http://www.philcovington.com/HPSDR/TEMP_STUFF/AD7760QSD.pdf

It uses 1/2 of a QSD (not quadrature sampled) to mix the frequency band of interest down to zero Hz with a bandwidth of something like 250 kHz. The IF would be offset to something like 125 kHz. The ADC samples the 1/2QSD output and results in a real data stream. A FPGA or CPLD mixes the real data stream with a complex NCO to generate a quadrature data stream which is sent over USB to the PC where the remaining processing is done. The advantage is a 1 X LO and no I/Q balance problems. One disadvantage is that your sampling rate should be 4 times the desired bandwidth. For narrow band applications this should be no problem because the AD7760 will sample up to 2.5MSPS. A 500 MSPS rate into the PC should allow a bandwidth of almost +/- 125 kHz from the LO frequency.

Nice SDR Enclosure?

Ken N9VV sent me a link to a cool PC case:

http://www.origenae.com/product_x15e.htm

vSound Progress & HPSDR OZY

vSOUND

I thought I'd better post an update to my progress on the vSound virtual sound card driver. I have been looking at the WDF stuff from Microsoft and how it could be supported in the upcoming Vista. There are some considerable issues in writing sound drivers that will work in Vista with the Digital Rights Management (DRM) crap. I am hoping to write the driver so it will work in W2K, XP, and Vista.

I would very much like for the driver to work like jack does in Linux. Some things are not possible in Windows, but I think I can get close to jack's functionality.

I hope to have something together to test in a month or so.

HPSDR OZY

I posted a photo of a almost complete OZY board on the HPSDR Wiki. Testing is going well. See updated info at hpsdr.org


73 de Phil N8VB

HPSDR Mentioned in ARRL Article

http://www.arrl.org/news/features/2006/06/09/1/?nc=1

The other news is that HPSDR has joined forces with TAPR to provide bare boards and parts:

http://www.tapr.org/kits_atlas.html?PHPSESSID=0e5e57933bb81af7e79b13ca6708d075

Small Update

The HPSDR project is progressing nicely. We have a design for the ATLAS backplane that has passed the alpha stage. The JANUS board is close to alpha. The OZY board's schematic has been posted for review and comment.

ATLAS orders are close to 200 boards now.

If you have no idea what I am talking about check out:

hpsdr.org

Also join the HPSDR mail reflector which is quite active.

www.hamsdr.com

is another site you should check out if you are interested in Software Defined Radio.

HPSDR and XYLO SDR group combine

HPSDR PROJECT:
We have combined the HPSDR and XYLO SDR groups into one project with common goals. There is a new domain and website for the project:

http://hpsdr.org

The XYLO SDR mailing list has now become the HPSDR mailing list. To join the list go to:

http://hpsdr.org/reflector.html

ATLAS BUS:

This is the first attempt at defining the physical layout of the Atlas bus.

The board ended up being 5.500" x 3.940", six slots, and 4 layers with
the following stackup:

1. Ground Plane (top component side)
2. YBUS
3. Power Plane (+12,-12, +5, -5, +3.3)
4. XBUS (bottom side)

Details are in the following document:

http://www.philcovington.com/HPSDR/ATLAS/Atlas_doc.pdf

After reading the document there are some other pdfs (such as the
schematic) in this folder:

http://www.philcovington.com/HPSDR/ATLAS/

For those interested, I'd appreciate if you'd please take a look at
the documents and make questions/comments.

HPSDR Progress Report - 02-21-2006

LTC2208 Mercury Board:
The HPSDR project is now broken down into various sub-projects. The most important is the Mercury board which contains the LTC2208 130 MSPS ADC. The Mercury board will also contain a FPGA to do the DDC (Digital Down Conversion) function. There will probably be an option to install a Cypress FX2 USB2 microcontroller to make the board stand alone for certain applications. Otherwise the FPGA will connect to the Atlas bus. If you are not sure what Atlas is then see the Xylo list archives.

I have a few LTC 2208 evaluation boards coming from Linear Technology. They should arrive this week. I want to compare the LVDS board to the CMOS board to see if there are any advantages of using the LVDS mode for the 1-70 MHz range.

Initially I think I will program the on board FPGA so that the 130 MSPS from the LTC2208 are downsampled to <= 250 kSPS. The 250kSPS then can be processed in the same way that we process the data from the soundcard. PowerSDR can then be modified to be used with the Mercury board.

DttSP#:
After reviewing the roadmap that Flex Radio has published for the future version of PowerSDR I have decided that it does not appear to meet my needs for the HPSDR project. I am starting work on a library based on DttSP called DttSP# (DttSPSharpened). It will be a C# wrapper around DttSP where the creation of radio objects are handled by C# and the low level functions are delegated to DttSP. There will probably be an alternate constructor for each object that will implement the equivalent DttSP function in C# so performance can be compared. DttSP# will be target Mono on both Linux and Windows.

Linear Technology LTC2208

I have settled on the Linear Technology LTC2208 16 bit, 130 MSPS ADC for the HPSDR project. The LTC2208 has some unique features that put it ahead of offerings from Analog Devices.

Here is the datasheet:

http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1155,C1001,C1150,P13693,D9659

of particular interest is the PGA, randomizer and dithering features.

We completed our move into our new home last weekend. We are getting settled in and soon I will start on the Mercury board - which is based on the LTC2208.

New Job

New Job:

I start a new position with the Ohio State University Department of Astronomy in the Imaging Sciences Laboratory on Monday December the 19th. This marks the end of my 5 year stint as a factory automation consultant. I learned a lot in those five years, but I am glad to be moving to something new, interesting, and challenging.

Before going out on my own as a consultant, I worked as an Electrical Engineer with a Department of Defense contractor in the 1980s and early 90s. The company was Piqua Engineering, Inc. - I worked there for 10 years. After PEI a few former employees and I started a company called Technitron Labs, Inc. TL's main product was specialized instrumentation for paper mills, municipal waste and drinking water treatment plants, and industrial water treatment plants. TL was sold after a few years (along with my designs); I moved on to doing Controls Engineering at a company called Zed Industries, Inc. Zed made packaging machinery and thermo-formers. I spent 6 years at Zed bringing their equipment control systems up to modern standards before moving on to a purely software engineering job.

Finally, in 2001 I started vHMI Automation, Inc. The main product when I first started was a Visual Basic based Human Machine Interface (HMI) package that I wrote and various C++ based Programmable Logic Controller communication drivers. I expanded into both hardware and software system consulting in factory automation and control systems. I also did instrumentation, automated test system, and microcontroller based system design. Because I was an independent consultant, it enabled me to live outside of the USA for a while (where I learned a lot about how other countries view the US - which is not as bad as you hear from the news). I also realized how much we take for granted the life we have in the USA. I returned to the US in June of 2004.

I am very happy about leaving the stressful and uncertain side of consulting behind. I am looking forward to working in OSU's Astronomy Department where they design and build extremely interesting instruments for ground-based optical and infrared astronomy.

http://www.astronomy.ohio-state.edu/MODS/Pictures/

Update... HPSDR

HPSDR Progress:
I am now able to configure the Spartan 3 FPGA over USB. I switched from slave parallel mode to slave serial configuration loading. This will make the FX2 firmware easy to use with Altera Cyclone FPGAs in addition the the Xilinx Spartan 3.

I am in the process of getting samples of Linear Technology's LTC2208 16 bit, 135 MSPS ADC. I still plan to develop a QSD based RX board using the TI PCM4202 as the ADC - So there will be a high bandwidth path as well as a low bandwidth path in the HPSDR. The LTC2208 board will probably get it's own FPGA to do DDC. The DDC's ouput will then feed the Spartan 3 which will be responsible for performing the second part of the DSP chain.

Verilog Projects for the Xylo Board:
I set up a folder on my server that people can browse . It will contain various verilog projects that can be tried on the Xylo board for educational purposes.

http://www.philcovington.com/FPGA/

Microscope for SMT

Here are a few pictures of an early Birthday present from my wife:





The 10x magnification makes it perfect for soldering and inspecting smt. I was able to hand solder the 208 pin 0.5mm pitch Xilinx Spartan 3 FPGA used on my HPSDR board in under 5 minutes which included inspecting each pin. If you do any serious smt work at all, you may want to consider purchasing a similar microscope. I was amazed at the difference it made in speed and comfort while working with fine pitch parts. (Price is about $214 + shipping).

Some notes on soft real-time under Linux 2,6...

Linux 2.6 Kernel:

With the 2.6 kernel, a large step was taken to improve Linux's real-time capabilities. The improvements are a result of two major changes in the kernel (as well as many minor changes):

1. Kernel preemption. Before 2.6 the scheduler was able to preempt threads running in user mode, but when the thread made a system call that caused a context switch to kernel mode there was no way for the thread to be preempted. This situation could cause a high-priority thread that was ready to run to be blocked by a lower priority thread inside a system call. With 2.6, the kernel can now be preempted.

2. Constant time scheduler. Prior to version 2.6, the time that it took for the scheduler to decide which thread to run depended on how many threads that were currently running on the system. The more threads on the system, the more time it took the scheduler to make a decision. In version 2.6, the scheduler makes the decision in the same amount of time whether there are 1 thread or 100 threads on the system. This makes the system more predictable.

Scheduling Priorities:

Most processes are started with the default scheduler: SCHED_NORMAL. There are two other schedulers that can be used for real time threads:

1. SCHED_FIFO. This is a first-in first-out scheduler. The highest priority SCHED_FIFO thread ready to run will be scheduled. Once the thread starts running it will only be preempted if a higher priority real time thread becomes runnable or if the thread yields the processor.

2. SCHED_RR. This is a round-robbin scheduler. Unlike SCHED_FIFO, the SCHED_RR scheduler does not allow a thread to run indefinitely unless it is preempted by a higher priority thread. If there are multiple threads of the same priority and they are runnable, the scheduler will alow each thread to run for a specific time before it is preempted (quantum).

To start a process with one of the real time schedulers you have to use the system call sched_setscheduler(pid_t pid, int policy, const struct sched_param *p). Once a thread is running under a real time scheduler you can adjust its priority with a call to sched_setparam().

Linux 2.6 Kernel Timers:

nanosleep(): In Linux 2.6 the kernel only checks on timers once every "jiffie" which defaults to 1ms (it was 10ms before 2.6). Even though you can specify times with nanosecond resolution in the call to nanosleep() don't expect that kind of time resolution. nanosleep() is good for a minimum of 2ms - meaning the timer will finish within 2ms of the programmed interval.

If more accurate timing is needed, /dev/rtc can be used. If you do a read() of /dev/rtc it will block until the rtc timer tick is hit. You can program the rtc's tick rate from 2 Hz to 8192 Hz.

Locking memory:

To keep the memory allocated for a process from being swapped out to disk, you can lock all or part of its memory in RAM using the mlock() call. You can unlock the memory by calling munlock(). If you want to lock the entire memory of a process, a call to mlockall(int flags) will lock the entire address space of a process into RAM. The flags are MCL_CURRENT and MCL_FUTURE. MCL_CURRENT will lock the current memory allocated to the process into RAM. MCL_FUTURE will lock any future allocation of memory by the process into physical RAM. You will usually want to or MCL_CURRENT and MCL_FUTURE together.