HPSDRwiki - User contributions [en]

Ghpsdr3-Qt

2018-05-05T17:07:34Z

WikiSysop: /* Architecture */

==A cross platform HPSDR Radio platform==

===C++/Qt version of the ghpsdr3===

[[Image:QtHPSDRServer.png |right| QtHPSDRServer program status page. (Click to enlarge)]]

'''ghpsdr3-Qt''' is a software defined radio server/client or server/dspserver/client format C++/Qt program written specifically for HPSDR by John Melton, G0ORX/N6LYT.

The software is being developed on the Ubuntu version of Linux (specifically version 11.10). I also compiles and runs on Windows 7 and Windows XP, and MacOS

This version of '''ghpsdr3-Qt''' allows for the server and client to be on the same machine or separate machines. The server is written in C++/Qt and run on John and others are working on a full set of clients to run on multiple machines connecting to the servers through TCP/IP protocals.

To follow the development of this code look at John's Blog http://g0orx.blogspot.com/

[[Image:QtHPSDRServer2.png |right| QtHPSDRServer program configuration page. (Click to enlarge)]]
===SVN===
The software is available from SVN and includes a precompiled executable in the bin directory. There are now a compiled version of the 32-bit Windows version on the openHPSDR web page, For other platform you will need to compile the code yourself. The README explains how to compile the source if you wish to modify the code.

Since this code does not currently run on Windows here is the Linux svn command,

svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/N6LYT/Qt

===Libraries===
It uses a modifed version of DttSP that is ported from the Windows version. this code is compiled into the QtDSPServer. The DttSP code is provided with the SVN distribution.

This code was written to minimize external dependencies. The only extern library is

* libfftw3 which is the Fast Fourier Transformation library

===Architecture===
[[Image:ghpsdr3.png |thumb |400px|right|Architecture of the server/dspserver/client configuration. (Click to enlarge)]]
The image illustrates the architecture of the ghpsdr3-Qt software chain. The software works with either the single receiver verilog code (Mercury 2.9) or the multiple receiver verilog code or (Mercury 3.x). If Mercury 2.9 is install only one receiver can be accessed.

'''HPSDR''' box represented the hardware and the Mercury/Ozy,Penelope, Mercury/Magister,Penelope, or Mercury/OzyII,Penelope

'''Link between HPSDR and Server''' uses the communication protocol documented in USB Protocol at the link on this page or in the SVN in the Documentation directory.

[[ghpsdr3-Qt QtHPSDRServer|'''QtHPSDRServer''']] box is a software multiplexer. It takes the multiple receiver communication protocol and divides it in to single receiver channels.

'''Link between Server and Receiver clients''' output is the same IQ signal format as the single receiver USB format except the data is sent over UDP link. The commands are handled as TCP protocol format to allow acknowledgement of the command.

'''Receiver Clients''' can be in many forms and it was designed to foster experimentation. The first client is the same interface used in [[ghpsdr3 receiver|'''ghpsdr''']]. The second interface is a simple waterfall called [[ghpsdr3 monitor|'''monitor''']] used to keep track of activity on other bands. Both of these programs the DSP code in in the GUI program. These programs usually will be with a short distance of the server as the bandwidth is quite large for most home network connections.

[[Image:QtRadio.png |right| QtRadio program. (Click to enlarge)]]
In an effort to demonstrate world wide access to your receiver a third approach was developed. In this method the receiver client is a [[ghpsdr3 dspserver|'''dspserver''']] that take the output of the [[ghpsdr3 Server|'''Server''']] and creates a low bandwidth version of the spectrum in 8 bit data, the audio data 8-bit ALAW audio format at only 480 sample size at 10 times a second. The [[ghpsdr3 dspserver|'''dspserver''']] also accepts commands from the client. To run multiple low bandwidth clients you must run a separate copy of [[ghpsdr3 dspserver|'''dspserver''']] for each client.

The base code for the current [[ghpsdr3 jmonitor|'''jmonitor''']] is written in java. It can be run as a program on a computer or within a web browser. This code has also been ported to the [[ghpsdr3 iphone|'''iphone''']] and [[ghpsdr3 android|'''Android''']] platforms so that you can monitor your radios on the go. At the 2010 Dayton Hamvention, John Melton monitored his receiver in England from the TAPR booth on the Hamvention floor.

[[Image:QtLogger.png |right| QtLogger program. (Click to enlarge)]]

[[Category:Ghpsdr3]]

VNA

2012-11-24T03:38:39Z

WikiSysop: /* Update 14 August 2012 */

==Vector Network Analyser==

This project is to develop PC and FPGA software in order to use Hermes (and possibly Mercury, PennyLane and Metis) as a Vector Network Analyser.

Project Leader: Phil VK6APH

====Update 14 August 2012====

FPGA code for Hermes has been developed and tested that enables the transmitter (which will be used as the VNA signal source) and receiver in Hermes to be phase synchronous.

PC code has been written (in C# using the free Visual Studio 2010 software) to implement the Reflection function of a VNA. The code draws a Smith Chart, which is zoomable, and displays the Impedance being measured as a complex value on the chart. Additionally, the equivalent series and parallel impedance is displayed as are the equivalent component values at the measurement frequency. The VSWR and Return Loss are also displayed.

The code enables Open/Short/Load calibration to be made (presently at a single frequency); the calibration data can be saved to a file and subsequently re-loaded as required. The repeatability of measurements after loading the previous calibration data is excellent.

The screen shot shows the current status of the PC software. An number of items being displayed are for debug purposes only and will be removed when no longer required.

The additional code required in the Hermes FPGA is very small. In which case a future version of code will include the ability to use Hermes in VNA mode via a Command & Control flag.

[[Image:HermesVNA2.png|VNA Screen Shot. ]]

====Reflection Bridge====

Reflection measurements require the use of a directional coupler or reflection bridge. There are a number of different designs, but one that is currently being looked at is a design by Sam Wetterlin. It uses a MiniCircuits balun transformer augmented by a string of three ferrite beads.

[http://www.wetterlin.org/sam/Reflection/3BeadBalunBridge.pdf PDF showing Sam's design and characterization]

The transformer is MiniCircuits TC1-1-13. There are several variants. Is there any advantage to any specific one? The following link leads to a page listing MiniCircuits' "configuration G" (ie balun) transformers.

[http://www.minicircuits.com/products/transformers_sm_g.shtml Configuration G balun transformers]

The ferrite beads are Steward LFB090050-000, which seem to match Digikey part number 240-2135-ND, listed as a product of Laird-Signal Integrity Products.

VNA

2012-11-24T03:36:11Z

WikiSysop: /* Update 14 August 2012 */

==Vector Network Analyser==

This project is to develop PC and FPGA software in order to use Hermes (and possibly Mercury, PennyLane and Metis) as a Vector Network Analyser.

Project Leader: Phil VK6APH

====Update 14 August 2012====

FPGA code for Hermes has been developed and tested that enables the transmitter (which will be used as the VNA signal source) and receiver in Hermes to be phase synchronous.

PC code has been written (in C# using the free Visual Studio 2010 software) to implement the Reflection function of a VNA. The code draws a Smith Chart, which is zoomable, and displays the Impedance being measured as a complex value on the chart. Additionally, the equivalent series and parallel impedance is displayed as are the equivalent component values at the measurement frequency. The VSWR and Return Loss are also displayed.

The code enables Open/Short/Load calibration to be made (presently at a single frequency); the calibration data can be saved to a file and subsequently re-loaded as required. The repeatability of measurements after loading the previous calibration data is excellent.

The screen shot shows the current status of the PC software. An number of items being displayed are for debug purposes only and will be removed when no longer required.

The additional code required in the Hermes FPGA is very small. In which case a future version of code will include the ability to use Hermes in VNA mode via a Command & Control flag.

[[Image:HermesVNA2.png|thumb|100px|VNA Screen Shot. Click to enlarge.]]

====Reflection Bridge====

Reflection measurements require the use of a directional coupler or reflection bridge. There are a number of different designs, but one that is currently being looked at is a design by Sam Wetterlin. It uses a MiniCircuits balun transformer augmented by a string of three ferrite beads.

[http://www.wetterlin.org/sam/Reflection/3BeadBalunBridge.pdf PDF showing Sam's design and characterization]

The transformer is MiniCircuits TC1-1-13. There are several variants. Is there any advantage to any specific one? The following link leads to a page listing MiniCircuits' "configuration G" (ie balun) transformers.

[http://www.minicircuits.com/products/transformers_sm_g.shtml Configuration G balun transformers]

The ferrite beads are Steward LFB090050-000, which seem to match Digikey part number 240-2135-ND, listed as a product of Laird-Signal Integrity Products.

File:HermesVNA2.png

2012-11-24T03:35:30Z

WikiSysop:

MediaWiki:Portal-url

2011-11-05T02:51:12Z

WikiSysop: Created page with "Project:Community Portal"

Project:Community Portal

METIS

2010-10-20T02:11:19Z

WikiSysop:

[[Image:OzyII_Block_Diagram_V1.9.jpg|thumb|600px| Block diagram for METIS V1.0 23 May 2010]]
'''METIS''' (formerly called OzyII) will be a high speed PC interface. Whilst the original Ozy board has served us well to date, in order to implement some of the future HPSDR projects we are going to need a faster interface between the various boards on the Atlas bus and the PC.

METIS is a kick off point for this project. Since this board will not need to support the SDR1000 there will be room for testing other high performance/speed interfaces.

Initial thoughts are around an Atlas size board that contains a large, leaded, Altera Cyclone III FPGA connected to a Gigabit Ethernet PHY.

User input relating to the design and features is requested via the HPSDR reflector.

Project Leader: Phil, VK6APH

===Update: 13 September 2010===

Have done some simple speed tests between Metis and my PC. At 100T, full duplex, I can send 1kB payload UDP/IP packets simultaneously in both directions at 96Mbps (12MBps).
At 1000T this increases to 560Mbps (70MBps). The delays are in the PC code (untuned C# using .NET Sockets) since the Metis board will operate at 960Mbps (120MBps) but my PC and router won't!

Beta PCBs and parts have been ordered and will be automatically assembled in order to check the design is production ready.

===Update: 30 August 2010===

Discovery code working. Can also now erase and program the EPCS16 flash memory via Ethernet. This will enable the FPGA code to be updated and maintained without the need for an Altera Byte or USB Blaster. Only major code left to add is I2C so that Penelope etc can be controlled via the Atlas bus.

Bill, KD5TFD, has built his Alpha PCB and has it working 100%. Kevin, M0KHZ, has made some slight modifications to the location of components on the PCB to enable a robotic pick-and-place machine to load parts on the board. Beta PCBs will be manufactured shortly.

===Update: 15 August 2010===

ARP, ping and DHCP all working. Currently implementing OzyII discovery code.

===Update: 11 August 2010===
OzyII Alpha PCB is fully functional. Some minor changes to the PCB will be made ready for the Beta run. Alpha PCBs currently being build by Bill, KD5TFD, and Kevin, M0KHZ. Presently adding ARP, DHCP and ping functions to the FPGA code. Basic automatic 100T/1000T network speed detection and switching tested and working.

===Update: 1 August 2010===
Completed building Alpha PCB and started testing. Works fine at 100T, need to check at 1000T next. Photo of top side of board nearby. [[Image:OzyII_Alpha_PCB.JPG|thumb|600px|OzyII Alpha PCB]]

===Update: 15 July 2010===
The PCB layout has been completed by Kevin, M0KHZ. Alpha PCBs have been ordered and are due this week, all parts have been ordered and are available. Verilog code has been written to test the PHY at 1000T and it appears to run OK.

===Update: 23 May 2010===
V1.1 of the OzyII schematic is available for peer review. The document is here [[Media:OzyII_v1.1.pdf]], note that if you click on a component a descriptive box opens showing full details of the particular component. Detailed checking of the schematic by others will greatly reduce the potential for errors in the Alpha PCB.
Comments, corrections and suggestions via the openHPSDR reflector please.

===Update: 8 April 2010===
Since OzyII will not incorporate and FX2 uP we will need a way of updating the FPGA code. Initially we can use a Byte Blaster or USB Blaster but eventually we will need a simple way for the user to install updated code via the Ethernet port. Two things need to be completed in order to enable this. Firstly, the ability to write to the EPCS16 configuration EEPROM via FPGA code and secondly the ability to have two sets of code in this chip. The first set of code (Factory code) will be loaded at power on if a particular jumper is installed. This code will look for the new FPGA code to arrive at the Ethernet connector. Without the jumper installed, at power on, the FPGA will load the alternative code (called the Application code) which will be the latest OzyII code.

Thanks to some work last year by Michael Wyrick, N3UC, I've been able to write some test code that allows me to read and write to any address in the EPCS16 and also select which of two sets of code to load at power on.

===Update: 15 March 2010===
MDIO interface to the PHY is now working; can set up its transmit and receive registers. I2C Master implemented in the FPGA for setting up Penelope and general I/O.

===Update: 5 March 2010===
Have implmented the discovery code in the FPGA and it's working fine. Also connected the 25AA02EA8 to the FPGA and the board now reads its MAC address from the EEPROM at start-up.

===Update: 2 March 2010===
DHCP is now implemented and working so a soft core uP is not immediately requred. The block diagram for the Alpha OyzII PCB has been updated and the PCB layout commenced. It has been decided not to include an FX2 USB interface since the Ethernet PHY provides all the connectivity to the PC necessary.
Have completed PC code that sends a broadcast message over the users network looking for an OzyII card. If an OzyII board detects this message it will reply with its IP and MAC addresses. The Verilog code has been simulated in C# and is working against the PC broadcast code.

===Update: 11 February 2010===
Have now implemented ARP and PING in OyzII so most of the IP Discovery code is now working. My PC will send an ARP request when KISS Konsole first starts to determine the MAC address of OzyII.

Now looking at implementing a soft core uP as an alternative to doing the Discovery code in Verilog.

===Update: 31 January 2010===
Now have OzyII sending and receiving UDP/IP frames. Have also implemented UDP/IP in [[KISS Konsole]]. Still have to add all the IP Discovery code but the concept basically works! Many thanks to Bill, KD5TFD, for dragging me up the Ethernet learning curve :)

Screen shot of KISS Konsole tuned to a Broadcast station below.[[Image:KK_UDP.JPG|thumb|600px|KISS Konsole and OzyII using UDP/IP. 31 January 2010]]

===Update: 29 January 2010===
I now have OzyII sending UDP/IP frames to my PC. Using C# .NET Sockets to receiver the data is very straightforward. Next step is to add UDP/IP support to [[KISS Konsole]].

===Update: 14 January 2010===
I've completed modifying K.I.S.S. Konsole to work with Ethernet data rather than USB by replacing libUSB with SharpPcap.
I've also added Ethernet support to Kirk's Ozy code. OzyII now sits on the Atlas bus, works with Mercury and Penny etc and talks to K.I.S.S Konsole.

There is an issue when using the Micrel KSZ9021RL evaluation board in full duplex but I think this is crosstalk due to the long leads from the chip to the edge of the board.

A prototype PCB is presently being layed out.

===Update: 27 October 2009===
I now have the receive code working in the FPGA and have been able to couple it to Kirk's v 1.7 Ozy code. That enables me to produce audio from the Mercury card using some PC software written by Bill, KD5TFD, that emulates data from PowerSDR or KK over Ethernet. Next step is to add the Ethernet transmit code to Ozy so we can send I&Q data from Mercury to the PC. By replacing the USB interface in PowerSDR or KK we will be able to test the entire system.

Lyle, KK7P, commenced drawing the schematic for OzyII.

===Update: 27 September 2009===
I now have the CRC32 generator working in the Ozy FPGA. The board can now generate Layer II Ethernet frames without being connected to a PC. This should be the last major building block necessary to complete the board design.

===Update: 26 September 2009.===
I'm making good progress with the development of a Gigabit interface to the Atlas bus i.e. OzyII (Aussie2).

The choice of a Micrel KSZ9021RL PHY chip looks like paying off. The chip uses the RGMII interface standard which means it only requires 12 pins in
order to connect to the associated FPGA. Given the low pin count 'we' (i.e. Lyle KK7P) should be able to support both the PHY and an FX2 chip on the
PCB. It's also only needs a single supply, is small, low power and low cost.

We can use the FX2 as a conventional USB interface, just like Ozy/Majster, to program the FPGAs associated Flash memory by making it emulate an Altera
USB Blaster and also perhaps hand off some of the Ethernet protocol processing to it (later on).[[Image:Micrel_evelauation_board.JPG|thumb|600px|Micrel KSZ9021RL Evaluation Board. 26 September 2009]] Micrel provide a very nice evaluation board for the KSZ9021RL (see nearby photo).

This has an Eternet connector, access to the RGMII pins and a USB interface. TheUSB interface provides access to read/write all the internal
registers of the PHY. There is also a very nice GUI on the PC that they also provide so you can play with all the register settings.

I've been able to interface the evaluation board to an Ozy board (see nearby photo)
so that I can write FPGA code to test the PHY in ernest.

[[Image:Test.JPG|thumb|600px|Micrel evaluation board piggy-backed onto an Ozy board. 26 September 2009]]

By using the USB port on Ozy I can format any Ethernet frame I like on the PC, send it to Ozy and then onwards to the PHY and my lab Ethernet switch.
Similarly, any Ethernet frames the PHY receives are by sent to the FPGA and thence via Ozy's USB port back to the PC.

Thanks to Bill, KD5TFD, for this suggestion - it has certainly speeded up development.

We intend to include an FX2 on the final OzyII board to enable it to be used as an Ozy board, enable the FPGA and/or its Flash memeory to be programed via a pseudo Altera USB Blaster and perhaps provide UDP or TCP support.

I've written a simple C# program on the PC that allows me to format an Ethernet frame, or send a canned one, to the PHY. The PC sends the entire
frame, including calculating the CRC32. I can also display any received Ethernet frames on the PC. Again, there is a screen shot of the PC software
nearby.
[[Image:Success.JPG|thumb|300px|PC code to send & receive Ethernet frames from OzyII. 26 September 2009]]

Being able to generate any type of Ethernet Fame on the PC is so much faster and easier than doing the code in the FPGA. Once I have the basic code
working in C# then I can port it to Verilog.

So far this all seems to work just fine. If I use the MAC address of the Ethernet Card in my PC as the 'To MAC address' then my Ethernet Switch
correctly forwards the frames to the PC. Similarly the switch learns the MAC address I have use as the 'From MAC address' and returns frames just to
the PHY board.

This will be a useful developement platform as we move to more advanced protocols in the future.

The next step is to get the FPGA code to generate the Ethernet preamble plus MAC addresses, get the data Payload from the PC via USB, and calculate
and append the CRC32.

I have this code working in simulation but have yet to try it in the actual Ozy + PHY hardware. (Now working in the FPGA - see update above).

Once that is working I can grab Mercury I & Q data off the Atlas bus and
send that to the PC via Ethernet. Similary, the demodulated audio and I & Q
data can be returned via Ethernet. We will need a modified version of
PowerSDR/KK to test this and Bill KD5TFD is already working on ways to do
this.

In order to use this initial software it will be necessary to program the
MAC address of the PC you intend to use with OzyII into the board. We will
provide a Flash memory chip on the PCB that will be programmed with the
boards MAC address during manfacture.

With the FPGA <> PHY hardware interface working we can start designing the
schematic for OzyII and Lyle KK7P will commence that after his holidays.

By using a large FPGA it offers the potential to add a soft core microprocessor in the future so that the board can run a full TCP/IP stack, UDP etc. e.g. uIP http://www.sics.se/~adam/uip/index.php/Main_Page

Initially we will use the Gigabit PHY as just a fast connection to the PC and use raw frames to communicate.

Feedback and comments are requested via the HPSDR reflector.

Ethernet Notes:

In general, an Ethernet subsystem is divided into two parts: the media access controller (MAC) and the physical device (PHY or line interface). Generally, the MAC handles generating and parsing physical frames and the PHY handles how this data is actually moved to or from the wire. The PHY is just a means of transmitting raw bits rather than logical data packets over a physical link that are connecting network nodes.

===Useful info:===
http://www.wireshark.org/

http://www.techonline.com/article/pdf/showPDFinIE.jhtml?id=2088017281

http://www.cs.rice.edu/CS/Architecture/docs/shafer-tree0611.pdf

Altera White paper on Ethernet using Cyclone III and NIOS soft core

http://cm.altera.com/g/?QYKFH2NRLY:SU6QAW3Y1V=ssID:480603690

[[Category:Hardware nearing completion]]

Talk:METIS

2010-10-20T02:10:47Z

WikiSysop: Talk:OZYII moved to Talk:METIS: Name change

==PHY?==

What does PHY in the second to last sentence mean? [[User:VK2NRA|Richard Ames, VK2NRA]] 07:51, 9 May 2009 (UTC)

:PHY is an industry term meaning the physical layer interface. In this case the reference is to the wire-level Ethernet interface. In the OSI Model nomenclature, it would be "Layer 1." If the reference is to a PHY integrated circuit, the IC implements OSI Layers 1 and most likely Layer 2 and perhaps even some of Layer 3. [[User:KE9H|Graham, KE9H]], 10 May 2009

OZYII

2010-10-20T02:10:47Z

WikiSysop: OZYII moved to METIS: Name change

#REDIRECT [[METIS]]

Talk:OZYII

2010-10-20T02:10:47Z

WikiSysop: Talk:OZYII moved to Talk:METIS: Name change

#REDIRECT [[Talk:METIS]]

METIS

2010-10-20T02:10:47Z

WikiSysop: OZYII moved to METIS: Name change

[[Image:OzyII_Block_Diagram_V1.9.jpg|thumb|600px| Block diagram for OzyII V1.0 23 May 2010]]
'''OzyII''' (or maybe Aussie II?) will be a high speed PC interface. Whilst the original [[OZY|Ozy]] board has served us well to date, in order to implement some of the future HPSDR projects we are going to need a faster interface between the various boards on the Atlas bus and the PC.

Aussie II is a kick off point for this project. Since this board will not need to support the SDR1000 there will be room for testing other high performance/speed interfaces.

Initial thoughts are around an Atlas size board that contains a large, leaded, Altera Cyclone III FPGA connected to a Gigabit Ethernet PHY.

User input relating to the design and features is requested via the HPSDR reflector.

Project Leader: Phil, VK6APH

===Update: 30 August 2010===

Discovery code working. Can also now erase and program the EPCS16 flash memory via Ethernet. This will enable the FPGA code to be updated and maintained without the need for an Altera Byte or USB Blaster. Only major code left to add is I2C so that Penelope etc can be controlled via the Atlas bus.

Bill, KD5TFD, has built his Alpha PCB and has it working 100%. Kevin, M0KHZ, has made some slight modifications to the location of components on the PCB to enable a robotic pick-and-place machine to load parts on the board. Beata PCBs will be manufactured shortly.

===Update: 15 August 2010===

ARP, ping and DHCP all working. Currently implementing OzyII discovery code.

===Update: 11 August 2010===
OzyII Alpha PCB is fully functional. Some minor changes to the PCB will be made ready for the Beta run. Alpha PCBs currently being build by Bill, KD5TFD, and Kevin, M0KHZ. Presently adding ARP, DHCP and ping functions to the FPGA code. Basic automatic 100T/1000T network speed detection and switching tested and working.

===Update: 1 August 2010===
Completed building Alpha PCB and started testing. Works fine at 100T, need to check at 1000T next. Photo of top side of board nearby. [[Image:OzyII_Alpha_PCB.JPG|thumb|600px|OzyII Alpha PCB]]

===Update: 15 July 2010===
The PCB layout has been completed by Kevin, M0KHZ. Alpha PCBs have been ordered and are due this week, all parts have been ordered and are available. Verilog code has been written to test the PHY at 1000T and it appears to run OK.

===Update: 23 May 2010===
V1.1 of the OzyII schematic is available for peer review. The document is here [[Media:OzyII_v1.1.pdf]], note that if you click on a component a descriptive box opens showing full details of the particular component. Detailed checking of the schematic by others will greatly reduce the potential for errors in the Alpha PCB.
Comments, corrections and suggestions via the openHPSDR reflector please.

===Update: 8 April 2010===
Since OzyII will not incorporate and FX2 uP we will need a way of updating the FPGA code. Initially we can use a Byte Blaster or USB Blaster but eventually we will need a simple way for the user to install updated code via the Ethernet port. Two things need to be completed in order to enable this. Firstly, the ability to write to the EPCS16 configuration EEPROM via FPGA code and secondly the ability to have two sets of code in this chip. The first set of code (Factory code) will be loaded at power on if a particular jumper is installed. This code will look for the new FPGA code to arrive at the Ethernet connector. Without the jumper installed, at power on, the FPGA will load the alternative code (called the Application code) which will be the latest OzyII code.

Thanks to some work last year by Michael Wyrick, N3UC, I've been able to write some test code that allows me to read and write to any address in the EPCS16 and also select which of two sets of code to load at power on.

===Update: 15 March 2010===
MDIO interface to the PHY is now working; can set up its transmit and receive registers. I2C Master implemented in the FPGA for setting up Penelope and general I/O.

===Update: 5 March 2010===
Have implmented the discovery code in the FPGA and it's working fine. Also connected the 25AA02EA8 to the FPGA and the board now reads its MAC address from the EEPROM at start-up.

===Update: 2 March 2010===
DHCP is now implemented and working so a soft core uP is not immediately requred. The block diagram for the Alpha OyzII PCB has been updated and the PCB layout commenced. It has been decided not to include an FX2 USB interface since the Ethernet PHY provides all the connectivity to the PC necessary.
Have completed PC code that sends a broadcast message over the users network looking for an OzyII card. If an OzyII board detects this message it will reply with its IP and MAC addresses. The Verilog code has been simulated in C# and is working against the PC broadcast code.

===Update: 11 February 2010===
Have now implemented ARP and PING in OyzII so most of the IP Discovery code is now working. My PC will send an ARP request when KISS Konsole first starts to determine the MAC address of OzyII.

Now looking at implementing a soft core uP as an alternative to doing the Discovery code in Verilog.

===Update: 31 January 2010===
Now have OzyII sending and receiving UDP/IP frames. Have also implemented UDP/IP in [[KISS Konsole]]. Still have to add all the IP Discovery code but the concept basically works! Many thanks to Bill, KD5TFD, for dragging me up the Ethernet learning curve :)

Screen shot of KISS Konsole tuned to a Broadcast station below.[[Image:KK_UDP.JPG|thumb|600px|KISS Konsole and OzyII using UDP/IP. 31 January 2010]]

===Update: 29 January 2010===
I now have OzyII sending UDP/IP frames to my PC. Using C# .NET Sockets to receiver the data is very straightforward. Next step is to add UDP/IP support to [[KISS Konsole]].

===Update: 14 January 2010===
I've completed modifying K.I.S.S. Konsole to work with Ethernet data rather than USB by replacing libUSB with SharpPcap.
I've also added Ethernet support to Kirk's Ozy code. OzyII now sits on the Atlas bus, works with Mercury and Penny etc and talks to K.I.S.S Konsole.

There is an issue when using the Micrel KSZ9021RL evaluation board in full duplex but I think this is crosstalk due to the long leads from the chip to the edge of the board.

A prototype PCB is presently being layed out.

===Update: 27 October 2009===
I now have the receive code working in the FPGA and have been able to couple it to Kirk's v 1.7 Ozy code. That enables me to produce audio from the Mercury card using some PC software written by Bill, KD5TFD, that emulates data from PowerSDR or KK over Ethernet. Next step is to add the Ethernet transmit code to Ozy so we can send I&Q data from Mercury to the PC. By replacing the USB interface in PowerSDR or KK we will be able to test the entire system.

Lyle, KK7P, commenced drawing the schematic for OzyII.

===Update: 27 September 2009===
I now have the CRC32 generator working in the Ozy FPGA. The board can now generate Layer II Ethernet frames without being connected to a PC. This should be the last major building block necessary to complete the board design.

===Update: 26 September 2009.===
I'm making good progress with the development of a Gigabit interface to the Atlas bus i.e. OzyII (Aussie2).

The choice of a Micrel KSZ9021RL PHY chip looks like paying off. The chip uses the RGMII interface standard which means it only requires 12 pins in
order to connect to the associated FPGA. Given the low pin count 'we' (i.e. Lyle KK7P) should be able to support both the PHY and an FX2 chip on the
PCB. It's also only needs a single supply, is small, low power and low cost.

We can use the FX2 as a conventional USB interface, just like Ozy/Majster, to program the FPGAs associated Flash memory by making it emulate an Altera
USB Blaster and also perhaps hand off some of the Ethernet protocol processing to it (later on).[[Image:Micrel_evelauation_board.JPG|thumb|600px|Micrel KSZ9021RL Evaluation Board. 26 September 2009]] Micrel provide a very nice evaluation board for the KSZ9021RL (see nearby photo).

This has an Eternet connector, access to the RGMII pins and a USB interface. TheUSB interface provides access to read/write all the internal
registers of the PHY. There is also a very nice GUI on the PC that they also provide so you can play with all the register settings.

I've been able to interface the evaluation board to an Ozy board (see nearby photo)
so that I can write FPGA code to test the PHY in ernest.

[[Image:Test.JPG|thumb|600px|Micrel evaluation board piggy-backed onto an Ozy board. 26 September 2009]]

By using the USB port on Ozy I can format any Ethernet frame I like on the PC, send it to Ozy and then onwards to the PHY and my lab Ethernet switch.
Similarly, any Ethernet frames the PHY receives are by sent to the FPGA and thence via Ozy's USB port back to the PC.

Thanks to Bill, KD5TFD, for this suggestion - it has certainly speeded up development.

We intend to include an FX2 on the final OzyII board to enable it to be used as an Ozy board, enable the FPGA and/or its Flash memeory to be programed via a pseudo Altera USB Blaster and perhaps provide UDP or TCP support.

I've written a simple C# program on the PC that allows me to format an Ethernet frame, or send a canned one, to the PHY. The PC sends the entire
frame, including calculating the CRC32. I can also display any received Ethernet frames on the PC. Again, there is a screen shot of the PC software
nearby.
[[Image:Success.JPG|thumb|300px|PC code to send & receive Ethernet frames from OzyII. 26 September 2009]]

Being able to generate any type of Ethernet Fame on the PC is so much faster and easier than doing the code in the FPGA. Once I have the basic code
working in C# then I can port it to Verilog.

So far this all seems to work just fine. If I use the MAC address of the Ethernet Card in my PC as the 'To MAC address' then my Ethernet Switch
correctly forwards the frames to the PC. Similarly the switch learns the MAC address I have use as the 'From MAC address' and returns frames just to
the PHY board.

This will be a useful developement platform as we move to more advanced protocols in the future.

The next step is to get the FPGA code to generate the Ethernet preamble plus MAC addresses, get the data Payload from the PC via USB, and calculate
and append the CRC32.

I have this code working in simulation but have yet to try it in the actual Ozy + PHY hardware. (Now working in the FPGA - see update above).

Once that is working I can grab Mercury I & Q data off the Atlas bus and
send that to the PC via Ethernet. Similary, the demodulated audio and I & Q
data can be returned via Ethernet. We will need a modified version of
PowerSDR/KK to test this and Bill KD5TFD is already working on ways to do
this.

In order to use this initial software it will be necessary to program the
MAC address of the PC you intend to use with OzyII into the board. We will
provide a Flash memory chip on the PCB that will be programmed with the
boards MAC address during manfacture.

With the FPGA <> PHY hardware interface working we can start designing the
schematic for OzyII and Lyle KK7P will commence that after his holidays.

By using a large FPGA it offers the potential to add a soft core microprocessor in the future so that the board can run a full TCP/IP stack, UDP etc. e.g. uIP http://www.sics.se/~adam/uip/index.php/Main_Page

Initially we will use the Gigabit PHY as just a fast connection to the PC and use raw frames to communicate.

Feedback and comments are requested via the HPSDR reflector.

Ethernet Notes:

In general, an Ethernet subsystem is divided into two parts: the media access controller (MAC) and the physical device (PHY or line interface). Generally, the MAC handles generating and parsing physical frames and the PHY handles how this data is actually moved to or from the wire. The PHY is just a means of transmitting raw bits rather than logical data packets over a physical link that are connecting network nodes.

===Useful info:===
http://www.wireshark.org/

http://www.techonline.com/article/pdf/showPDFinIE.jhtml?id=2088017281

http://www.cs.rice.edu/CS/Architecture/docs/shafer-tree0611.pdf

Altera White paper on Ethernet using Cyclone III and NIOS soft core

http://cm.altera.com/g/?QYKFH2NRLY:SU6QAW3Y1V=ssID:480603690

[[Category:Hardware nearing completion]]

METIS

2010-10-20T02:09:55Z

WikiSysop: Reverted edits by VK2NRA (Talk) to last version by VK6APH

Antenna Performance Tests

2010-04-05T04:53:19Z

WikiSysop:

=== [[Instruments required]] ===

=== Tests ===
==== Sensitivity ====

by Rick VE3MM

Antenna Performance Tests

2010-04-05T04:52:25Z

WikiSysop:

=== [[Instruments required]] ===

=== Tests ===
==== Sensitivity ====

[[[Active Antenna and HPSDR]]]

[[Antenna Performance Testing]]

by Rick VE3MM

Antenna Performance Tests

2010-04-05T04:50:36Z

WikiSysop:

[[[Active Antenna and HPSDR]]]

[[Antenna Performance Testing]]

by Rick VE3MM

Antenna Performance Tests

2010-04-05T04:50:21Z

WikiSysop:

[[[Active Antenna and HPSDR]]]

[[Antnna Performance Testing]]

by Rick VE3MM

Antenna Performance Tests

2010-04-05T04:49:58Z

WikiSysop: New page: [Active Antenna and HPSDR] Anetnna Performance Testing by Rick VE3MM

[[[Active Antenna and HPSDR]]]

[[Anetnna Performance Testing]]

by Rick VE3MM

HPSDRwiki:Community Portal

2010-04-05T04:48:12Z

WikiSysop: /* Receiver Performance Tests */

== [[FAQ]] - Frequently Asked Questions ==

This is a new section started to allow asking and hopefully answering questions about HPSDR.

== [[DOC]] - Documentation ==

This section contains links for downloading all documentation for HPSDR Projects.

== Software ==

===[[DOWNLOADS]] - Firmware and Software ===

Links to current firmware and software available.

===[[SVN]] Subversion code versioning software ===
Source code in the process of development

=== [[HPSDR_related_software|Software links and introduction to software components.]] ===

Links to HPSDR software and resources can be found on the [http://openhpsdr.org/resources.html Resource] page.

Links to the FPGA programming course by Kirk, KD7IRS -- see the [[Verilog]] page.

=== Microsoft Windows XP, Vista, and Windows 7 Software ===

[http://www.g3ukb.co.uk/ Acorn-SDR] by Bob Cowdery

[http://www.dxatlas.com/CwSkimmer/ CW Skimmer] From Alex, VE3NEA, has support for Mercury

[[KISS Konsole]], Written in C# and intended as a simple introduction to PC DSP programming.

[https://java-sdr.dev.java.net/ java-sdr] Platform independent Java by John G0ORX/N6LYT.

[[PowerSDR]] Running on Microsoft Windows XP.

[[WinUSB Notes]] by George, K9TRV

====PowerSDR [[Quick Startup Guide]]====

Documents to help users get HPSDR setup and working. Includes firmware upload instructions.

====[[HPSDR Digital Modes Operation using PowerSDR, Fldigi, VAC and com0com]]====

How to use additional programs to enable the digital modes using PowerSDR

====[[PowerSDR Keyboard Shortcut List ]]====

This page lists all the known PowerSDR keyboard shortcuts.

=== Linux Software ===

[[ghpsdr]], written in C with a [http://www.gtk.org/ GTK+] GUI by John G0ORX/N6LYT. http://javaguifordttsp.blogspot.com/

[[ghpsdr3]], written in C with as a server/client or server/dspserver/client framework by John G0ORX/N6LYT. http://g0orx.blogspot.com/

[https://java-sdr.dev.java.net/ java-sdr] Platform independent Java by John G0ORX/N6LYT.

====Linux [[SYSTEM INTEGRATION]]====

This section contains information relative to "putting the pieces together".

=== Mac OS-X Software ===

[[ghpsdr]], written in C with a [http://www.gtk.org/ GTK+] GUI by John G0ORX/N6LYT. http://javaguifordttsp.blogspot.com/

[[Mac-Ghpsdr]] is a version of ghpsdr v2 with changes to make it run acceptably on the Mac by Jeremy McDermond ([[User:NH6Z|NH6Z]]).

[[MacHPSDR]] is a native Cocoa implementation of an HPSDR receiver. It uses currently John Melton's modified DttSP from ghpsdr to do the DSP work, but replaces out everything else with native Objective-C and Cocoa technologies. The current author and maintainer of the code is Jeremy McDermond ([[User:NH6Z|NH6Z]]).

[https://java-sdr.dev.java.net/ java-sdr] Platform independent Java by John G0ORX/N6LYT.

=== Individual software Project Wiki Pages ===

* '''[[ATHENA]] - A software Server module''' - A project to build OS specific server code, module communication libraries and communication protocol documentation.

* '''[[KISS Konsole]] - Learning SDR Console''' - The KISS Konsole is a software project to provide a straightforward, well-commented User Interface to [[Mercury]] and other modules.

== Building HPSDR Rigs ==

===[[Hardware Introduction]]===

This is a guide for those new to HPSDR about exactly what hardware you need to be able to use the system.

=== [http://openhpsdr.org/support.html Support documentation] ===

Documents for user interested in building boards can be found on the [http://openhpsdr.org/support.html Support] page.

===[[A complete HPSDR transceiver]]===

This page provides an example of how to build your own transceiver using HPSDR components and other available hardware and software.

===[[The Antec P183 Solution]]===

This page documents an example of how to build your own transceiver using HPSDR components and other available hardware and software in a traditional a mid-tower PC enclosure.

===[[The Tokyo Hy-Power HL-45B Solution]]===

This page documents an example of how to add a commercial solid state 45 Watt Amplifier to your HPSDR rig.

===[[The Rino R-1 Solution]]===

A smaller PC case solution with an optical drive included.

===[[The Antec Minuet Solution]]===

The smallest PC case solution attempted so far.

===[[Never Short a Penelope by AD9DP]]===

The short paper tells you why you should never operate Penelope into a shorted load.

===[[Using Penelope with a linear amplifier]]===

When using Penelope with a linear amplifier you need to ensure you use enough drive. This paper explains why.

== HPSDR Performance Tests ==

The purpose of these pages are to establish HPSDR performance measurement process standards.

=== Receiver Performance Tests ===
* Mercury: [[Receiver Performance Tests]]
* Active Antennas and HPSDR: [[Antenna Performance Tests]]

=== Transmitter Performance Tests ===

== Individual hardware Project Wiki Pages ==

Click on the NAME of the project to get to its page!

=== Completed ===

==== Common ====

* '''[[ATLAS]] - Backplane''' - The Atlas is a passive backplane that all other modules plug into.

* '''[[LPU]] - Simple Linear Power Unit''' - The LPU unit takes power from a regulated power supply and steps it to the input needed by Atlas.

* '''[[MAGISTER]] - USB 2.0 to Atlas Bus Interface''' - The Magister module is an alternative to OZY.

==== Primarily Mercury and Penelope related ====

* '''[[Antenna Switch|ANTENNA SWITCH]] - by NT-Electronics''' - An antenna switch for use with Penelope and Mercury when Alex is not used, also has optional low Noise RX Amplifier for 6 meters

* '''[[MERCURY]] - 0-55 MHz Direct Sampling Receiver''' - Perhaps the most exciting of all modules, Mercury will enable direct sampling of the 0-55 MHz spectrum.

* '''[[PENELOPE]] - Companion Exciter to Mercury''' - A 1/2 watt DUC(k).

==== Primarily Phoenix and Janus related ====

* '''[[JANUS]] - ADC/DAC Board''' - The Janus module is a very high performance, dual, full duplex, A/D and D/A converter board.

==== Optional ====

* '''[[PANDORA]] - Enclosure''' - HPSDR enclosure.

* '''[[EXCALIBUR]] - Clock Reference board''' - A board to allow an external 10 MHz frequency reference interface.

* '''[[PINOCCHIO]] - Extender Card''' - Pinocchio is an extender card to allow measurements and troubleshooting of an active card in an ATLAS back-plane.

* '''[[HERCULES]] - By NT-Electronics''' - A 100 Watt amplifier designed to be compatible with current HPSDR hardware (Atlas, Penelope, Mercury, and Magister/Ozy).

* '''[[PENNYWHISTLE]] - 20 Watt RF Power Ampilfier''' - The PennyWhistle takes the RF output of Penelope and amplifies it to approximately 20 watts.

===Completed but unavailable===

* '''[[OZY]] - HPSDR Host Interface & Control''' - The OZY module is an FPGA based interface controller card providing input and output connections to the real world. Now replaced with the Magister module - see above.

===Future hardware===
====Hardware nearing completion====

* '''[[ALEXIARES]] - RF Preselector''' - Alexiares (or Alex for short) is a set of RF Bandpass filters for use with Mercury and Penelope or any other SDR. Alex also contain an RX/TX antenna switch.

* '''[[HERMES]] - A DUC/DDC Transceiver''' - Merging the verilog code of Mercury and Penelope into a single FPGA, on a single board.

* '''[[APOLLO]] - 15W PA and Filter''' - A companion 15W PA and Low Pass Filter for [[HERMES|Hermes]].

* '''[[OZYII]] - (AussieII) - A high speed PC interface''' - High speed PC interface using Ethernet PHY.

* '''[[PHOENIX]] - QSD/QSE Receiver/Transmitter Module''' - QSD based HF Receiver, a QSE based HF Exciter and a supporting synthesizer.

====Proposed hardware====

* '''[[CYCLOPS]] - Spectrum Analyzer''' - Cyclops is a 0-1 GHz spectrum analyzer with tracking generator support.

* '''[[DEMETER]] - Power Supply''' - Power supply designed for HPSDR.

* '''[[GIBRALTAR]] - GPS-disciplined Frequency Standard''' - Gibraltar is a GPS-disciplined frequency standard board.

* '''[[ODYSSEY]] - Low Power Handheld SDR''' - Odyssey includes a low power SDR based on the QSD, QSE, and a dsPIC33 as the basic radio core.

* '''[[THOR]] - High Efficiency HF Power Amplifier''' - Thor is a high efficiency HF power amplifier using Envelope Elimination and Restoration (ERR) techniques.

* '''[[MUNIN]] - 100W HF Power Amplifier''' - Munin is a 100W HF power amplifier, This hardware is dependent on Alex filters.

====Other proposed/future hardware====

* '''[[ANICETUS]] (Anie) - Preselector''' - A few designs for narrow band preselectors.

* '''[[EPIMETHEUS]] - General Purpose I/O''' - Epi is a general purpose I/O board for the Atlas bus and includes relays, open collectors, IF switching, etc.

* '''[[HELIOS]] - Helios Small Transmitting Loop Antenna and Controller.

* '''[[HORTON]] - Receiver Module''' - A receiver module integrating the Janus ADC with a QSD on a board for a version of the HPSDR RX board.

* '''[[PROTEUS]] - Prototyping Board''' - This is the planned prototyping board.

* '''[[SASQUATCH]] - DSP back-end''' - The Sasquatch board is a hardware DSP back-end intended for use by constructors who would like to operate stand-alone rather than attached to a PC.

== [[Board Designer's Resources]] ==

== [[ANCILLARY]] - Additional "stuff" of interest to HPSDR ==
Some stuff like Norton Amplifier, FPGA VHDL/Verilog ...

== [[EXPERIMENTERS-CORNER]] - Ideas not yet projects ==

== [[ADMINISTRATION-NEWS]] - Messages about HPSDR web, wiki, discussion list ==
__NOTOC__

[[Category:Community| ]]
[[Category:Hardware| ]]
[[Category:Categories]]
[[Category:Developer resources| ]]

WinUSB Notes

2009-12-20T21:00:05Z

WikiSysop: /* WinUSB Notes */

== WinUSB Notes ==

This page contains information on using WinUSB with HPSDR hardware.

WinUSB Notes

2009-12-20T20:59:05Z

WikiSysop: New page: == WinUSB Notes ==

== WinUSB Notes ==

HPSDRwiki:Community Portal

2009-12-20T20:58:25Z

WikiSysop: /* Microsoft Windows XP, Vista, and Windows 7 Software */

== [[FAQ]] - Frequently Asked Questions ==

This is a new section started to allow asking and hopefully answering questions about HPSDR.

== [[DOC]] - Documentation ==

This section contains links for downloading all documentation for HPSDR Projects.

== Software ==

===[[DOWNLOADS]] - Firmware and Software ===

Links to current firmware and software available.

===[[SVN]] Subversion code versioning software ===
Source code in the process of development

=== [[HPSDR_related_software|Software links and introduction to software components.]] ===

Links to HPSDR software and resources can be found on the [http://openhpsdr.org/resources.html Resource] page.

Links to the FPGA programming course by Kirk, KD7IRS -- see the [[Verilog]] page.

=== Microsoft Windows XP, Vista, and Windows 7 Software ===

[[PowerSDR]] Running on Microsoft Windows XP.

[http://www.g3ukb.co.uk/ Acorn-SDR] by Bob Cowdery

[http://www.dxatlas.com/CwSkimmer/ CW Skimmer] From Alex, VE3NEA, has support for Mercury

[[KISS Konsole]], Written in C# and intended as a simple introduction to PC DSP programming.

[https://java-sdr.dev.java.net/ java-sdr] Platform independent Java by John G0ORX/N6LYT.

[[WinUSB Notes]] by George, K9TRV

====PowerSDR [[Quick Startup Guide]]====

Documents to help users get HPSDR setup and working. Includes firmware upload instructions.

====[[ PowerSDR Keyboard Shortcut List ]]====

This page lists all the known PowerSDR keyboard shortcuts.

=== Linux Software ===

[[ghpsdr]], written in C with a [http://www.gtk.org/ GTK+] GUI by John G0ORX/N6LYT. http://javaguifordttsp.blogspot.com/

[https://java-sdr.dev.java.net/ java-sdr] Platform independent Java by John G0ORX/N6LYT.

====Linux [[SYSTEM INTEGRATION]]====

This section contains information relative to "putting the pieces together".

=== Mac OS-X Software ===

[[ghpsdr]], written in C with a [http://www.gtk.org/ GTK+] GUI by John G0ORX/N6LYT. http://javaguifordttsp.blogspot.com/

[https://java-sdr.dev.java.net/ java-sdr] Platform independent Java by John G0ORX/N6LYT.

== Building HPSDR Rigs ==

===[[Hardware Introduction]]===

This is a guide for those new to HPSDR about exactly what hardware you need to be able to use the system.

=== [http://openhpsdr.org/support.html Support documentation] ===

Documents for user interested in building boards can be found on the [http://openhpsdr.org/support.html Support] page.

===[[A complete HPSDR transceiver]]===

This page provides an example of how to build your own transceiver using HPSDR components and other available hardware and software.

===[[The Antec P183 Solution]]===

This page documents an example of how to build your own transceiver using HPSDR components and other available hardware and software in a traditional a mid-tower PC enclosure.

===[[The Tokyo Hy-Power HL-45B Solution]]===

This page documents an example of how to add a commercial solid state 45 Watt Amplifier to your HPSDR rig.

===[[The Rino R-1 Solution]]===

A smaller PC case solution with an optical drive included.

===[[The Antec Minuet Solution]]===

The smallest PC case solution attempted so far.

===[[Never Short a Penelope by AD9DP]]===

The short paper tells you why you should never operate Penelope into a shorted load.

== HPSDR Performance Tests ==

The purpose of these pages are to establish HPSDR performance measurement process standards.

=== [[Receiver Performance Tests]] ===

=== Transmitter Performance Tests ===

== Individual Project Wiki Pages ==

Click on the NAME of the project to get to its page!

=== [[ALEXIARES]] - RF Preselector ===

Alexiares (or Alex for short) is a set of RF Bandpass filters for use with Mercury or any other SDR.

=== [[ANICETUS]] (Anie) - Preselector ===

A few designs for narrow band preselectors

===[[Antenna Switch|ANTENNA SWITCH]] - by NT-Electronics ===

An antenna switch for use with Penelope and Mercury when Alex is not used, also has optional low Noise RX Amplifier for 6 meters

=== [[APOLLO]] - 15W PA and Filter===
A companion 15W PA and Low Pass Filter for [[HERMES|Hermes]]

=== [[ATHENA]] - A software Server module ===
A project to build OS specific server code, module communication libraries and communication protocol documentation.

=== [[ATLAS]] - Backplane ===

The Atlas is a passive backplane that all other modules plug into.

=== [[CYCLOPS]] - Spectrum Analyzer ===

Cyclops is a 0-1 GHz spectrum analyzer with tracking generator support.

=== [[DEMETER]] - Power Supply ===
Power supply designed for HPSDR.

=== [[EPIMETHEUS]] - General Purpose I/O ===

Epi is a general purpose I/O board for the Atlas bus and includes relays, open collectors, IF switching, etc.

=== [[EXCALIBUR]] - Clock Reference board ===
A board to allow an external 10 MHz frequency reference interface.

=== [[GIBRALTAR]] - GPS-disciplined Frequency Standard ===

Gibraltar is a GPS-disciplined frequency standard board.

=== [[HELIOS]] - Helios Small Transmitting Loop Antenna and Controller ===

=== [[HERMES]] - A DUC/DDC Transceiver. ===
Merging the verilog code of Mercury and Penelope into a single FPGA, on a single board.

=== [[HORTON]] - Receiver Module ===

A receiver module integrating the Janus ADC with a QSD on a board for a version of the HPSDR RX board.

=== [[JANUS]] - ADC/DAC Board ===

The Janus module is a very high performance, dual, full duplex, A/D and D/A converter board.

=== [[KISS Konsole]] - Learning SDR Console ===

The KISS Konsole is a software project to provide a straightforward, well-commented User Interface to Mercury and other modules.

=== [[LPU]] - Simple Linear Power Unit ===

The LPU unit takes power from a regulated power supply and steps it to the input needed by Atlas.

=== [[MAGISTER]] - USB 2.0 to Atlas Bus Interface ===

The Magister module is an alternative to OZY.

=== [[MERCURY]] - 0-55 MHz Direct Sampling Receiver ===
Perhaps the most exciting of all modules, Mercury will enable direct sampling of the 0-55 MHz spectrum.

=== [[ODYSSEY]] - Low Power Handheld SDR ===

Odyssey includes a low power SDR based on the QSD, QSE, and a dsPIC33 as the basic radio core.

=== [[OZY]] - HPSDR Host Interface & Control ===

The OZY module is an FPGA based interface controller card providing input and output connections to the real world.

=== [[OZYII]] - (AussieII) - A high speed PC interface. ===
High speed PC interface using Ethernet PHY.

=== [[PANDORA]] - Enclosure ===
HPSDR enclosure

=== [[PENELOPE]] - Companion Exciter to Mercury ===

A 1/2 watt DUC(k).

=== [[PENNYWHISTLE]] - 20 Watt RF Power Ampilfier ===

The PennyWhistle takes the RF output of Penelope and amplifies it to approximately 20 watts.

=== [[PHOENIX]] - QSD/QSE Receiver/Transmitter Module ===

QSD based HF Receiver, a QSE based HF Exciter and a supporting synthesizer.

=== [[PINOCCHIO]] - Extender Card ===

Pinocchio is an extender card to allow measurements and troubleshooting of an active card in an ATLAS back-plane.

=== [[PROTEUS]] - Prototyping Board ===

This is the planned prototyping board.

=== [[SASQUATCH]] - DSP back-end ===

The Sasquatch board is a hardware DSP back-end intended for use by constructors who would like to operate
stand-alone rather than attached to a PC.

=== [[THOR]] - High Efficiency HF Power Amplifier ===

Thor is a high efficiency HF power amplifier using Envelope Elimination and Restoration (ERR) techniques.

== [[Board Designer's Resources]] ==

== [[ANCILLARY]] - Additional "stuff" of interest to HPSDR ==
Some stuff like Norton Amplifier, FPGA VHDL/Verilog ...

== [[EXPERIMENTERS-CORNER]] - Ideas not yet projects ==

== [[ADMINISTRATION-NEWS]] - Messages about HPSDR web, wiki, discussion list ==
__NOTOC__

MAGISTER

2009-09-17T23:28:07Z

WikiSysop:

''' Magister'''

The project leader for the Magister board is Lyle Johnson, KK7P

MAGISTER

2009-09-17T23:27:51Z

WikiSysop:

''' Magister'''

The project leader for the Magister board were Lyle Johnson, KK7P

MAGISTER

2009-09-17T23:27:26Z

WikiSysop:

''' Magister'''

The project leaders for the Mercury board were Lyle Johnson, KK7P

MAGISTER

2009-09-17T23:25:47Z

WikiSysop: New page: ''' Magister'''

''' Magister'''

HPSDRwiki:Community Portal

2009-09-17T23:24:53Z

WikiSysop: /* Magister - */

== [[FAQ]] - Frequently Asked Questions ==

This is a new section started to allow asking and hopefully answering questions about HPSDR.

== [[DOC]] - Documentation ==

Summary of current documentation available.

=== [[Quick Startup Guide]] ===

Documents to help users get HPSDR setup and working. Includes firmware upload instructions.

=== [http://openhpsdr.org/support.html Support documentation] ===

Documents for user interested in building boards can be found on the [http://openhpsdr.org/support.html Support] page.

=== [[HPSDR_related_software|Software links]] ===

Links to HPSDR software and resources can be found on the [http://openhpsdr.org/resources.html Resource] page.

Links to the FPGA programming course by Kirk, KD7IRS -- see the [[Verilog]] page.

== [[DOWNLOADS]] - Firmware and Software ==

Links to current firmware and software available.

== [[SYSTEM INTEGRATION]] ==

This section contains information relative to "putting the pieces together".

== [[A complete HPSDR transceiver]] ==

This page provides an example of how to build your own transceiver using HPSDR components and other available hardware and software. It concludes with test measurements that compare the finished transceiver to other commercially available high end transceivers.

== [[The Antec P183 Solution]] ==

This page documents an example of how to build your own transceiver using HPSDR components and other available hardware and software in a traditional a mid-tower PC enclosure. This example system can accommodate all sizes of PC motherboards up to the standard ATX. The system design will also accommodate larger PC power supplies to power RF amplifiers in the 200 - 500 watt range. The large enclosure is configured to provide a HPSDR with maximum performance.

== [[ PowerSDR Keyboard Shortcut List ]] ==

This page lists all the known PowerSDR keyboard shortcuts.

== Individual Project Wiki Pages ==

Click on the NAME of the project to get to its page!

=== [[ALEXIARES]] - RF Preselector ===

Alexiares (or Alex for short) is a set of RF Bandpass filters for use with Mercury or any other SDR.

=== [[ANICETUS]] (Anie) - Preselector ===

A few designs for narrow band preselectors

===[[Antenna Switch|ANTENNA SWITCH]] - by NT-Electronics ===

An antenna switch for use with Penelope and Mercury when Alex is not used, also has optional low Noise RX Amplifier for 6 meters

=== [[ATLAS]] - Backplane ===

The Atlas is a passive backplane that all other modules plug into.

=== [[CYCLOPS]] - Spectrum Analyzer ===

Cyclops is a 0-1 GHz spectrum analyzer with tracking generator support.

=== [[DEMETER]] - Power Supply ===

=== [[EPIMETHEUS]] - General Purpose I/O ===

Epi is a general purpose I/O board for the Atlas bus and includes relays, open collectors, IF switching, etc.

=== [[EXCALIBUR]] - Clock Reference board ===

=== [[GIBRALTAR]] - GPS-disciplined Frequency Standard ===

Gibraltar is a GPS-disciplined frequency standard board.

=== [[HELIOS]] - Helios Small Transmitting Loop Antenna and Controller ===

=== [[HERMES]] - A DUC/DDC Transceiver. ===

=== [[HORTON]] - Receiver Module ===

A receiver module integrating the Janus ADC with a QSD on a board for a version of the HPSDR RX board.

=== [[JANUS]] - ADC/DAC Board ===

The Janus module is a very high performance, dual, full duplex, A/D and D/A converter board.

=== [[KISS Konsole]] - Learning SDR Console ===

The KISS Konsole is a software project to provide a straightforward, well-commented User Interface to Mercury and other modules.

=== [[LPU]] - Simple Linear Power Unit ===

The LPU unit takes power from a regulated power supply and steps it to the input needed by Atlas

=== [[MAGISTER]] - ===

=== [[MERCURY]] - 0-55 MHz Direct Sampling Receiver ===
Perhaps the most exciting of all modules, Mercury will enable direct sampling of the 0-55 MHz spectrum.

=== [[ODYSSEY]] - Low Power Handheld SDR ===

Odyssey includes a low power SDR based on the QSD, QSE, and a dsPIC33 as the basic radio core.

=== [[OZY]] - HPSDR Host Interface & Control ===

The OZY module is an FPGA based interface controller card providing input and output connections to the real world.

=== [[OZYII]] - (AussieII) - A high speed PC interface. ===

=== [[PANDORA]] - Enclosure ===

=== [[PENELOPE]] - Companion Exciter to Mercury ===

A 1/2 watt DUC(k).

=== [[PENNYWHISTLE]] - 20 Watt RF Power Ampilfier ===

The PennyWhistle takes the RF out put of Penelope and ampilifes it to approximately 20 watts.

=== [[PHOENIX]] - QSD/QSE Receiver/Transmitter Module ===

QSD based HF Receiver, a QSE based HF Exciter and a supporting synthesizer.

=== [[PINOCCHIO]] - Extender Card ===

Pinocchio is an extender card to allow measurements and troubleshooting of an active card in an ATLAS backplane.

=== [[PROTEUS]] - Prototyping Board ===

This is the planned prototyping board.

=== [[SASQUATCH]] - DSP back-end ===

The Sasquatch board is a hardware DSP back-end intended for use by constructors who would like to operate
stand-alone rather than attached to a PC.

=== [[THOR]] - High Efficiency HF Power Amplifier ===

Thor is a high efficiency HF power amplifier using Envelope Elimination and Restoration (ERR) techniques.

== [[Board Designer's Resources]] ==

== [[ANCILLARY]] - Additional "stuff" of interest to HPSDR ==
Some stuff like Norton Amplifier, FPGA VHDL/Verilog ...

== [[EXPERIMENTERS-CORNER]] - Ideas not yet projects ==

== [[ADMINISTRATION-NEWS]] - Messages about HPSDR web, wiki, discussion list ==
__NOTOC__

HPSDRwiki:Community Portal

2009-09-17T23:23:13Z

WikiSysop:

== [[FAQ]] - Frequently Asked Questions ==

This is a new section started to allow asking and hopefully answering questions about HPSDR.

== [[DOC]] - Documentation ==

Summary of current documentation available.

=== [[Quick Startup Guide]] ===

Documents to help users get HPSDR setup and working. Includes firmware upload instructions.

=== [http://openhpsdr.org/support.html Support documentation] ===

Documents for user interested in building boards can be found on the [http://openhpsdr.org/support.html Support] page.

=== [[HPSDR_related_software|Software links]] ===

Links to HPSDR software and resources can be found on the [http://openhpsdr.org/resources.html Resource] page.

Links to the FPGA programming course by Kirk, KD7IRS -- see the [[Verilog]] page.

== [[DOWNLOADS]] - Firmware and Software ==

Links to current firmware and software available.

== [[SYSTEM INTEGRATION]] ==

This section contains information relative to "putting the pieces together".

== [[A complete HPSDR transceiver]] ==

This page provides an example of how to build your own transceiver using HPSDR components and other available hardware and software. It concludes with test measurements that compare the finished transceiver to other commercially available high end transceivers.

== [[The Antec P183 Solution]] ==

This page documents an example of how to build your own transceiver using HPSDR components and other available hardware and software in a traditional a mid-tower PC enclosure. This example system can accommodate all sizes of PC motherboards up to the standard ATX. The system design will also accommodate larger PC power supplies to power RF amplifiers in the 200 - 500 watt range. The large enclosure is configured to provide a HPSDR with maximum performance.

== [[ PowerSDR Keyboard Shortcut List ]] ==

This page lists all the known PowerSDR keyboard shortcuts.

== Individual Project Wiki Pages ==

Click on the NAME of the project to get to its page!

=== [[ALEXIARES]] - RF Preselector ===

Alexiares (or Alex for short) is a set of RF Bandpass filters for use with Mercury or any other SDR.

=== [[ANICETUS]] (Anie) - Preselector ===

A few designs for narrow band preselectors

===[[Antenna Switch|ANTENNA SWITCH]] - by NT-Electronics ===

An antenna switch for use with Penelope and Mercury when Alex is not used, also has optional low Noise RX Amplifier for 6 meters

=== [[ATLAS]] - Backplane ===

The Atlas is a passive backplane that all other modules plug into.

=== [[CYCLOPS]] - Spectrum Analyzer ===

Cyclops is a 0-1 GHz spectrum analyzer with tracking generator support.

=== [[DEMETER]] - Power Supply ===

=== [[EPIMETHEUS]] - General Purpose I/O ===

Epi is a general purpose I/O board for the Atlas bus and includes relays, open collectors, IF switching, etc.

=== [[EXCALIBUR]] - Clock Reference board ===

=== [[GIBRALTAR]] - GPS-disciplined Frequency Standard ===

Gibraltar is a GPS-disciplined frequency standard board.

=== [[HELIOS]] - Helios Small Transmitting Loop Antenna and Controller ===

=== [[HERMES]] - A DUC/DDC Transceiver. ===

=== [[HORTON]] - Receiver Module ===

A receiver module integrating the Janus ADC with a QSD on a board for a version of the HPSDR RX board.

=== [[JANUS]] - ADC/DAC Board ===

The Janus module is a very high performance, dual, full duplex, A/D and D/A converter board.

=== [[KISS Konsole]] - Learning SDR Console ===

The KISS Konsole is a software project to provide a straightforward, well-commented User Interface to Mercury and other modules.

=== [[LPU]] - Simple Linear Power Unit ===

The LPU unit takes power from a regulated power supply and steps it to the input needed by Atlas

=== [[Magister]] - ===

=== [[MERCURY]] - 0-55 MHz Direct Sampling Receiver ===
Perhaps the most exciting of all modules, Mercury will enable direct sampling of the 0-55 MHz spectrum.

=== [[ODYSSEY]] - Low Power Handheld SDR ===

Odyssey includes a low power SDR based on the QSD, QSE, and a dsPIC33 as the basic radio core.

=== [[OZY]] - HPSDR Host Interface & Control ===

The OZY module is an FPGA based interface controller card providing input and output connections to the real world.

=== [[OZYII]] - (AussieII) - A high speed PC interface. ===

=== [[PANDORA]] - Enclosure ===

=== [[PENELOPE]] - Companion Exciter to Mercury ===

A 1/2 watt DUC(k).

=== [[PENNYWHISTLE]] - 20 Watt RF Power Ampilfier ===

The PennyWhistle takes the RF out put of Penelope and ampilifes it to approximately 20 watts.

=== [[PHOENIX]] - QSD/QSE Receiver/Transmitter Module ===

QSD based HF Receiver, a QSE based HF Exciter and a supporting synthesizer.

=== [[PINOCCHIO]] - Extender Card ===

Pinocchio is an extender card to allow measurements and troubleshooting of an active card in an ATLAS backplane.

=== [[PROTEUS]] - Prototyping Board ===

This is the planned prototyping board.

=== [[SASQUATCH]] - DSP back-end ===

The Sasquatch board is a hardware DSP back-end intended for use by constructors who would like to operate
stand-alone rather than attached to a PC.

=== [[THOR]] - High Efficiency HF Power Amplifier ===

Thor is a high efficiency HF power amplifier using Envelope Elimination and Restoration (ERR) techniques.

== [[Board Designer's Resources]] ==

== [[ANCILLARY]] - Additional "stuff" of interest to HPSDR ==
Some stuff like Norton Amplifier, FPGA VHDL/Verilog ...

== [[EXPERIMENTERS-CORNER]] - Ideas not yet projects ==

== [[ADMINISTRATION-NEWS]] - Messages about HPSDR web, wiki, discussion list ==
__NOTOC__

FAQ

2009-05-23T15:25:17Z

WikiSysop: /* The HPSDR Project */

== The HPSDR Project ==

Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''

A. After searching for an answer and not finding it, usually the best way is to post your question on the HPSDR Discussion List (reflector).
This allows two things to happen: (1) it permits someone other than the very busy developers to answer he question if they can, and (2) it allows everyone on the list to gain the benefit of any reply.

----

Q. '''How do I get in direct email contact with project leaders?'''

A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.

----

Q. '''What is the status of the various boards or modules?'''

A. Here's the scoop on some as of May 23, 2009:

ATLAS - in production, order through http://tapr.org
PINOCCHIO - in production, order through http://tapr.org
OZY - 1st production run - Sold out - PCB are available. Order through http://tapr.org
JANUS - 1st production run - currently being shipped. Order through http://tapr.org
MERCURY - 1st production Order through http://tapr.org
MERCURY-EU - alpha - see Gerd, DJ8AY
PENELOPE - 1st production run - Sold Out - PCB are available Order through http://tapr.org, available from Gerd, DJ8AY
LPU - in production - available in kit form. Order through http://tapr.org
ALEX - Pre-production
PENNYWHISTLE - Pre-production
EXCALIBUR - Pre-production
PANDORA - Pre-production

All others - in various stages of design/development -- see their wiki pages or the [http://openhpsdr.org HPSDR] website.

----

Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''

A. It is important to remember the goals of HPSDR. All modules are not meant to be combined together to make a “single flavor” HPSDR transceiver. A number of different combinations will be possible (examples: Horton or Mercury for the receiver). How the modules are used and combined are in the hands of the experimenter/builder. Some users may not even wish to make an entire transceiver out of the modules (example: SDR1000 owners who only want to use Atlas, Ozy, and Janus to replace their sound cards).

In the words of Phil Covington, project leader for a number of the modules, “HPSDR was not formed to be a manufacturer of finished Ham Radio equipment. Its primary purpose is to develop a High Performance SDR in a modular fashion by experimentation with various methods.”

If your only goal is to get “on the air” with an SDR transceiver, there may be cheaper and/or easier routes to achieve this goal (Softrock or Flexradio).

If your goal is high performance software defined radio with a “roll your own” mentality, then the HPSDR modules should enable the creation of your own high performance SDR transceiver.

----

Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''

A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.

----

Q. '''Will Ozy and Janus "bare boards" be available?'''

A. Bare boards (not kits of parts) are available through TAPR.

----

Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''

A. A partial kit of harder to obtain parts is being offered for Janus. Potential users may certainly get together for a group buy on other parts needed to complete the boards. There are several reasons for TAPR (or HPSDR) not offering complete kits: (1) being an all-volunteer organization, it would take tremendous manpower to break the parts down to individual kits and package them, (2) there is a very large support problem for kit builders whose boards do not work when completed, and (3) the cost of a kit of parts would be about equal or may exceed the cost of an assembled and tested board.

----

Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''

A. Yes. They are released under the new TAPR open source hardware license called OHL. The board designer may restrict to non-commercial use. The OHL license was finalized and approved in May 2007. For License information see [http://tapr.org/OHL Open hardware license] or [http://tapr.org/NCL Non-Commercial hardware license]. The Schematics, Gerber files and Bill of Materials (BOM) area available of the [http://openhpsdr.org/support.html Support] webpage.

----

Q. '''Why not put OZY and JANUS on a single board?'''

A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated
circuit on the Janus board allows a future (and hopefully better) chip to be used on a similar board, but keeping Ozy for the interface
and control. Flexibility is the goal.

----

Q. '''How much better will the Ozy-Janus combination be in terms of performance when used with the SDR-1000 in place of a sound card such as the Delta 44?'''

A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.

----

Q. '''Will a Ozy-Janus-Atlas combination work with my PowerSDR software used for my Flex Radio SDR-1000 in place of a sound card in my PC?'''

A. Yes, that was one of the early goals of the HPSDR group. Phil, VK6APH, did confirm with Gerald and Eric at the Flex-Radio meeting at the Dayton Hamvention 2007 that Ozy/Janus will be fully supported in future releases in their 'mainstream' releases of PowerSDR. Bill, KD5TFD, will be working with Eric from Flex to accomplish this. At this point it is not known exactly when, and what version the support will begin, but it will happen. Direct all questions regarding Janus/Ozy to the HPSDR Discussion List (and NOT the Flex-Radio list), as folks have been doing and admirably responding. The arrangement with Flex-Radio required the donation of a working Ozy/Janus to Flex-Radio and this has been accomplished after TAPR approved the expense.

----

Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''

A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH

----

Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''

A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.

----
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''

A. USB 2.0 is a requirement. Currently, the OS recommendation is WinXP. Windows 2000 is NOT recommended as the USB 2.0 stack on Windows 2000 is just too slow.

At this time, there are no solid recommendations for minimum CPU or RAM that are based on actual testing with HPSDR hardware of how low we can go.

FlexRadio does have Minimum Recommended PC Configurations for systems using the PowerSDR software. Since the HPSDR hardware may use PowerSDR, these specs are probably a good guide to what would be advisable for the HPSDR. FlexRadio's numbers from their website are as follows:

Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater

Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)

----

Q. '''What user name and password do I use to access the HPSDR svn repository?'''

A. None is required for reading the SVN, only required to place something in the repository. The IP address of the repository is shown on the resources page of the main HPSDR.org website.

----

Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''

A. There is a group doing SDR for microwave: [http://uwsdr.berlios.de/ ] Current HPSDR projects could certainly be used as an IF for a transverter, but there is nothing going on with HPSDR that is specifically aimed at microwave.

----

== The HPSDR Wiki ==

Q. '''Do I need to log in?'''

A. Those who contribute by editing the wiki need to have a login.
----
Q. '''How do I get a account? (a login)'''

A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]
----
Q. '''What if I find that a correction is needed in the wiki?'''

A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]
----

== ATLAS Backplane ==
Q. '''What is the recommended means of powering ATLAS?'''

A. Demeter. Until Demeter is available...

The ATX 20 pin power connector on the Atlas board enables the use of standard PC power supplies. (Please Note: There is no reason that you cannot utilize a non-PC power supply regulated and wired to provide the proper voltages to the 20pin connector. A non-PC power supply could also enable custom current limiting of the voltages going to the 20 pin connector, an advisable setup when testing or prototyping boards plugged into ATLAS. An analog power supply may be an attractive option for users particularly concerned about spurious emissions in the HF band which some low cost PC power supplies may produce.)

If you choose to use an ATX computer power supply care should be taken that the -12V current requirement is met. (Note of warning: some versions of the attractive picoPSU do not provide proper -12V current capacity. Check before you buy.)

As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:

Ozy/Janus
+12v: 200 ma
+5v: 180 ma
-12v: 70 ma

Obviously additional boards connected to the Atlas board will increase these numbers.

Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):

Penelope
+12v: 200 ma
+5v: 300 ma

Mercury
+12v: 200 ma
+5v: 500 ma

Q. '''Will the Atlas be offered assembled?'''

A. Probably not. It is fairly easy to assemble with a very minimal amount of surface mount parts. There are quite a few solder pads due to the 96 pin connectors. If you are not able to do this work yourself, our advice is to ask on the HPSDR Discussion List (reflector) to see if you can pay someone to do the work for you.

----

Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''

A. It is possible, but at least one report indicates problems with the center row on the connectors. If considering doing this, we suggest you ask on the discussion list. If anyone has had success or failure, please report it to the wikisysop so we can update this reply.

----

Q. '''Will a larger (or smaller?) number of slots version be offered?'''

A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).

----

Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''

A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.

== PINOCCHIO Extender ==

Q. '''Availability?'''

A. The bare board and connectors are now available from TAPR http://tapr.org

== OZY ==

Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''

A. A USB 2 connection will be required on the PC. Most modern PCs have this as standard. With MS Windows, for the USB driver we are using the LibUsb-Win32 library which is a free download from http://libusb-win32.sourceforge.net/ A Linux version is also available, see http://www.linux-usb.org/ and http://libusb.sourceforge.net/ . Experience will tell us if there are any problems with certain types of USB2 ports.

----

Q. '''Why do we need a "configuration device" when the software can just load the FPGA via USB and the Cypress CY7C68013 (FX2) chip? The schematic shows the programming pins connected from FX2 GPIO pins to FPGA.'''

A. It does load via USB and this is how OZY is normally used. BUT, there will come a time when someone wants to use the OZY without PC attached and the configuraton device allows this possibility.

----

Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''

A. We certainly hope so and expect that some will use it as a learning tool or development platform for other projects not even remotely related to SDR. It provides an inexpensive piece of hardware for many purposes.

----

== JANUS ==

Q. '''Is Janus a "sound card" ?'''

A. NO! The usual meaning of a sound card is one which plugs into a personal computer (ISA, PCI, or other bus). The Janus module plugs into our Atlas bus and contains some of the components of the usual sound card. It also requires the Ozy or similar interface to use it in applications which call for a PC sound card.

----

Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''

A. In theory, Yes! This will require a Windows or Linux driver; there is no reason one can't be written, we just need a volunteer!

----

== MERCURY ==

Q. '''Why are there no input RF filters on the Mercury PCB?'''

A. This is due to the multi-function nature of the Mercury board. Whilst primarily a high performance HF (and VHF/UHF in alias mode) receiver, Mercury can also be used for other functions. For example, it can be used as a high performance 0-55MHz spectrum analyzer, sampling oscilloscope and VNA (by using Penelope as the signal source for the VNA and also as a tracking generator). In these cases it is desirable not to have any RF filtering before the ADC on Mercury.

When used as a receiver the amount of filtering will vary depending on the antenna system the user has. For most situations with say an HF beam or dipoles the natural frequency response of the antenna may provide adequate filtering. For the user with a high performance broadband antenna e.g. a rhombic, or very strong local signals, then additional filtering may be required.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance ADCs to be come available in the future. These newer devices will still require some form of input filtering. By using external filters the cost of replacing the ADC board is reduced.

== PENELOPE ==

Q. '''Why are there no output RF filters on the Penelope PCB?'''

A. This is due to a number of reasons. Firstly, whilst Penelope is primarily an HF ( and VHF/UHF on alias) exciter it can be used for other functions. For example, when used with Mercury it can form a low level signal source as a tracking generator or VNA. For these functions the lack of output filters is an advantage.

Secondly, Penelope generates RF directly at the desired output frequency by synthesizing the required RF waveform using a DAC. The lack of mixers, DDS, frequency synthesizer etc means the output spectrum of Penelope is particularly clean. In fact the spurious output at 0.5w meets the FCC requirements without additional filtering.

Thirdly, Penelope is an exciter. Whilst we expect it will be used by QRP operators as is we also expect it to be used to drive a higher power amplifier. In the latter case the user will most likely provided external filtering as part of this power amplification.

Fourthly, Penelope does provide a 55MHz LPF that can be placed in circuit after the DAC and prior to the 0.5W PA. If desired the user can add external bandpass filters here. Alternatively, the filter can be bypassed and/or an external VHF/UHF filter fitted such that the alias output of the DAC can be used on the higher bands.

Fifthly, if is desirable to use LPFs that may be also be used before Mercury. The IP3 performance of Mercury is very good and using small inductors, that are quite acceptable for removing the harmonics from Penelope, results in a significant degradation in IP3 performance.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance DACs to be come available in the future. These newer devices will still require some form of output filtering. By using external filters the cost of replacing the exciter board is reduced.

== Miscellaneous ==

Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."

General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]

FAQ

2009-05-23T15:24:47Z

WikiSysop: /* The HPSDR Project */

== The HPSDR Project ==

Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''

A. After searching for an answer and not finding it, usually the best way is to post your question on the HPSDR Discussion List (reflector).
This allows two things to happen: (1) it permits someone other than the very busy developers to answer he question if they can, and (2) it allows everyone on the list to gain the benefit of any reply.

----

Q. '''How do I get in direct email contact with project leaders?'''

A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.

----

Q. '''What is the status of the various boards or modules?'''

A. Here's the scoop on some as of May 23, 2009:

ATLAS - in production, order through http://tapr.org
PINOCCHIO - in production, order through http://tapr.org
OZY - 1st production run - Sold out - PCB are available. Order through http://tapr.org
JANUS - 1st production run - currently being shipped. Order through http://tapr.org
MERCURY - 1st production Order through http://tapr.org
MERCURY-EU - alpha - see Gerd, DJ8AY
PENELOPE - 1st production run - Sold Out - PCB are available Order through http://tapr.org, available from Gerd, DJ8AY
LPU - in production - available in kit form. Order through http://tapr.org
ALEX - Pre-production
PENNYWHISTLE - Pre-production
EXCALIBUR - Pre-production
PANDORA - Pre-production

All others - in various stages of design/development -- see their wiki pages or the [http://openhpsdr.org HPSDR] website.

----

Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''

A. It is important to remember the goals of HPSDR. All modules are not meant to be combined together to make a “single flavor” HPSDR transceiver. A number of different combinations will be possible (examples: Horton or Mercury for the receiver). How the modules are used and combined are in the hands of the experimenter/builder. Some users may not even wish to make an entire transceiver out of the modules (example: SDR1000 owners who only want to use Atlas, Ozy, and Janus to replace their sound cards).

In the words of Phil Covington, project leader for a number of the modules, “HPSDR was not formed to be a manufacturer of finished Ham Radio equipment. Its primary purpose is to develop a High Performance SDR in a modular fashion by experimentation with various methods.”

If your only goal is to get “on the air” with an SDR transceiver, there may be cheaper and/or easier routes to achieve this goal (Softrock or Flexradio).

If your goal is high performance software defined radio with a “roll your own” mentality, then the HPSDR modules should enable the creation of your own high performance SDR transceiver.

----

Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''

A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.

----

Q. '''Will Ozy and Janus "bare boards" be available?'''

A. Bare boards (not kits of parts) are available through TAPR.

----

Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''

A. A partial kit of harder to obtain parts is being offered for Janus. Potential users may certainly get together for a group buy on other parts needed to complete the boards. There are several reasons for TAPR (or HPSDR) not offering complete kits: (1) being an all-volunteer organization, it would take tremendous manpower to break the parts down to individual kits and package them, (2) there is a very large support problem for kit builders whose boards do not work when completed, and (3) the cost of a kit of parts would be about equal or may exceed the cost of an assembled and tested board.

----

Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''

A. Yes. They are released under the new TAPR open source hardware license called OHL. The board designer may restrict to non-commercial use. The OHL license was finalized and approved in May 2007. For License information see [http://tapr.org/OHL Open hardware license] or [http://tapr.org/NCL Non-Commercial hardware license]. The Schematics, Gerber files and Bill of Materials (BOM) area available of the [http://opnhpsdr.org/support.html Support] webpage.

----

Q. '''Why not put OZY and JANUS on a single board?'''

A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated
circuit on the Janus board allows a future (and hopefully better) chip to be used on a similar board, but keeping Ozy for the interface
and control. Flexibility is the goal.

----

Q. '''How much better will the Ozy-Janus combination be in terms of performance when used with the SDR-1000 in place of a sound card such as the Delta 44?'''

A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.

----

Q. '''Will a Ozy-Janus-Atlas combination work with my PowerSDR software used for my Flex Radio SDR-1000 in place of a sound card in my PC?'''

A. Yes, that was one of the early goals of the HPSDR group. Phil, VK6APH, did confirm with Gerald and Eric at the Flex-Radio meeting at the Dayton Hamvention 2007 that Ozy/Janus will be fully supported in future releases in their 'mainstream' releases of PowerSDR. Bill, KD5TFD, will be working with Eric from Flex to accomplish this. At this point it is not known exactly when, and what version the support will begin, but it will happen. Direct all questions regarding Janus/Ozy to the HPSDR Discussion List (and NOT the Flex-Radio list), as folks have been doing and admirably responding. The arrangement with Flex-Radio required the donation of a working Ozy/Janus to Flex-Radio and this has been accomplished after TAPR approved the expense.

----

Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''

A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH

----

Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''

A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.

----
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''

A. USB 2.0 is a requirement. Currently, the OS recommendation is WinXP. Windows 2000 is NOT recommended as the USB 2.0 stack on Windows 2000 is just too slow.

At this time, there are no solid recommendations for minimum CPU or RAM that are based on actual testing with HPSDR hardware of how low we can go.

FlexRadio does have Minimum Recommended PC Configurations for systems using the PowerSDR software. Since the HPSDR hardware may use PowerSDR, these specs are probably a good guide to what would be advisable for the HPSDR. FlexRadio's numbers from their website are as follows:

Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater

Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)

----

Q. '''What user name and password do I use to access the HPSDR svn repository?'''

A. None is required for reading the SVN, only required to place something in the repository. The IP address of the repository is shown on the resources page of the main HPSDR.org website.

----

Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''

A. There is a group doing SDR for microwave: [http://uwsdr.berlios.de/ ] Current HPSDR projects could certainly be used as an IF for a transverter, but there is nothing going on with HPSDR that is specifically aimed at microwave.

----

== The HPSDR Wiki ==

Q. '''Do I need to log in?'''

A. Those who contribute by editing the wiki need to have a login.
----
Q. '''How do I get a account? (a login)'''

A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]
----
Q. '''What if I find that a correction is needed in the wiki?'''

A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]
----

== ATLAS Backplane ==
Q. '''What is the recommended means of powering ATLAS?'''

A. Demeter. Until Demeter is available...

The ATX 20 pin power connector on the Atlas board enables the use of standard PC power supplies. (Please Note: There is no reason that you cannot utilize a non-PC power supply regulated and wired to provide the proper voltages to the 20pin connector. A non-PC power supply could also enable custom current limiting of the voltages going to the 20 pin connector, an advisable setup when testing or prototyping boards plugged into ATLAS. An analog power supply may be an attractive option for users particularly concerned about spurious emissions in the HF band which some low cost PC power supplies may produce.)

If you choose to use an ATX computer power supply care should be taken that the -12V current requirement is met. (Note of warning: some versions of the attractive picoPSU do not provide proper -12V current capacity. Check before you buy.)

As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:

Ozy/Janus
+12v: 200 ma
+5v: 180 ma
-12v: 70 ma

Obviously additional boards connected to the Atlas board will increase these numbers.

Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):

Penelope
+12v: 200 ma
+5v: 300 ma

Mercury
+12v: 200 ma
+5v: 500 ma

Q. '''Will the Atlas be offered assembled?'''

A. Probably not. It is fairly easy to assemble with a very minimal amount of surface mount parts. There are quite a few solder pads due to the 96 pin connectors. If you are not able to do this work yourself, our advice is to ask on the HPSDR Discussion List (reflector) to see if you can pay someone to do the work for you.

----

Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''

A. It is possible, but at least one report indicates problems with the center row on the connectors. If considering doing this, we suggest you ask on the discussion list. If anyone has had success or failure, please report it to the wikisysop so we can update this reply.

----

Q. '''Will a larger (or smaller?) number of slots version be offered?'''

A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).

----

Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''

A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.

== PINOCCHIO Extender ==

Q. '''Availability?'''

A. The bare board and connectors are now available from TAPR http://tapr.org

== OZY ==

Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''

A. A USB 2 connection will be required on the PC. Most modern PCs have this as standard. With MS Windows, for the USB driver we are using the LibUsb-Win32 library which is a free download from http://libusb-win32.sourceforge.net/ A Linux version is also available, see http://www.linux-usb.org/ and http://libusb.sourceforge.net/ . Experience will tell us if there are any problems with certain types of USB2 ports.

----

Q. '''Why do we need a "configuration device" when the software can just load the FPGA via USB and the Cypress CY7C68013 (FX2) chip? The schematic shows the programming pins connected from FX2 GPIO pins to FPGA.'''

A. It does load via USB and this is how OZY is normally used. BUT, there will come a time when someone wants to use the OZY without PC attached and the configuraton device allows this possibility.

----

Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''

A. We certainly hope so and expect that some will use it as a learning tool or development platform for other projects not even remotely related to SDR. It provides an inexpensive piece of hardware for many purposes.

----

== JANUS ==

Q. '''Is Janus a "sound card" ?'''

A. NO! The usual meaning of a sound card is one which plugs into a personal computer (ISA, PCI, or other bus). The Janus module plugs into our Atlas bus and contains some of the components of the usual sound card. It also requires the Ozy or similar interface to use it in applications which call for a PC sound card.

----

Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''

A. In theory, Yes! This will require a Windows or Linux driver; there is no reason one can't be written, we just need a volunteer!

----

== MERCURY ==

Q. '''Why are there no input RF filters on the Mercury PCB?'''

A. This is due to the multi-function nature of the Mercury board. Whilst primarily a high performance HF (and VHF/UHF in alias mode) receiver, Mercury can also be used for other functions. For example, it can be used as a high performance 0-55MHz spectrum analyzer, sampling oscilloscope and VNA (by using Penelope as the signal source for the VNA and also as a tracking generator). In these cases it is desirable not to have any RF filtering before the ADC on Mercury.

When used as a receiver the amount of filtering will vary depending on the antenna system the user has. For most situations with say an HF beam or dipoles the natural frequency response of the antenna may provide adequate filtering. For the user with a high performance broadband antenna e.g. a rhombic, or very strong local signals, then additional filtering may be required.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance ADCs to be come available in the future. These newer devices will still require some form of input filtering. By using external filters the cost of replacing the ADC board is reduced.

== PENELOPE ==

Q. '''Why are there no output RF filters on the Penelope PCB?'''

A. This is due to a number of reasons. Firstly, whilst Penelope is primarily an HF ( and VHF/UHF on alias) exciter it can be used for other functions. For example, when used with Mercury it can form a low level signal source as a tracking generator or VNA. For these functions the lack of output filters is an advantage.

Secondly, Penelope generates RF directly at the desired output frequency by synthesizing the required RF waveform using a DAC. The lack of mixers, DDS, frequency synthesizer etc means the output spectrum of Penelope is particularly clean. In fact the spurious output at 0.5w meets the FCC requirements without additional filtering.

Thirdly, Penelope is an exciter. Whilst we expect it will be used by QRP operators as is we also expect it to be used to drive a higher power amplifier. In the latter case the user will most likely provided external filtering as part of this power amplification.

Fourthly, Penelope does provide a 55MHz LPF that can be placed in circuit after the DAC and prior to the 0.5W PA. If desired the user can add external bandpass filters here. Alternatively, the filter can be bypassed and/or an external VHF/UHF filter fitted such that the alias output of the DAC can be used on the higher bands.

Fifthly, if is desirable to use LPFs that may be also be used before Mercury. The IP3 performance of Mercury is very good and using small inductors, that are quite acceptable for removing the harmonics from Penelope, results in a significant degradation in IP3 performance.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance DACs to be come available in the future. These newer devices will still require some form of output filtering. By using external filters the cost of replacing the exciter board is reduced.

== Miscellaneous ==

Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."

General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]

FAQ

2009-05-23T15:21:54Z

WikiSysop: /* The HPSDR Project */

== The HPSDR Project ==

Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''

A. After searching for an answer and not finding it, usually the best way is to post your question on the HPSDR Discussion List (reflector).
This allows two things to happen: (1) it permits someone other than the very busy developers to answer he question if they can, and (2) it allows everyone on the list to gain the benefit of any reply.

----

Q. '''How do I get in direct email contact with project leaders?'''

A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.

----

Q. '''What is the status of the various boards or modules?'''

A. Here's the scoop on some as of May 23, 2009:

ATLAS - in production, order through http://tapr.org
PINOCCHIO - in production, order through http://tapr.org
OZY - 1st production run - Sold out - PCB are available. Order through http://tapr.org
JANUS - 1st production run - currently being shipped. Order through http://tapr.org
MERCURY - 1st production Order through http://tapr.org
MERCURY-EU - alpha - see Gerd, DJ8AY
PENELOPE - 1st production run - Sold Out - PCB are available Order through http://tapr.org, available from Gerd, DJ8AY
LPU - in production - available in kit form. Order through http://tapr.org
ALEX - Pre-production
PENNYWHISTLE - Pre-production
EXCALIBUR - Pre-production
PANDORA - Pre-production

All others - in various stages of design/development -- see their wiki pages or the [http://openhpsdr.org HPSDR] website.

----

Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''

A. It is important to remember the goals of HPSDR. All modules are not meant to be combined together to make a “single flavor” HPSDR transceiver. A number of different combinations will be possible (examples: Horton or Mercury for the receiver). How the modules are used and combined are in the hands of the experimenter/builder. Some users may not even wish to make an entire transceiver out of the modules (example: SDR1000 owners who only want to use Atlas, Ozy, and Janus to replace their sound cards).

In the words of Phil Covington, project leader for a number of the modules, “HPSDR was not formed to be a manufacturer of finished Ham Radio equipment. Its primary purpose is to develop a High Performance SDR in a modular fashion by experimentation with various methods.”

If your only goal is to get “on the air” with an SDR transceiver, there may be cheaper and/or easier routes to achieve this goal (Softrock or Flexradio).

If your goal is high performance software defined radio with a “roll your own” mentality, then the HPSDR modules should enable the creation of your own high performance SDR transceiver.

----

Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''

A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.

----

Q. '''Will Ozy and Janus "bare boards" be available?'''

A. Bare boards (not kits of parts) are available through TAPR.

----

Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''

A. A partial kit of harder to obtain parts is being offered for Janus. Potential users may certainly get together for a group buy on other parts needed to complete the boards. There are several reasons for TAPR (or HPSDR) not offering complete kits: (1) being an all-volunteer organization, it would take tremendous manpower to break the parts down to individual kits and package them, (2) there is a very large support problem for kit builders whose boards do not work when completed, and (3) the cost of a kit of parts would be about equal or may exceed the cost of an assembled and tested board.

----

Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''

A. Yes. They are released under the new TAPR open source hardware license called OHL. The board designer may restrict to non-commercial use. The OHL license was finalized and approved in May 2007. For License information see [http://tapr.org/OHL Open hardware license] or [http://tapr.org/NCL Non-Commercial hardware license].

----

Q. '''Why not put OZY and JANUS on a single board?'''

A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated
circuit on the Janus board allows a future (and hopefully better) chip to be used on a similar board, but keeping Ozy for the interface
and control. Flexibility is the goal.

----

Q. '''How much better will the Ozy-Janus combination be in terms of performance when used with the SDR-1000 in place of a sound card such as the Delta 44?'''

A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.

----

Q. '''Will a Ozy-Janus-Atlas combination work with my PowerSDR software used for my Flex Radio SDR-1000 in place of a sound card in my PC?'''

A. Yes, that was one of the early goals of the HPSDR group. Phil, VK6APH, did confirm with Gerald and Eric at the Flex-Radio meeting at the Dayton Hamvention 2007 that Ozy/Janus will be fully supported in future releases in their 'mainstream' releases of PowerSDR. Bill, KD5TFD, will be working with Eric from Flex to accomplish this. At this point it is not known exactly when, and what version the support will begin, but it will happen. Direct all questions regarding Janus/Ozy to the HPSDR Discussion List (and NOT the Flex-Radio list), as folks have been doing and admirably responding. The arrangement with Flex-Radio required the donation of a working Ozy/Janus to Flex-Radio and this has been accomplished after TAPR approved the expense.

----

Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''

A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH

----

Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''

A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.

----
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''

A. USB 2.0 is a requirement. Currently, the OS recommendation is WinXP. Windows 2000 is NOT recommended as the USB 2.0 stack on Windows 2000 is just too slow.

At this time, there are no solid recommendations for minimum CPU or RAM that are based on actual testing with HPSDR hardware of how low we can go.

FlexRadio does have Minimum Recommended PC Configurations for systems using the PowerSDR software. Since the HPSDR hardware may use PowerSDR, these specs are probably a good guide to what would be advisable for the HPSDR. FlexRadio's numbers from their website are as follows:

Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater

Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)

----

Q. '''What user name and password do I use to access the HPSDR svn repository?'''

A. None is required for reading the SVN, only required to place something in the repository. The IP address of the repository is shown on the resources page of the main HPSDR.org website.

----

Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''

A. There is a group doing SDR for microwave: [http://uwsdr.berlios.de/ ] Current HPSDR projects could certainly be used as an IF for a transverter, but there is nothing going on with HPSDR that is specifically aimed at microwave.

----

== The HPSDR Wiki ==

Q. '''Do I need to log in?'''

A. Those who contribute by editing the wiki need to have a login.
----
Q. '''How do I get a account? (a login)'''

A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]
----
Q. '''What if I find that a correction is needed in the wiki?'''

A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]
----

== ATLAS Backplane ==
Q. '''What is the recommended means of powering ATLAS?'''

A. Demeter. Until Demeter is available...

The ATX 20 pin power connector on the Atlas board enables the use of standard PC power supplies. (Please Note: There is no reason that you cannot utilize a non-PC power supply regulated and wired to provide the proper voltages to the 20pin connector. A non-PC power supply could also enable custom current limiting of the voltages going to the 20 pin connector, an advisable setup when testing or prototyping boards plugged into ATLAS. An analog power supply may be an attractive option for users particularly concerned about spurious emissions in the HF band which some low cost PC power supplies may produce.)

If you choose to use an ATX computer power supply care should be taken that the -12V current requirement is met. (Note of warning: some versions of the attractive picoPSU do not provide proper -12V current capacity. Check before you buy.)

As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:

Ozy/Janus
+12v: 200 ma
+5v: 180 ma
-12v: 70 ma

Obviously additional boards connected to the Atlas board will increase these numbers.

Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):

Penelope
+12v: 200 ma
+5v: 300 ma

Mercury
+12v: 200 ma
+5v: 500 ma

Q. '''Will the Atlas be offered assembled?'''

A. Probably not. It is fairly easy to assemble with a very minimal amount of surface mount parts. There are quite a few solder pads due to the 96 pin connectors. If you are not able to do this work yourself, our advice is to ask on the HPSDR Discussion List (reflector) to see if you can pay someone to do the work for you.

----

Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''

A. It is possible, but at least one report indicates problems with the center row on the connectors. If considering doing this, we suggest you ask on the discussion list. If anyone has had success or failure, please report it to the wikisysop so we can update this reply.

----

Q. '''Will a larger (or smaller?) number of slots version be offered?'''

A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).

----

Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''

A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.

== PINOCCHIO Extender ==

Q. '''Availability?'''

A. The bare board and connectors are now available from TAPR http://tapr.org

== OZY ==

Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''

A. A USB 2 connection will be required on the PC. Most modern PCs have this as standard. With MS Windows, for the USB driver we are using the LibUsb-Win32 library which is a free download from http://libusb-win32.sourceforge.net/ A Linux version is also available, see http://www.linux-usb.org/ and http://libusb.sourceforge.net/ . Experience will tell us if there are any problems with certain types of USB2 ports.

----

Q. '''Why do we need a "configuration device" when the software can just load the FPGA via USB and the Cypress CY7C68013 (FX2) chip? The schematic shows the programming pins connected from FX2 GPIO pins to FPGA.'''

A. It does load via USB and this is how OZY is normally used. BUT, there will come a time when someone wants to use the OZY without PC attached and the configuraton device allows this possibility.

----

Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''

A. We certainly hope so and expect that some will use it as a learning tool or development platform for other projects not even remotely related to SDR. It provides an inexpensive piece of hardware for many purposes.

----

== JANUS ==

Q. '''Is Janus a "sound card" ?'''

A. NO! The usual meaning of a sound card is one which plugs into a personal computer (ISA, PCI, or other bus). The Janus module plugs into our Atlas bus and contains some of the components of the usual sound card. It also requires the Ozy or similar interface to use it in applications which call for a PC sound card.

----

Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''

A. In theory, Yes! This will require a Windows or Linux driver; there is no reason one can't be written, we just need a volunteer!

----

== MERCURY ==

Q. '''Why are there no input RF filters on the Mercury PCB?'''

A. This is due to the multi-function nature of the Mercury board. Whilst primarily a high performance HF (and VHF/UHF in alias mode) receiver, Mercury can also be used for other functions. For example, it can be used as a high performance 0-55MHz spectrum analyzer, sampling oscilloscope and VNA (by using Penelope as the signal source for the VNA and also as a tracking generator). In these cases it is desirable not to have any RF filtering before the ADC on Mercury.

When used as a receiver the amount of filtering will vary depending on the antenna system the user has. For most situations with say an HF beam or dipoles the natural frequency response of the antenna may provide adequate filtering. For the user with a high performance broadband antenna e.g. a rhombic, or very strong local signals, then additional filtering may be required.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance ADCs to be come available in the future. These newer devices will still require some form of input filtering. By using external filters the cost of replacing the ADC board is reduced.

== PENELOPE ==

Q. '''Why are there no output RF filters on the Penelope PCB?'''

A. This is due to a number of reasons. Firstly, whilst Penelope is primarily an HF ( and VHF/UHF on alias) exciter it can be used for other functions. For example, when used with Mercury it can form a low level signal source as a tracking generator or VNA. For these functions the lack of output filters is an advantage.

Secondly, Penelope generates RF directly at the desired output frequency by synthesizing the required RF waveform using a DAC. The lack of mixers, DDS, frequency synthesizer etc means the output spectrum of Penelope is particularly clean. In fact the spurious output at 0.5w meets the FCC requirements without additional filtering.

Thirdly, Penelope is an exciter. Whilst we expect it will be used by QRP operators as is we also expect it to be used to drive a higher power amplifier. In the latter case the user will most likely provided external filtering as part of this power amplification.

Fourthly, Penelope does provide a 55MHz LPF that can be placed in circuit after the DAC and prior to the 0.5W PA. If desired the user can add external bandpass filters here. Alternatively, the filter can be bypassed and/or an external VHF/UHF filter fitted such that the alias output of the DAC can be used on the higher bands.

Fifthly, if is desirable to use LPFs that may be also be used before Mercury. The IP3 performance of Mercury is very good and using small inductors, that are quite acceptable for removing the harmonics from Penelope, results in a significant degradation in IP3 performance.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance DACs to be come available in the future. These newer devices will still require some form of output filtering. By using external filters the cost of replacing the exciter board is reduced.

== Miscellaneous ==

Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."

General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]

FAQ

2009-05-21T02:35:31Z

WikiSysop: /* The HPSDR Wiki */

== The HPSDR Project ==

Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''

A. After searching for an answer and not finding it, usually the best way is to post your question on the HPSDR Discussion List (reflector).
This allows two things to happen: (1) it permits someone other than the very busy developers to answer he question if they can, and (2) it allows everyone on the list to gain the benefit of any reply.

----

Q. '''How do I get in direct email contact with project leaders?'''

A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.

----

Q. '''What is the status of the various boards or modules?'''

A. Here's the scoop on some as of Jaunary 1, 2009:

ATLAS - in production, order through http://tapr.org
PINOCCHIO - in production, order through http://tapr.org
OZY - 1st production run - currently being shipped. Order through http://tapr.org
JANUS - 1st production run - currently being shipped. Order through http://tapr.org
MERCURY - 1st production Order through http://tapr.org
MERCURY-EU - alpha - see DJ8AY
PENELOPE - Sold Out http://tapr.org
ALEX - Pre-production

All others - in various stages of design/development -- see their wiki pages.

----

Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''

A. It is important to remember the goals of HPSDR. All modules are not meant to be combined together to make a “single flavor” HPSDR transceiver. A number of different combinations will be possible (examples: Horton or Mercury for the receiver). How the modules are used and combined are in the hands of the experimenter/builder. Some users may not even wish to make an entire transceiver out of the modules (example: SDR1000 owners who only want to use Atlas, Ozy, and Janus to replace their sound cards).

In the words of Phil Covington, project leader for a number of the modules, “HPSDR was not formed to be a manufacturer of finished Ham Radio equipment. Its primary purpose is to develop a High Performance SDR in a modular fashion by experimentation with various methods.”

If your only goal is to get “on the air” with an SDR transceiver, there may be cheaper and/or easier routes to achieve this goal (Softrock or Flexradio).

If your goal is high performance software defined radio with a “roll your own” mentality, then the HPSDR modules should enable the creation of your own high performance SDR transceiver.

----

Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''

A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.

----

Q. '''Will Ozy and Janus "bare boards" be available?'''

A. Bare boards (not kits of parts) are available through TAPR.

----

Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''

A. A partial kit of harder to obtain parts is being offered for Janus. Potential users may certainly get together for a group buy on other parts needed to complete the boards. There are several reasons for TAPR (or HPSDR) not offering complete kits: (1) being an all-volunteer organization, it would take tremendous manpower to break the parts down to individual kits and package them, (2) there is a very large support problem for kit builders whose boards do not work when completed, and (3) the cost of a kit of parts would be about equal or may exceed the cost of an assembled and tested board.

----

Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''

A. Yes. They are released under the new TAPR open source hardware license called OHL. The board designer may restrict to non-commercial use. The OHL license was finalized and approved in May 2007. See [http://tapr.org/OHL]

----

Q. '''Why not put OZY and JANUS on a single board?'''

A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated
circuit on the Janus board allows a future (and hopefully better) chip to be used on a similar board, but keeping Ozy for the interface
and control. Flexibility is the goal.

----

Q. '''How much better will the Ozy-Janus combination be in terms of performance when used with the SDR-1000 in place of a sound card such as the Delta 44?'''

A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.

----

Q. '''Will a Ozy-Janus-Atlas combination work with my PowerSDR software used for my Flex Radio SDR-1000 in place of a sound card in my PC?'''

A. Yes, that was one of the early goals of the HPSDR group. Phil, VK6APH, did confirm with Gerald and Eric at the Flex-Radio meeting at the Dayton Hamvention 2007 that Ozy/Janus will be fully supported in future releases in their 'mainstream' releases of PowerSDR. Bill, KD5TFD, will be working with Eric from Flex to accomplish this. At this point it is not known exactly when, and what version the support will begin, but it will happen. Direct all questions regarding Janus/Ozy to the HPSDR Discussion List (and NOT the Flex-Radio list), as folks have been doing and admirably responding. The arrangement with Flex-Radio required the donation of a working Ozy/Janus to Flex-Radio and this has been accomplished after TAPR approved the expense.

----

Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''

A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH

----

Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''

A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.

----
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''

A. USB 2.0 is a requirement. Currently, the OS recommendation is WinXP. Windows 2000 is NOT recommended as the USB 2.0 stack on Windows 2000 is just too slow.

At this time, there are no solid recommendations for minimum CPU or RAM that are based on actual testing with HPSDR hardware of how low we can go.

FlexRadio does have Minimum Recommended PC Configurations for systems using the PowerSDR software. Since the HPSDR hardware may use PowerSDR, these specs are probably a good guide to what would be advisable for the HPSDR. FlexRadio's numbers from their website are as follows:

Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater

Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)

----

Q. '''What user name and password do I use to access the HPSDR svn repository?'''

A. None is required for reading the SVN, only required to place something in the repository. The IP address of the repository is shown on the resources page of the main HPSDR.org website.

----

Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''

A. There is a group doing SDR for microwave: [http://uwsdr.berlios.de/ ] Current HPSDR projects could certainly be used as an IF for a transverter, but there is nothing going on with HPSDR that is specifically aimed at microwave.

----

== The HPSDR Wiki ==

Q. '''Do I need to log in?'''

A. Those who contribute by editing the wiki need to have a login.
----
Q. '''How do I get a account? (a login)'''

A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]
----
Q. '''What if I find that a correction is needed in the wiki?'''

A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]
----

== ATLAS Backplane ==
Q. '''What is the recommended means of powering ATLAS?'''

A. Demeter. Until Demeter is available...

The ATX 20 pin power connector on the Atlas board enables the use of standard PC power supplies. (Please Note: There is no reason that you cannot utilize a non-PC power supply regulated and wired to provide the proper voltages to the 20pin connector. A non-PC power supply could also enable custom current limiting of the voltages going to the 20 pin connector, an advisable setup when testing or prototyping boards plugged into ATLAS. An analog power supply may be an attractive option for users particularly concerned about spurious emissions in the HF band which some low cost PC power supplies may produce.)

If you choose to use an ATX computer power supply care should be taken that the -12V current requirement is met. (Note of warning: some versions of the attractive picoPSU do not provide proper -12V current capacity. Check before you buy.)

As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:

Ozy/Janus
+12v: 200 ma
+5v: 180 ma
-12v: 70 ma

Obviously additional boards connected to the Atlas board will increase these numbers.

Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):

Penelope
+12v: 200 ma
+5v: 300 ma

Mercury
+12v: 200 ma
+5v: 500 ma

Q. '''Will the Atlas be offered assembled?'''

A. Probably not. It is fairly easy to assemble with a very minimal amount of surface mount parts. There are quite a few solder pads due to the 96 pin connectors. If you are not able to do this work yourself, our advice is to ask on the HPSDR Discussion List (reflector) to see if you can pay someone to do the work for you.

----

Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''

A. It is possible, but at least one report indicates problems with the center row on the connectors. If considering doing this, we suggest you ask on the discussion list. If anyone has had success or failure, please report it to the wikisysop so we can update this reply.

----

Q. '''Will a larger (or smaller?) number of slots version be offered?'''

A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).

----

Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''

A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.

== PINOCCHIO Extender ==

Q. '''Availability?'''

A. The bare board and connectors are now available from TAPR http://tapr.org

== OZY ==

Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''

A. A USB 2 connection will be required on the PC. Most modern PCs have this as standard. With MS Windows, for the USB driver we are using the LibUsb-Win32 library which is a free download from http://libusb-win32.sourceforge.net/ A Linux version is also available, see http://www.linux-usb.org/ and http://libusb.sourceforge.net/ . Experience will tell us if there are any problems with certain types of USB2 ports.

----

Q. '''Why do we need a "configuration device" when the software can just load the FPGA via USB and the Cypress CY7C68013 (FX2) chip? The schematic shows the programming pins connected from FX2 GPIO pins to FPGA.'''

A. It does load via USB and this is how OZY is normally used. BUT, there will come a time when someone wants to use the OZY without PC attached and the configuraton device allows this possibility.

----

Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''

A. We certainly hope so and expect that some will use it as a learning tool or development platform for other projects not even remotely related to SDR. It provides an inexpensive piece of hardware for many purposes.

----

== JANUS ==

Q. '''Is Janus a "sound card" ?'''

A. NO! The usual meaning of a sound card is one which plugs into a personal computer (ISA, PCI, or other bus). The Janus module plugs into our Atlas bus and contains some of the components of the usual sound card. It also requires the Ozy or similar interface to use it in applications which call for a PC sound card.

----

Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''

A. In theory, Yes! This will require a Windows or Linux driver; there is no reason one can't be written, we just need a volunteer!

----

== MERCURY ==

Q. '''Why are there no input RF filters on the Mercury PCB?'''

A. This is due to the multi-function nature of the Mercury board. Whilst primarily a high performance HF (and VHF/UHF in alias mode) receiver, Mercury can also be used for other functions. For example, it can be used as a high performance 0-55MHz spectrum analyzer, sampling oscilloscope and VNA (by using Penelope as the signal source for the VNA and also as a tracking generator). In these cases it is desirable not to have any RF filtering before the ADC on Mercury.

When used as a receiver the amount of filtering will vary depending on the antenna system the user has. For most situations with say an HF beam or dipoles the natural frequency response of the antenna may provide adequate filtering. For the user with a high performance broadband antenna e.g. a rhombic, or very strong local signals, then additional filtering may be required.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance ADCs to be come available in the future. These newer devices will still require some form of input filtering. By using external filters the cost of replacing the ADC board is reduced.

== PENELOPE ==

Q. '''Why are there no output RF filters on the Penelope PCB?'''

A. This is due to a number of reasons. Firstly, whilst Penelope is primarily an HF ( and VHF/UHF on alias) exciter it can be used for other functions. For example, when used with Mercury it can form a low level signal source as a tracking generator or VNA. For these functions the lack of output filters is an advantage.

Secondly, Penelope generates RF directly at the desired output frequency by synthesizing the required RF waveform using a DAC. The lack of mixers, DDS, frequency synthesizer etc means the output spectrum of Penelope is particularly clean. In fact the spurious output at 0.5w meets the FCC requirements without additional filtering.

Thirdly, Penelope is an exciter. Whilst we expect it will be used by QRP operators as is we also expect it to be used to drive a higher power amplifier. In the latter case the user will most likely provided external filtering as part of this power amplification.

Fourthly, Penelope does provide a 55MHz LPF that can be placed in circuit after the DAC and prior to the 0.5W PA. If desired the user can add external bandpass filters here. Alternatively, the filter can be bypassed and/or an external VHF/UHF filter fitted such that the alias output of the DAC can be used on the higher bands.

Fifthly, if is desirable to use LPFs that may be also be used before Mercury. The IP3 performance of Mercury is very good and using small inductors, that are quite acceptable for removing the harmonics from Penelope, results in a significant degradation in IP3 performance.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance DACs to be come available in the future. These newer devices will still require some form of output filtering. By using external filters the cost of replacing the exciter board is reduced.

== Miscellaneous ==

Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."

General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]

FAQ

2009-05-21T02:34:59Z

WikiSysop: /* The HPSDR Wiki */ Please use my first name and callsign

== The HPSDR Project ==

Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''

A. After searching for an answer and not finding it, usually the best way is to post your question on the HPSDR Discussion List (reflector).
This allows two things to happen: (1) it permits someone other than the very busy developers to answer he question if they can, and (2) it allows everyone on the list to gain the benefit of any reply.

----

Q. '''How do I get in direct email contact with project leaders?'''

A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.

----

Q. '''What is the status of the various boards or modules?'''

A. Here's the scoop on some as of Jaunary 1, 2009:

ATLAS - in production, order through http://tapr.org
PINOCCHIO - in production, order through http://tapr.org
OZY - 1st production run - currently being shipped. Order through http://tapr.org
JANUS - 1st production run - currently being shipped. Order through http://tapr.org
MERCURY - 1st production Order through http://tapr.org
MERCURY-EU - alpha - see DJ8AY
PENELOPE - Sold Out http://tapr.org
ALEX - Pre-production

All others - in various stages of design/development -- see their wiki pages.

----

Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''

A. It is important to remember the goals of HPSDR. All modules are not meant to be combined together to make a “single flavor” HPSDR transceiver. A number of different combinations will be possible (examples: Horton or Mercury for the receiver). How the modules are used and combined are in the hands of the experimenter/builder. Some users may not even wish to make an entire transceiver out of the modules (example: SDR1000 owners who only want to use Atlas, Ozy, and Janus to replace their sound cards).

In the words of Phil Covington, project leader for a number of the modules, “HPSDR was not formed to be a manufacturer of finished Ham Radio equipment. Its primary purpose is to develop a High Performance SDR in a modular fashion by experimentation with various methods.”

If your only goal is to get “on the air” with an SDR transceiver, there may be cheaper and/or easier routes to achieve this goal (Softrock or Flexradio).

If your goal is high performance software defined radio with a “roll your own” mentality, then the HPSDR modules should enable the creation of your own high performance SDR transceiver.

----

Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''

A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.

----

Q. '''Will Ozy and Janus "bare boards" be available?'''

A. Bare boards (not kits of parts) are available through TAPR.

----

Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''

A. A partial kit of harder to obtain parts is being offered for Janus. Potential users may certainly get together for a group buy on other parts needed to complete the boards. There are several reasons for TAPR (or HPSDR) not offering complete kits: (1) being an all-volunteer organization, it would take tremendous manpower to break the parts down to individual kits and package them, (2) there is a very large support problem for kit builders whose boards do not work when completed, and (3) the cost of a kit of parts would be about equal or may exceed the cost of an assembled and tested board.

----

Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''

A. Yes. They are released under the new TAPR open source hardware license called OHL. The board designer may restrict to non-commercial use. The OHL license was finalized and approved in May 2007. See [http://tapr.org/OHL]

----

Q. '''Why not put OZY and JANUS on a single board?'''

A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated
circuit on the Janus board allows a future (and hopefully better) chip to be used on a similar board, but keeping Ozy for the interface
and control. Flexibility is the goal.

----

Q. '''How much better will the Ozy-Janus combination be in terms of performance when used with the SDR-1000 in place of a sound card such as the Delta 44?'''

A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.

----

Q. '''Will a Ozy-Janus-Atlas combination work with my PowerSDR software used for my Flex Radio SDR-1000 in place of a sound card in my PC?'''

A. Yes, that was one of the early goals of the HPSDR group. Phil, VK6APH, did confirm with Gerald and Eric at the Flex-Radio meeting at the Dayton Hamvention 2007 that Ozy/Janus will be fully supported in future releases in their 'mainstream' releases of PowerSDR. Bill, KD5TFD, will be working with Eric from Flex to accomplish this. At this point it is not known exactly when, and what version the support will begin, but it will happen. Direct all questions regarding Janus/Ozy to the HPSDR Discussion List (and NOT the Flex-Radio list), as folks have been doing and admirably responding. The arrangement with Flex-Radio required the donation of a working Ozy/Janus to Flex-Radio and this has been accomplished after TAPR approved the expense.

----

Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''

A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH

----

Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''

A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.

----
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''

A. USB 2.0 is a requirement. Currently, the OS recommendation is WinXP. Windows 2000 is NOT recommended as the USB 2.0 stack on Windows 2000 is just too slow.

At this time, there are no solid recommendations for minimum CPU or RAM that are based on actual testing with HPSDR hardware of how low we can go.

FlexRadio does have Minimum Recommended PC Configurations for systems using the PowerSDR software. Since the HPSDR hardware may use PowerSDR, these specs are probably a good guide to what would be advisable for the HPSDR. FlexRadio's numbers from their website are as follows:

Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater

Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)

----

Q. '''What user name and password do I use to access the HPSDR svn repository?'''

A. None is required for reading the SVN, only required to place something in the repository. The IP address of the repository is shown on the resources page of the main HPSDR.org website.

----

Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''

A. There is a group doing SDR for microwave: [http://uwsdr.berlios.de/ ] Current HPSDR projects could certainly be used as an IF for a transverter, but there is nothing going on with HPSDR that is specifically aimed at microwave.

----

== The HPSDR Wiki ==

Q. '''Do I need to log in?'''

A. Those who contribute by editing the wiki need to have a login.
----
Q. '''How do I get a account? (a login)'''

A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave Larsen]
----
Q. '''What if I find that a correction is needed in the wiki?'''

A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]
----

== ATLAS Backplane ==
Q. '''What is the recommended means of powering ATLAS?'''

A. Demeter. Until Demeter is available...

The ATX 20 pin power connector on the Atlas board enables the use of standard PC power supplies. (Please Note: There is no reason that you cannot utilize a non-PC power supply regulated and wired to provide the proper voltages to the 20pin connector. A non-PC power supply could also enable custom current limiting of the voltages going to the 20 pin connector, an advisable setup when testing or prototyping boards plugged into ATLAS. An analog power supply may be an attractive option for users particularly concerned about spurious emissions in the HF band which some low cost PC power supplies may produce.)

If you choose to use an ATX computer power supply care should be taken that the -12V current requirement is met. (Note of warning: some versions of the attractive picoPSU do not provide proper -12V current capacity. Check before you buy.)

As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:

Ozy/Janus
+12v: 200 ma
+5v: 180 ma
-12v: 70 ma

Obviously additional boards connected to the Atlas board will increase these numbers.

Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):

Penelope
+12v: 200 ma
+5v: 300 ma

Mercury
+12v: 200 ma
+5v: 500 ma

Q. '''Will the Atlas be offered assembled?'''

A. Probably not. It is fairly easy to assemble with a very minimal amount of surface mount parts. There are quite a few solder pads due to the 96 pin connectors. If you are not able to do this work yourself, our advice is to ask on the HPSDR Discussion List (reflector) to see if you can pay someone to do the work for you.

----

Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''

A. It is possible, but at least one report indicates problems with the center row on the connectors. If considering doing this, we suggest you ask on the discussion list. If anyone has had success or failure, please report it to the wikisysop so we can update this reply.

----

Q. '''Will a larger (or smaller?) number of slots version be offered?'''

A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).

----

Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''

A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.

== PINOCCHIO Extender ==

Q. '''Availability?'''

A. The bare board and connectors are now available from TAPR http://tapr.org

== OZY ==

Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''

A. A USB 2 connection will be required on the PC. Most modern PCs have this as standard. With MS Windows, for the USB driver we are using the LibUsb-Win32 library which is a free download from http://libusb-win32.sourceforge.net/ A Linux version is also available, see http://www.linux-usb.org/ and http://libusb.sourceforge.net/ . Experience will tell us if there are any problems with certain types of USB2 ports.

----

Q. '''Why do we need a "configuration device" when the software can just load the FPGA via USB and the Cypress CY7C68013 (FX2) chip? The schematic shows the programming pins connected from FX2 GPIO pins to FPGA.'''

A. It does load via USB and this is how OZY is normally used. BUT, there will come a time when someone wants to use the OZY without PC attached and the configuraton device allows this possibility.

----

Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''

A. We certainly hope so and expect that some will use it as a learning tool or development platform for other projects not even remotely related to SDR. It provides an inexpensive piece of hardware for many purposes.

----

== JANUS ==

Q. '''Is Janus a "sound card" ?'''

A. NO! The usual meaning of a sound card is one which plugs into a personal computer (ISA, PCI, or other bus). The Janus module plugs into our Atlas bus and contains some of the components of the usual sound card. It also requires the Ozy or similar interface to use it in applications which call for a PC sound card.

----

Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''

A. In theory, Yes! This will require a Windows or Linux driver; there is no reason one can't be written, we just need a volunteer!

----

== MERCURY ==

Q. '''Why are there no input RF filters on the Mercury PCB?'''

A. This is due to the multi-function nature of the Mercury board. Whilst primarily a high performance HF (and VHF/UHF in alias mode) receiver, Mercury can also be used for other functions. For example, it can be used as a high performance 0-55MHz spectrum analyzer, sampling oscilloscope and VNA (by using Penelope as the signal source for the VNA and also as a tracking generator). In these cases it is desirable not to have any RF filtering before the ADC on Mercury.

When used as a receiver the amount of filtering will vary depending on the antenna system the user has. For most situations with say an HF beam or dipoles the natural frequency response of the antenna may provide adequate filtering. For the user with a high performance broadband antenna e.g. a rhombic, or very strong local signals, then additional filtering may be required.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance ADCs to be come available in the future. These newer devices will still require some form of input filtering. By using external filters the cost of replacing the ADC board is reduced.

== PENELOPE ==

Q. '''Why are there no output RF filters on the Penelope PCB?'''

A. This is due to a number of reasons. Firstly, whilst Penelope is primarily an HF ( and VHF/UHF on alias) exciter it can be used for other functions. For example, when used with Mercury it can form a low level signal source as a tracking generator or VNA. For these functions the lack of output filters is an advantage.

Secondly, Penelope generates RF directly at the desired output frequency by synthesizing the required RF waveform using a DAC. The lack of mixers, DDS, frequency synthesizer etc means the output spectrum of Penelope is particularly clean. In fact the spurious output at 0.5w meets the FCC requirements without additional filtering.

Thirdly, Penelope is an exciter. Whilst we expect it will be used by QRP operators as is we also expect it to be used to drive a higher power amplifier. In the latter case the user will most likely provided external filtering as part of this power amplification.

Fourthly, Penelope does provide a 55MHz LPF that can be placed in circuit after the DAC and prior to the 0.5W PA. If desired the user can add external bandpass filters here. Alternatively, the filter can be bypassed and/or an external VHF/UHF filter fitted such that the alias output of the DAC can be used on the higher bands.

Fifthly, if is desirable to use LPFs that may be also be used before Mercury. The IP3 performance of Mercury is very good and using small inductors, that are quite acceptable for removing the harmonics from Penelope, results in a significant degradation in IP3 performance.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance DACs to be come available in the future. These newer devices will still require some form of output filtering. By using external filters the cost of replacing the exciter board is reduced.

== Miscellaneous ==

Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."

General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]

FAQ

2009-05-21T02:31:56Z

WikiSysop: /* Miscellaneous */ Please only use my first name ans callsign.

== The HPSDR Project ==

Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''

A. After searching for an answer and not finding it, usually the best way is to post your question on the HPSDR Discussion List (reflector).
This allows two things to happen: (1) it permits someone other than the very busy developers to answer he question if they can, and (2) it allows everyone on the list to gain the benefit of any reply.

----

Q. '''How do I get in direct email contact with project leaders?'''

A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.

----

Q. '''What is the status of the various boards or modules?'''

A. Here's the scoop on some as of Jaunary 1, 2009:

ATLAS - in production, order through http://tapr.org
PINOCCHIO - in production, order through http://tapr.org
OZY - 1st production run - currently being shipped. Order through http://tapr.org
JANUS - 1st production run - currently being shipped. Order through http://tapr.org
MERCURY - 1st production Order through http://tapr.org
MERCURY-EU - alpha - see DJ8AY
PENELOPE - Sold Out http://tapr.org
ALEX - Pre-production

All others - in various stages of design/development -- see their wiki pages.

----

Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''

A. It is important to remember the goals of HPSDR. All modules are not meant to be combined together to make a “single flavor” HPSDR transceiver. A number of different combinations will be possible (examples: Horton or Mercury for the receiver). How the modules are used and combined are in the hands of the experimenter/builder. Some users may not even wish to make an entire transceiver out of the modules (example: SDR1000 owners who only want to use Atlas, Ozy, and Janus to replace their sound cards).

In the words of Phil Covington, project leader for a number of the modules, “HPSDR was not formed to be a manufacturer of finished Ham Radio equipment. Its primary purpose is to develop a High Performance SDR in a modular fashion by experimentation with various methods.”

If your only goal is to get “on the air” with an SDR transceiver, there may be cheaper and/or easier routes to achieve this goal (Softrock or Flexradio).

If your goal is high performance software defined radio with a “roll your own” mentality, then the HPSDR modules should enable the creation of your own high performance SDR transceiver.

----

Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''

A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.

----

Q. '''Will Ozy and Janus "bare boards" be available?'''

A. Bare boards (not kits of parts) are available through TAPR.

----

Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''

A. A partial kit of harder to obtain parts is being offered for Janus. Potential users may certainly get together for a group buy on other parts needed to complete the boards. There are several reasons for TAPR (or HPSDR) not offering complete kits: (1) being an all-volunteer organization, it would take tremendous manpower to break the parts down to individual kits and package them, (2) there is a very large support problem for kit builders whose boards do not work when completed, and (3) the cost of a kit of parts would be about equal or may exceed the cost of an assembled and tested board.

----

Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''

A. Yes. They are released under the new TAPR open source hardware license called OHL. The board designer may restrict to non-commercial use. The OHL license was finalized and approved in May 2007. See [http://tapr.org/OHL]

----

Q. '''Why not put OZY and JANUS on a single board?'''

A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated
circuit on the Janus board allows a future (and hopefully better) chip to be used on a similar board, but keeping Ozy for the interface
and control. Flexibility is the goal.

----

Q. '''How much better will the Ozy-Janus combination be in terms of performance when used with the SDR-1000 in place of a sound card such as the Delta 44?'''

A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.

----

Q. '''Will a Ozy-Janus-Atlas combination work with my PowerSDR software used for my Flex Radio SDR-1000 in place of a sound card in my PC?'''

A. Yes, that was one of the early goals of the HPSDR group. Phil, VK6APH, did confirm with Gerald and Eric at the Flex-Radio meeting at the Dayton Hamvention 2007 that Ozy/Janus will be fully supported in future releases in their 'mainstream' releases of PowerSDR. Bill, KD5TFD, will be working with Eric from Flex to accomplish this. At this point it is not known exactly when, and what version the support will begin, but it will happen. Direct all questions regarding Janus/Ozy to the HPSDR Discussion List (and NOT the Flex-Radio list), as folks have been doing and admirably responding. The arrangement with Flex-Radio required the donation of a working Ozy/Janus to Flex-Radio and this has been accomplished after TAPR approved the expense.

----

Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''

A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH

----

Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''

A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.

----
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''

A. USB 2.0 is a requirement. Currently, the OS recommendation is WinXP. Windows 2000 is NOT recommended as the USB 2.0 stack on Windows 2000 is just too slow.

At this time, there are no solid recommendations for minimum CPU or RAM that are based on actual testing with HPSDR hardware of how low we can go.

FlexRadio does have Minimum Recommended PC Configurations for systems using the PowerSDR software. Since the HPSDR hardware may use PowerSDR, these specs are probably a good guide to what would be advisable for the HPSDR. FlexRadio's numbers from their website are as follows:

Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater

Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)

----

Q. '''What user name and password do I use to access the HPSDR svn repository?'''

A. None is required for reading the SVN, only required to place something in the repository. The IP address of the repository is shown on the resources page of the main HPSDR.org website.

----

Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''

A. There is a group doing SDR for microwave: [http://uwsdr.berlios.de/ ] Current HPSDR projects could certainly be used as an IF for a transverter, but there is nothing going on with HPSDR that is specifically aimed at microwave.

----

== The HPSDR Wiki ==

Q. '''Do I need to log in?'''

A. Those who contribute by editing the wiki need to have a login.
----
Q. '''How do I get a account? (a login)'''

A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave Larsen]
----
Q. '''What if I find that a correction is needed in the wiki?'''

A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave Larsen]
----

== ATLAS Backplane ==
Q. '''What is the recommended means of powering ATLAS?'''

A. Demeter. Until Demeter is available...

The ATX 20 pin power connector on the Atlas board enables the use of standard PC power supplies. (Please Note: There is no reason that you cannot utilize a non-PC power supply regulated and wired to provide the proper voltages to the 20pin connector. A non-PC power supply could also enable custom current limiting of the voltages going to the 20 pin connector, an advisable setup when testing or prototyping boards plugged into ATLAS. An analog power supply may be an attractive option for users particularly concerned about spurious emissions in the HF band which some low cost PC power supplies may produce.)

If you choose to use an ATX computer power supply care should be taken that the -12V current requirement is met. (Note of warning: some versions of the attractive picoPSU do not provide proper -12V current capacity. Check before you buy.)

As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:

Ozy/Janus
+12v: 200 ma
+5v: 180 ma
-12v: 70 ma

Obviously additional boards connected to the Atlas board will increase these numbers.

Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):

Penelope
+12v: 200 ma
+5v: 300 ma

Mercury
+12v: 200 ma
+5v: 500 ma

Q. '''Will the Atlas be offered assembled?'''

A. Probably not. It is fairly easy to assemble with a very minimal amount of surface mount parts. There are quite a few solder pads due to the 96 pin connectors. If you are not able to do this work yourself, our advice is to ask on the HPSDR Discussion List (reflector) to see if you can pay someone to do the work for you.

----

Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''

A. It is possible, but at least one report indicates problems with the center row on the connectors. If considering doing this, we suggest you ask on the discussion list. If anyone has had success or failure, please report it to the wikisysop so we can update this reply.

----

Q. '''Will a larger (or smaller?) number of slots version be offered?'''

A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).

----

Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''

A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.

== PINOCCHIO Extender ==

Q. '''Availability?'''

A. The bare board and connectors are now available from TAPR http://tapr.org

== OZY ==

Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''

A. A USB 2 connection will be required on the PC. Most modern PCs have this as standard. With MS Windows, for the USB driver we are using the LibUsb-Win32 library which is a free download from http://libusb-win32.sourceforge.net/ A Linux version is also available, see http://www.linux-usb.org/ and http://libusb.sourceforge.net/ . Experience will tell us if there are any problems with certain types of USB2 ports.

----

Q. '''Why do we need a "configuration device" when the software can just load the FPGA via USB and the Cypress CY7C68013 (FX2) chip? The schematic shows the programming pins connected from FX2 GPIO pins to FPGA.'''

A. It does load via USB and this is how OZY is normally used. BUT, there will come a time when someone wants to use the OZY without PC attached and the configuraton device allows this possibility.

----

Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''

A. We certainly hope so and expect that some will use it as a learning tool or development platform for other projects not even remotely related to SDR. It provides an inexpensive piece of hardware for many purposes.

----

== JANUS ==

Q. '''Is Janus a "sound card" ?'''

A. NO! The usual meaning of a sound card is one which plugs into a personal computer (ISA, PCI, or other bus). The Janus module plugs into our Atlas bus and contains some of the components of the usual sound card. It also requires the Ozy or similar interface to use it in applications which call for a PC sound card.

----

Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''

A. In theory, Yes! This will require a Windows or Linux driver; there is no reason one can't be written, we just need a volunteer!

----

== MERCURY ==

Q. '''Why are there no input RF filters on the Mercury PCB?'''

A. This is due to the multi-function nature of the Mercury board. Whilst primarily a high performance HF (and VHF/UHF in alias mode) receiver, Mercury can also be used for other functions. For example, it can be used as a high performance 0-55MHz spectrum analyzer, sampling oscilloscope and VNA (by using Penelope as the signal source for the VNA and also as a tracking generator). In these cases it is desirable not to have any RF filtering before the ADC on Mercury.

When used as a receiver the amount of filtering will vary depending on the antenna system the user has. For most situations with say an HF beam or dipoles the natural frequency response of the antenna may provide adequate filtering. For the user with a high performance broadband antenna e.g. a rhombic, or very strong local signals, then additional filtering may be required.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance ADCs to be come available in the future. These newer devices will still require some form of input filtering. By using external filters the cost of replacing the ADC board is reduced.

== PENELOPE ==

Q. '''Why are there no output RF filters on the Penelope PCB?'''

A. This is due to a number of reasons. Firstly, whilst Penelope is primarily an HF ( and VHF/UHF on alias) exciter it can be used for other functions. For example, when used with Mercury it can form a low level signal source as a tracking generator or VNA. For these functions the lack of output filters is an advantage.

Secondly, Penelope generates RF directly at the desired output frequency by synthesizing the required RF waveform using a DAC. The lack of mixers, DDS, frequency synthesizer etc means the output spectrum of Penelope is particularly clean. In fact the spurious output at 0.5w meets the FCC requirements without additional filtering.

Thirdly, Penelope is an exciter. Whilst we expect it will be used by QRP operators as is we also expect it to be used to drive a higher power amplifier. In the latter case the user will most likely provided external filtering as part of this power amplification.

Fourthly, Penelope does provide a 55MHz LPF that can be placed in circuit after the DAC and prior to the 0.5W PA. If desired the user can add external bandpass filters here. Alternatively, the filter can be bypassed and/or an external VHF/UHF filter fitted such that the alias output of the DAC can be used on the higher bands.

Fifthly, if is desirable to use LPFs that may be also be used before Mercury. The IP3 performance of Mercury is very good and using small inductors, that are quite acceptable for removing the harmonics from Penelope, results in a significant degradation in IP3 performance.

An external set of filters will be provided as part of the Alex project.

Additionally, HPDR is a journey and not a destination! We fully expect higher performance DACs to be come available in the future. These newer devices will still require some form of output filtering. By using external filters the cost of replacing the exciter board is reduced.

== Miscellaneous ==

Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."

General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]

User:WikiSysop

2009-05-18T23:17:15Z

WikiSysop: Who is the sysop?

Dave KV0S

HPSDR enthusiasts, Software side. I program in C, C++, Erlang and Python. I like the Qt4 GUI library.

User:WikiSysop

2009-05-18T23:14:42Z

WikiSysop:

This is Dave KV0S

HPSDR related software

2009-05-18T22:34:27Z

WikiSysop: /* Client Programs */

'''HPSDR related software''' consists of many programs and levels of software.

Each board contains firmware for its particular chips, this is usualy written in [[Verilog]].

The computer linked to the HPSDR hardware contains software to process the I and Q signals for the hardware....

=== Libraries and 'middleware' ===

DttSP - https://www.cgran.org/wiki/DttSP Dsp Library used in many packages.

http://dttsp.org/ looks stale

Dttsp wiki - http://dttsp.org/wiki/index.php?title=Main_Page looks stale

GNU Radio - http://www.gnu.org/software/gnuradio/index.html

=== Client Programs ===

A listing of programs that specifically support the HPSDR hardware:

[[PowerSDR]] running on Microsoft Windows XP.

John G0ORX/N6LYT has developed two programs see: http://javaguifordttsp.blogspot.com/
#a C program with a [http://www.gtk.org/ GTK+] GUI (ghpsdr) running on Linux and Mac OS
#a platform independent Java client (java-sdr), https://java-sdr.dev.java.net/ running on Linux, Mac OS and Windows

CW Skimmer from Alex, VE3NEA has support for Mercury: http://www.dxatlas.com/CwSkimmer/

HPSDR related software

2009-05-18T22:33:47Z

WikiSysop: /* Client Programs */

'''HPSDR related software''' consists of many programs and levels of software.

Each board contains firmware for its particular chips, this is usualy written in [[Verilog]].

The computer linked to the HPSDR hardware contains software to process the I and Q signals for the hardware....

=== Libraries and 'middleware' ===

DttSP - https://www.cgran.org/wiki/DttSP Dsp Library used in many packages.

http://dttsp.org/ looks stale

Dttsp wiki - http://dttsp.org/wiki/index.php?title=Main_Page looks stale

GNU Radio - http://www.gnu.org/software/gnuradio/index.html

=== Client Programs ===

A listing of programs that specifically support the HPSDR hardware:

[[PowerSDR]] running on Microsoft Windows XP.

John G0ORX/N6LYT has developed two programs see: http://javaguifordttsp.blogspot.com/
#a C program with a [http://www.gtk.org/ GTK+ GUI] (ghpsdr) running on Linux and Mac OS
#a platform independent Java client (java-sdr), https://java-sdr.dev.java.net/ running on Linux, Mac OS and Windows

CW Skimmer from Alex, VE3NEA has support for Mercury: http://www.dxatlas.com/CwSkimmer/

HPSDR related software

2009-05-18T22:33:10Z

WikiSysop: added like to GTK webpage

'''HPSDR related software''' consists of many programs and levels of software.

Each board contains firmware for its particular chips, this is usualy written in [[Verilog]].

The computer linked to the HPSDR hardware contains software to process the I and Q signals for the hardware....

=== Libraries and 'middleware' ===

DttSP - https://www.cgran.org/wiki/DttSP Dsp Library used in many packages.

http://dttsp.org/ looks stale

Dttsp wiki - http://dttsp.org/wiki/index.php?title=Main_Page looks stale

GNU Radio - http://www.gnu.org/software/gnuradio/index.html

=== Client Programs ===

A listing of programs that specifically support the HPSDR hardware:

[[PowerSDR]] running on Microsoft Windows XP.

John G0ORX/N6LYT has developed two programs see: http://javaguifordttsp.blogspot.com/
#a C program with a [http://www.gtk.org/ GTK+ GUI] ([[GTK+ Graphic User Interface|ghpsdr]]) running on Linux and Mac OS
#a platform independent Java client (java-sdr), https://java-sdr.dev.java.net/ running on Linux, Mac OS and Windows

CW Skimmer from Alex, VE3NEA has support for Mercury: http://www.dxatlas.com/CwSkimmer/

Talk:HPSDR related software

2009-05-18T20:43:33Z

WikiSysop: /* John's Code */

== John's Code ==

John has two programs "ghpsdr" in C with GTK2 GUI and "java-sdr" in Java. Java-sdr has a webpage for the svn, the ghpsdr uses our HPSDR project svn. (KV0S, May 18, 2009)

Talk:HPSDR related software

2009-05-18T20:43:06Z

WikiSysop: /* John's Code */

== John's Code ==

John has two programs "ghpsdr" in C with GTK2 GUI and "java-sdr" in Java. Java-sdr has a webpage for the svn, the ghpsdr uses our HPSDR project svn KV0S, May 18, 2009

Talk:HPSDR related software

2009-05-18T20:42:36Z

WikiSysop: Note on John's Code

== John's Code ==

John has two programs "ghpsdr" in C with GTK2 GUI and "java-sdr" in Java. Java-sdr has a webpage for the svn, the ghpsdr uses our HPSDR project svn KV0S, May 18, 2009

HPSDR related software

2009-05-18T20:39:05Z

WikiSysop: John has only two programs, Items 2 and 3 your list are the same program

'''HPSDR related software''' consists of many programs and levels of software.

Each board contains firmware for its particular chips, this is usualy written in [[Verilog]].

The computer linked to the HPSDR hardware contains software to process the I and Q signals for the hardware....

=== Libraries and 'middleware' ===

DttSP - https://www.cgran.org/wiki/DttSP Dsp Library used in many packages.

http://dttsp.org/ looks stale

Dttsp wiki - http://dttsp.org/wiki/index.php?title=Main_Page looks stale

GNU Radio - http://www.gnu.org/software/gnuradio/index.html

=== Client Programs ===

A listing of programs that specifically support the HPSDR hardware:

[[PowerSDR]] running on Microsoft Windows XP.

John G0ORX/N6LYT has developed two programs see: http://javaguifordttsp.blogspot.com/
#a C program with a GTK+ GUI ([[GTK+ Graphic User Interface|ghpsdr]]) running on Linux and Mac OS
#a platform independent Java client (java-sdr)
#Java-SDR - https://java-sdr.dev.java.net/ running on Linux, Mac OS and Windows

CW Skimmer from Alex, VE3NEA has support for Mercury: http://www.dxatlas.com/CwSkimmer/

HPSDR related software

2009-05-18T19:39:27Z

WikiSysop: /* Client Programs */

'''HPSDR related software''' consists of many programs and levels of software.

Each board contains firmware for its particular chips, this is usualy written in [[Verilog]].

The computer linked to the HPSDR hardware contains software to process the I and Q signals for the hardware....

=== Libraries and 'middleware' ===

DttSP - https://www.cgran.org/wiki/DttSP Dsp Library used in many packages.

http://dttsp.org/ looks stale

Dttsp wiki - http://dttsp.org/wiki/index.php?title=Main_Page looks stale

GNU Radio - http://www.gnu.org/software/gnuradio/index.html

=== Client Programs ===

A listing of programs that specifically support the HPSDR hardware:

[[PowerSDR]] running on Microsoft Windows XP.

John G0ORX/N6LYT has developed two programs see: http://javaguifordttsp.blogspot.com/
#a C program with a GTK+ GUI ([[GTK+ Graphic User Interface|ghpsdr]]) running on Linux and Mac OS
#a platform independent Java client (java-sdr).

Java-SDR - https://java-sdr.dev.java.net/ running on Linux, Mac OS and Windows by John G0ORX/N6LYT.

CW Skimmer from Alex, VE3NEA has support for Mercury: http://www.dxatlas.com/CwSkimmer/

HPSDR related software

2009-05-18T19:34:16Z

WikiSysop: /* Client Programs */

'''HPSDR related software''' consists of many programs and levels of software.

Each board contains firmware for its particular chips, this is usualy written in [[Verilog]].

The computer linked to the HPSDR hardware contains software to process the I and Q signals for the hardware....

=== Libraries and 'middleware' ===

DttSP - https://www.cgran.org/wiki/DttSP Dsp Library used in many packages.

http://dttsp.org/ looks stale

Dttsp wiki - http://dttsp.org/wiki/index.php?title=Main_Page looks stale

GNU Radio - http://www.gnu.org/software/gnuradio/index.html

=== Client Programs ===

A listing of programs that specifically support the HPSDR hardware:

[[PowerSDR]] running on Microsoft Windows XP.

John Melton has developed two programs see: http://javaguifordttsp.blogspot.com/
#a C program with a GTK+ GUI ([[GTK+ Graphic User Interface|ghpsdr]]) running on Linux and Mac OS
#a platform independent Java client (java-sdr).

Java-SDR - https://java-sdr.dev.java.net/ running on Linux, Mac OS and Windows.

CW Skimmer from VE3NEA has support for Mercury: http://www.dxatlas.com/CwSkimmer/

User talk:VK2NRA

2009-05-18T13:21:10Z

WikiSysop: /* John Melton's Code */

==Welcome==

Please feel free to leave messages for me here. Click on the plus (+) tab above to create a new section.[[User:VK2NRA|VK2NRA]] 12:28, 3 May 2009 (UTC)

== Away ==

I will be away for four days attending a wedding.... wiki-break. Regards, [[User:VK2NRA|Richard Ames, VK2NRA]] 20:40, 13 May 2009 (UTC)

== John Melton's Code ==

Yes John talks about the two GUIs but the main sources for the Java GUI is the line below. The Blog is the only discussion of the GTK GUI and he has been working on the GUI only for about 6 months. The GTK GUI does not use any Java the line we had made it sound like the C program talked to the Java GUI, its two separate programs.

User talk:VK2NRA

2009-05-18T13:18:39Z

WikiSysop:

==Welcome==

Please feel free to leave messages for me here. Click on the plus (+) tab above to create a new section.[[User:VK2NRA|VK2NRA]] 12:28, 3 May 2009 (UTC)

== Away ==

I will be away for four days attending a wedding.... wiki-break. Regards, [[User:VK2NRA|Richard Ames, VK2NRA]] 20:40, 13 May 2009 (UTC)

== John Melton's Code ==

Yes John talks about the two Gui but the main sources for the Java GUI is the line below. The Blog is the only discussion of the GTK GUI and he has been working on the GUI only for about 6 months.

HPSDR related software

2009-05-18T13:14:56Z

WikiSysop: /* Client Programs */

'''HPSDR related software''' consists of many programs and levels of software.

Each board contains firmware for its particular chips, this is usualy written in [[Verilog]].

The computer linked to the HPSDR hardware contains software to process the I and Q signals for the hardware....

=== Libraries and 'middleware' ===

DttSP - https://www.cgran.org/wiki/DttSP Dsp Library used in many packages.

http://dttsp.org/ looks stale

Dttsp wiki - http://dttsp.org/wiki/index.php?title=Main_Page looks stale

GNU Radio - http://www.gnu.org/software/gnuradio/index.html

=== Client Programs ===

A listing of programs that specifically support the HPSDR hardware:

[[PowerSDR]] running on Microsoft Windows XP.

A C program with a GTK+ GUI ([[GTK+ Graphic User Interface|ghpsdr]]) running on Linux and Mac OS. see: http://javaguifordttsp.blogspot.com/

Java-SDR - https://java-sdr.dev.java.net/ running on Linux, Mac OS and Windows.

CW Skimmer from VE3NEA has support for Mercury: http://www.dxatlas.com/CwSkimmer/

HPSDR related software

2009-05-18T13:14:08Z

WikiSysop: /* Client Programs */

'''HPSDR related software''' consists of many programs and levels of software.

Each board contains firmware for its particular chips, this is usualy written in [[Verilog]].

The computer linked to the HPSDR hardware contains software to process the I and Q signals for the hardware....

=== Libraries and 'middleware' ===

DttSP - https://www.cgran.org/wiki/DttSP Dsp Library used in many packages.

http://dttsp.org/ looks stale

Dttsp wiki - http://dttsp.org/wiki/index.php?title=Main_Page looks stale

GNU Radio - http://www.gnu.org/software/gnuradio/index.html

=== Client Programs ===

A listing of programs that specifically support the HPSDR hardware:

[[PowerSDR]] running on Microsoft Windows XP.

A Java GUI and a C program with a GTK+ GUI ([[GTK+ Graphic User Interface|ghpsdr]]) running on Linux and Mac OS. see: http://javaguifordttsp.blogspot.com/

Java-SDR - https://java-sdr.dev.java.net/ running on Linux, Mac OS and Windows.

CW Skimmer from VE3NEA has support for Mercury: http://www.dxatlas.com/CwSkimmer/

Main Page

2009-05-18T13:08:13Z

WikiSysop: Unprotected "Main Page": To allow VK2NRA edit permission

== '''The [http://openhpsdr.org HPSDR] (High Performance Software Defined Radio) Wiki''' ==

== [http://openhpsdr.org HDSDR Project] Overview ==

=== Introduction -- What's It All About? ===

The HPSDR is an open source (GNU type) hardware and software project intended as a "next generation" Software Defined Radio (SDR) for use by Radio Amateurs ("hams") and Short Wave Listeners (SWLs). It is being designed and developed by a group of SDR enthusiasts with representation from interested experimenters worldwide. The discussion list membership currently stands at over 900 and includes such SDR enthusiasts as Ray Anderson WB6TPU, Steve Bible N7HPR, Phil Covington N8VB, Rick Hambly W2GPS, Phil Harman VK6APH, Lyle Johnson KK7P, Ulrich Rohde N1UL, and Bill Tracey KD5TFD to name a few.

The rationale behind the project is to break the overall design up into a number of modules. Each module is designed by an individual or group and connects to other modules using a pre-defined and common bus -- rather like plugging boards into a PC motherboard.

This modular approach enables users to incorporate just the modules that interest them as well as designing their own variants if desired. The approach also enables new ideas and circuits to be tested by replacing an existing module. Since the majority of modules will be retained, such experimentation can be done with minimum disruption to an existing working system.

The modules vary in complexity from simple bandpass filters and input/output interfaces, to full blown DSP functions. Such variety enables experimenters with varying degrees of experience to contribute. If you wish to contribute your skills to this project, the best way is to advise your availability on the discussion list and communicate with project leaders -- or if you have a proposal for a new module, fly it on the discussion list and if feasible, become a project leader!

The modules have each been named for easier identification when talking or writing about them. On this wiki, each module has its own page, as noted by the links below. Some of the modules are being designed so that they can be either used in conjunction with others or stand-alone. Each module board size (except the backplane) will be 100 mm by 120 to 220 mm and use either a 64 pin or 96 pin DIN41612 type connector.

== HPSDR History and Philosophy ==

The High Performance SDR project was started in October, 2005
by Phil Covington (N8VB) as the Open_High_Performance_SDR @ Yahoo group. In
November, 2005 another small group, based on the Xylo board
product (an FPGA experimenter's board) with SDR applications in
mind, evolved and the Xylo-SDR discussion list was formed. On
March 1, 2006 the two groups merged to form HPSDR and the two
discussion lists were replaced with the present HPSDR list.

Initially a small group of developers, HPSDR has grown to over
800 members, including hardware, software and firmware
developers; system architects; analog and digital designers; RF
engineers; planners, executers and users; testers, documenters
and technicians; bank presidents and sanitation engineers. While
the last two are dubious, the point is that HPSDR is a diverse
group. Everyone has something to contribute and all are
encouraged to participate.

The rationale behind HPSDR is to break the overall design up into
a number of modules. Each module is designed by an individual or
group and connects to other modules using a pre-defined and
common bus -- rather like plugging boards into a PC motherboard.

This modular approach enables prospective users to incorporate
just the modules that interest them as well as designing their own
variants if desired. The approach also enables new ideas and
circuits to be tested by replacing an existing module. Since the
majority of modules will be retained, such experimentation can be
done with minimum disruption to an existing, working system.

The modules vary in complexity from simple band-pass filters and
input/output interfaces to full blown DSP functions. Such variety
enables experimenters with varying degrees of experience to
contribute. If you are interested in contributing, you are invited to
join in new or ongoing design, development and documentation
efforts.

The modules have each been named for easier identification when
talking or writing about them. On the HPSDR website, each module
has its own web page. Some of the modules are being designed
so that they can be either used in conjunction with others or standalone.
Each module board size (except the Atlas backplane) is
typically 100mm by 120mm (optionally up to 220mm) and uses
either a 64 pin or 96 pin DIN41612 type connector.
=== Milestone ===

[[image:MOPA1.jpg|thumb|400px|Mile Stone Radio]]

Here is a photo of a complete Digital Up Conversion/Digital Down Conversion HPSDR transceiver by Phil Harman, VK6APH. The modules are, from left to right - prototype Mercury DDC based on an LT2208 evaluation board and Ozy board - V2 Penelope DUC - Ozy controller board - all sitting on the Atlas bus. Phil had the first QSO (2-way radio contact for the non-hams amongst us) with this on 7 October 2007 which coincided with his 40th anniversary of getting a Ham license!

=== Block Diagram ===

Here is a block diagram showing the Janus, Ozy, Mercury and Sasquatch modules and their functions.
[[image:HPSDR_Block_10_Dec_2006.jpg|thumb|400px|]]

=== Module/Board Availability ===

Completely assembled and tested, parts kits, and/or bare boards may be available for each of the HPSDR projects on a limited basis. See the FAQ section or individual wiki pages for what is available at the present time. Generally, the boards, kits, or assemblies will be available for purchase through TAPR [http://tapr.org] and an indication of pre-production interest is gaged by a sign-up process located
at website http://www.hamsdr.com where one must register, log in, and use the "Projects" tab to get to any list.

=== Future Modules ===

In order to provide a complete SDR transceiver other modules will be required. These include bandpass filters, a narrow band I/Q down converter to supplement the Mercury A/D converter, and low power transmitter functions etc.

There is still much to be done in bringing the HPSDR project to fruition. For those experimentally minded Amateurs, this may turn out to be the golden age of (software defined) radio!

=== Open source design ===

'''Brief definition of Open Source'''

In a "nutshell", open source is a term that is applied to a philosophy, in that the production and organization of a project or system is created through open and cooperative efforts.

Open source software refers to computer software available with its source code and under an "open source license" to study, change and improve its design and functionality.

There are many "Open source software" licenses, the most prominent being the GNU General Public License (GNU GPL or simply GPL), originally written by Richard Stallman. The GPL grants the recipients of a computer program the following rights, or freedoms:

* The freedom to run the program, for any purpose. 
* The freedom to study how the program works, and modify it. 
* The freedom to redistribute copies. 
* The freedom to improve the program, and release 
the improvements to the public. 

The users are treated like co-developers, are encouraged to submit additions to the software, code fixes, bug reports, documentation etc. Having more co-developers increases the rate at which the software evolves. Furthermore, each end user's machine provides an additional testing environment. This new testing environment offers the ability to find and fix a new bug quickly.

[Note: this definition does not go into the various obligations and legalities and is intended to be brief and non-exhaustive. The original was supplied by Kevin, M0KHZ and modified by the WikiSysOp.]

This GPL philosophy extends to the hardware for this HPSDR cooperative project. However it was felt by many that the software GPL and similar licenses would not adequately cover the hardware portion of this project, so an Open Hardware License (OHL) was devised. Also, another license referred to as the NCL - Non-Commercial License, was implemented to take care of situation where the project developers wish to reserve commercial licensing rights. The complete text of the two versions of the OHL/NCL licenses along with some explanation may be found on the TAPR website at http://www.tapr.org/ohl.html

=== TAPR Affiliation ===

In early June (2006) it was announced that agreement had been reached with TAPR http://tapr.org for TAPR to provide assistance and a "storefront" for the "products" of the HPSDR group. TAPR has a long history of supporting various digital amateur radio related ventures. We would encourage our members to become TAPR members, not only to support a worthy organization, but also to receive a member discount (usually around 10%) on their HPSDR and other purchases from them.

Assistance in project development is in the form of partial funding for alpha and beta runs of boards upon application to and approval by TAPR's Board of Directors, and then in guiding the manufacturing process. It is not the intention of TAPR to profit from providing this assistance or the manufacture of projects.

It should be emphasized that TAPR and HPSDR are independent organizations or communities and that any TAPR reproduction of HPSDR developed projects is through licensing agreements.

TAPR will be most likely the only source for HPSDR boards due to short runs and the investment required. This does not preclude '''individuals''' having their '''own''' PCB boards made in keeping with the open-source philosophy. Commercial reproduction may be restricted depending on the license granted by the board developers. Visit the TAPR website http://tapr.org for current availability.

=== AMSAT Affiliation ===

In July (2006) the following announcement was made by Rick Hambly W2GPS, AMSAT President:

AMSAT will immediately initiate support for The High Performance Software
Defined Radio (HPSDR) project, an independent team that is dedicated to
bringing high performance software defined radio devices within the reach of
amateurs in terms of access to the hardware and software and at manageable
prices.

This is a rare opportunity for AMSAT to easily join a major technological
development and have a positive impact on both that development and AMSAT's
own primary interests. The High Performance Software Defined Radio (HPSDR)
project is a completely open source software (GNU Public License) and open
hardware design. It has an extremely capable group of core designers, many
of whom are also key AMSAT design team members, supported by a cast of
hundreds.

AMSAT will support HPSDR with a modest amount of financial, personnel and
other resources. Financial resources will be under AMSAT control and will be
used to support activities such as joint HPSDR and Eagle design meetings.
AMSAT's Engineering team will submit a 2007 budget for the AMSAT Board's
approval at the annual meeting in October. The modest resources that are
needed in 2006 can be provided by the Eagle team project.

=== Resources ===

== Our Internet Resources ==

Please be aware that we have a website with pages devoted to each sub-project plus other information and resources. The website will not necessarily contain the latest information (that's the reason we have this wiki) but is a good starting place for a little less technical overview of the project and its parts. The website is at http://openhpsdr.org -- and the website also contains other information and links to many other references and resources of interest to the topics of Software Defined Radio, FPGA's, etc.

'''''For the very latest scoop, join the HPSDR discussion list (reflector). You'll find information on the http://openhpsdr.org/reflector.html webpage on how to subscribe to this email list.'''''

We now also offer an alternative notification list (an announcement list) for those potential users not wanting the daily discussion list traffic. Information on this HPSDR-announce list may also be found on the http://openhpsdr.org/reflector.html webpage.

Additional information can be found on the [http://openhpsdr.org/resources.html Resources] webpage this page has link to the relevant software being used for could be used with HPSDR boards and the [http://openhpsdr.org/support.html Support] webpage has schematic and production documents for the boards that have been produced.

TAPR/HPSDR ordering page: http://tapr.org/products.html

== Wiki Sysop ==

Please contact KV0S (the "Wiki Sysop") for information or help. Contact may be
made via email: "kv0s" at "openhpsdr" dot "org".

All who wish to edit this Wiki must be authorized by the Sysop.
This is done to prevent vandalism of our wiki.
To obtain a log in account, please email the Sysop with a request.

Do not submit copyrighted work without permission. All submittals, unless otherwise
arranged will be considered in public domain.

== Go to the [[HPSDRWiki:Community Portal|Community Portal]] for project information ==

HPSDRwiki:Community Portal

2009-05-18T13:07:31Z

WikiSysop: Unprotected "HPSDRwiki:Community Portal": To allow VK2NRA edit permission

__NOTOC__

== [[FAQ]] - Frequently Asked Questions ==

This is a new section started to allow asking and hopefully answering questions about HPSDR.

== [[DOC]] - Documentation ==

Summary of current documentation available.

=== [[Quick Startup Guide]] ===

Documents to help users get HPSDR setup and working.

=== [http://openhpsdr.org/support.html Support documentation] ===

Documents for user interested in building boards can be found on the [http://openhpsdr.org/support.html Support] page.

=== [http://openhpsdr.org/wiki/index.php?title=HPSDR_related_software Software links] ===

Links to HPSDR software and resources can be found on the [http://openhpsdr.org/resources.html Resource] page.

Links to the FPGA programming course by Kirk, KD7IRS -- [http://openhpsdr.org/wiki/index.php?title=Verilog Verilog] webpage.

== [[DOWNLOADS]] - Firmware and Software ==

Links to current firmware and software available.

== [[SYSTEM INTEGRATION]] ==

This section contains information relative to "putting the pieces together".

----

== Individual Project Wiki Pages ==

Click on the NAME of the project to get to its page!

=== [[ALEXIARES]] - RF Preselector ===

Alexiares (or Alex for short) is a set of RF Bandpass filters for use with Mercury or any other SDR.

=== [[ANICETUS]] (Anie) - Preselector ===

A few designs for narrow band preselectors

=== [[ATLAS]] - Backplane ===

The Atlas is a passive backplane that all other modules plug into.

=== [[CYCLOPS]] - Spectrum Analyzer ===

Cyclops is a 0-1 GHz spectrum analyzer with tracking generator support.

=== [[DEMETER]] - Power Supply ===

=== [[EPIMETHEUS]] - General Purpose I/O ===

Epi is a general purpose I/O board for the Atlas bus and includes relays, open collectors, IF switching, etc.

=== [[EXCALIBUR]] - Clock Reference board ===

=== [[GIBRALTAR]] - GPS-disciplined Frequency Standard ===

Gibraltar is a GPS-disciplined frequency standard board.

=== [[HELIOS]] - Helios Small Transmitting Loop Antenna and Controller ===

=== [[HERMES]] - A DUC/DDC Transceiver. ===

=== [[HORTON]] - Receiver Module ===

A receiver module integrating the Janus ADC with a QSD on a board for a version of the HPSDR RX board.

=== [[JANUS]] - ADC/DAC Board ===

The Janus module is a very high performance, dual, full duplex, A/D and D/A converter board.

=== [[LPU]] - Simple Linear Power Unit ===

The LPU unit takes power from a regulated power supply and steps it to the input needed by Atlas

=== [[MERCURY]] - 0-55 MHz Direct Sampling Receiver ===

Perhaps the most exciting of all modules, Mercury will enable direct sampling of the 0-55 MHz spectrum.

=== [[ODYSSEY]] - Low Power Handheld SDR ===

Odyssey includes a low power SDR based on the QSD, QSE, and a dsPIC33 as the basic radio core.

=== [[OZY]] - HPSDR Host Interface & Control ===

The OZY module is an FPGA based interface controller card providing input and output connections to the real world.

=== [[OZYII]] - (AussieII) - A high speed PC interface. ===

=== [[PANDORA]] - Enclosure ===

=== [[PENELOPE]] - Companion Exciter to Mercury ===

A 1/2 watt DUC(k).

=== [[PENNYWHISTLE]] - 20 Watt RF Power Ampilfier ===

The PennyWhistle takes the RF out put of Penelope and ampilifes it to approximately 20 watts.

=== [[PHOENIX]] - QSD/QSE Receiver/Transmitter Module ===

QSD based HF Receiver, a QSE based HF Exciter and a supporting synthesizer.

=== [[PINOCCHIO]] - Extender Card ===

Pinocchio is an extender card to allow measurements and troubleshooting of an active card in an ATLAS backplane.

=== [[PROTEUS]] - Prototyping Board ===

This is the planned prototyping board.

=== [[SASQUATCH]] - DSP back-end ===

The Sasquatch board is a hardware DSP back-end intended for use by constructors who would like to operate
stand-alone rather than attached to a PC.

=== [[THOR]] - High Efficiency HF Power Amplifier ===

Thor is a high efficiency HF power amplifier using Envelope Elimination and Restoration (ERR) techniques.

== [[Board Designer's Resources]] ==

== [[ANCILLARY]] - Additional "stuff" of interest to HPSDR ==
Some stuff like Norton Amplifier, FPGA VHDL/Verilog ...

== [[EXPERIMENTERS-CORNER]] - Ideas not yet projects ==

== [[ADMINISTRATION-NEWS]] - Messages about HPSDR web, wiki, discussion list ==

PHOENIX

2009-05-17T15:51:48Z

WikiSysop: /* GENERAL DESCRIPTION */

'''PHOENIX - is a ISD/QSE Receiver/Transmitter Module'''

Update 16 November 2008: A variant of the original Phoenix idea has been produced by Richard VK6BRO. This is based in the original concept by Ray, WB6TPU, and includes a QSD based receiver, QSE based exciter and AD9912 DDS local oscillator.

A number of Alpha builders are currently constructing boards; these include Al, N0TVJ, Bill, KD5TFD, Kevin, M0KHZ and Phil, VK6APH.

The builders are indebted to VK6BRO for donating the PCBs and in particular N0TVJ for the donation of components and the fantastic job he did of kitting them.

[[Image:Phoenix.JPG|thumb|500px|VK6APH's partly completed Phoenix board, November 2008]]

This has the QSD receiver and QSE exciter both built and working plus the AD9912 DDS chip and associated components ready for testing. Preliminary CPLD code has been written by Phil, VK6APH, that enables testing of the major sections of the PCB.

Relevant files for the Phoenix project can be found under SVN at the following location:

svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/Phoenix

[[Image:First_Phoenix_Signal.JPG|thumb|500px|VK6APH's Alpha Phoenix board feeding a Janus sound card and running with PowerSDR, November 2008 ]]

More test results to follow - Phil....VK6APH

The Phoenix PCB contains a ISD (Integrating Sampling Detector) based HF Receiver, a QSE (Quadrature Sampling Exciter) based HF Exciter and a supporting synthesizer.



=== GENERAL DESCRIPTION ===

The initial project leader was Ray Anderson, WB6TPU

The Phoenix board is envisioned to contain a receiver, a transmitter and a synthesizer on a single HPSDR (High Performance software Defined Radio) plug-in module. One of the goals is to develop a board that will enable a user to get 'on the air' with a minimal amount of extra add-ons. Currently the plan is to realize the receiver as a QSD based device and the transmitter as a similar QSE. The local oscillator will be supplied by an on-board synthesizer with an onboard reference oscillator (but with provisions for accepting an external reference if desired).

Phoenix will leverage a lot of the lessons learned in SDR (Software Defined Radio) hardware from thoughout the SDR community, hence the name 'Phoenix'. It will be a re-birth of proven circuit concepts in the HPSDR format. The Phoenix board will be an alternative choice to Horton and Mercury as a means of implementing the RF receive and transmit functions. Compared to those projects it will be 'low-end' as far as complexity goes, but definitely not low-performance. Further details will be provided as they emerge....

Inital Block diagram for discussion:

The following diagram illustrates a concept where the AK5394a A/D is colocated on the same PCB physically adjacent to the ISD as suggested by Bob N4HY to minimize the spurious pickup between the ISD and the A/D: This approach has been discarded (i.e. having the AK5394a A/D on the Phoenix board. It makes more sense to utilize the full functionality of the Janus board)

[[Image:phoenix_simplified_block2.jpg]]

The following diagram illustrates an alternate architecture proposed by Phil VK6APH where the output from the ISD is converted to a low impedance balanced signal for transport to the balanced inputs on the Janus board. This would have the advantage of minimizing the complexity on the Phoenix board by not requiring the majority of the Janus parts to reside on Phoenix. This is somewhat like the initial Phoenix concept. After further study it appears that this is the basic architecture that will be pursued for the Phoenix board.

[[Image:phoenix_simplified_block4.jpg]]

Aug. 11, 2006The following simplified schematic illustrates the architecture being pursued. Details on front-end filtering, switching, the pre-amp and the LO synthesizer are not shown at this time. Many component values are not shown and those that are are subject to change.

[[Image:Phoenix_rx_1.jpg]]

Feature List for Discussion:

There have already been a number of good suggestions made on the reflector since this project was proposed related to various aspects of the design. The following is a list (in no particular order) of some of the suggested features/circuits:

Synthesizer:

Utilize AD9951 with a divide by 4 to generate quadrature LO signals
Utilize 2 AD9951 with phase offset
Microwave PLL divided down to HF

(as a general thing, suggestions are running towards avoiding 10-bit DDS circuits due to spurious considerations)

Preamp:

A robust high dynamic range low noise preamp has been suggested to precede the detector. Suggestions include:

Norton amplifier (noiseless feedback) amplifier using BFG591
Makhinson amplifier (push-pull version of Norton amp)

Rx Filters:

Switched BPF filters
Broadband (0-30 MHz) frontend with external BPF

QSD: It is looking like either a 74auc2g53 with OPA1632 or LT1127 amps may end up being the ISD (integrating sampling detector).

The OPA1632 variant is being evaluated by Ahti OH2RZ and the LT1127 variant is being looked at by Phil N8VB.

This is a critical part of the circuit as far as overall performance is concerned.

'''Jan 2008 (Richard Hosking VK6BRO)'''

I have been working over the last 2 months or so on a schematic and PCB layout for Phoenix broadly based on the comments above.
I have used the AD9912 DDS, a CPLD to allow flexibility and mapping to the Atlas Bus and QSD/QSE based on the 74auc2g53 mixer and OPA1632 differential output opamp. Drafting has been done using the Kicad Open Source package running on Kubuntu Linux.
Note that this work is copyright to me (Richard Hosking VK6BRO) until I sort out the process of assigning it for Open Source Use - this is my intention.

Look at the various schematics at

[[Schematics]]

and the current PCB layouts are at

[[Layouts]]

Please contact me if you want to play with Kicad for the various libraries