http://openhpsdr.org/wiki/api.php?action=feedcontributions&user=VK2NRA&feedformat=atomHPSDRwiki - User contributions [en]2024-03-19T01:53:53ZUser contributionsMediaWiki 1.26.0http://openhpsdr.org/wiki/index.php?title=AGC_Tests&diff=3970AGC Tests2011-02-13T21:11:10Z<p>VK2NRA: rem section heads</p>
<hr />
<div>Pete W6XX has conducted an number of of tests on the PowerSDR AGC. These test have been repeated on both the HPSDR hardware and Flex Radios.<br />
<br />
Here is the a PDF of the report [[media:HPSDR AGC-R5.pdf|HPSDR AGC Test document]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=How_to_use_SVN&diff=3939How to use SVN2011-01-06T23:56:13Z<p>VK2NRA: /* Our SVN repository */ fix error</p>
<hr />
<div>Most of the HPSDR [[HPSDR related software|software]] repositories are managed by '''Subversion''', which is a popular collaborative software/firmware development tool for open-source projects. This is a code database repository that is developed with all copies of all code that has been checked in by developers. With a system like this you can go back and check out any previous version of the the software. Wikipedia has an overview of SVN at [http://en.wikipedia.org/wiki/Svn_(software) http://en.wikipedia.org/wiki/Svn_(software)]. <br />
<br />
To access this software you will need to install and use a Subversion (SVN) client. There are several clients listed at the above Wikipedia page. Some of our users have found TortoiseSVN for Windows XP easy to use; it can be downloaded from: [http://tortoisesvn.net/ http://tortoisesvn.net/]. The Tortoise documentation is at [http://tortoisesvn.net/support http://tortoisesvn.net/support] or can be accessed by pressing the F1 key in any Tortoise dialog box.<br />
<br />
A free book on subversion is available at: http://svnbook.red-bean.com/<br />
<br />
==Downloading with TortoiseSVN==<br />
<br />
This is meant to be a simplified procedure to use the Windows SVN client 'TortoiseSVN'.<br />
<br />
*You have TortoiseSVN installed and working.<br />
<br />
*Create a new empty directory, Give it a name appropriate to the item(s) you are downloading.<br />
<br />
*Go to that empty directory, right click in the empty directory and from the menu choices choose 'SVN Checkout'. Enter the svn address of the item you want in the box titled 'URL of repository:'. A typical entry would be:<br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
*Click OK.<br />
<br />
It should download all the data into the directory.....<br />
<br />
== Our SVN repository ==<br />
<br />
The open HPSDR project maintains a SVN for the the members of the project. The top address of the repository is: <br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk<br />
<br />
'''Please do not try to check out the entire SVN it is over 2.5 GB'''. Because of problems the root is no longer browsable. The following directories are under the trunk and are browsable.<br />
<br />
Code is not generally erased from a repository. So many of the some of the directories are very active and may change daily other may have not changes in years. Check the dates on the files to determine when tey were lats updated. Your SVN program will help you keep a up to date copy of the code on your computer and you can easily update the directory with a single command. <br />
<br />
The repository evolves over time so the organization is not usually for the new viewer but for those that post code. To help people find things here is an index of major folders. Several directories were not included in this list as they are empty.<br />
<br />
==SVN Directories==<br />
<br />
====AE6VK====<br />
Chris Day's on OzyJanus to be used with SDR1000 from 2007<br />
====Atlas====<br />
Reference files of the the [[ATLAS]] connections to other boards<br />
====CyclopsII====<br />
Verilog and C# code for [[CYCLOPS]]<br />
====Documentation====<br />
USB '''HPSDR''' protocol definitions, [[ATLAS|Atlas]] buss pin definitions<br />
<br />
====I2PHD====<br />
Code by Alberto DiBene for HPSDR Winrad<br />
====Janus-CPLDV2====<br />
Verilog code for Janus Version 2<br />
====Janus-CPLDV3====<br />
Verliog code for Janus Version 3<br />
====K5FR====<br />
Steve Nance's C# code for DDUtil<br />
====KA6S====<br />
Steve Wilson's code for verilog code for i2c simulation<br />
====KD5TFD====<br />
Bill Tracey's utility code for testing a large number of interfaces.<br />
====Mercury====<br />
Latest version of the Mercury verilog code<br />
====N4HY====<br />
Bob McGwier's proposal and Documents of Horton and Odyssey<br />
====N6LYT====<br />
John Melton's code for [[ghpsdr]] (single machine no server) and [[ghpsdr3]] (multiple receiver multi machine) code build for Linux systems. Uses DttSP, FFTw3, libusb1.0 and gtk+.<br />
====N8VB====<br />
Phil Covington's code for MercScope, Ozy V1, and SharpDSP<br />
====OZY2-test====<br />
C and Verilog code for test Ozy2<br />
====Ozy V1.2====<br />
First version of the Ozy verilog code<br />
====Ozy V1.4====<br />
First version of the Ozy verilog code<br />
====Ozy V1.5====<br />
First version of the Ozy verilog code<br />
====Ozy V1.6====<br />
First version of the Ozy verilog code<br />
====Ozy V1.7====<br />
First version of the Ozy verilog code<br />
====OzyFX2====<br />
C# code to talk with FX2<br />
<br />
====OzyII====<br />
C and Verilog code for Ozy II<br />
====OzyJanus-Jack====<br />
C code to allow powerSDR to talk to SDR1000 through [[JANUS]] and Jack<br />
====Ozy-JanusV2====<br />
Verilog code for Ozy-Janus from 2006<br />
====OzyUtil-NativeWin====<br />
C code to initalize Ozy on a Windows system<br />
====OzyV2-JanusV2====<br />
Verilog code for Ozy-Janus based on new [[OZY]] code.<br />
====Penelope====<br />
Latest version verilog code for [[PENELOPE]].<br />
====Phoenix====<br />
Verilog code and documentation for [[PHOENIX]].<br />
====PowerSDR-ForJanusOzy-LatestReleaseBinaries====<br />
PowerSDR files from 2007, PowerSDR code for HPSDR is on the Flex SVN<br />
====ProjectDiagrams====<br />
Diagrams for Atlas and Janus from 2006<br />
====VE3NEA====<br />
Alex Shovkoplyas's verilog and firmware code for HPSDR<br />
====VK6APH====<br />
Phil Harmon's verilog and C# code for various projects<br />
====vu3rdd====<br />
Ramakrishnan Muthukrishnan's code to the USB-Blaster using an Ozy board.<br />
====W1BW====<br />
Verilog code for Mercury 3.0 and Ozy 1.8 Multi-receiver code<br />
====WA2DFI====<br />
Scotty Cowling information of the code loaded in to production boards.<br />
====WD5Y====<br />
Joe Torrey's code fro PowerSDR using portAudio<br />
<br />
[[Category:Developer resources]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=WinUSB_Notes&diff=3938WinUSB Notes2011-01-06T23:40:13Z<p>VK2NRA: /* Other interesting projects and info on WinUSB */ URL vs IP</p>
<hr />
<div><blockquote><br />
'''THIS MATERIAL SHOULD BE CONSIDERED AS OBSOLETE, BUT INFORMATIVE''' <br><br />
'''THAT IS BECAUSE libusb0 HAS BEEN PUBLISHED BY openhpsdr.org AS A SIGNED DRIVER''' <br><br />
'''PLEASE SEARCH THE FORUM'S ARCHIVES FOR MORE INFORMATION ON THE TOPIC OF LIBUSB0''' <br><br />
</blockquote><br />
<br />
Here are the signed libusb0 drivers:<br />
<br />
svn://svn.openhpsdr.org/svn/repos_hpsdr_kiss/branches/K9TRV/libusb0-driver-signed<br />
<br />
Please see my listserver posting on 12 May 2010 in the archives...<br />
<br />
<blockquote><br />
'''BECAUSE OF THIS, I HAVE STOPPED ANY MAINTENANCE ON THE WinUSB version of KISS'''<br />
</blockquote><br />
<br />
''Update, 28 July 2010, George Byrkit, K9TRV'' <br />
<br />
This page contains information on using WinUSB with HPSDR hardware.<br />
<br />
First, let's all be clear that WinUSB used as a driver replaces libusb0 used as a driver for some particular device, like the Ozy board. If you install WinUSB as the driver for Ozy, libusb0 is no longer the driver. So applications that use libusb0 (like PowerSDR, until Bill Tracey KD5TFD finished porting [[PowerSDR]] to WinUSB, or like [http://www.dxatlas.com/CwSkimmer/ CWSkimmer], which use libusb0 to speak to [[OZY]]) are not able to coexist with my branch of KISS. My branch of [[KISS Konsole]] uses WinUSB.<br />
<br />
So it's an either/or proposition. If you need libusb0, and can install libusb0 as the driver, and can run [[PowerSDR]], you want to use Phil VK6APH's branch of [[KISS Konsole]]. His branch is the 'original', and is considered to be the main development branch. I try to keep step with his branch, and feed common bugs and hopefully their solutions back to him. I'm keeping step best as I can with Phil's development work using the [[HERMES]] board, as well.<br />
<br />
It seems that WinUSB is needed to use KISS (thus my branch is needed...) on Windows 64 bit OS versions, such as Vista 64 bit and Windows 7, 64 bit. Some have reported trouble using libusb0-based KISS on Windows 7 32 bit. These people report that my WinUSB branch does work fine on Windows 7, 32 bit (with WinUSB installed as the driver). This problem on 32 bit Vista and 32 bit Windows 7 has recently (approx 15 Jan 2010) traced to a problem in HPSDR_USB_LIB_V1.dll by Bill Tracey (KD5TFD), who has fixed this problem! He has mentioned this on the reflector (hpsdr mailing list), and has posted a fixed library. Phil is testing and updating his development branch to include this fixed file. Those of you using Vista 32 bit and Windows 7 32 bit may well wish to use that version and not my WinUSB version! That way, you can use both PowerSDR and KISS, and optionally use [http://www.dxatlas.com/CwSkimmer/ CWSkimmer] and other similar applications.<br />
<br />
Is there anything that WinUSB can do that libusb0 cannot do, other than work on a 64 bit machine? It seems that, yes, there is at least one advantage to WinUSB. WinUSB is able to detect an [[OZY]] or [[HERMES]] board that is plugged in or powered on AFTER KISS has been launched. Libusb0 required that Ozy be plugged in and powered on BEFORE launching/running KISS (or PowerSDR). So this is an advantage. Is there any disadvantage? I think that yes, there is. I don't have data to back it up, but libusb0 seems more 'performant' than WinUSB. What do I mean by that? I think that libusb0 has fewer delays and may use a larger blocksize for transfers than WinUSB does. What is the evidence? KISS using libusb0 has no troubles doing the normal (band) spectrum display, along with the full bandwidth display. I found that I had to reduce the number of data points (samples) for the full spectrum display from 8192 to 4096, to get rid of distorted, chopped audio. I think that Alberto came to the same conclusion.<br />
<br />
====WinRad origins====<br />
<br />
The first thing that you will need is the WinUSB driver package from Alberto, I2PHD, from www.weaksignals.com. [http://www.weaksignals.com Alberto I2PHD's WinRad site] Go to his website and download his WinRad package, which will give you his WinUSB driver installer. Using this installer should let you install WinUSB as the driver for your hardware on Windows XP, Vista and Windows 7, whether you have a 32 bit OS, or Intel/AMD 64 bit OS (x86 architecture) or Intel Itanium IA64 64 bit OS versions of windows installed.<br />
<br />
You will also be able to use WinRad, until Bill KD5TFD ports PowerSDR to WinUSB.<br />
<br />
Alberto has some very good notes on installing the driver, or replacing libusb0 with WinUSB, as part of his package. I suggest that you read his notes and follow his directions. I think that you have to install WinUSB twice for Ozy, once when Ozy contains no programming, and once when Ozy has has its firmware downloaded. You can also find these drivers, newly fixed so that 64 bit Intel/AMD x86 OS install works, in the WinUSBDrivers folder under my SVN archive listed below. You will still want Alberto's instructions...<br />
<br />
There were errors in the 64 bit installers, due to an error Microsoft had in their 'Using WinUSB' document. I consulted with Microsoft, who made me aware of the errors. I communicated these facts to Alberto I2PHD and Phil N8VB, who are updating their .inf files to fix the 64 bit x86 architecture processor installations correspondingly. Some teamwork and mutual communications was involved. Everyone has a better result due to the work that was done co-operatively.<br />
<br />
====Other interesting projects and info on WinUSB====<br />
<br />
:1) The SourceForge (www.sourceforge.net) project called LibUsbDotNet. You can download both source and binary. This is a project that allows .Net code to use either libusb0 or WinUSB, without the application program having to know which driver is installed for the hardware. This is not yet being used by KISS or HPSDR, but does hold some promise on Windows for this option. Using LibUsbDotNet would allow a single version of KISS, for example, to exist that would work with either libusb0 or WinUSB.<br />
<br />
:2) the website http://www.lvr.com/winusb.htm, which contains information on WinUSB, USB in general, sample code, much other information and sample code on things like Serial Ports, Parallel Ports, ethernet, and more. Its maintainer, Jan Axelson, has also written a number of books on these topics. I found his winusb_cs to be very helpful to study in porting KISS and its support programs from libusb0 to WinUSB. [http://www.lvr.com/winusb.htm Jan Axelson's website]<br />
<br />
What has been ported from libusb0 to WinUSB?<br />
:1) Phil Harman VK6APH's project KISS Console<br />
:2) supporting programs like loadfw.exe, loadfpga.exe and writei2c.exe<br />
:3) there is also a Visual Studio 2008 project called WinUSBAPI that is Alberto's Borland C++ Builder code ported to VS2008 C++. It doesn't yet have all the methods that the C# project WinUSBManaged that I wrote does. Hopefully, I'll find the time to back-port those methods from WinUSBManaged to WinUSBApi.<br />
<br />
The purpose of the 'supporting programs' (which also use winusbmanaged.dll) is to replace the current versions that use libusb0. With these, you can update the versions in your usbblaster-binaries folder so that you can still update the firmware in Penelope, Mercury and other boards. You may have multiple places where these are needed. Up-to-date copies are in my "KISS Konsole\bin\release" and "Kiss Konsole\bin\debug" folders, so that initozy11.bat that is in those folders will continue to work.<br />
<br />
Where can I find this new code that uses WinUSB?<br />
Try this svn path (K9TRV's KISS Branch): <br />
<br />
svn://svn.openhpsdr.org/svn/repos_hpsdr_kiss/branches/K9TRV<br />
<br />
== '''So, you're going to be running or recompiling the KISS code on a 64 bit machine?''' ==<br />
<br />
<br />
If so, then you'll need to check the 'fftw' subfolder in my branch for the 64 bit dll. I've provided the installers for the 32 bit and 64 bit fftw dlls, from the [http://www.fftw.org/ http://www.fftw.org/] website. Please either install the 64 bit package and replace all versions of the 32 bit dll with the dll it installs. Much easier is to copy and rename the libfftw3f64.dll to libfftw3f.dll, especially in the bin\release and bin\debug folders of my version of the [[KISS Konsole]] project. I've already placed libfftw3f64.dll in those directories for your convenience. Replacing the current libfftw3f.dll is then all you need to do. I suggest that you rename the current libfftw3f.dll file (to anything else...), then copy libfftw3f64.dll and rename the copy to libfftw3f.dll. Thanks to Dr. Hermann von Hasseln, DL3HVH, for this information!<br />
<br />
The alternative to this renaming is to rebuild SharpDSP, but ONLY after editing its file DSPBuffer.cs to change the line containing library_name = "libfftw3f.dll" to library_name = "libfftw3f64.dll".<br />
<br />
The issue here is that both KISS and Sharp_DSP are built with the 'mixed cpu' setting (see Configuration Manager), and thus when run on a 64 bit system, 64 bit code is generated (at run time! you don't even need to recompile! That's how .NET framework programs work...), and all DLLs that are called MUST BE 64 bit dlls. If you will tolerate 32 bit code on your 64 bit system, you can use the Configuration Manager and change the cpu type for BOTH KISS and Sharp_DSP to 'x86'. This will cause only 32 bit code to be generated. This will allow the 32 bit versions of FFTW as well as libusb0 to be used...<br />
<br />
So I cannot test the above, as I don't have a 64 bit OS installed to check it on. You can also find processor selection on the Build page of a project's properties. Double-click on Properties in the Kiss Konsole project in the solution explorer pane. This will bring up some tabbed dialogs in the main window. Select the 'build' tab. Note the combo-box to the right of the text saying 'Platform target'. This will by default be set to 'Any CPU'. You could choose to set it to 'x86' to force 32 bit code to be generated. Selecting 'x64' would force 64 bit code to be generated, which wouldn't work on 32 bit OS installations, and would require all 64 bit dlls be available (libusb0, probably and libfftw3f for 64 bit for sure!). I'd be willing to be that no one has an Itanium CPU, so please don't select that one...<br />
<br />
If you change the setting for KISS Konsole, make SURE that you make the setting for Sharp_DSP match! Otherwise, things just won't work... In my KISS branch, the Sharp_DSP project is part of the KISS Konsole solution, so this is easier to do. If you are using Phil's branch, you either need to add the Sharp_DSP project to the KISS solution, or make sure that you open the Sharp_DSP solution and make the needed changes in the Sharp_DSP project build settings and rebuild.<br />
<br />
[[Category:Software]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=PHOENIX&diff=3937PHOENIX2011-01-06T23:39:21Z<p>VK2NRA: URL vs IP</p>
<hr />
<div>'''PHOENIX - is a ISD/QSE Receiver/Transmitter Module'''<br />
<br />
<br />
'''Update 29 March 2010'''<br />
<br />
Richard, VK6BRO, has layed out a V2 PCB in an attempt to elimimate the large number of spurs that the V1 boards produced. <br />
The latest PCB layout, in Kicad format, are available here:<br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/Phoenix/Phoenix_V2<br />
<br />
<br />
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.<br />
<br />
A number of Alpha builders are currently constructing boards; these include Al, N0TVJ, Bill, KD5TFD, Kevin, M0KHZ and Phil, VK6APH. <br />
<br />
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. <br />
<br />
[[Image:Phoenix.JPG|thumb|500px|VK6APH's partly completed Phoenix board, November 2008]]<br />
<br />
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.<br />
<br />
Relevant files for the Phoenix project can be found under SVN at the following location:<br />
* svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/Phoenix<br />
<br />
[[Image:First_Phoenix_Signal.JPG|thumb|500px|VK6APH's Alpha Phoenix board feeding a Janus sound card and running with PowerSDR, November 2008 ]]<br />
<br />
More test results to follow - Phil....VK6APH <br />
<br />
The Phoenix PCB contains a ISD (Integrating Sampling Detector) based HF Receiver, a QSE (Quadrature Sampling Exciter) based HF Exciter and a supporting synthesizer.<br />
<br />
<!-- [[Image:phoenix_bird.jpg]]<br />
<br />
This image of a Phoenix Bird is emblazoned on 8 trams in Brisbane, Australia that were rebuilt and 'arose from the ashes' after the Paddington tram depot fire in 1962. The artist, Ken Howard, has released all rights to this drawing. <br />
<br />
--><br />
<br />
=== GENERAL DESCRIPTION ===<br />
<br />
The initial project leader was Ray Anderson, WB6TPU<br />
<br />
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).<br />
<br />
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....<br />
<br />
Inital Block diagram for discussion:<br />
<br />
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)<br />
<br />
[[Image:phoenix_simplified_block2.jpg]]<br />
<br />
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.<br />
<br />
[[Image:phoenix_simplified_block4.jpg]]<br />
<br />
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.<br />
<br />
[[Image:Phoenix_rx_1.jpg]]<br />
<br />
Feature List for Discussion:<br />
<br />
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:<br />
<br />
Synthesizer:<br />
<br />
:Utilize AD9951 with a divide by 4 to generate quadrature LO signals<br />
:Utilize 2 AD9951 with phase offset<br />
:Microwave PLL divided down to HF<br />
<br />
(as a general thing, suggestions are running towards avoiding 10-bit DDS circuits due to spurious considerations)<br />
<br />
Preamp:<br />
<br />
A robust high dynamic range low noise preamp has been suggested to precede the detector. Suggestions include:<br />
<br />
:Norton amplifier (noiseless feedback) amplifier using BFG591<br />
:Makhinson amplifier (push-pull version of Norton amp)<br />
<br />
Rx Filters:<br />
<br />
:Switched BPF filters<br />
:Broadband (0-30 MHz) frontend with external BPF<br />
<br />
QSD: It is looking like either a 74auc2g53 with OPA1632 or LT1127 amps may end up being the ISD (integrating sampling detector).<br />
<br />
The OPA1632 variant is being evaluated by Ahti OH2RZ and the LT1127 variant is being looked at by Phil N8VB.<br />
<br />
This is a critical part of the circuit as far as overall performance is concerned.<br />
<br />
'''Jan 2008 (Richard Hosking VK6BRO)'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
Look at the various schematics at: [[Phoenix Schematics]] and the current PCB layouts are at: [[Phoenix Layouts]]<br />
<br />
Please contact me if you want to play with Kicad for the various libraries<br />
<br />
[[Category:Phoenix| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Quick_Startup_Guide_(Windows)&diff=3936Quick Startup Guide (Windows)2011-01-06T23:38:16Z<p>VK2NRA: /* Preparation */ typo</p>
<hr />
<div>'''Quick Startup Guide''' for PCs running Microsoft Windows'''<br />
<br />
== System Real-Time Capabilities ==<br />
<br />
Processing of streaming data in real-time can be a challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that tasks can be executed in a deterministic (timely) manner. <br />
<br />
Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and later) there is a specific interrupt handling mechanism. When a device driver cannot process data immediately in its interrupt routine, it schedules a DPC. <br />
<br />
Microsoft defines them as ''A Deferred Procedure Call (DPC) is a queued call to a kernel-mode function that will usually be executed at a later time. DPCs are used by drivers to schedule I/O operations that do not have to take place in an ISR at a high IRQL, and can instead be safely postponed until the processor IRQL has been lowered.''<br />
<br />
When you look at Windows Task Manager and sort the running processes by CPU (Processor Utilization), the System Idle Process is almost always at the top of the list. What you may not know is that “process” is really a roll-up of several things. Among other things, included in that CPU number, is hardware interrupts and DPCs. You can see these two items by using the Microsoft “SysInternals” Process Explorer available here: [http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx Process Explorer] <br />
<br />
Thesycon's DPC Latency Checker is a free Windows tool that analyses the capabilities of a computer system to handle real-time data streams properly. It may help you to determine if your PC is capable of powering your HPSDR system or find the cause for interruptions in real-time audio and video streams, also known as drop-outs. The program supports Windows 2000, Windows XP, Windows XP x64, Windows Server 2003, Windows Server 2003 x64, Windows Vista, Windows Vista x64 and is available here: [http://www.thesycon.de/deu/latency_check.shtml DPC Latency Checker]<br />
<br />
== USBIO Driver ==<br />
Before connecting your HPSDR equipment you will need to install the USBIO drivers that can be found at FlexRadio or just click here: [http://support.flex-radio.com/Downloads.aspx?id=50 USBIO Driver]. You will need to have administrator rights on your Windows system for this install to complete. During install make sure you check the box that allows this driver to be used by everyone, not just the current user. Once the install has completed reboot your PC even if the driver install does not prompt you to restart. <br />
<br />
By default the installation program will install this driver on your system in this directory: <br />
<br />
C:\Program Files\FlexRadio Systems\USBIO Driver<br />
<br />
''('''Note:''' HPSDR requires that your PC has USB 2.0 ports. USB 1.x ports will not work.)''<br />
<br />
== .NET Framework ==<br />
The HPSDR version of PowerSDR requires that your system have Microsoft's .NET Framework version 1.1 installed. Most systems already have the framework, however, in case you need it here is the link:<br />
<br />
[http://www.microsoft.com/downloads/details.aspx?FamilyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en .NET Framework 1.1]<br />
<br />
If you are going to use Ozy to program software updates into Mercury and Penelope, then you also need Framework 2.0.<br />
<br />
[http://www.microsoft.com/downloads/details.aspx?familyid=79BC3B77-E02C-4AD3-AACF-A7633F706BA5&displaylang=en .NET 2.0 SP1]<br />
<br />
== PowerSDR Software Installation ==<br />
Currently, there is a lot of development activity and expected updates to HPSDR firmware and software. Because the software is fluid, and the developers desire to post releases quickly and as often as possible, a manual installation is easier to manage. This step will eventually be relplaced with a more standard software setup.<br />
<br />
To use [[MERCURY|Mercury]] and [[PENELOPE|Penelope]], you will need the latest released PowerSDR software from the "PennyMerge" branch of the open-source development tree. The repository is managed by Subversion, which is a popular collaborative software/firmware development tool for open-source projects. To access this software you will need to install and use a Subversion (SVN) client, see [[How to use SVN]]. There are several out there, however, TortoiseSVN for Windows XP can be downloaded from here:<br />
<br />
[http://tortoisesvn.net/ TortoiseSVN]<br />
<br />
Once TortoiseSVN is installed, follow these steps:<br />
<br />
# Create the following directory structure<br/>C:\HPSDR\PennyMerge<br/>''(this is an arbitrary convention, but logical and easy to find)''<br />
# Navigate to HPSDR<br/>Click Start and select Run...<br/>Type: C:\HPSDR then [Enter]<br/>You should see a PennyMerge directory in the window that opens.<br />
# Download the latest software<br/>Right click on the PennyMerge directory<br/>Select SVN Checkout...<br/>Type or copy & paste the following line into the "URL of repository" field:<br/><br/><tt><br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_windows/PowerSDR/branches/kd5tfd/PennyMerge/bin/Release</tt><br />
<br />
<br/><br/<br />
>Click OK<br/>At this point, TortoiseSVN should begin downloading the most current released version of the PowerSDR client for HPSDR. Once it completes go to step 4.<br/>''('''Note:''' To update to subsequent releases, you can right click the PennyMerge directory and select SVN Update...)''<br />
# Copy the files to a working directory for better version control.<br/>This directory can be anywhere you like, but we recommend using<br/><tt>C:\Program Files\FlexRadio Systems\HPSDR\</tt><br/>If you are updating an existing installation, make sure PowerSDR is not running before you write over the old version.<br />
# To create a PowerSDR desktop shortcut<br/>Open the working directory (where you copied the files i.e. <tt>C:\Program Files\FlexRadio Systems\HPSDR\</tt>)<br/>Locate the PowerSDR application file (PowerSDR.exe)<br/>Right-click on PowerSDR.exe then drag and drop it to your desktop<br/>Select "Create Shortcuts Here"<br/>''('''Note:''' It is no longer required to start PowerSDR with the --ignore-pp-ptt flag.)''<br />
<br />
== HPSDR Board Installation ==<br />
The current release versions of the HPSDR firmware does NOT require attention to the order you install the HPSDR board set on the Atlas buss. If you are using previous versions, there are several arrangements that are reported to be successful; however, this order is one of the most common:<br />
<br />
On [[ATLAS|Atlas]] J6 is next to the power connector, J1 is farthest away:<br />
* Slot J5: Mercury <br />
* Slot J3: Penelope ''(if used, open jumper J8 on Mercury, this disables Mercury's 10Mhz clock)''<br />
* Slot J2: Ozy<br />
<br />
=== What About Janus? ===<br />
<br />
[[JANUS|Janus]] is a high performance replacement soundcard for radios that produce analog I-Q inputs and outputs (like a FLEX-1000 or a Softrock). If you are using your HPSDR to control radios like these then you will need Janus. If you are running Mercury and Penelope, Janus is not needed as their I-Q signals are already in digital format.<br />
:''('''Note:''' As of 5/30/09 the firmware team has released a fix for board order dependency)''<br />
:''('''Note:''' Receiver audio is output from one of the two 1/8" stereo jacks on the Mercury board. The upper jack is at line level, the lower is suitable for headphones)''<br />
<br />
== USB Device Detection ==<br />
# Connect your power supply to Atlas - Remember that poor supply voltages will cause you problems - be certain your supply is capable of supplying the right current and voltage during operation.<br />
# Connect Ozy to a USB 2.0 port on your PC or USB 2.0 hub.<br />
# Power up the Atlas - at this point Windows should detect there is a new USB device and pop-up the standard Windows driver installation wizard. Note: you may need to manually direct the wizard to the C:\Program Files\FlexRadio Systems\USBIO Driver directory and install the correct driver.<br />
# You should see a USB device named "OZY Host Assisted Firmware Load" listed in your USB devices.<br />
<br />
:''('''Note:''' If there is a problem at this point, it needs to be resolved before moving on. There have been posts that eventually required corrections to power supplys, USB cables and/or hubs.)''<br />
<br />
== PowerSDR Configuration ==<br />
Double-click on the shortcut you created to start PowerSDR. When it first starts, it will go through a short system speed test.<br />
<br />
The latest PennyMerge PowerSDR release features a Wizard to more easily configure HPSDR systems. If this is the first time PowerSDR has run the wizard should automatically start. Just answer the wizard's questions. <br />
<br />
# Select HPSDR radio button<br />
# Click Next<br />
# Select the hardware you have installed on Atlas ''(Ozy is assumed and Alex is the filter board set not yet generally available)''<br />
# Click Finish<br />
# Select Setup from the main menu. ''(note that you can also restart the wizard here)''<br />
# Select the General Tab.<br />
# Select the HPSDR tab ''(next to Hardware Config)''<br />
# Select the correct 10MHz Clock Source for your system. ''(e.g. Mercury or Penelope, select Atlas if you are using Excalibur)''<br />
# Set Mercury as the 122.88 MHz Clock Source if using the latest code version, otherwise see this [http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/2009-May/009647.html message].<br />
# Click Apply if you changed anything.<br />
# Select the Audio tab in the PowerSDR Setup window and confirm that the Sample Rate is 192000. ''('''Important Note:''' it is possible to select a lower sample rate, but unless you are testing Mercury 2.x beta firmware releases, any sample rate other than 192000 will not work correctly.)''<br />
# Click Apply if necessary - then close the Setup window.<br />
<br />
== Startup ==<br />
At this point you should be ready to start up the system for the first time. Click "Start" in PowerSDR and you should be good to go.<br />
<br />
For instructions on how to operate PowerSDR, and further information on how to configure PowerSDR, please read Chapters 3, 4, 5, 6 and Appendix A of the Flex-5000 manual on the FlexRadio website...<br/><br/>[http://support.flex-radio.com/Downloads.aspx?id=246 Flex-5000 Owners Manual v1.14.0]<br />
<br />
:''('''Note:''' If you receive an error message noting Ozy software is not loaded, then you probably don't have all of the release software files in your working directory. Follow the instructions above in the '''PowerSDR Software Installation''' section above and copy '''ALL''' of the release files from the SVN managed directory into your working directory. The Ozy code download files and script must be in the same directory as PowerSDR.exe.'' <br />
<br />
:''('''Note:''' it's normal to see a command window open and start scrolling text when you first start PowerSDR. It is not normal to see errors during startup)''<br />
<br />
== Calibration ==<br />
The latest version of PowerSDR allows calibration of both frequency and level. It is usually only necessary to calibrate Mercury when you update Mercury firmware or the settings file (PowerSDR.mdb) is deleted. <br />
<br />
=== Level Calibration ===<br />
# Connect a calibrated RF generator to the RF-in BNC connector on Mercury. <br />
# Set the RF generator to an appropriate frequency and output level (I use 10Mhz @ 20uV or -81dBm)<br />
# In the PowerSDR Setup->General->Calibration tab, set the Frequency and Level values in the Level Cal group box to match the output of your RF generator. Mosely has a nice dBm to uV table here: [http://www.moseleysb.com/mb/mv2dbm.html Microvolts to dBm Conversion Table]<br />
# Click the Start button in the Level Cal group box and wait for the routine to complete.<br />
<br />
=== Frequency Calibration ===<br />
# Connect a calibrated RF generator to the RF-in BNC connector on Mercury. If you intend to use WWV as the frequency calibration source, connect an appropriate antenna instead. ''('''note:''' the higher the frequency used here, the more accurate the result.)''<br />
# In the PowerSDR Setup->General->Calibration tab, set the Frequency value in the Freq Cal group box to output frequency of your RF generator or use the appropriate WWV frequency.<br />
# Click the Start button in the Freq Cal group box and wait for the routine to complete<br />
<br />
== 64 bit Windows XP and Vista Installation Notes ==<br />
<br />
===USB Driver for Windows XP64===<br />
<br />
1. Download SIXAXIS_libusb-win64.zip from [http://www.4shared.com/file/41034572/1c815fbc/SIXAXIS.html this link]. Unzip this file to a temporary directory.<br />
<br />
2. Plug in the USB cable to Ozy. Don't worry about the fact that there is no driver to install yet. Just cancel the driver installation and let it give you a warning.<br />
<br />
3. In the temporary directory, run the program inf-wizard.exe. In the Device Selection window pick the USB device with Vender ID 0xFFFE, Product ID 0x0007 - that's Ozy. Click Next.<br />
<br />
4. Change Manufacturer to HPSDR. Change Device name to "OZY Host Assisted Firmware Load". Click Next<br />
<br />
5. Select a file name to save this information. I chose HPSDR.inf. Click Next then Finish.<br />
<br />
6. Now go to System Manager and select Device Properties. Ozy should be the USB device with the yellow question mark next to it. It may be under the category "LibUSB-Win32 Devices." Right click and select "Update Driver." Select to install from a specific location and browse to your temporary directory. Click Next and Finish. <br />
<br />
Things should now begin to work properly. PowerSDR will load Ozy over USB and the HPSDR stack will work just like it did under Windows XP 32.<br />
<br />
==Firmware Programming or Upgrade Instructions==<br />
<br />
These steps are required to program or update the firmware for various HPSDR boards. This procedure may be altered for a specific update or release. So please read any additional installation notes or instructions from the release team.<br />
<br />
===Preparation===<br />
<br />
1. Use a Subversion client (see [[How to use SVN]]) and download all the files from:<br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
2. Install the Altera Quartus II Programmer application (80MB) [https://www.altera.com/support/software/download/programming/quartus2/dnl-quartus2_programmer.jsp located here].<br />
<br />
''Note: The latest version is V9.0, be sure to install in the default directory. If you must install in a different directory then you will need to edit the appropriate upgrade batch files to reflect the change. A full application installation is required to run the command line programer (quartus_pgm.exe).''<br />
<br />
3. '''THE FIRST TIME YOU UPGRADE''' <br />
<br />
The following procedure loads a USB Blaster capability into your Ozy. This makes it possible to update the firmware on your other HPSDR boards without purchasing additional programming hardware. ''Once the Ozy/USB Blaster firmware has successfully loaded, you should not have to repeat this step.''<br />
<br />
:a. Connect just your Ozy board to the Atlas bus, connect the USB cable and power it on.<br />
:b. Run the file usbblaster.bat. This will load the code in the FX2 to make it appear to be an Altera USBblaster. <br />
:c. Windows will detect a new USB device. You need to install the drivers for it. Click [http://www.altera.com/literature/ug/ug_usb_blstr.pdf here] for driver installation instructions. What you need can be found in section 1.3.<br />
:d. The Found New Hardware Wizard will open.<br />
::Select Install from a list or specific location and browse to C:/altera/''[installed version]''/qprogrammer/drivers/usb-blaster. The Wizard will then install Altera USB-Blaster<br />
::Check that the drivers have installed correctly by looking in Start\Control Panel\System\Hardware\Device Manager\Universal Serial Bus controllers there should be an entry marked Altera USB-Blaster<br />
<br />
===Mercury Firmware Upgrade===<br />
<br />
# Power off your Atlas board.<br />
# Remove all boards except Ozy.<br />
# Make sure your Ozy board is placed one slot away from the power connector on Atlas.<br />
# Fit a jumper on Mercury to the JP7 header pins marked ''LAST JTAG'' at bottom left of the board just above the Atlas connector.<br />
# Install Mercury in the slot between Ozy and the power connector.<br />
# Power up the Atlas board.<br />
# Run the batch file Program-Mercury-EPCS16.bat, select which version of the Altera Quartus programmer code you are using and the Mercury firmware version you wish to load and look at the output, there should be no errors. ''Do not interrupt the loading process, it takes approximately 1 minute to load the EPCS16.''<br />
# Power off your Atlas board.<br />
# Remove the jumper on JP7.<br />
# Continue with additional firmware upgrades or read restarting after firmware upgrade below.<br />
<br />
===Penelope Firmware Upgrade===<br />
<br />
# Power off your Atlas board.<br />
# Remove all boards except Ozy.<br />
# Make sure your Ozy board is placed one slot away from the power connector on Atlas.<br />
# Fit a jumper on Penelope to the JP7 header pins marked ''LAST'' located at the edge of the board next to the FPGA.<br />
# Install Penelope in the slot between Ozy and the power connector.<br />
# Power up the Atlas board.<br />
# Run the batch file Program-Penelope--EPCS4.bat, select which version of the Altera Quartus programmer code you are using and the Penelope firmware version you wish to load and look at the output, there should be no errors. ''Do not interrupt the loading process, it takes approximately 15 seconds to load the EPCS4.''<br />
# Power off your Atlas board.<br />
# Remove the jumper on JP7.<br />
# Continue with additional firmware upgrades or read restarting after firmware upgrade below.<br />
<br />
===Janus Firmware Upgrade===<br />
<br />
# Power off your Atlas board.<br />
# Remove all boards except Ozy.<br />
# Make sure your Ozy board is placed one slot away from the power connector on Atlas.<br />
# Fit a jumper on Janus to the JP12 header pins marked ''LAST JTAG'' located at the bottom left of the board just above the Atlas connector.<br />
# Install Janus in the slot between Ozy and the power connector.<br />
# Power up the Atlas board.<br />
# Run the batch file Program-Janus-EPM240T100.bat, select which version of the Altera Quartus programmer code you are using and the Janus firmware version you wish to load and look at the output, there should be no errors. ''Do not interrupt the loading process; it takes approximately 5 seconds to load the EPM240T100.''<br />
# Power off your Atlas board.<br />
# Remove the jumper on JP12.<br />
# Continue with additional firmware upgrades or read restarting after firmware upgrade below.<br />
<br />
===Restarting After a Firmware Upgrade===<br />
# Place your HPSDR boards in their operational slots.<br />
# Download any new update for PowerSDR (there is usually a corresponding update with new firmware).<br />
# Make a note of any important settings in PowerSDR. ''(Hint: Use Alt-PrtScn to take a screen capture of the PowerSDR settings you want to save, paste the capture into the Paint program or other image editor, then print or save the image for reference)''<br />
# Make a backup copy of the settings file (PowerSDR.mdb), then delete the original. PowerSDR will rebuild it when it starts.<br />
# Power cycle the supply to the Atlas bus. <br />
# Make any important settings from the notes that were saved above.<br />
# If necessary recalibrate Frequency and Level.<br />
# Test Mercury/Penelope/Janus with PowerSDR.<br />
<br />
[[Category:PowerSDR| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Quick_Startup_Guide_(Windows)&diff=3935Quick Startup Guide (Windows)2011-01-06T23:37:53Z<p>VK2NRA: /* Preparation */ URL vs IP</p>
<hr />
<div>'''Quick Startup Guide''' for PCs running Microsoft Windows'''<br />
<br />
== System Real-Time Capabilities ==<br />
<br />
Processing of streaming data in real-time can be a challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that tasks can be executed in a deterministic (timely) manner. <br />
<br />
Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and later) there is a specific interrupt handling mechanism. When a device driver cannot process data immediately in its interrupt routine, it schedules a DPC. <br />
<br />
Microsoft defines them as ''A Deferred Procedure Call (DPC) is a queued call to a kernel-mode function that will usually be executed at a later time. DPCs are used by drivers to schedule I/O operations that do not have to take place in an ISR at a high IRQL, and can instead be safely postponed until the processor IRQL has been lowered.''<br />
<br />
When you look at Windows Task Manager and sort the running processes by CPU (Processor Utilization), the System Idle Process is almost always at the top of the list. What you may not know is that “process” is really a roll-up of several things. Among other things, included in that CPU number, is hardware interrupts and DPCs. You can see these two items by using the Microsoft “SysInternals” Process Explorer available here: [http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx Process Explorer] <br />
<br />
Thesycon's DPC Latency Checker is a free Windows tool that analyses the capabilities of a computer system to handle real-time data streams properly. It may help you to determine if your PC is capable of powering your HPSDR system or find the cause for interruptions in real-time audio and video streams, also known as drop-outs. The program supports Windows 2000, Windows XP, Windows XP x64, Windows Server 2003, Windows Server 2003 x64, Windows Vista, Windows Vista x64 and is available here: [http://www.thesycon.de/deu/latency_check.shtml DPC Latency Checker]<br />
<br />
== USBIO Driver ==<br />
Before connecting your HPSDR equipment you will need to install the USBIO drivers that can be found at FlexRadio or just click here: [http://support.flex-radio.com/Downloads.aspx?id=50 USBIO Driver]. You will need to have administrator rights on your Windows system for this install to complete. During install make sure you check the box that allows this driver to be used by everyone, not just the current user. Once the install has completed reboot your PC even if the driver install does not prompt you to restart. <br />
<br />
By default the installation program will install this driver on your system in this directory: <br />
<br />
C:\Program Files\FlexRadio Systems\USBIO Driver<br />
<br />
''('''Note:''' HPSDR requires that your PC has USB 2.0 ports. USB 1.x ports will not work.)''<br />
<br />
== .NET Framework ==<br />
The HPSDR version of PowerSDR requires that your system have Microsoft's .NET Framework version 1.1 installed. Most systems already have the framework, however, in case you need it here is the link:<br />
<br />
[http://www.microsoft.com/downloads/details.aspx?FamilyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en .NET Framework 1.1]<br />
<br />
If you are going to use Ozy to program software updates into Mercury and Penelope, then you also need Framework 2.0.<br />
<br />
[http://www.microsoft.com/downloads/details.aspx?familyid=79BC3B77-E02C-4AD3-AACF-A7633F706BA5&displaylang=en .NET 2.0 SP1]<br />
<br />
== PowerSDR Software Installation ==<br />
Currently, there is a lot of development activity and expected updates to HPSDR firmware and software. Because the software is fluid, and the developers desire to post releases quickly and as often as possible, a manual installation is easier to manage. This step will eventually be relplaced with a more standard software setup.<br />
<br />
To use [[MERCURY|Mercury]] and [[PENELOPE|Penelope]], you will need the latest released PowerSDR software from the "PennyMerge" branch of the open-source development tree. The repository is managed by Subversion, which is a popular collaborative software/firmware development tool for open-source projects. To access this software you will need to install and use a Subversion (SVN) client, see [[How to use SVN]]. There are several out there, however, TortoiseSVN for Windows XP can be downloaded from here:<br />
<br />
[http://tortoisesvn.net/ TortoiseSVN]<br />
<br />
Once TortoiseSVN is installed, follow these steps:<br />
<br />
# Create the following directory structure<br/>C:\HPSDR\PennyMerge<br/>''(this is an arbitrary convention, but logical and easy to find)''<br />
# Navigate to HPSDR<br/>Click Start and select Run...<br/>Type: C:\HPSDR then [Enter]<br/>You should see a PennyMerge directory in the window that opens.<br />
# Download the latest software<br/>Right click on the PennyMerge directory<br/>Select SVN Checkout...<br/>Type or copy & paste the following line into the "URL of repository" field:<br/><br/><tt><br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_windows/PowerSDR/branches/kd5tfd/PennyMerge/bin/Release</tt><br />
<br />
<br/><br/<br />
>Click OK<br/>At this point, TortoiseSVN should begin downloading the most current released version of the PowerSDR client for HPSDR. Once it completes go to step 4.<br/>''('''Note:''' To update to subsequent releases, you can right click the PennyMerge directory and select SVN Update...)''<br />
# Copy the files to a working directory for better version control.<br/>This directory can be anywhere you like, but we recommend using<br/><tt>C:\Program Files\FlexRadio Systems\HPSDR\</tt><br/>If you are updating an existing installation, make sure PowerSDR is not running before you write over the old version.<br />
# To create a PowerSDR desktop shortcut<br/>Open the working directory (where you copied the files i.e. <tt>C:\Program Files\FlexRadio Systems\HPSDR\</tt>)<br/>Locate the PowerSDR application file (PowerSDR.exe)<br/>Right-click on PowerSDR.exe then drag and drop it to your desktop<br/>Select "Create Shortcuts Here"<br/>''('''Note:''' It is no longer required to start PowerSDR with the --ignore-pp-ptt flag.)''<br />
<br />
== HPSDR Board Installation ==<br />
The current release versions of the HPSDR firmware does NOT require attention to the order you install the HPSDR board set on the Atlas buss. If you are using previous versions, there are several arrangements that are reported to be successful; however, this order is one of the most common:<br />
<br />
On [[ATLAS|Atlas]] J6 is next to the power connector, J1 is farthest away:<br />
* Slot J5: Mercury <br />
* Slot J3: Penelope ''(if used, open jumper J8 on Mercury, this disables Mercury's 10Mhz clock)''<br />
* Slot J2: Ozy<br />
<br />
=== What About Janus? ===<br />
<br />
[[JANUS|Janus]] is a high performance replacement soundcard for radios that produce analog I-Q inputs and outputs (like a FLEX-1000 or a Softrock). If you are using your HPSDR to control radios like these then you will need Janus. If you are running Mercury and Penelope, Janus is not needed as their I-Q signals are already in digital format.<br />
:''('''Note:''' As of 5/30/09 the firmware team has released a fix for board order dependency)''<br />
:''('''Note:''' Receiver audio is output from one of the two 1/8" stereo jacks on the Mercury board. The upper jack is at line level, the lower is suitable for headphones)''<br />
<br />
== USB Device Detection ==<br />
# Connect your power supply to Atlas - Remember that poor supply voltages will cause you problems - be certain your supply is capable of supplying the right current and voltage during operation.<br />
# Connect Ozy to a USB 2.0 port on your PC or USB 2.0 hub.<br />
# Power up the Atlas - at this point Windows should detect there is a new USB device and pop-up the standard Windows driver installation wizard. Note: you may need to manually direct the wizard to the C:\Program Files\FlexRadio Systems\USBIO Driver directory and install the correct driver.<br />
# You should see a USB device named "OZY Host Assisted Firmware Load" listed in your USB devices.<br />
<br />
:''('''Note:''' If there is a problem at this point, it needs to be resolved before moving on. There have been posts that eventually required corrections to power supplys, USB cables and/or hubs.)''<br />
<br />
== PowerSDR Configuration ==<br />
Double-click on the shortcut you created to start PowerSDR. When it first starts, it will go through a short system speed test.<br />
<br />
The latest PennyMerge PowerSDR release features a Wizard to more easily configure HPSDR systems. If this is the first time PowerSDR has run the wizard should automatically start. Just answer the wizard's questions. <br />
<br />
# Select HPSDR radio button<br />
# Click Next<br />
# Select the hardware you have installed on Atlas ''(Ozy is assumed and Alex is the filter board set not yet generally available)''<br />
# Click Finish<br />
# Select Setup from the main menu. ''(note that you can also restart the wizard here)''<br />
# Select the General Tab.<br />
# Select the HPSDR tab ''(next to Hardware Config)''<br />
# Select the correct 10MHz Clock Source for your system. ''(e.g. Mercury or Penelope, select Atlas if you are using Excalibur)''<br />
# Set Mercury as the 122.88 MHz Clock Source if using the latest code version, otherwise see this [http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/2009-May/009647.html message].<br />
# Click Apply if you changed anything.<br />
# Select the Audio tab in the PowerSDR Setup window and confirm that the Sample Rate is 192000. ''('''Important Note:''' it is possible to select a lower sample rate, but unless you are testing Mercury 2.x beta firmware releases, any sample rate other than 192000 will not work correctly.)''<br />
# Click Apply if necessary - then close the Setup window.<br />
<br />
== Startup ==<br />
At this point you should be ready to start up the system for the first time. Click "Start" in PowerSDR and you should be good to go.<br />
<br />
For instructions on how to operate PowerSDR, and further information on how to configure PowerSDR, please read Chapters 3, 4, 5, 6 and Appendix A of the Flex-5000 manual on the FlexRadio website...<br/><br/>[http://support.flex-radio.com/Downloads.aspx?id=246 Flex-5000 Owners Manual v1.14.0]<br />
<br />
:''('''Note:''' If you receive an error message noting Ozy software is not loaded, then you probably don't have all of the release software files in your working directory. Follow the instructions above in the '''PowerSDR Software Installation''' section above and copy '''ALL''' of the release files from the SVN managed directory into your working directory. The Ozy code download files and script must be in the same directory as PowerSDR.exe.'' <br />
<br />
:''('''Note:''' it's normal to see a command window open and start scrolling text when you first start PowerSDR. It is not normal to see errors during startup)''<br />
<br />
== Calibration ==<br />
The latest version of PowerSDR allows calibration of both frequency and level. It is usually only necessary to calibrate Mercury when you update Mercury firmware or the settings file (PowerSDR.mdb) is deleted. <br />
<br />
=== Level Calibration ===<br />
# Connect a calibrated RF generator to the RF-in BNC connector on Mercury. <br />
# Set the RF generator to an appropriate frequency and output level (I use 10Mhz @ 20uV or -81dBm)<br />
# In the PowerSDR Setup->General->Calibration tab, set the Frequency and Level values in the Level Cal group box to match the output of your RF generator. Mosely has a nice dBm to uV table here: [http://www.moseleysb.com/mb/mv2dbm.html Microvolts to dBm Conversion Table]<br />
# Click the Start button in the Level Cal group box and wait for the routine to complete.<br />
<br />
=== Frequency Calibration ===<br />
# Connect a calibrated RF generator to the RF-in BNC connector on Mercury. If you intend to use WWV as the frequency calibration source, connect an appropriate antenna instead. ''('''note:''' the higher the frequency used here, the more accurate the result.)''<br />
# In the PowerSDR Setup->General->Calibration tab, set the Frequency value in the Freq Cal group box to output frequency of your RF generator or use the appropriate WWV frequency.<br />
# Click the Start button in the Freq Cal group box and wait for the routine to complete<br />
<br />
== 64 bit Windows XP and Vista Installation Notes ==<br />
<br />
===USB Driver for Windows XP64===<br />
<br />
1. Download SIXAXIS_libusb-win64.zip from [http://www.4shared.com/file/41034572/1c815fbc/SIXAXIS.html this link]. Unzip this file to a temporary directory.<br />
<br />
2. Plug in the USB cable to Ozy. Don't worry about the fact that there is no driver to install yet. Just cancel the driver installation and let it give you a warning.<br />
<br />
3. In the temporary directory, run the program inf-wizard.exe. In the Device Selection window pick the USB device with Vender ID 0xFFFE, Product ID 0x0007 - that's Ozy. Click Next.<br />
<br />
4. Change Manufacturer to HPSDR. Change Device name to "OZY Host Assisted Firmware Load". Click Next<br />
<br />
5. Select a file name to save this information. I chose HPSDR.inf. Click Next then Finish.<br />
<br />
6. Now go to System Manager and select Device Properties. Ozy should be the USB device with the yellow question mark next to it. It may be under the category "LibUSB-Win32 Devices." Right click and select "Update Driver." Select to install from a specific location and browse to your temporary directory. Click Next and Finish. <br />
<br />
Things should now begin to work properly. PowerSDR will load Ozy over USB and the HPSDR stack will work just like it did under Windows XP 32.<br />
<br />
==Firmware Programming or Upgrade Instructions==<br />
<br />
These steps are required to program or update the firmware for various HPSDR boards. This procedure may be altered for a specific update or release. So please read any additional installation notes or instructions from the release team.<br />
<br />
===Preparation===<br />
<br />
1. Use a Subversion client (see [[How to use SVN]]) and download all the files from:<br />
<br />
svn://1svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
2. Install the Altera Quartus II Programmer application (80MB) [https://www.altera.com/support/software/download/programming/quartus2/dnl-quartus2_programmer.jsp located here].<br />
<br />
''Note: The latest version is V9.0, be sure to install in the default directory. If you must install in a different directory then you will need to edit the appropriate upgrade batch files to reflect the change. A full application installation is required to run the command line programer (quartus_pgm.exe).''<br />
<br />
3. '''THE FIRST TIME YOU UPGRADE''' <br />
<br />
The following procedure loads a USB Blaster capability into your Ozy. This makes it possible to update the firmware on your other HPSDR boards without purchasing additional programming hardware. ''Once the Ozy/USB Blaster firmware has successfully loaded, you should not have to repeat this step.''<br />
<br />
:a. Connect just your Ozy board to the Atlas bus, connect the USB cable and power it on.<br />
:b. Run the file usbblaster.bat. This will load the code in the FX2 to make it appear to be an Altera USBblaster. <br />
:c. Windows will detect a new USB device. You need to install the drivers for it. Click [http://www.altera.com/literature/ug/ug_usb_blstr.pdf here] for driver installation instructions. What you need can be found in section 1.3.<br />
:d. The Found New Hardware Wizard will open.<br />
::Select Install from a list or specific location and browse to C:/altera/''[installed version]''/qprogrammer/drivers/usb-blaster. The Wizard will then install Altera USB-Blaster<br />
::Check that the drivers have installed correctly by looking in Start\Control Panel\System\Hardware\Device Manager\Universal Serial Bus controllers there should be an entry marked Altera USB-Blaster<br />
<br />
===Mercury Firmware Upgrade===<br />
<br />
# Power off your Atlas board.<br />
# Remove all boards except Ozy.<br />
# Make sure your Ozy board is placed one slot away from the power connector on Atlas.<br />
# Fit a jumper on Mercury to the JP7 header pins marked ''LAST JTAG'' at bottom left of the board just above the Atlas connector.<br />
# Install Mercury in the slot between Ozy and the power connector.<br />
# Power up the Atlas board.<br />
# Run the batch file Program-Mercury-EPCS16.bat, select which version of the Altera Quartus programmer code you are using and the Mercury firmware version you wish to load and look at the output, there should be no errors. ''Do not interrupt the loading process, it takes approximately 1 minute to load the EPCS16.''<br />
# Power off your Atlas board.<br />
# Remove the jumper on JP7.<br />
# Continue with additional firmware upgrades or read restarting after firmware upgrade below.<br />
<br />
===Penelope Firmware Upgrade===<br />
<br />
# Power off your Atlas board.<br />
# Remove all boards except Ozy.<br />
# Make sure your Ozy board is placed one slot away from the power connector on Atlas.<br />
# Fit a jumper on Penelope to the JP7 header pins marked ''LAST'' located at the edge of the board next to the FPGA.<br />
# Install Penelope in the slot between Ozy and the power connector.<br />
# Power up the Atlas board.<br />
# Run the batch file Program-Penelope--EPCS4.bat, select which version of the Altera Quartus programmer code you are using and the Penelope firmware version you wish to load and look at the output, there should be no errors. ''Do not interrupt the loading process, it takes approximately 15 seconds to load the EPCS4.''<br />
# Power off your Atlas board.<br />
# Remove the jumper on JP7.<br />
# Continue with additional firmware upgrades or read restarting after firmware upgrade below.<br />
<br />
===Janus Firmware Upgrade===<br />
<br />
# Power off your Atlas board.<br />
# Remove all boards except Ozy.<br />
# Make sure your Ozy board is placed one slot away from the power connector on Atlas.<br />
# Fit a jumper on Janus to the JP12 header pins marked ''LAST JTAG'' located at the bottom left of the board just above the Atlas connector.<br />
# Install Janus in the slot between Ozy and the power connector.<br />
# Power up the Atlas board.<br />
# Run the batch file Program-Janus-EPM240T100.bat, select which version of the Altera Quartus programmer code you are using and the Janus firmware version you wish to load and look at the output, there should be no errors. ''Do not interrupt the loading process; it takes approximately 5 seconds to load the EPM240T100.''<br />
# Power off your Atlas board.<br />
# Remove the jumper on JP12.<br />
# Continue with additional firmware upgrades or read restarting after firmware upgrade below.<br />
<br />
===Restarting After a Firmware Upgrade===<br />
# Place your HPSDR boards in their operational slots.<br />
# Download any new update for PowerSDR (there is usually a corresponding update with new firmware).<br />
# Make a note of any important settings in PowerSDR. ''(Hint: Use Alt-PrtScn to take a screen capture of the PowerSDR settings you want to save, paste the capture into the Paint program or other image editor, then print or save the image for reference)''<br />
# Make a backup copy of the settings file (PowerSDR.mdb), then delete the original. PowerSDR will rebuild it when it starts.<br />
# Power cycle the supply to the Atlas bus. <br />
# Make any important settings from the notes that were saved above.<br />
# If necessary recalibrate Frequency and Level.<br />
# Test Mercury/Penelope/Janus with PowerSDR.<br />
<br />
[[Category:PowerSDR| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=How_to_use_SVN&diff=3934How to use SVN2011-01-06T23:36:52Z<p>VK2NRA: /* Downloading with TortoiseSVN */ URL vs IP</p>
<hr />
<div>Most of the HPSDR [[HPSDR related software|software]] repositories are managed by '''Subversion''', which is a popular collaborative software/firmware development tool for open-source projects. This is a code database repository that is developed with all copies of all code that has been checked in by developers. With a system like this you can go back and check out any previous version of the the software. Wikipedia has an overview of SVN at [http://en.wikipedia.org/wiki/Svn_(software) http://en.wikipedia.org/wiki/Svn_(software)]. <br />
<br />
To access this software you will need to install and use a Subversion (SVN) client. There are several clients listed at the above Wikipedia page. Some of our users have found TortoiseSVN for Windows XP easy to use; it can be downloaded from: [http://tortoisesvn.net/ http://tortoisesvn.net/]. The Tortoise documentation is at [http://tortoisesvn.net/support http://tortoisesvn.net/support] or can be accessed by pressing the F1 key in any Tortoise dialog box.<br />
<br />
A free book on subversion is available at: http://svnbook.red-bean.com/<br />
<br />
==Downloading with TortoiseSVN==<br />
<br />
This is meant to be a simplified procedure to use the Windows SVN client 'TortoiseSVN'.<br />
<br />
*You have TortoiseSVN installed and working.<br />
<br />
*Create a new empty directory, Give it a name appropriate to the item(s) you are downloading.<br />
<br />
*Go to that empty directory, right click in the empty directory and from the menu choices choose 'SVN Checkout'. Enter the svn address of the item you want in the box titled 'URL of repository:'. A typical entry would be:<br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
*Click OK.<br />
<br />
It should download all the data into the directory.....<br />
<br />
== Our SVN repository ==<br />
<br />
The open HPSDR project maintains a SVN for the the members of the project. The top address of the repository is: <br />
<br />
svn://svn.openhpsdr.org/repos_sdr_hpsdr/trunk<br />
<br />
'''Please do not try to check out the entire SVN it is over 2.5 GB'''. Because of problems the root is no longer browsable. The following directories are under the trunk and are browsable.<br />
<br />
Code is not generally erased from a repository. So many of the some of the directories are very active and may change daily other may have not changes in years. Check the dates on the files to determine when tey were lats updated. Your SVN program will help you keep a up to date copy of the code on your computer and you can easily update the directory with a single command. <br />
<br />
The repository evolves over time so the organization is not usually for the new viewer but for those that post code. To help people find things here is an index of major folders. Several directories were not included in this list as they are empty.<br />
<br />
==SVN Directories==<br />
<br />
====AE6VK====<br />
Chris Day's on OzyJanus to be used with SDR1000 from 2007<br />
====Atlas====<br />
Reference files of the the [[ATLAS]] connections to other boards<br />
====CyclopsII====<br />
Verilog and C# code for [[CYCLOPS]]<br />
====Documentation====<br />
USB '''HPSDR''' protocol definitions, [[ATLAS|Atlas]] buss pin definitions<br />
<br />
====I2PHD====<br />
Code by Alberto DiBene for HPSDR Winrad<br />
====Janus-CPLDV2====<br />
Verilog code for Janus Version 2<br />
====Janus-CPLDV3====<br />
Verliog code for Janus Version 3<br />
====K5FR====<br />
Steve Nance's C# code for DDUtil<br />
====KA6S====<br />
Steve Wilson's code for verilog code for i2c simulation<br />
====KD5TFD====<br />
Bill Tracey's utility code for testing a large number of interfaces.<br />
====Mercury====<br />
Latest version of the Mercury verilog code<br />
====N4HY====<br />
Bob McGwier's proposal and Documents of Horton and Odyssey<br />
====N6LYT====<br />
John Melton's code for [[ghpsdr]] (single machine no server) and [[ghpsdr3]] (multiple receiver multi machine) code build for Linux systems. Uses DttSP, FFTw3, libusb1.0 and gtk+.<br />
====N8VB====<br />
Phil Covington's code for MercScope, Ozy V1, and SharpDSP<br />
====OZY2-test====<br />
C and Verilog code for test Ozy2<br />
====Ozy V1.2====<br />
First version of the Ozy verilog code<br />
====Ozy V1.4====<br />
First version of the Ozy verilog code<br />
====Ozy V1.5====<br />
First version of the Ozy verilog code<br />
====Ozy V1.6====<br />
First version of the Ozy verilog code<br />
====Ozy V1.7====<br />
First version of the Ozy verilog code<br />
====OzyFX2====<br />
C# code to talk with FX2<br />
<br />
====OzyII====<br />
C and Verilog code for Ozy II<br />
====OzyJanus-Jack====<br />
C code to allow powerSDR to talk to SDR1000 through [[JANUS]] and Jack<br />
====Ozy-JanusV2====<br />
Verilog code for Ozy-Janus from 2006<br />
====OzyUtil-NativeWin====<br />
C code to initalize Ozy on a Windows system<br />
====OzyV2-JanusV2====<br />
Verilog code for Ozy-Janus based on new [[OZY]] code.<br />
====Penelope====<br />
Latest version verilog code for [[PENELOPE]].<br />
====Phoenix====<br />
Verilog code and documentation for [[PHOENIX]].<br />
====PowerSDR-ForJanusOzy-LatestReleaseBinaries====<br />
PowerSDR files from 2007, PowerSDR code for HPSDR is on the Flex SVN<br />
====ProjectDiagrams====<br />
Diagrams for Atlas and Janus from 2006<br />
====VE3NEA====<br />
Alex Shovkoplyas's verilog and firmware code for HPSDR<br />
====VK6APH====<br />
Phil Harmon's verilog and C# code for various projects<br />
====vu3rdd====<br />
Ramakrishnan Muthukrishnan's code to the USB-Blaster using an Ozy board.<br />
====W1BW====<br />
Verilog code for Mercury 3.0 and Ozy 1.8 Multi-receiver code<br />
====WA2DFI====<br />
Scotty Cowling information of the code loaded in to production boards.<br />
====WD5Y====<br />
Joe Torrey's code fro PowerSDR using portAudio<br />
<br />
[[Category:Developer resources]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Ghpsdr&diff=3933Ghpsdr2011-01-06T23:35:55Z<p>VK2NRA: /* SVN */ URL vs IP</p>
<hr />
<div>[[Image:ghpsdr4.png|thumb|400px|right|Screenshot of the ghpsdr GUI on 20 meters. (Click to enlarge)]]<br />
<br />
===Stand Alone version of ghpsdr===<br />
<br />
'''ghpsdr''' is a software defined radio client written specifically for HPSDR by John Melton, G0ORX/N6LYT. <br />
<br />
The software is being developed on the Ubuntu version of Linux (specifically version 9.04). This code has be compiled and runs on MacOS as well.<br />
<br />
Currently (early August, 2009) it does not have a full transmit function, but that is expected shortly.<br />
<br />
This version of '''ghpsdr''' is a all in one program on a single machine. <br />
<br />
===SVN===<br />
The software is available from SVN and includes a precompiled executable in the bin directory. There are now a compiled version of the 64-bit linux version, 32-bit linux version and the MacOS version. The README explains how to compile the source if you wish to modify the code.<br />
<br />
<br />
Since this code does not currently run on Windows here is the Linux svn command,<br />
<br />
svn co svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/N6LYT/ghpsdr<br />
<br />
===Libraries===<br />
It uses a modifed version of DttSP that is ported from the Windows version. DttSP is built as a static library that is linked with the GUI code. The DttSP code is provided with the SVN distribution.<br />
<br />
You will need a couple of libraries to run this code, they include:<br />
* '''libfftw3''' - FFTW is a C subroutine library for computing the discrete Fourier transform (DFT) in one or more dimensions, of arbitrary input size, and of both real and complex data (as well as of even/odd data, i.e. the discrete cosine/sine transforms or DCT/DST).<br />
* '''libgtk2''' - GTK+ is a highly usable, feature rich toolkit for creating graphical user interfaces which boasts cross platform compatibility and an easy to use API.<br />
* '''libusb-1.0''' - libusb is an open source library that allows you to communicate with USB devices from userspace.<br />
These can be obtain with your package installer.<br />
<br />
<br />
Links to other pages:<br />
<br />
* [[ghpsdr FAQ|Frequently Asked Questions]]<br />
* [http://www.tapr.org/pdf/2010-G0ORX-N6LYT-Linux-HPSDR.pdf John Melton's Dayton 2010 presentation on ghpsdr.]<br />
* Features List [[ghpsdr Requests|requests]]<br />
* Programmers [[ghpsdr Notes|Notes]]<br />
* Known [[ghpsdr Bugs|bugs]]<br />
<br />
[[Category:Ghpsdr| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=GRIFFIN&diff=3932GRIFFIN2011-01-06T23:33:54Z<p>VK2NRA: URL vs IP</p>
<hr />
<div>'''GRIFFIN - Stand alone beacon board'''<br />
[[Image:Griffin_Block_Diagram_Rev_1_0.jpg|thumb|500px|Block diagram as of 23 Aug 2010. Click for full size.]] <br />
<br />
Many will be aware of the work undertaken by Bill, KD5TFD, to develop FPGA<br />
code that enables Penelope to operate as a stand alone WSPR beacon. Not<br />
only does his code allow a full implementation of the WSPR protocol, without<br />
the need to connect to a PC, it also enables multiple beacons to operate<br />
simultaneously on multiple bands. This is the dual of multiple independent<br />
receives in a Mercury - multiple independent transmitters in a Penny.<br />
<br />
More details of Bill's work can be found here:<br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/PennyWSPR <br />
<br />
There's a README file at:<br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/PennyWSPR/README.txt<br />
<br />
One of the advantages we have in the way that HPSDR has evolved is the<br />
ability to try new modes without the need to build or buy new hardware.<br />
Here's another example.<br />
<br />
Many CW operators will remember the time when a CW report, say 559, also<br />
sometimes included a 'C' at the end (e.g. 559C) which indicated the received<br />
signal had a 'chirp' i.e. unstable when keyed, FM etc.<br />
<br />
Chirp was regarded as an undesirable feature and best to let the operator<br />
know. There was also the practice of adding an 'H' to the report<br />
indicating Hum. The story goes that the difficulty in obtaining high<br />
voltage smoothing capacitors in Eastern Europe resulted in some operators<br />
applying un-smoothed rectified mains to the anode/plate of the PA stage<br />
giving it a distinctive err... note. However, a story for another day<br />
perhaps.<br />
<br />
The introduction of digital/HDTV in many parts of the world has triggered <br />
the removal of the analogue TV broadcasters that are/were located adjacent <br />
to the 6m band. Magic Band operators often use these stations as an indicator<br />
of propagation conditions. Since they typically run much higher ERP than<br />
Amateur stations, 10's of kW, they were/are an ideal source of propagation<br />
beacons.<br />
<br />
With the removal of these services in many parts of the world 6m operators<br />
loose a very valuable source of propagation information. It's just this <br />
problem that has lead Andrew Martin, VK30E, to develop an alternative that can be used<br />
in either a RADAR or beacon mode.<br />
<br />
Andrew describes his technique fully in the 2/2010 edition of DUBUS<br />
<br />
http://www.marsport.org.uk/dubus/last.htm<br />
<br />
but here's the basic idea.<br />
<br />
We deliberately, repeatedly, linearly sweep the frequency of a carrier over<br />
1kHz in one second. The nominal frequency of the carrier is derived from a<br />
GPS locked 10MHz reference. The start of the one second sweep is<br />
synchronised to the 1 PPS signal from a GPS.<br />
<br />
At the receiver we use a matched filter, again triggered from a 1 PPS signal<br />
from a GPS, to detect the signal. The matched filter in this case runs on<br />
your PC and uses your sound card or VAC to digitise the received signal.<br />
<br />
The effect is similar to WSPR. However, we trade RF bandwidth for time - in<br />
which case the output of the matched filter is available every second rather<br />
then every few minutes as in the case of WSPR. We also gain a signal<br />
processing advantage over WSPR which typically can decode at -26dB in a<br />
2.7kHz bandwidth. 'Chirp' will decode at -36dB in the same bandwidth. If we<br />
integrate multiple chirp signals over say 1 minute then the processing gain<br />
increases to -54dB.<br />
<br />
So if we run a 100W amateur beacon by applying a chirp to the signal we<br />
effectively have a 400kW signal - in line with the TV transmitters we are<br />
trying to replace.<br />
<br />
Initial tests on 20m between Andrew and Don, VK6HK over a 2700Km path, have <br />
shown the technique to work such that a barely audible SSB signal gives a <br />
spike with a 45dB S/N ratio at the output of the matched filter.<br />
<br />
This is chirp in the beacon mode.<br />
<br />
Alternatively, one station can transmit a<br />
chirp signal, using full power and a beam, in a certain direction and<br />
another station listens beaming in the same direction. The stations need to<br />
be sufficiently far apart such that the transmitting station does not<br />
overload the receiver of the receiving station.<br />
<br />
The receiving station will then receive echoes of the transmitted signal<br />
from the various mediums in the direction he is beaming. Since his matched<br />
filter is triggered at exactly the same time as the transmitting station he<br />
can plot of graph of signal strength against distance in miles/km. Such a<br />
graph can clearly show the presence of single and multi hop E's and their<br />
intensity. Andrew's DUBUS article has some very interesting examples of<br />
enhanced 6m propagation that chirp is able to identify.<br />
<br />
The free sound card software Spectrum Lab:<br />
<br />
http://www.qsl.net/dl4yhf/spectra1.html <br />
<br />
will both generate and demodulate chirp signals.<br />
<br />
What would be interesting would be to have a single board that generates a<br />
chirp modulated carrier and could be used as the replacement for the low<br />
level drive stage in a conventional 6m beacon. You guessed it - Penelope!<br />
<br />
Bill kindly offered to take on this 'Weekender Project' (which did actually<br />
fit in a weekend for once!) and produced a version of his PennyWSPR code<br />
that included BOTH a chirp and WSPR beacon and would trigger on the 1 PPS<br />
from a GPS receiver. The nominal frequency of the beacons is at 50.3MHz<br />
(for initial testing) with the chirp extending from 300Hz to 1300Hz above<br />
this and the WSPR beacon 1500Hz above. The WSPR beacon is 6dB below the<br />
power level of the chirp beacon.<br />
<br />
Since VHF beacons in VK are allocated on a 2kHz channel spacing the spectrum <br />
of the two signals fits nicely within an allocated channel.<br />
<br />
Work is also in progress to look at including an aural CW ident on the <br />
allocated carrier frequency.<br />
<br />
Testing is about to start and I'll report progress in due course.<br />
<br />
If testing is successful then we intend to develop an FPGA based PCB that <br />
will provide a 6m/2m beacon exciter stage. The board is intended to be used <br />
as a replacement for the low level driver board in an existing beacon. As <br />
well as the FGPA, power supplies etc, it will include a GPS receiver and <br />
oven controlled 10MHz reference.<br />
<br />
The project leaders for the board was Phil VK6APH and Kevin M0KHZ.<br />
<br />
<br />
[[Category:Future hardware]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=WinUSB_Notes&diff=3931WinUSB Notes2011-01-06T23:32:58Z<p>VK2NRA: URL vs IP</p>
<hr />
<div><blockquote><br />
'''THIS MATERIAL SHOULD BE CONSIDERED AS OBSOLETE, BUT INFORMATIVE''' <br><br />
'''THAT IS BECAUSE libusb0 HAS BEEN PUBLISHED BY openhpsdr.org AS A SIGNED DRIVER''' <br><br />
'''PLEASE SEARCH THE FORUM'S ARCHIVES FOR MORE INFORMATION ON THE TOPIC OF LIBUSB0''' <br><br />
</blockquote><br />
<br />
Here are the signed libusb0 drivers:<br />
<br />
svn://svn.openhpsdr.org/svn/repos_hpsdr_kiss/branches/K9TRV/libusb0-driver-signed<br />
<br />
Please see my listserver posting on 12 May 2010 in the archives...<br />
<br />
<blockquote><br />
'''BECAUSE OF THIS, I HAVE STOPPED ANY MAINTENANCE ON THE WinUSB version of KISS'''<br />
</blockquote><br />
<br />
''Update, 28 July 2010, George Byrkit, K9TRV'' <br />
<br />
This page contains information on using WinUSB with HPSDR hardware.<br />
<br />
First, let's all be clear that WinUSB used as a driver replaces libusb0 used as a driver for some particular device, like the Ozy board. If you install WinUSB as the driver for Ozy, libusb0 is no longer the driver. So applications that use libusb0 (like PowerSDR, until Bill Tracey KD5TFD finished porting [[PowerSDR]] to WinUSB, or like [http://www.dxatlas.com/CwSkimmer/ CWSkimmer], which use libusb0 to speak to [[OZY]]) are not able to coexist with my branch of KISS. My branch of [[KISS Konsole]] uses WinUSB.<br />
<br />
So it's an either/or proposition. If you need libusb0, and can install libusb0 as the driver, and can run [[PowerSDR]], you want to use Phil VK6APH's branch of [[KISS Konsole]]. His branch is the 'original', and is considered to be the main development branch. I try to keep step with his branch, and feed common bugs and hopefully their solutions back to him. I'm keeping step best as I can with Phil's development work using the [[HERMES]] board, as well.<br />
<br />
It seems that WinUSB is needed to use KISS (thus my branch is needed...) on Windows 64 bit OS versions, such as Vista 64 bit and Windows 7, 64 bit. Some have reported trouble using libusb0-based KISS on Windows 7 32 bit. These people report that my WinUSB branch does work fine on Windows 7, 32 bit (with WinUSB installed as the driver). This problem on 32 bit Vista and 32 bit Windows 7 has recently (approx 15 Jan 2010) traced to a problem in HPSDR_USB_LIB_V1.dll by Bill Tracey (KD5TFD), who has fixed this problem! He has mentioned this on the reflector (hpsdr mailing list), and has posted a fixed library. Phil is testing and updating his development branch to include this fixed file. Those of you using Vista 32 bit and Windows 7 32 bit may well wish to use that version and not my WinUSB version! That way, you can use both PowerSDR and KISS, and optionally use [http://www.dxatlas.com/CwSkimmer/ CWSkimmer] and other similar applications.<br />
<br />
Is there anything that WinUSB can do that libusb0 cannot do, other than work on a 64 bit machine? It seems that, yes, there is at least one advantage to WinUSB. WinUSB is able to detect an [[OZY]] or [[HERMES]] board that is plugged in or powered on AFTER KISS has been launched. Libusb0 required that Ozy be plugged in and powered on BEFORE launching/running KISS (or PowerSDR). So this is an advantage. Is there any disadvantage? I think that yes, there is. I don't have data to back it up, but libusb0 seems more 'performant' than WinUSB. What do I mean by that? I think that libusb0 has fewer delays and may use a larger blocksize for transfers than WinUSB does. What is the evidence? KISS using libusb0 has no troubles doing the normal (band) spectrum display, along with the full bandwidth display. I found that I had to reduce the number of data points (samples) for the full spectrum display from 8192 to 4096, to get rid of distorted, chopped audio. I think that Alberto came to the same conclusion.<br />
<br />
====WinRad origins====<br />
<br />
The first thing that you will need is the WinUSB driver package from Alberto, I2PHD, from www.weaksignals.com. [http://www.weaksignals.com Alberto I2PHD's WinRad site] Go to his website and download his WinRad package, which will give you his WinUSB driver installer. Using this installer should let you install WinUSB as the driver for your hardware on Windows XP, Vista and Windows 7, whether you have a 32 bit OS, or Intel/AMD 64 bit OS (x86 architecture) or Intel Itanium IA64 64 bit OS versions of windows installed.<br />
<br />
You will also be able to use WinRad, until Bill KD5TFD ports PowerSDR to WinUSB.<br />
<br />
Alberto has some very good notes on installing the driver, or replacing libusb0 with WinUSB, as part of his package. I suggest that you read his notes and follow his directions. I think that you have to install WinUSB twice for Ozy, once when Ozy contains no programming, and once when Ozy has has its firmware downloaded. You can also find these drivers, newly fixed so that 64 bit Intel/AMD x86 OS install works, in the WinUSBDrivers folder under my SVN archive listed below. You will still want Alberto's instructions...<br />
<br />
There were errors in the 64 bit installers, due to an error Microsoft had in their 'Using WinUSB' document. I consulted with Microsoft, who made me aware of the errors. I communicated these facts to Alberto I2PHD and Phil N8VB, who are updating their .inf files to fix the 64 bit x86 architecture processor installations correspondingly. Some teamwork and mutual communications was involved. Everyone has a better result due to the work that was done co-operatively.<br />
<br />
====Other interesting projects and info on WinUSB====<br />
<br />
:1) The SourceForge (www.sourceforge.net) project called LibUsbDotNet. You can download both source and binary. This is a project that allows .Net code to use either libusb0 or WinUSB, without the application program having to know which driver is installed for the hardware. This is not yet being used by KISS or HPSDR, but does hold some promise on Windows for this option. Using LibUsbDotNet would allow a single version of KISS, for example, to exist that would work with either libusb0 or WinUSB.<br />
<br />
:2) the website http://www.lvr.com/winusb.htm, which contains information on WinUSB, USB in general, sample code, much other information and sample code on things like Serial Ports, Parallel Ports, ethernet, and more. Its maintainer, Jan Axelson, has also written a number of books on these topics. I found his winusb_cs to be very helpful to study in porting KISS and its support programs from libusb0 to WinUSB. [http://www.lvr.com/winusb.htm Jan Axelson's website]<br />
<br />
What has been ported from libusb0 to WinUSB?<br />
:1) Phil Harman VK6APH's project KISS Console<br />
:2) supporting programs like loadfw.exe, loadfpga.exe and writei2c.exe<br />
:3) there is also a Visual Studio 2008 project called WinUSBAPI that is Alberto's Borland C++ Builder code ported to VS2008 C++. It doesn't yet have all the methods that the C# project WinUSBManaged that I wrote does. Hopefully, I'll find the time to back-port those methods from WinUSBManaged to WinUSBApi.<br />
<br />
The purpose of the 'supporting programs' (which also use winusbmanaged.dll) is to replace the current versions that use libusb0. With these, you can update the versions in your usbblaster-binaries folder so that you can still update the firmware in Penelope, Mercury and other boards. You may have multiple places where these are needed. Up-to-date copies are in my "KISS Konsole\bin\release" and "Kiss Konsole\bin\debug" folders, so that initozy11.bat that is in those folders will continue to work.<br />
<br />
Where can I find this new code that uses WinUSB?<br />
Try this svn path (K9TRV's KISS Branch): <br />
<br />
svn://184.81.173.3/svn/repos_hpsdr_kiss/branches/K9TRV<br />
<br />
== '''So, you're going to be running or recompiling the KISS code on a 64 bit machine?''' ==<br />
<br />
<br />
If so, then you'll need to check the 'fftw' subfolder in my branch for the 64 bit dll. I've provided the installers for the 32 bit and 64 bit fftw dlls, from the [http://www.fftw.org/ http://www.fftw.org/] website. Please either install the 64 bit package and replace all versions of the 32 bit dll with the dll it installs. Much easier is to copy and rename the libfftw3f64.dll to libfftw3f.dll, especially in the bin\release and bin\debug folders of my version of the [[KISS Konsole]] project. I've already placed libfftw3f64.dll in those directories for your convenience. Replacing the current libfftw3f.dll is then all you need to do. I suggest that you rename the current libfftw3f.dll file (to anything else...), then copy libfftw3f64.dll and rename the copy to libfftw3f.dll. Thanks to Dr. Hermann von Hasseln, DL3HVH, for this information!<br />
<br />
The alternative to this renaming is to rebuild SharpDSP, but ONLY after editing its file DSPBuffer.cs to change the line containing library_name = "libfftw3f.dll" to library_name = "libfftw3f64.dll".<br />
<br />
The issue here is that both KISS and Sharp_DSP are built with the 'mixed cpu' setting (see Configuration Manager), and thus when run on a 64 bit system, 64 bit code is generated (at run time! you don't even need to recompile! That's how .NET framework programs work...), and all DLLs that are called MUST BE 64 bit dlls. If you will tolerate 32 bit code on your 64 bit system, you can use the Configuration Manager and change the cpu type for BOTH KISS and Sharp_DSP to 'x86'. This will cause only 32 bit code to be generated. This will allow the 32 bit versions of FFTW as well as libusb0 to be used...<br />
<br />
So I cannot test the above, as I don't have a 64 bit OS installed to check it on. You can also find processor selection on the Build page of a project's properties. Double-click on Properties in the Kiss Konsole project in the solution explorer pane. This will bring up some tabbed dialogs in the main window. Select the 'build' tab. Note the combo-box to the right of the text saying 'Platform target'. This will by default be set to 'Any CPU'. You could choose to set it to 'x86' to force 32 bit code to be generated. Selecting 'x64' would force 64 bit code to be generated, which wouldn't work on 32 bit OS installations, and would require all 64 bit dlls be available (libusb0, probably and libfftw3f for 64 bit for sure!). I'd be willing to be that no one has an Itanium CPU, so please don't select that one...<br />
<br />
If you change the setting for KISS Konsole, make SURE that you make the setting for Sharp_DSP match! Otherwise, things just won't work... In my KISS branch, the Sharp_DSP project is part of the KISS Konsole solution, so this is easier to do. If you are using Phil's branch, you either need to add the Sharp_DSP project to the KISS solution, or make sure that you open the Sharp_DSP solution and make the needed changes in the Sharp_DSP project build settings and rebuild.<br />
<br />
[[Category:Software]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Multiple_independent_receivers_-_how_to_set_up_on_Windows&diff=3930Multiple independent receivers - how to set up on Windows2011-01-06T23:32:11Z<p>VK2NRA: URL vs IP</p>
<hr />
<div>The ability to have multiple independent receivers using a single Mercury is made possible<br />
by the efforts of Kirk Weedman KD7IRS, John Melton G0ORX / N6LYT, and Bruce Walker W1BW.<br />
Two of the parts of John Melton's [[ghpsdr3]] have been ported to Windows (tested on XP 32 bit)<br />
The two pieces are "server" and "dspserver". These two, with Mercury FPGA version 3.0 and the corresponding Ozy code (version 1.8), <br />
provide for four simulteneous independent receivers for a single [[MERCURY]] board, using John's <br />
jmonitor as the (minimal) receiver graphical user interface. The controls available for <br />
each receiver are fewer than with [[PowerSDR]] or [[KISS Konsole]], but are quite adequate for monitoring <br />
up to four 96kHz segments in the frequency range 0 to 55 MHz simultaneously.<br />
<br />
No transmit capability is provided.<br />
<br />
All files needed to run server and dspserver on Windows may be found on the SVN<br />
<br />
svn://svn.openhpsdr.org/svn/repos_hpsdr_kiss/branches/WA8YWQ/ghpsdr3-Windows<br />
<br />
You'll find the following folders<br />
<pre><br />
Folder Contents<br />
bin Executables and all files needed to run<br />
dist java files for jmonitor (you'll need to have installed java)<br />
dspserver source for dspserver, with solution/project files<br />
DttSP source for DSP package, with solution/project files to create .dll<br />
LoadMercuryFirmware all files needed to load Mercury FPGA with V3.0<br />
server source for server, with VS2003 solution/project files<br />
</pre><br />
<br />
Both server and dspserver are written in pure C (no C++). The files include project (solution) files for<br />
Visual Studio 2003. You'll probably have no trouble using VS2005 or VS2008.<br />
I've added #ifdef ... #endif so that (hopefully) the same code may be compiled on Windows<br />
and on Linux. Once any problems have been ironed out, the merged code will be placed in the<br />
SVN trunk, rather than branch, so that further development will simultaneously apply to both<br />
Windows and Linux.<br />
<br />
In the future, additional options will be explored / implemented. These include using the fully-<br />
featured ghpsdr3 receiver user interface, other receiver interfaces, connections to digital mode<br />
software, and special communication software, such as [http://physics.princeton.edu/pulsar/K1JT/wspr.html WSPR]. Transmit capability may also be possible.<br />
(Of course WSPR needs to transmit. I'd hope that one could run WSPR on four bands simultaneously,<br />
with the software setting Penelope frequency as needed.)<br />
<br />
The server part loads Ozy FX2 and FPGA via the USB, sends I & Q samples to dspservers 0 thru 3,<br />
and sends demodulated audio (for receiver 0 only) back to Ozy and Mercury. Each jmonitor sends <br />
demodulated audio to computer's sound card. When more than one receiver is active, the sound <br />
card output is the sum of audio from all active receivers. If you want to listen to only one, <br />
reduce the AFGain to zero on other instances of jmonitor. The server does not read the 55 MHz wide<br />
spectrum samples from [[OZY]] / [[MERCURY]] (USB endpoint 4).<br />
<br />
Each functional receiver uses its own instances of dspserver and jmonitor. dspserver provides the<br />
passband filtering, demodulation, AGC, and noise reduction.<br />
<br />
server and dspserver are launched from a command window ("DOS window"), and each is started with<br />
some command-line arguments, or options.<br />
<br />
For the server, the options are--<br />
<pre><br />
receivers 1, 2, 3, or 4 The number of simultaneous receivers to be supported<br />
samplerate 96000 One of 48000, 96000, 192000 (only tested with 96000)<br />
dither on / off Setting for Mercury ADC<br />
random on / off Setting for Mercury ADC<br />
preamp on / off Setting for Mercury<br />
10mhzsource atlas / penelope / mercury<br />
122.8mhzsource penelope / mercury<br />
micsource penelope / janus<br />
class other / E<br />
timing<br />
<br />
The default settings are<br />
receivers 1<br />
samplerate 96000<br />
dither off<br />
random off<br />
preamp off<br />
10mhzsource mercury<br />
122.88mhzsource mercury<br />
micsource penelope<br />
class other<br />
</pre><br />
<br />
You only need to specify the options whose values need to be different from the defaults.<br />
<br />
For the dspserver, the options are--<br />
<pre><br />
dspserver options:<br />
soundcard SANTA_CRUZ, AUDIGY_2_ZS, MP3_PLUS, EXTIGY, <br />
DELTA_44, FIREBOX, EDIROL_FA_66, HPSDR<br />
receiver 0 - 3<br />
server IP address<br />
offset ?<br />
<br />
default values:<br />
soundcard HPSDR<br />
server 127.0.0.1 (this is "localhost")<br />
receiver 0<br />
offset 0<br />
</pre><br />
<br />
To make it easy to launch multiple receivers, make a folder with a short path name, <br />
such as C:\MultiRx<br />
<br />
Into this folder place the following--<br />
<pre><br />
libfftw3f-3.dll<br />
pthreadVC2.dll<br />
jmonitor.jar<br />
ozyfw-sdr1k.hex<br />
Ozy_Janus.rbf<br />
server.exe<br />
dspserver.exe<br />
folder "lib" from the java dist folder<br />
</pre><br />
<br />
Here's how to start the system--<br />
<pre><br />
First command window<br />
cd \MultiRx<br />
server --receivers 4 <br />
<br />
<br />
2nd command window<br />
cd \MultiRx<br />
dspserver --receiver 0<br />
<br />
<br />
3rd command window<br />
cd \MultiRx<br />
java -jar "jmonitor.jar" --server 127.0.0.1 --receiver 0<br />
</pre><br />
<br />
Now you have one receiver running.<br />
<br />
To use more than one simultaneous receiver,<br />
<pre><br />
When launching server, use a value greater than 1 for the number of receivers.<br />
Launch multiple copies of dspserver and jmonitor, each from their own command window, <br />
using different receiver numbers--ie 0, 1, 2, 3 <br />
(Only one instance of server is needed--it supplies connection to the hardware <br />
for all receivers.)<br />
</pre><br />
<br />
With 4 receivers running, you'll have 9 command windows open.<br />
<br />
<br />
When server starts it says--<br />
<pre><br />
Listening for TCP connections on port 11000<br />
(a few seconds delay while Ozy FX2 and FPGA are loaded)<br />
... (hex dumps of 9 USB frames)<br />
server configured for 4 receivers at 96000<br />
Ozy Software version 18<br />
Mercury Software version 30<br />
<br />
client_socket 1832<br />
client connected 127.0.0.1:12000<br />
client connected: 127.0.0.1:12000<br />
parse_command(Rx-842150451): 'attach 0'<br />
response(Rx0): OK 96000'<br />
parse_command(Rx0): 'start iq 13000'<br />
response(Rx0): 'OK'<br />
audio_thread port=15000<br />
listening for rx 0 audio on port 15000<br />
</pre><br />
<br />
When dspserver starts it says (socket numbers and buffer addresses will be different on your system)--<br />
<pre><br />
hHPSDR rx 0 (Version 0.6)<br />
getSoundcardID: HPSDR id=8<br />
setSoundcard: 8<br />
setSoundcard -11 000000 -25 000000<br />
setup_system_audio: sdr-5044-0<br />
setup_system_audio: sdr-5044-1<br />
client_init audio_buffer_size=2000 audio_buffer=9736336<br />
client_thread<br />
client_thread: listening on port 8000<br />
ozy_init: command bound to port 12000 socket 1808<br />
ozy_init: server 127.0.0.1<br />
connect: sampleRate=96000<br />
setSpeed 1<br />
ozy_init: iq bound to port 13000 socket=1776<br />
iq_thread: socket 1784<br />
output_sample_increment=2<br />
</pre><br />
<br />
(when jmonitor for Rx 0 starts, dspserver says:)<br />
<pre><br />
26/06/2010 23:48:29 RX0: client connection from 127.0.0.1:2995<br />
client message: setFrequency 7048000<br />
client message: setMode 0<br />
client message: setFilter -2850 -150<br />
client message: SetRXOutputGain 30<br />
client message: start AudioStream 480<br />
</pre><br />
<br />
As you start additional receivers, and make changes to the state of each of the receivers,<br />
you'll see more output from server and the dspservers.<br />
<br />
Some information on how to make a receiver available on the internet may be found at<br />
<br />
http://www.n9vv.com/N6LYT-Online-Mercury-Receiver.pdf<br />
<br />
Please post your comments and questions to the openhpsdr email reflector, hpsdr (at) openhpsdr.org.</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=PHOENIX&diff=3929PHOENIX2011-01-06T23:31:29Z<p>VK2NRA: URL vs IP</p>
<hr />
<div>'''PHOENIX - is a ISD/QSE Receiver/Transmitter Module'''<br />
<br />
<br />
'''Update 29 March 2010'''<br />
<br />
Richard, VK6BRO, has layed out a V2 PCB in an attempt to elimimate the large number of spurs that the V1 boards produced. <br />
The latest PCB layout, in Kicad format, are available here:<br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/Phoenix/Phoenix_V2<br />
<br />
<br />
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.<br />
<br />
A number of Alpha builders are currently constructing boards; these include Al, N0TVJ, Bill, KD5TFD, Kevin, M0KHZ and Phil, VK6APH. <br />
<br />
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. <br />
<br />
[[Image:Phoenix.JPG|thumb|500px|VK6APH's partly completed Phoenix board, November 2008]]<br />
<br />
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.<br />
<br />
Relevant files for the Phoenix project can be found under SVN at the following location:<br />
* svn://184.81.173.3/svn/repos_sdr_hpsdr/trunk/Phoenix<br />
<br />
[[Image:First_Phoenix_Signal.JPG|thumb|500px|VK6APH's Alpha Phoenix board feeding a Janus sound card and running with PowerSDR, November 2008 ]]<br />
<br />
More test results to follow - Phil....VK6APH <br />
<br />
The Phoenix PCB contains a ISD (Integrating Sampling Detector) based HF Receiver, a QSE (Quadrature Sampling Exciter) based HF Exciter and a supporting synthesizer.<br />
<br />
<!-- [[Image:phoenix_bird.jpg]]<br />
<br />
This image of a Phoenix Bird is emblazoned on 8 trams in Brisbane, Australia that were rebuilt and 'arose from the ashes' after the Paddington tram depot fire in 1962. The artist, Ken Howard, has released all rights to this drawing. <br />
<br />
--><br />
<br />
=== GENERAL DESCRIPTION ===<br />
<br />
The initial project leader was Ray Anderson, WB6TPU<br />
<br />
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).<br />
<br />
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....<br />
<br />
Inital Block diagram for discussion:<br />
<br />
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)<br />
<br />
[[Image:phoenix_simplified_block2.jpg]]<br />
<br />
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.<br />
<br />
[[Image:phoenix_simplified_block4.jpg]]<br />
<br />
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.<br />
<br />
[[Image:Phoenix_rx_1.jpg]]<br />
<br />
Feature List for Discussion:<br />
<br />
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:<br />
<br />
Synthesizer:<br />
<br />
:Utilize AD9951 with a divide by 4 to generate quadrature LO signals<br />
:Utilize 2 AD9951 with phase offset<br />
:Microwave PLL divided down to HF<br />
<br />
(as a general thing, suggestions are running towards avoiding 10-bit DDS circuits due to spurious considerations)<br />
<br />
Preamp:<br />
<br />
A robust high dynamic range low noise preamp has been suggested to precede the detector. Suggestions include:<br />
<br />
:Norton amplifier (noiseless feedback) amplifier using BFG591<br />
:Makhinson amplifier (push-pull version of Norton amp)<br />
<br />
Rx Filters:<br />
<br />
:Switched BPF filters<br />
:Broadband (0-30 MHz) frontend with external BPF<br />
<br />
QSD: It is looking like either a 74auc2g53 with OPA1632 or LT1127 amps may end up being the ISD (integrating sampling detector).<br />
<br />
The OPA1632 variant is being evaluated by Ahti OH2RZ and the LT1127 variant is being looked at by Phil N8VB.<br />
<br />
This is a critical part of the circuit as far as overall performance is concerned.<br />
<br />
'''Jan 2008 (Richard Hosking VK6BRO)'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
Look at the various schematics at: [[Phoenix Schematics]] and the current PCB layouts are at: [[Phoenix Layouts]]<br />
<br />
Please contact me if you want to play with Kicad for the various libraries<br />
<br />
[[Category:Phoenix| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Quick_Startup_Guide_(Windows)&diff=3928Quick Startup Guide (Windows)2011-01-06T23:30:09Z<p>VK2NRA: /* PowerSDR Software Installation */ URL vs IP</p>
<hr />
<div>'''Quick Startup Guide''' for PCs running Microsoft Windows'''<br />
<br />
== System Real-Time Capabilities ==<br />
<br />
Processing of streaming data in real-time can be a challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that tasks can be executed in a deterministic (timely) manner. <br />
<br />
Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and later) there is a specific interrupt handling mechanism. When a device driver cannot process data immediately in its interrupt routine, it schedules a DPC. <br />
<br />
Microsoft defines them as ''A Deferred Procedure Call (DPC) is a queued call to a kernel-mode function that will usually be executed at a later time. DPCs are used by drivers to schedule I/O operations that do not have to take place in an ISR at a high IRQL, and can instead be safely postponed until the processor IRQL has been lowered.''<br />
<br />
When you look at Windows Task Manager and sort the running processes by CPU (Processor Utilization), the System Idle Process is almost always at the top of the list. What you may not know is that “process” is really a roll-up of several things. Among other things, included in that CPU number, is hardware interrupts and DPCs. You can see these two items by using the Microsoft “SysInternals” Process Explorer available here: [http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx Process Explorer] <br />
<br />
Thesycon's DPC Latency Checker is a free Windows tool that analyses the capabilities of a computer system to handle real-time data streams properly. It may help you to determine if your PC is capable of powering your HPSDR system or find the cause for interruptions in real-time audio and video streams, also known as drop-outs. The program supports Windows 2000, Windows XP, Windows XP x64, Windows Server 2003, Windows Server 2003 x64, Windows Vista, Windows Vista x64 and is available here: [http://www.thesycon.de/deu/latency_check.shtml DPC Latency Checker]<br />
<br />
== USBIO Driver ==<br />
Before connecting your HPSDR equipment you will need to install the USBIO drivers that can be found at FlexRadio or just click here: [http://support.flex-radio.com/Downloads.aspx?id=50 USBIO Driver]. You will need to have administrator rights on your Windows system for this install to complete. During install make sure you check the box that allows this driver to be used by everyone, not just the current user. Once the install has completed reboot your PC even if the driver install does not prompt you to restart. <br />
<br />
By default the installation program will install this driver on your system in this directory: <br />
<br />
C:\Program Files\FlexRadio Systems\USBIO Driver<br />
<br />
''('''Note:''' HPSDR requires that your PC has USB 2.0 ports. USB 1.x ports will not work.)''<br />
<br />
== .NET Framework ==<br />
The HPSDR version of PowerSDR requires that your system have Microsoft's .NET Framework version 1.1 installed. Most systems already have the framework, however, in case you need it here is the link:<br />
<br />
[http://www.microsoft.com/downloads/details.aspx?FamilyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en .NET Framework 1.1]<br />
<br />
If you are going to use Ozy to program software updates into Mercury and Penelope, then you also need Framework 2.0.<br />
<br />
[http://www.microsoft.com/downloads/details.aspx?familyid=79BC3B77-E02C-4AD3-AACF-A7633F706BA5&displaylang=en .NET 2.0 SP1]<br />
<br />
== PowerSDR Software Installation ==<br />
Currently, there is a lot of development activity and expected updates to HPSDR firmware and software. Because the software is fluid, and the developers desire to post releases quickly and as often as possible, a manual installation is easier to manage. This step will eventually be relplaced with a more standard software setup.<br />
<br />
To use [[MERCURY|Mercury]] and [[PENELOPE|Penelope]], you will need the latest released PowerSDR software from the "PennyMerge" branch of the open-source development tree. The repository is managed by Subversion, which is a popular collaborative software/firmware development tool for open-source projects. To access this software you will need to install and use a Subversion (SVN) client, see [[How to use SVN]]. There are several out there, however, TortoiseSVN for Windows XP can be downloaded from here:<br />
<br />
[http://tortoisesvn.net/ TortoiseSVN]<br />
<br />
Once TortoiseSVN is installed, follow these steps:<br />
<br />
# Create the following directory structure<br/>C:\HPSDR\PennyMerge<br/>''(this is an arbitrary convention, but logical and easy to find)''<br />
# Navigate to HPSDR<br/>Click Start and select Run...<br/>Type: C:\HPSDR then [Enter]<br/>You should see a PennyMerge directory in the window that opens.<br />
# Download the latest software<br/>Right click on the PennyMerge directory<br/>Select SVN Checkout...<br/>Type or copy & paste the following line into the "URL of repository" field:<br/><br/><tt><br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_windows/PowerSDR/branches/kd5tfd/PennyMerge/bin/Release</tt><br />
<br />
<br/><br/<br />
>Click OK<br/>At this point, TortoiseSVN should begin downloading the most current released version of the PowerSDR client for HPSDR. Once it completes go to step 4.<br/>''('''Note:''' To update to subsequent releases, you can right click the PennyMerge directory and select SVN Update...)''<br />
# Copy the files to a working directory for better version control.<br/>This directory can be anywhere you like, but we recommend using<br/><tt>C:\Program Files\FlexRadio Systems\HPSDR\</tt><br/>If you are updating an existing installation, make sure PowerSDR is not running before you write over the old version.<br />
# To create a PowerSDR desktop shortcut<br/>Open the working directory (where you copied the files i.e. <tt>C:\Program Files\FlexRadio Systems\HPSDR\</tt>)<br/>Locate the PowerSDR application file (PowerSDR.exe)<br/>Right-click on PowerSDR.exe then drag and drop it to your desktop<br/>Select "Create Shortcuts Here"<br/>''('''Note:''' It is no longer required to start PowerSDR with the --ignore-pp-ptt flag.)''<br />
<br />
== HPSDR Board Installation ==<br />
The current release versions of the HPSDR firmware does NOT require attention to the order you install the HPSDR board set on the Atlas buss. If you are using previous versions, there are several arrangements that are reported to be successful; however, this order is one of the most common:<br />
<br />
On [[ATLAS|Atlas]] J6 is next to the power connector, J1 is farthest away:<br />
* Slot J5: Mercury <br />
* Slot J3: Penelope ''(if used, open jumper J8 on Mercury, this disables Mercury's 10Mhz clock)''<br />
* Slot J2: Ozy<br />
<br />
=== What About Janus? ===<br />
<br />
[[JANUS|Janus]] is a high performance replacement soundcard for radios that produce analog I-Q inputs and outputs (like a FLEX-1000 or a Softrock). If you are using your HPSDR to control radios like these then you will need Janus. If you are running Mercury and Penelope, Janus is not needed as their I-Q signals are already in digital format.<br />
:''('''Note:''' As of 5/30/09 the firmware team has released a fix for board order dependency)''<br />
:''('''Note:''' Receiver audio is output from one of the two 1/8" stereo jacks on the Mercury board. The upper jack is at line level, the lower is suitable for headphones)''<br />
<br />
== USB Device Detection ==<br />
# Connect your power supply to Atlas - Remember that poor supply voltages will cause you problems - be certain your supply is capable of supplying the right current and voltage during operation.<br />
# Connect Ozy to a USB 2.0 port on your PC or USB 2.0 hub.<br />
# Power up the Atlas - at this point Windows should detect there is a new USB device and pop-up the standard Windows driver installation wizard. Note: you may need to manually direct the wizard to the C:\Program Files\FlexRadio Systems\USBIO Driver directory and install the correct driver.<br />
# You should see a USB device named "OZY Host Assisted Firmware Load" listed in your USB devices.<br />
<br />
:''('''Note:''' If there is a problem at this point, it needs to be resolved before moving on. There have been posts that eventually required corrections to power supplys, USB cables and/or hubs.)''<br />
<br />
== PowerSDR Configuration ==<br />
Double-click on the shortcut you created to start PowerSDR. When it first starts, it will go through a short system speed test.<br />
<br />
The latest PennyMerge PowerSDR release features a Wizard to more easily configure HPSDR systems. If this is the first time PowerSDR has run the wizard should automatically start. Just answer the wizard's questions. <br />
<br />
# Select HPSDR radio button<br />
# Click Next<br />
# Select the hardware you have installed on Atlas ''(Ozy is assumed and Alex is the filter board set not yet generally available)''<br />
# Click Finish<br />
# Select Setup from the main menu. ''(note that you can also restart the wizard here)''<br />
# Select the General Tab.<br />
# Select the HPSDR tab ''(next to Hardware Config)''<br />
# Select the correct 10MHz Clock Source for your system. ''(e.g. Mercury or Penelope, select Atlas if you are using Excalibur)''<br />
# Set Mercury as the 122.88 MHz Clock Source if using the latest code version, otherwise see this [http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/2009-May/009647.html message].<br />
# Click Apply if you changed anything.<br />
# Select the Audio tab in the PowerSDR Setup window and confirm that the Sample Rate is 192000. ''('''Important Note:''' it is possible to select a lower sample rate, but unless you are testing Mercury 2.x beta firmware releases, any sample rate other than 192000 will not work correctly.)''<br />
# Click Apply if necessary - then close the Setup window.<br />
<br />
== Startup ==<br />
At this point you should be ready to start up the system for the first time. Click "Start" in PowerSDR and you should be good to go.<br />
<br />
For instructions on how to operate PowerSDR, and further information on how to configure PowerSDR, please read Chapters 3, 4, 5, 6 and Appendix A of the Flex-5000 manual on the FlexRadio website...<br/><br/>[http://support.flex-radio.com/Downloads.aspx?id=246 Flex-5000 Owners Manual v1.14.0]<br />
<br />
:''('''Note:''' If you receive an error message noting Ozy software is not loaded, then you probably don't have all of the release software files in your working directory. Follow the instructions above in the '''PowerSDR Software Installation''' section above and copy '''ALL''' of the release files from the SVN managed directory into your working directory. The Ozy code download files and script must be in the same directory as PowerSDR.exe.'' <br />
<br />
:''('''Note:''' it's normal to see a command window open and start scrolling text when you first start PowerSDR. It is not normal to see errors during startup)''<br />
<br />
== Calibration ==<br />
The latest version of PowerSDR allows calibration of both frequency and level. It is usually only necessary to calibrate Mercury when you update Mercury firmware or the settings file (PowerSDR.mdb) is deleted. <br />
<br />
=== Level Calibration ===<br />
# Connect a calibrated RF generator to the RF-in BNC connector on Mercury. <br />
# Set the RF generator to an appropriate frequency and output level (I use 10Mhz @ 20uV or -81dBm)<br />
# In the PowerSDR Setup->General->Calibration tab, set the Frequency and Level values in the Level Cal group box to match the output of your RF generator. Mosely has a nice dBm to uV table here: [http://www.moseleysb.com/mb/mv2dbm.html Microvolts to dBm Conversion Table]<br />
# Click the Start button in the Level Cal group box and wait for the routine to complete.<br />
<br />
=== Frequency Calibration ===<br />
# Connect a calibrated RF generator to the RF-in BNC connector on Mercury. If you intend to use WWV as the frequency calibration source, connect an appropriate antenna instead. ''('''note:''' the higher the frequency used here, the more accurate the result.)''<br />
# In the PowerSDR Setup->General->Calibration tab, set the Frequency value in the Freq Cal group box to output frequency of your RF generator or use the appropriate WWV frequency.<br />
# Click the Start button in the Freq Cal group box and wait for the routine to complete<br />
<br />
== 64 bit Windows XP and Vista Installation Notes ==<br />
<br />
===USB Driver for Windows XP64===<br />
<br />
1. Download SIXAXIS_libusb-win64.zip from [http://www.4shared.com/file/41034572/1c815fbc/SIXAXIS.html this link]. Unzip this file to a temporary directory.<br />
<br />
2. Plug in the USB cable to Ozy. Don't worry about the fact that there is no driver to install yet. Just cancel the driver installation and let it give you a warning.<br />
<br />
3. In the temporary directory, run the program inf-wizard.exe. In the Device Selection window pick the USB device with Vender ID 0xFFFE, Product ID 0x0007 - that's Ozy. Click Next.<br />
<br />
4. Change Manufacturer to HPSDR. Change Device name to "OZY Host Assisted Firmware Load". Click Next<br />
<br />
5. Select a file name to save this information. I chose HPSDR.inf. Click Next then Finish.<br />
<br />
6. Now go to System Manager and select Device Properties. Ozy should be the USB device with the yellow question mark next to it. It may be under the category "LibUSB-Win32 Devices." Right click and select "Update Driver." Select to install from a specific location and browse to your temporary directory. Click Next and Finish. <br />
<br />
Things should now begin to work properly. PowerSDR will load Ozy over USB and the HPSDR stack will work just like it did under Windows XP 32.<br />
<br />
==Firmware Programming or Upgrade Instructions==<br />
<br />
These steps are required to program or update the firmware for various HPSDR boards. This procedure may be altered for a specific update or release. So please read any additional installation notes or instructions from the release team.<br />
<br />
===Preparation===<br />
<br />
1. Use a Subversion client (see [[How to use SVN]]) and download all the files from:<br />
<br />
svn://184.81.173.3/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
2. Install the Altera Quartus II Programmer application (80MB) [https://www.altera.com/support/software/download/programming/quartus2/dnl-quartus2_programmer.jsp located here].<br />
<br />
''Note: The latest version is V9.0, be sure to install in the default directory. If you must install in a different directory then you will need to edit the appropriate upgrade batch files to reflect the change. A full application installation is required to run the command line programer (quartus_pgm.exe).''<br />
<br />
3. '''THE FIRST TIME YOU UPGRADE''' <br />
<br />
The following procedure loads a USB Blaster capability into your Ozy. This makes it possible to update the firmware on your other HPSDR boards without purchasing additional programming hardware. ''Once the Ozy/USB Blaster firmware has successfully loaded, you should not have to repeat this step.''<br />
<br />
:a. Connect just your Ozy board to the Atlas bus, connect the USB cable and power it on.<br />
:b. Run the file usbblaster.bat. This will load the code in the FX2 to make it appear to be an Altera USBblaster. <br />
:c. Windows will detect a new USB device. You need to install the drivers for it. Click [http://www.altera.com/literature/ug/ug_usb_blstr.pdf here] for driver installation instructions. What you need can be found in section 1.3.<br />
:d. The Found New Hardware Wizard will open.<br />
::Select Install from a list or specific location and browse to C:/altera/''[installed version]''/qprogrammer/drivers/usb-blaster. The Wizard will then install Altera USB-Blaster<br />
::Check that the drivers have installed correctly by looking in Start\Control Panel\System\Hardware\Device Manager\Universal Serial Bus controllers there should be an entry marked Altera USB-Blaster<br />
<br />
===Mercury Firmware Upgrade===<br />
<br />
# Power off your Atlas board.<br />
# Remove all boards except Ozy.<br />
# Make sure your Ozy board is placed one slot away from the power connector on Atlas.<br />
# Fit a jumper on Mercury to the JP7 header pins marked ''LAST JTAG'' at bottom left of the board just above the Atlas connector.<br />
# Install Mercury in the slot between Ozy and the power connector.<br />
# Power up the Atlas board.<br />
# Run the batch file Program-Mercury-EPCS16.bat, select which version of the Altera Quartus programmer code you are using and the Mercury firmware version you wish to load and look at the output, there should be no errors. ''Do not interrupt the loading process, it takes approximately 1 minute to load the EPCS16.''<br />
# Power off your Atlas board.<br />
# Remove the jumper on JP7.<br />
# Continue with additional firmware upgrades or read restarting after firmware upgrade below.<br />
<br />
===Penelope Firmware Upgrade===<br />
<br />
# Power off your Atlas board.<br />
# Remove all boards except Ozy.<br />
# Make sure your Ozy board is placed one slot away from the power connector on Atlas.<br />
# Fit a jumper on Penelope to the JP7 header pins marked ''LAST'' located at the edge of the board next to the FPGA.<br />
# Install Penelope in the slot between Ozy and the power connector.<br />
# Power up the Atlas board.<br />
# Run the batch file Program-Penelope--EPCS4.bat, select which version of the Altera Quartus programmer code you are using and the Penelope firmware version you wish to load and look at the output, there should be no errors. ''Do not interrupt the loading process, it takes approximately 15 seconds to load the EPCS4.''<br />
# Power off your Atlas board.<br />
# Remove the jumper on JP7.<br />
# Continue with additional firmware upgrades or read restarting after firmware upgrade below.<br />
<br />
===Janus Firmware Upgrade===<br />
<br />
# Power off your Atlas board.<br />
# Remove all boards except Ozy.<br />
# Make sure your Ozy board is placed one slot away from the power connector on Atlas.<br />
# Fit a jumper on Janus to the JP12 header pins marked ''LAST JTAG'' located at the bottom left of the board just above the Atlas connector.<br />
# Install Janus in the slot between Ozy and the power connector.<br />
# Power up the Atlas board.<br />
# Run the batch file Program-Janus-EPM240T100.bat, select which version of the Altera Quartus programmer code you are using and the Janus firmware version you wish to load and look at the output, there should be no errors. ''Do not interrupt the loading process; it takes approximately 5 seconds to load the EPM240T100.''<br />
# Power off your Atlas board.<br />
# Remove the jumper on JP12.<br />
# Continue with additional firmware upgrades or read restarting after firmware upgrade below.<br />
<br />
===Restarting After a Firmware Upgrade===<br />
# Place your HPSDR boards in their operational slots.<br />
# Download any new update for PowerSDR (there is usually a corresponding update with new firmware).<br />
# Make a note of any important settings in PowerSDR. ''(Hint: Use Alt-PrtScn to take a screen capture of the PowerSDR settings you want to save, paste the capture into the Paint program or other image editor, then print or save the image for reference)''<br />
# Make a backup copy of the settings file (PowerSDR.mdb), then delete the original. PowerSDR will rebuild it when it starts.<br />
# Power cycle the supply to the Atlas bus. <br />
# Make any important settings from the notes that were saved above.<br />
# If necessary recalibrate Frequency and Level.<br />
# Test Mercury/Penelope/Janus with PowerSDR.<br />
<br />
[[Category:PowerSDR| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=PowerSDR&diff=3927PowerSDR2011-01-06T23:28:42Z<p>VK2NRA: URL vs IP</p>
<hr />
<div>[[Image:PowerSDR1.19.3.jpg|thumb|400px|PowerSDR in operation by Ron, W9KFB ]]<br />
'''PowerSDR''' is the Microsoft Windows based client [[HPSDR related software|software]] created by [http://www.flex-radio.com/Products.aspx?topic=powersdr1x Flexradio] to operate their software defined radios.<br />
<br />
<br />
<br />
It has been adapted (primarily by Bill Tracey, KD5TFD and Doug Wigley, W5WC) to work with the HPSDR [[MERCURY|Mercury]], [[PENELOPE|Penelope]], [[OZY|Ozy]], [[MAGISTER|Magister]], and [[EXCALIBUR|Excalibur]] boards. Features of the software also support the [[ANTENNA SWITCH|Antenna Switch]], [[ALEXIARES|Alexiares]], and the [[HERCULES|Hercules 100 Watt Amplifier]]. <br />
<br />
<br />
<br />
As of this writing (May 2010) the latest HPSDR modified version of PowerSDR can be found on the HPSDR source code management system ([[How to use SVN|SVN]]). The address (URL) to use is: <br /> <br />
<br />
svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/W5WC/PowerSDR_HPSDR_1.19.3/bin/Release<br />
<br />
To use this software you will also need to download a "Skins folder". Currently the quickest/easy way to get this folder is to download and install a related program called "PowerSDR-IF Stage" which can be found at URL: http://www.wu2x.com/sdr.html#download<br />
<br />
This Skins folder must be placed in a folder as follows on Windows XP Professional operating systems:<br />
<br />
Windows Disc (C:)<br />
\Documents and Settings<br />
\<username> (Has to be a name other than Administrator, All Users, or Default User)<br />
\Application Data (you must turn on hidden files to see this branch)<br />
\FlexRadio Systems<br />
\PowerSDR ("PowerSDR v 1.19.3" won't work) <br />
\Skins<br />
<br />
On Vista the path is:<br />
Windows Disk (C:)<br />
Users<br />
<username> (Has to be a name other than Administrator, All Users, or Default User)<br />
AppData (you must turn on hidden files to see this branch)<br />
Roaming<br />
FlexRadio Systems<br />
PowerSDR ("PowerSDR v 1.19.3" won't work) <br />
Skins<br />
<br />
On Windows 7 the path is:<br />
<br />
Windows Disk (C:)<br />
Users<br />
<username> (Has to be a name other than Administrator, All Users, or Default User)<br />
AppData (you must turn on hidden files to see this branch)<br />
Roaming<br />
FlexRadio Systems<br />
PowerSDR ("PowerSDR v 1.19.3" won't work) <br />
Skins<br />
<br />
<br />
PowerSDR is licensed under the GPL.<br />
<br />
See the [[Quick Startup Guide]] for installation and configuration notes.<br />
<br />
See also [[PowerSDR Keyboard Shortcut List]].<br />
<br />
[[Category:PowerSDR| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=KISS_Konsole&diff=3926KISS Konsole2011-01-06T23:27:19Z<p>VK2NRA: /* SVN */ URL vs IP</p>
<hr />
<div>[[Image:KKV1.0.0.jpg|thumb|400px|Here is screen shot of V1.0.0. The upper green trace is the full spectrum from 0 - 55MHz and the lower white trace 48kHz of the 20m band. Click to enlarge.]]<br />
K.I.S.S (Keep It Simple Stupid) Konsole is a straightforward PC program that will allow beginners in SDR and DSP programming to get their feet wet.<br />
<br />
KK is intended as a learning experience and not as a competitor or replacement for any existing Console code. Where it goes and what features get added is up to you. <br />
<br />
KISS Konsole is written in C# using the free VS 2008 IDE. The code is heavily commented and aimed at the newbie programmer. It is straight line code with as simple a format as possible.<br />
<br />
The code is available under SVN at: <br />
<br />
svn://svn.openhpsdr.org/svn/repos_hpsdr_kiss <br />
<br />
([[How to use SVN]])<br />
<br />
The directory structure is:<br />
<br />
:\branches - directories containing alpha code from some of the developers. Since it's alpha code the usual caveats apply!<br />
:\tags - directories containing previous Stable Releases<br />
:\trunk - directories containing current Stable Release, Beta Release for user testing, Documents etc<br />
<br />
Beginners, intermediate and expert programmers are encouraged to play with the code, make modifications and share them with the group. <br />
<br />
If you would like to share your modifications with the HPSDR community then please:<br />
<br />
*make your code available under the terms of the GNU General Public License; and<br />
<br />
*Any code you write MUST HAVE SUITABLE COMMENTS in it - too many comments will get you a higher grade! If you find/know a better way of doing something then explain in the comments how it works and how it’s implemented.<br />
<br />
As a novice C# programmer myself my deep gratitude to Bill, KD5TFD, Dave, WA8YWQ and Joe K5SO for their invaluable assistance in getting KK released. We also owe Phil, N8VB our thanks for making his SharpDSP library available under GPL. <br />
<br />
Links to other pages:<br />
<br />
* Known [[KISS Konsole Bugs|bugs]]<br />
* [[KISS Konsole FAQ|Frequently Asked Questions]]<br />
* Feature [[KISS Konsole Requests|requests]]<br />
* Programmers [[KISS Konsole Notes|Notes]]<br />
<br />
<br />
Phil VK6APH<br />
<br />
[[Category:KISS Konsole| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Ghpsdr3&diff=3925Ghpsdr32011-01-06T23:26:17Z<p>VK2NRA: /* SVN */ URL vs IP</p>
<hr />
<div>===Server/Client version of ghpsdr===<br />
[[Image:ghpsdr4.png|thumb|400px|right|Screenshot of the ghpsdr3 GUI on 20 meters. (Click to enlarge)]]<br />
<br />
'''ghpsdr3''' is a software defined radio server/client or server/dspserver/client format program written specifically for HPSDR by John Melton, G0ORX/N6LYT. <br />
<br />
The software is being developed on the Ubuntu version of Linux (specifically version 9.10).<br />
The server and dspserver have been ported to run on Windows--<br />
* [[How to set up on Windows]]<br />
<br />
This version of '''ghpsdr3''' allows for the server and client to be on the same machine or separate machines. The servers are written in C and run on linux machines. John and others are working on a full set of clients to run on multiple machines connecting to the servers through TCP/IP protocals.<br />
<br />
To follow the development of this code look at John's Blog http://g0orx.blogspot.com/<br />
<br />
===SVN===<br />
The software is available from SVN and includes a precompiled executable in the bin directory. There are now a compiled version of the 64-bit linux version, 32-bit linux version and the MacOS version. The README explains how to compile the source if you wish to modify the code.<br />
<br />
Since this code does not currently run on Windows here is the Linux svn command,<br />
<br />
svn co svn://svn.openhpsdr.org/svn/repos_sdr_hpsdr/trunk/N6LYT/ghpsdr3<br />
<br />
[[Image:Screenshot-JMonitor - [[Image:Screenshot-JMonitor - Mozilla Firefox.png|thumb|400px|right|Screenshot of the java in a web browser GUI on 40 meters. (Click to enlarge)]]<br />
<br />
[[Image:Screenshot-QtRadio-8.png|thumb|400px|right|Screenshot of the QtRadio GUI on 40 meters. (Click to enlarge)]]<br />
<br />
===Libraries===<br />
It uses a modifed version of DttSP that is ported from the Windows version. DttSP is built as a static library that is linked with the GUI code. The DttSP code is provided with the SVN distribution.<br />
<br />
You will need a couple of libraries to run this code, they include:<br />
* '''libfftw3''' - [http://www.fftw.org/ FFTW3] is a C subroutine library for computing the discrete Fourier transform (DFT) in one or more dimensions, of arbitrary input size, and of both real and complex data (as well as of even/odd data, i.e. the discrete cosine/sine transforms or DCT/DST).<br />
* '''libgtk2''' - [http://www.gtk.org/ GTK+] is a highly usable, feature rich toolkit for creating graphical user interfaces which boasts cross platform compatibility and an easy to use API.<br />
* '''libusb-1.0''' - [http://www.libusb.org/ libusb] is an open source library that allows you to communicate with USB devices from userspace.<br />
These can be obtain with your package installer.<br />
<br />
===Architecture===<br />
[[Image:ghpsdr3.png|thumb|400px|right|Architecture of the server/dspserver/client configuration. (Click to enlarge)]]<br />
The image illustrates the architecture of the ghpsdr3 software chain. The software works with either the single receiver verilog code (Mercury 2.9) or the multiple receiver verilog code or (Mercury 3.0 experimental). If Mercury 2.9 is install only one receiver can be accessed. (Please not that there is a matching ozyfw-sdr1k.hex and Ozy_Janus.rbf file to go with the different versions of the Mercury code).<br />
<br />
'''HPSDR''' box represented the hardware and the Mercury/Ozy,Penelope, Mercury/Magister,Penelope, or Mercury/OzyII,Penelope <br />
<br />
'''Link between HPSDR and Server''' uses the communication protocol documented in USB Protocol v1.27 at the link on this page or in the SVN in the Documentation directory.<br />
<br />
[[ghpsdr3 Server|'''Server''']] box is a software multiplexer. It takes the multiple receiver communication protocol and divides it in to single receiver channels. <br />
<br />
'''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. <br />
<br />
'''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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
In the summer of 2010 the development of the [[ghpsdr3_QtRadio|'''Qt Radio''']] and [[ghpsdr3 qtmonitor|'''qtmonitor''']] began. This GUI is written in Qt4, an open-source cross platform environment. The code compiles and runs on Linux, Windows and MacOS, this with the jmonitor and the server code written in the C language has been ported from Linux to Windows makes this a multi-platform radio environment.<br />
<br />
All this code can be found in the SVN listed above. Here is a [[ghpsdr3 build| '''build page''']] that helps explain how to build the applications.<br />
<br />
Links to other pages:<br />
<br />
* [[ghpsdr3 FAQ|Frequently Asked Questions]]<br />
* [http://www.tapr.org/pdf/2010-G0ORX-N6LYT-Putting-HPSDR-on-Internet.pdf John Melton's 2010 Dayton presentation on ghpsdr3]<br />
* [[Media:ghpsdr3-protocols2010-08-07.pdf|ghpsdr3 communication protocols 2010-08-07]]<br />
* [[Ghpsdr3 protocols|updated protocol description]]<br />
* [http://www.n9vv.com/N6LYT-Online-Mercury-Receiver.pdf Ken Hoppers N9VV online documentation of the online multi-receiver setup.]<br />
* [[How to set up on Windows]]<br />
* Features List [[ghpsdr3 Requests|requests]]<br />
* Programmers Notes<br />
* - [[ghpsdr3 Ports|Ports]]<br />
* Known [[ghpsdr3 Bugs|bugs]]<br />
<br />
[[Category:ghpsdr3| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=How_to_use_SVN&diff=3924How to use SVN2011-01-06T23:24:59Z<p>VK2NRA: /* Our SVN repository */ URL vs IP</p>
<hr />
<div>Most of the HPSDR [[HPSDR related software|software]] repositories are managed by '''Subversion''', which is a popular collaborative software/firmware development tool for open-source projects. This is a code database repository that is developed with all copies of all code that has been checked in by developers. With a system like this you can go back and check out any previous version of the the software. Wikipedia has an overview of SVN at [http://en.wikipedia.org/wiki/Svn_(software) http://en.wikipedia.org/wiki/Svn_(software)]. <br />
<br />
To access this software you will need to install and use a Subversion (SVN) client. There are several clients listed at the above Wikipedia page. Some of our users have found TortoiseSVN for Windows XP easy to use; it can be downloaded from: [http://tortoisesvn.net/ http://tortoisesvn.net/]. The Tortoise documentation is at [http://tortoisesvn.net/support http://tortoisesvn.net/support] or can be accessed by pressing the F1 key in any Tortoise dialog box.<br />
<br />
A free book on subversion is available at: http://svnbook.red-bean.com/<br />
<br />
==Downloading with TortoiseSVN==<br />
<br />
This is meant to be a simplified procedure to use the Windows SVN client 'TortoiseSVN'.<br />
<br />
*You have TortoiseSVN installed and working.<br />
<br />
*Create a new empty directory, Give it a name appropriate to the item(s) you are downloading.<br />
<br />
*Go to that empty directory, right click in the empty directory and from the menu choices choose 'SVN Checkout'. Enter the svn address of the item you want in the box titled 'URL of repository:'. A typical entry would be:<br />
<br />
svn://184.81.173.3/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
*Click OK.<br />
<br />
It should download all the data into the directory.....<br />
<br />
== Our SVN repository ==<br />
<br />
The open HPSDR project maintains a SVN for the the members of the project. The top address of the repository is: <br />
<br />
svn://svn.openhpsdr.org/repos_sdr_hpsdr/trunk<br />
<br />
'''Please do not try to check out the entire SVN it is over 2.5 GB'''. Because of problems the root is no longer browsable. The following directories are under the trunk and are browsable.<br />
<br />
Code is not generally erased from a repository. So many of the some of the directories are very active and may change daily other may have not changes in years. Check the dates on the files to determine when tey were lats updated. Your SVN program will help you keep a up to date copy of the code on your computer and you can easily update the directory with a single command. <br />
<br />
The repository evolves over time so the organization is not usually for the new viewer but for those that post code. To help people find things here is an index of major folders. Several directories were not included in this list as they are empty.<br />
<br />
==SVN Directories==<br />
<br />
====AE6VK====<br />
Chris Day's on OzyJanus to be used with SDR1000 from 2007<br />
====Atlas====<br />
Reference files of the the [[ATLAS]] connections to other boards<br />
====CyclopsII====<br />
Verilog and C# code for [[CYCLOPS]]<br />
====Documentation====<br />
USB '''HPSDR''' protocol definitions, [[ATLAS|Atlas]] buss pin definitions<br />
<br />
====I2PHD====<br />
Code by Alberto DiBene for HPSDR Winrad<br />
====Janus-CPLDV2====<br />
Verilog code for Janus Version 2<br />
====Janus-CPLDV3====<br />
Verliog code for Janus Version 3<br />
====K5FR====<br />
Steve Nance's C# code for DDUtil<br />
====KA6S====<br />
Steve Wilson's code for verilog code for i2c simulation<br />
====KD5TFD====<br />
Bill Tracey's utility code for testing a large number of interfaces.<br />
====Mercury====<br />
Latest version of the Mercury verilog code<br />
====N4HY====<br />
Bob McGwier's proposal and Documents of Horton and Odyssey<br />
====N6LYT====<br />
John Melton's code for [[ghpsdr]] (single machine no server) and [[ghpsdr3]] (multiple receiver multi machine) code build for Linux systems. Uses DttSP, FFTw3, libusb1.0 and gtk+.<br />
====N8VB====<br />
Phil Covington's code for MercScope, Ozy V1, and SharpDSP<br />
====OZY2-test====<br />
C and Verilog code for test Ozy2<br />
====Ozy V1.2====<br />
First version of the Ozy verilog code<br />
====Ozy V1.4====<br />
First version of the Ozy verilog code<br />
====Ozy V1.5====<br />
First version of the Ozy verilog code<br />
====Ozy V1.6====<br />
First version of the Ozy verilog code<br />
====Ozy V1.7====<br />
First version of the Ozy verilog code<br />
====OzyFX2====<br />
C# code to talk with FX2<br />
<br />
====OzyII====<br />
C and Verilog code for Ozy II<br />
====OzyJanus-Jack====<br />
C code to allow powerSDR to talk to SDR1000 through [[JANUS]] and Jack<br />
====Ozy-JanusV2====<br />
Verilog code for Ozy-Janus from 2006<br />
====OzyUtil-NativeWin====<br />
C code to initalize Ozy on a Windows system<br />
====OzyV2-JanusV2====<br />
Verilog code for Ozy-Janus based on new [[OZY]] code.<br />
====Penelope====<br />
Latest version verilog code for [[PENELOPE]].<br />
====Phoenix====<br />
Verilog code and documentation for [[PHOENIX]].<br />
====PowerSDR-ForJanusOzy-LatestReleaseBinaries====<br />
PowerSDR files from 2007, PowerSDR code for HPSDR is on the Flex SVN<br />
====ProjectDiagrams====<br />
Diagrams for Atlas and Janus from 2006<br />
====VE3NEA====<br />
Alex Shovkoplyas's verilog and firmware code for HPSDR<br />
====VK6APH====<br />
Phil Harmon's verilog and C# code for various projects<br />
====vu3rdd====<br />
Ramakrishnan Muthukrishnan's code to the USB-Blaster using an Ozy board.<br />
====W1BW====<br />
Verilog code for Mercury 3.0 and Ozy 1.8 Multi-receiver code<br />
====WA2DFI====<br />
Scotty Cowling information of the code loaded in to production boards.<br />
====WD5Y====<br />
Joe Torrey's code fro PowerSDR using portAudio<br />
<br />
[[Category:Developer resources]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=User:VK2NRA&diff=3908User:VK2NRA2010-12-31T05:28:58Z<p>VK2NRA: </p>
<hr />
<div><nowiki>{{userpage}}</nowiki><br />
<!-- == Current Status == Between vacations! :-) I am travelling --- so will be less frequently on the wiki. --><br />
== Introducing myself ==<br />
<br />
My name is Richard Ames and I live in Sydney, Australia.<br />
<br />
I dreamed of being a 'ham' or Amateur license holder as teenager but never did it. I received my 'Standard'<ref>http://www.acma.gov.au/WEB/STANDARD/pc=PC_1255#lo</ref> license in March 2009 and I'm learning the techniques and customs of this hobby.<br />
<br />
Regarding this wiki - I would like to see it used and improved by more of the project participants - users/customers / software people / hardware people.... Have a go - improve something - If there is something I did that you can improve; please do it.!<br />
<br />
== My work aids ==<br />
<br />
[[SandBox1|Sandbox in main space.... don't use for personal work.]]<br />
<br />
[[/sandbox|Sandbox in my user area.]]<br/><br />
[[/sandbox2|Sandbox2 in my user area.]]<br/><br />
[[/sandbox3|Sandbox3 in my user area.]]<br/><br />
[[/sandbox4|Sandbox4 in my user area.]]<br />
<br />
<nowiki><br />
{{User committed identity|ee3023bfe42abfd8d87bbb9703ef8ae7b47c6df204de075a6e423a86ad9783f28dceba42d84658f4a49fba58dbcbab2742a6b6e18968832f50d207fe705d47e7}}</nowiki><br />
<br />
==Notes==<br />
<br />
<references /><br />
<br />
__NOTOC__</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=User:VK2NRA&diff=3907User:VK2NRA2010-12-31T05:23:42Z<p>VK2NRA: /* Current Status */ update</p>
<hr />
<div><nowiki>{{userpage}}</nowiki><br />
<br />
<!-- == Current Status ==<br />
<br />
Between vacations! :-) <br />
I am travelling --- so will be less frequently on the wiki. --><br />
<br />
== Introducing myself ==<br />
<br />
My name is Richard Ames and I live in Sydney, Australia.<br />
<br />
I dreamed of being a 'ham' or Amateur license holder as teenager but never did it. I received my 'Standard'<ref>http://www.acma.gov.au/WEB/STANDARD/pc=PC_1255#lo</ref> license in March 2009 and I'm learning the techniques and customs of this hobby.<br />
<br />
Regarding this wiki - I would like to see it used and improved by more of the project participants - users/customers / software people / hardware people.... Have a go - improve something - If there is something I did that you can improve; please do it.!<br />
<br />
== My work aids ==<br />
<br />
[[SandBox1|Sandbox in main space.... don't use for personal work.]]<br />
<br />
[[/sandbox|Sandbox in my user area.]]<br/><br />
[[/sandbox2|Sandbox2 in my user area.]]<br/><br />
[[/sandbox3|Sandbox3 in my user area.]]<br/><br />
[[/sandbox4|Sandbox4 in my user area.]]<br />
<br />
<nowiki><br />
{{User committed identity|ee3023bfe42abfd8d87bbb9703ef8ae7b47c6df204de075a6e423a86ad9783f28dceba42d84658f4a49fba58dbcbab2742a6b6e18968832f50d207fe705d47e7}}</nowiki><br />
<br />
==Notes==<br />
<br />
<references /><br />
<br />
__NOTOC__</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=GRIFFIN&diff=3906GRIFFIN2010-12-31T00:02:53Z<p>VK2NRA: new ip</p>
<hr />
<div>'''GRIFFIN - Stand alone beacon board'''<br />
[[Image:Griffin_Block_Diagram_Rev_1_0.jpg|thumb|500px|Block diagram as of 23 Aug 2010. Click for full size.]] <br />
<br />
Many will be aware of the work undertaken by Bill, KD5TFD, to develop FPGA<br />
code that enables Penelope to operate as a stand alone WSPR beacon. Not<br />
only does his code allow a full implementation of the WSPR protocol, without<br />
the need to connect to a PC, it also enables multiple beacons to operate<br />
simultaneously on multiple bands. This is the dual of multiple independent<br />
receives in a Mercury - multiple independent transmitters in a Penny.<br />
<br />
More details of Bill's work can be found here:<br />
<br />
svn://184.81.170.126/svn/repos_sdr_hpsdr/trunk/PennyWSPR <br />
<br />
There's a README file at:<br />
<br />
svn://184.81.170.126/svn/repos_sdr_hpsdr/trunk/PennyWSPR/README.txt<br />
<br />
One of the advantages we have in the way that HPSDR has evolved is the<br />
ability to try new modes without the need to build or buy new hardware.<br />
Here's another example.<br />
<br />
Many CW operators will remember the time when a CW report, say 559, also<br />
sometimes included a 'C' at the end (e.g. 559C) which indicated the received<br />
signal had a 'chirp' i.e. unstable when keyed, FM etc.<br />
<br />
Chirp was regarded as an undesirable feature and best to let the operator<br />
know. There was also the practice of adding an 'H' to the report<br />
indicating Hum. The story goes that the difficulty in obtaining high<br />
voltage smoothing capacitors in Eastern Europe resulted in some operators<br />
applying un-smoothed rectified mains to the anode/plate of the PA stage<br />
giving it a distinctive err... note. However, a story for another day<br />
perhaps.<br />
<br />
The introduction of digital/HDTV in many parts of the world has triggered <br />
the removal of the analogue TV broadcasters that are/were located adjacent <br />
to the 6m band. Magic Band operators often use these stations as an indicator<br />
of propagation conditions. Since they typically run much higher ERP than<br />
Amateur stations, 10's of kW, they were/are an ideal source of propagation<br />
beacons.<br />
<br />
With the removal of these services in many parts of the world 6m operators<br />
loose a very valuable source of propagation information. It's just this <br />
problem that has lead Andrew Martin, VK30E, to develop an alternative that can be used<br />
in either a RADAR or beacon mode.<br />
<br />
Andrew describes his technique fully in the 2/2010 edition of DUBUS<br />
<br />
http://www.marsport.org.uk/dubus/last.htm<br />
<br />
but here's the basic idea.<br />
<br />
We deliberately, repeatedly, linearly sweep the frequency of a carrier over<br />
1kHz in one second. The nominal frequency of the carrier is derived from a<br />
GPS locked 10MHz reference. The start of the one second sweep is<br />
synchronised to the 1 PPS signal from a GPS.<br />
<br />
At the receiver we use a matched filter, again triggered from a 1 PPS signal<br />
from a GPS, to detect the signal. The matched filter in this case runs on<br />
your PC and uses your sound card or VAC to digitise the received signal.<br />
<br />
The effect is similar to WSPR. However, we trade RF bandwidth for time - in<br />
which case the output of the matched filter is available every second rather<br />
then every few minutes as in the case of WSPR. We also gain a signal<br />
processing advantage over WSPR which typically can decode at -26dB in a<br />
2.7kHz bandwidth. 'Chirp' will decode at -36dB in the same bandwidth. If we<br />
integrate multiple chirp signals over say 1 minute then the processing gain<br />
increases to -54dB.<br />
<br />
So if we run a 100W amateur beacon by applying a chirp to the signal we<br />
effectively have a 400kW signal - in line with the TV transmitters we are<br />
trying to replace.<br />
<br />
Initial tests on 20m between Andrew and Don, VK6HK over a 2700Km path, have <br />
shown the technique to work such that a barely audible SSB signal gives a <br />
spike with a 45dB S/N ratio at the output of the matched filter.<br />
<br />
This is chirp in the beacon mode.<br />
<br />
Alternatively, one station can transmit a<br />
chirp signal, using full power and a beam, in a certain direction and<br />
another station listens beaming in the same direction. The stations need to<br />
be sufficiently far apart such that the transmitting station does not<br />
overload the receiver of the receiving station.<br />
<br />
The receiving station will then receive echoes of the transmitted signal<br />
from the various mediums in the direction he is beaming. Since his matched<br />
filter is triggered at exactly the same time as the transmitting station he<br />
can plot of graph of signal strength against distance in miles/km. Such a<br />
graph can clearly show the presence of single and multi hop E's and their<br />
intensity. Andrew's DUBUS article has some very interesting examples of<br />
enhanced 6m propagation that chirp is able to identify.<br />
<br />
The free sound card software Spectrum Lab:<br />
<br />
http://www.qsl.net/dl4yhf/spectra1.html <br />
<br />
will both generate and demodulate chirp signals.<br />
<br />
What would be interesting would be to have a single board that generates a<br />
chirp modulated carrier and could be used as the replacement for the low<br />
level drive stage in a conventional 6m beacon. You guessed it - Penelope!<br />
<br />
Bill kindly offered to take on this 'Weekender Project' (which did actually<br />
fit in a weekend for once!) and produced a version of his PennyWSPR code<br />
that included BOTH a chirp and WSPR beacon and would trigger on the 1 PPS<br />
from a GPS receiver. The nominal frequency of the beacons is at 50.3MHz<br />
(for initial testing) with the chirp extending from 300Hz to 1300Hz above<br />
this and the WSPR beacon 1500Hz above. The WSPR beacon is 6dB below the<br />
power level of the chirp beacon.<br />
<br />
Since VHF beacons in VK are allocated on a 2kHz channel spacing the spectrum <br />
of the two signals fits nicely within an allocated channel.<br />
<br />
Work is also in progress to look at including an aural CW ident on the <br />
allocated carrier frequency.<br />
<br />
Testing is about to start and I'll report progress in due course.<br />
<br />
If testing is successful then we intend to develop an FPGA based PCB that <br />
will provide a 6m/2m beacon exciter stage. The board is intended to be used <br />
as a replacement for the low level driver board in an existing beacon. As <br />
well as the FGPA, power supplies etc, it will include a GPS receiver and <br />
oven controlled 10MHz reference.<br />
<br />
The project leaders for the board was Phil VK6APH and Kevin M0KHZ.<br />
<br />
<br />
[[Category:Future hardware]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=WinUSB_Notes&diff=3905WinUSB Notes2010-12-31T00:01:51Z<p>VK2NRA: new ip</p>
<hr />
<div><blockquote><br />
'''THIS MATERIAL SHOULD BE CONSIDERED AS OBSOLETE, BUT INFORMATIVE''' <br><br />
'''THAT IS BECAUSE libusb0 HAS BEEN PUBLISHED BY openhpsdr.org AS A SIGNED DRIVER''' <br><br />
'''PLEASE SEARCH THE FORUM'S ARCHIVES FOR MORE INFORMATION ON THE TOPIC OF LIBUSB0''' <br><br />
</blockquote><br />
<br />
Here are the signed libusb0 drivers:<br />
<br />
svn://184.81.170.126/svn/repos_hpsdr_kiss/branches/K9TRV/libusb0-driver-signed<br />
<br />
Please see my listserver posting on 12 May 2010 in the archives...<br />
<br />
<blockquote><br />
'''BECAUSE OF THIS, I HAVE STOPPED ANY MAINTENANCE ON THE WinUSB version of KISS'''<br />
</blockquote><br />
<br />
''Update, 28 July 2010, George Byrkit, K9TRV'' <br />
<br />
This page contains information on using WinUSB with HPSDR hardware.<br />
<br />
First, let's all be clear that WinUSB used as a driver replaces libusb0 used as a driver for some particular device, like the Ozy board. If you install WinUSB as the driver for Ozy, libusb0 is no longer the driver. So applications that use libusb0 (like PowerSDR, until Bill Tracey KD5TFD finished porting [[PowerSDR]] to WinUSB, or like [http://www.dxatlas.com/CwSkimmer/ CWSkimmer], which use libusb0 to speak to [[OZY]]) are not able to coexist with my branch of KISS. My branch of [[KISS Konsole]] uses WinUSB.<br />
<br />
So it's an either/or proposition. If you need libusb0, and can install libusb0 as the driver, and can run [[PowerSDR]], you want to use Phil VK6APH's branch of [[KISS Konsole]]. His branch is the 'original', and is considered to be the main development branch. I try to keep step with his branch, and feed common bugs and hopefully their solutions back to him. I'm keeping step best as I can with Phil's development work using the [[HERMES]] board, as well.<br />
<br />
It seems that WinUSB is needed to use KISS (thus my branch is needed...) on Windows 64 bit OS versions, such as Vista 64 bit and Windows 7, 64 bit. Some have reported trouble using libusb0-based KISS on Windows 7 32 bit. These people report that my WinUSB branch does work fine on Windows 7, 32 bit (with WinUSB installed as the driver). This problem on 32 bit Vista and 32 bit Windows 7 has recently (approx 15 Jan 2010) traced to a problem in HPSDR_USB_LIB_V1.dll by Bill Tracey (KD5TFD), who has fixed this problem! He has mentioned this on the reflector (hpsdr mailing list), and has posted a fixed library. Phil is testing and updating his development branch to include this fixed file. Those of you using Vista 32 bit and Windows 7 32 bit may well wish to use that version and not my WinUSB version! That way, you can use both PowerSDR and KISS, and optionally use [http://www.dxatlas.com/CwSkimmer/ CWSkimmer] and other similar applications.<br />
<br />
Is there anything that WinUSB can do that libusb0 cannot do, other than work on a 64 bit machine? It seems that, yes, there is at least one advantage to WinUSB. WinUSB is able to detect an [[OZY]] or [[HERMES]] board that is plugged in or powered on AFTER KISS has been launched. Libusb0 required that Ozy be plugged in and powered on BEFORE launching/running KISS (or PowerSDR). So this is an advantage. Is there any disadvantage? I think that yes, there is. I don't have data to back it up, but libusb0 seems more 'performant' than WinUSB. What do I mean by that? I think that libusb0 has fewer delays and may use a larger blocksize for transfers than WinUSB does. What is the evidence? KISS using libusb0 has no troubles doing the normal (band) spectrum display, along with the full bandwidth display. I found that I had to reduce the number of data points (samples) for the full spectrum display from 8192 to 4096, to get rid of distorted, chopped audio. I think that Alberto came to the same conclusion.<br />
<br />
====WinRad origins====<br />
<br />
The first thing that you will need is the WinUSB driver package from Alberto, I2PHD, from www.weaksignals.com. [http://www.weaksignals.com Alberto I2PHD's WinRad site] Go to his website and download his WinRad package, which will give you his WinUSB driver installer. Using this installer should let you install WinUSB as the driver for your hardware on Windows XP, Vista and Windows 7, whether you have a 32 bit OS, or Intel/AMD 64 bit OS (x86 architecture) or Intel Itanium IA64 64 bit OS versions of windows installed.<br />
<br />
You will also be able to use WinRad, until Bill KD5TFD ports PowerSDR to WinUSB.<br />
<br />
Alberto has some very good notes on installing the driver, or replacing libusb0 with WinUSB, as part of his package. I suggest that you read his notes and follow his directions. I think that you have to install WinUSB twice for Ozy, once when Ozy contains no programming, and once when Ozy has has its firmware downloaded. You can also find these drivers, newly fixed so that 64 bit Intel/AMD x86 OS install works, in the WinUSBDrivers folder under my SVN archive listed below. You will still want Alberto's instructions...<br />
<br />
There were errors in the 64 bit installers, due to an error Microsoft had in their 'Using WinUSB' document. I consulted with Microsoft, who made me aware of the errors. I communicated these facts to Alberto I2PHD and Phil N8VB, who are updating their .inf files to fix the 64 bit x86 architecture processor installations correspondingly. Some teamwork and mutual communications was involved. Everyone has a better result due to the work that was done co-operatively.<br />
<br />
====Other interesting projects and info on WinUSB====<br />
<br />
:1) The SourceForge (www.sourceforge.net) project called LibUsbDotNet. You can download both source and binary. This is a project that allows .Net code to use either libusb0 or WinUSB, without the application program having to know which driver is installed for the hardware. This is not yet being used by KISS or HPSDR, but does hold some promise on Windows for this option. Using LibUsbDotNet would allow a single version of KISS, for example, to exist that would work with either libusb0 or WinUSB.<br />
<br />
:2) the website http://www.lvr.com/winusb.htm, which contains information on WinUSB, USB in general, sample code, much other information and sample code on things like Serial Ports, Parallel Ports, ethernet, and more. Its maintainer, Jan Axelson, has also written a number of books on these topics. I found his winusb_cs to be very helpful to study in porting KISS and its support programs from libusb0 to WinUSB. [http://www.lvr.com/winusb.htm Jan Axelson's website]<br />
<br />
What has been ported from libusb0 to WinUSB?<br />
:1) Phil Harman VK6APH's project KISS Console<br />
:2) supporting programs like loadfw.exe, loadfpga.exe and writei2c.exe<br />
:3) there is also a Visual Studio 2008 project called WinUSBAPI that is Alberto's Borland C++ Builder code ported to VS2008 C++. It doesn't yet have all the methods that the C# project WinUSBManaged that I wrote does. Hopefully, I'll find the time to back-port those methods from WinUSBManaged to WinUSBApi.<br />
<br />
The purpose of the 'supporting programs' (which also use winusbmanaged.dll) is to replace the current versions that use libusb0. With these, you can update the versions in your usbblaster-binaries folder so that you can still update the firmware in Penelope, Mercury and other boards. You may have multiple places where these are needed. Up-to-date copies are in my "KISS Konsole\bin\release" and "Kiss Konsole\bin\debug" folders, so that initozy11.bat that is in those folders will continue to work.<br />
<br />
Where can I find this new code that uses WinUSB?<br />
Try this svn path (K9TRV's KISS Branch): <br />
<br />
svn://64.245.179.219/svn/repos_hpsdr_kiss/branches/K9TRV<br />
<br />
== '''So, you're going to be running or recompiling the KISS code on a 64 bit machine?''' ==<br />
<br />
<br />
If so, then you'll need to check the 'fftw' subfolder in my branch for the 64 bit dll. I've provided the installers for the 32 bit and 64 bit fftw dlls, from the [http://www.fftw.org/ http://www.fftw.org/] website. Please either install the 64 bit package and replace all versions of the 32 bit dll with the dll it installs. Much easier is to copy and rename the libfftw3f64.dll to libfftw3f.dll, especially in the bin\release and bin\debug folders of my version of the [[KISS Konsole]] project. I've already placed libfftw3f64.dll in those directories for your convenience. Replacing the current libfftw3f.dll is then all you need to do. I suggest that you rename the current libfftw3f.dll file (to anything else...), then copy libfftw3f64.dll and rename the copy to libfftw3f.dll. Thanks to Dr. Hermann von Hasseln, DL3HVH, for this information!<br />
<br />
The alternative to this renaming is to rebuild SharpDSP, but ONLY after editing its file DSPBuffer.cs to change the line containing library_name = "libfftw3f.dll" to library_name = "libfftw3f64.dll".<br />
<br />
The issue here is that both KISS and Sharp_DSP are built with the 'mixed cpu' setting (see Configuration Manager), and thus when run on a 64 bit system, 64 bit code is generated (at run time! you don't even need to recompile! That's how .NET framework programs work...), and all DLLs that are called MUST BE 64 bit dlls. If you will tolerate 32 bit code on your 64 bit system, you can use the Configuration Manager and change the cpu type for BOTH KISS and Sharp_DSP to 'x86'. This will cause only 32 bit code to be generated. This will allow the 32 bit versions of FFTW as well as libusb0 to be used...<br />
<br />
So I cannot test the above, as I don't have a 64 bit OS installed to check it on. You can also find processor selection on the Build page of a project's properties. Double-click on Properties in the Kiss Konsole project in the solution explorer pane. This will bring up some tabbed dialogs in the main window. Select the 'build' tab. Note the combo-box to the right of the text saying 'Platform target'. This will by default be set to 'Any CPU'. You could choose to set it to 'x86' to force 32 bit code to be generated. Selecting 'x64' would force 64 bit code to be generated, which wouldn't work on 32 bit OS installations, and would require all 64 bit dlls be available (libusb0, probably and libfftw3f for 64 bit for sure!). I'd be willing to be that no one has an Itanium CPU, so please don't select that one...<br />
<br />
If you change the setting for KISS Konsole, make SURE that you make the setting for Sharp_DSP match! Otherwise, things just won't work... In my KISS branch, the Sharp_DSP project is part of the KISS Konsole solution, so this is easier to do. If you are using Phil's branch, you either need to add the Sharp_DSP project to the KISS solution, or make sure that you open the Sharp_DSP solution and make the needed changes in the Sharp_DSP project build settings and rebuild.<br />
<br />
[[Category:Software]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Multiple_independent_receivers_-_how_to_set_up_on_Windows&diff=3904Multiple independent receivers - how to set up on Windows2010-12-31T00:01:07Z<p>VK2NRA: new ip</p>
<hr />
<div>The ability to have multiple independent receivers using a single Mercury is made possible<br />
by the efforts of Kirk Weedman KD7IRS, John Melton G0ORX / N6LYT, and Bruce Walker W1BW.<br />
Two of the parts of John Melton's [[ghpsdr3]] have been ported to Windows (tested on XP 32 bit)<br />
The two pieces are "server" and "dspserver". These two, with Mercury FPGA version 3.0 and the corresponding Ozy code (version 1.8), <br />
provide for four simulteneous independent receivers for a single [[MERCURY]] board, using John's <br />
jmonitor as the (minimal) receiver graphical user interface. The controls available for <br />
each receiver are fewer than with [[PowerSDR]] or [[KISS Konsole]], but are quite adequate for monitoring <br />
up to four 96kHz segments in the frequency range 0 to 55 MHz simultaneously.<br />
<br />
No transmit capability is provided.<br />
<br />
All files needed to run server and dspserver on Windows may be found on the SVN<br />
<br />
svn://184.81.170.126/svn/repos_hpsdr_kiss/branches/WA8YWQ/ghpsdr3-Windows<br />
<br />
You'll find the following folders<br />
<pre><br />
Folder Contents<br />
bin Executables and all files needed to run<br />
dist java files for jmonitor (you'll need to have installed java)<br />
dspserver source for dspserver, with solution/project files<br />
DttSP source for DSP package, with solution/project files to create .dll<br />
LoadMercuryFirmware all files needed to load Mercury FPGA with V3.0<br />
server source for server, with VS2003 solution/project files<br />
</pre><br />
<br />
Both server and dspserver are written in pure C (no C++). The files include project (solution) files for<br />
Visual Studio 2003. You'll probably have no trouble using VS2005 or VS2008.<br />
I've added #ifdef ... #endif so that (hopefully) the same code may be compiled on Windows<br />
and on Linux. Once any problems have been ironed out, the merged code will be placed in the<br />
SVN trunk, rather than branch, so that further development will simultaneously apply to both<br />
Windows and Linux.<br />
<br />
In the future, additional options will be explored / implemented. These include using the fully-<br />
featured ghpsdr3 receiver user interface, other receiver interfaces, connections to digital mode<br />
software, and special communication software, such as [http://physics.princeton.edu/pulsar/K1JT/wspr.html WSPR]. Transmit capability may also be possible.<br />
(Of course WSPR needs to transmit. I'd hope that one could run WSPR on four bands simultaneously,<br />
with the software setting Penelope frequency as needed.)<br />
<br />
The server part loads Ozy FX2 and FPGA via the USB, sends I & Q samples to dspservers 0 thru 3,<br />
and sends demodulated audio (for receiver 0 only) back to Ozy and Mercury. Each jmonitor sends <br />
demodulated audio to computer's sound card. When more than one receiver is active, the sound <br />
card output is the sum of audio from all active receivers. If you want to listen to only one, <br />
reduce the AFGain to zero on other instances of jmonitor. The server does not read the 55 MHz wide<br />
spectrum samples from [[OZY]] / [[MERCURY]] (USB endpoint 4).<br />
<br />
Each functional receiver uses its own instances of dspserver and jmonitor. dspserver provides the<br />
passband filtering, demodulation, AGC, and noise reduction.<br />
<br />
server and dspserver are launched from a command window ("DOS window"), and each is started with<br />
some command-line arguments, or options.<br />
<br />
For the server, the options are--<br />
<pre><br />
receivers 1, 2, 3, or 4 The number of simultaneous receivers to be supported<br />
samplerate 96000 One of 48000, 96000, 192000 (only tested with 96000)<br />
dither on / off Setting for Mercury ADC<br />
random on / off Setting for Mercury ADC<br />
preamp on / off Setting for Mercury<br />
10mhzsource atlas / penelope / mercury<br />
122.8mhzsource penelope / mercury<br />
micsource penelope / janus<br />
class other / E<br />
timing<br />
<br />
The default settings are<br />
receivers 1<br />
samplerate 96000<br />
dither off<br />
random off<br />
preamp off<br />
10mhzsource mercury<br />
122.88mhzsource mercury<br />
micsource penelope<br />
class other<br />
</pre><br />
<br />
You only need to specify the options whose values need to be different from the defaults.<br />
<br />
For the dspserver, the options are--<br />
<pre><br />
dspserver options:<br />
soundcard SANTA_CRUZ, AUDIGY_2_ZS, MP3_PLUS, EXTIGY, <br />
DELTA_44, FIREBOX, EDIROL_FA_66, HPSDR<br />
receiver 0 - 3<br />
server IP address<br />
offset ?<br />
<br />
default values:<br />
soundcard HPSDR<br />
server 127.0.0.1 (this is "localhost")<br />
receiver 0<br />
offset 0<br />
</pre><br />
<br />
To make it easy to launch multiple receivers, make a folder with a short path name, <br />
such as C:\MultiRx<br />
<br />
Into this folder place the following--<br />
<pre><br />
libfftw3f-3.dll<br />
pthreadVC2.dll<br />
jmonitor.jar<br />
ozyfw-sdr1k.hex<br />
Ozy_Janus.rbf<br />
server.exe<br />
dspserver.exe<br />
folder "lib" from the java dist folder<br />
</pre><br />
<br />
Here's how to start the system--<br />
<pre><br />
First command window<br />
cd \MultiRx<br />
server --receivers 4 <br />
<br />
<br />
2nd command window<br />
cd \MultiRx<br />
dspserver --receiver 0<br />
<br />
<br />
3rd command window<br />
cd \MultiRx<br />
java -jar "jmonitor.jar" --server 127.0.0.1 --receiver 0<br />
</pre><br />
<br />
Now you have one receiver running.<br />
<br />
To use more than one simultaneous receiver,<br />
<pre><br />
When launching server, use a value greater than 1 for the number of receivers.<br />
Launch multiple copies of dspserver and jmonitor, each from their own command window, <br />
using different receiver numbers--ie 0, 1, 2, 3 <br />
(Only one instance of server is needed--it supplies connection to the hardware <br />
for all receivers.)<br />
</pre><br />
<br />
With 4 receivers running, you'll have 9 command windows open.<br />
<br />
<br />
When server starts it says--<br />
<pre><br />
Listening for TCP connections on port 11000<br />
(a few seconds delay while Ozy FX2 and FPGA are loaded)<br />
... (hex dumps of 9 USB frames)<br />
server configured for 4 receivers at 96000<br />
Ozy Software version 18<br />
Mercury Software version 30<br />
<br />
client_socket 1832<br />
client connected 127.0.0.1:12000<br />
client connected: 127.0.0.1:12000<br />
parse_command(Rx-842150451): 'attach 0'<br />
response(Rx0): OK 96000'<br />
parse_command(Rx0): 'start iq 13000'<br />
response(Rx0): 'OK'<br />
audio_thread port=15000<br />
listening for rx 0 audio on port 15000<br />
</pre><br />
<br />
When dspserver starts it says (socket numbers and buffer addresses will be different on your system)--<br />
<pre><br />
hHPSDR rx 0 (Version 0.6)<br />
getSoundcardID: HPSDR id=8<br />
setSoundcard: 8<br />
setSoundcard -11 000000 -25 000000<br />
setup_system_audio: sdr-5044-0<br />
setup_system_audio: sdr-5044-1<br />
client_init audio_buffer_size=2000 audio_buffer=9736336<br />
client_thread<br />
client_thread: listening on port 8000<br />
ozy_init: command bound to port 12000 socket 1808<br />
ozy_init: server 127.0.0.1<br />
connect: sampleRate=96000<br />
setSpeed 1<br />
ozy_init: iq bound to port 13000 socket=1776<br />
iq_thread: socket 1784<br />
output_sample_increment=2<br />
</pre><br />
<br />
(when jmonitor for Rx 0 starts, dspserver says:)<br />
<pre><br />
26/06/2010 23:48:29 RX0: client connection from 127.0.0.1:2995<br />
client message: setFrequency 7048000<br />
client message: setMode 0<br />
client message: setFilter -2850 -150<br />
client message: SetRXOutputGain 30<br />
client message: start AudioStream 480<br />
</pre><br />
<br />
As you start additional receivers, and make changes to the state of each of the receivers,<br />
you'll see more output from server and the dspservers.<br />
<br />
Some information on how to make a receiver available on the internet may be found at<br />
<br />
http://www.n9vv.com/N6LYT-Online-Mercury-Receiver.pdf<br />
<br />
Please post your comments and questions to the openhpsdr email reflector, hpsdr (at) openhpsdr.org.</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=PHOENIX&diff=3903PHOENIX2010-12-30T23:59:53Z<p>VK2NRA: new ip</p>
<hr />
<div>'''PHOENIX - is a ISD/QSE Receiver/Transmitter Module'''<br />
<br />
<br />
'''Update 29 March 2010'''<br />
<br />
Richard, VK6BRO, has layed out a V2 PCB in an attempt to elimimate the large number of spurs that the V1 boards produced. <br />
The latest PCB layout, in Kicad format, are available here:<br />
<br />
svn://184.81.170.126/svn/repos_sdr_hpsdr/trunk/Phoenix/Phoenix_V2<br />
<br />
<br />
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.<br />
<br />
A number of Alpha builders are currently constructing boards; these include Al, N0TVJ, Bill, KD5TFD, Kevin, M0KHZ and Phil, VK6APH. <br />
<br />
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. <br />
<br />
[[Image:Phoenix.JPG|thumb|500px|VK6APH's partly completed Phoenix board, November 2008]]<br />
<br />
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.<br />
<br />
Relevant files for the Phoenix project can be found under SVN at the following location:<br />
* svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/Phoenix<br />
<br />
[[Image:First_Phoenix_Signal.JPG|thumb|500px|VK6APH's Alpha Phoenix board feeding a Janus sound card and running with PowerSDR, November 2008 ]]<br />
<br />
More test results to follow - Phil....VK6APH <br />
<br />
The Phoenix PCB contains a ISD (Integrating Sampling Detector) based HF Receiver, a QSE (Quadrature Sampling Exciter) based HF Exciter and a supporting synthesizer.<br />
<br />
<!-- [[Image:phoenix_bird.jpg]]<br />
<br />
This image of a Phoenix Bird is emblazoned on 8 trams in Brisbane, Australia that were rebuilt and 'arose from the ashes' after the Paddington tram depot fire in 1962. The artist, Ken Howard, has released all rights to this drawing. <br />
<br />
--><br />
<br />
=== GENERAL DESCRIPTION ===<br />
<br />
The initial project leader was Ray Anderson, WB6TPU<br />
<br />
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).<br />
<br />
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....<br />
<br />
Inital Block diagram for discussion:<br />
<br />
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)<br />
<br />
[[Image:phoenix_simplified_block2.jpg]]<br />
<br />
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.<br />
<br />
[[Image:phoenix_simplified_block4.jpg]]<br />
<br />
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.<br />
<br />
[[Image:Phoenix_rx_1.jpg]]<br />
<br />
Feature List for Discussion:<br />
<br />
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:<br />
<br />
Synthesizer:<br />
<br />
:Utilize AD9951 with a divide by 4 to generate quadrature LO signals<br />
:Utilize 2 AD9951 with phase offset<br />
:Microwave PLL divided down to HF<br />
<br />
(as a general thing, suggestions are running towards avoiding 10-bit DDS circuits due to spurious considerations)<br />
<br />
Preamp:<br />
<br />
A robust high dynamic range low noise preamp has been suggested to precede the detector. Suggestions include:<br />
<br />
:Norton amplifier (noiseless feedback) amplifier using BFG591<br />
:Makhinson amplifier (push-pull version of Norton amp)<br />
<br />
Rx Filters:<br />
<br />
:Switched BPF filters<br />
:Broadband (0-30 MHz) frontend with external BPF<br />
<br />
QSD: It is looking like either a 74auc2g53 with OPA1632 or LT1127 amps may end up being the ISD (integrating sampling detector).<br />
<br />
The OPA1632 variant is being evaluated by Ahti OH2RZ and the LT1127 variant is being looked at by Phil N8VB.<br />
<br />
This is a critical part of the circuit as far as overall performance is concerned.<br />
<br />
'''Jan 2008 (Richard Hosking VK6BRO)'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
Look at the various schematics at: [[Phoenix Schematics]] and the current PCB layouts are at: [[Phoenix Layouts]]<br />
<br />
Please contact me if you want to play with Kicad for the various libraries<br />
<br />
[[Category:Phoenix| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=METIS&diff=3872METIS2010-11-27T09:36:52Z<p>VK2NRA: close up blank lines</p>
<hr />
<div>[[Image:OzyII_Block_Diagram_V1.9.jpg|thumb|600px| Block diagram for METIS V1.0 23 May 2010]]<br />
'''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.<br />
<br />
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. <br />
<br />
Initial thoughts are around an Atlas size board that contains a large, leaded, Altera Cyclone III FPGA connected to a Gigabit Ethernet PHY. <br />
<br />
User input relating to the design and features is requested via the HPSDR reflector.<br />
<br />
Project Leader: Phil, VK6APH <br />
<br />
===Update: 23 November 2010===<br />
Beta boards check out OK. TAPR have been advised that Metis is ready for production. Beta FPGA code testing continuing with new features and tuning currently taking place.<br />
<br />
===Update: 4 November 2010===<br />
Beta boards have been manufactured and shipped to Beta testers. Beta Metis boards are running using KISS Konsole and ghpsdr (see http://www.g0orx.blogspot.com/).<br />
Expresions of interest to purchase production boards from TAPR can be placed here http://www.hamsdr.com/Home.aspx. Note that you need to login then select Projects > TAPR-HPSDR.<br />
<br />
===Update: 13 September 2010===<br />
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). <br />
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! <br />
<br />
Beta PCBs and parts have been ordered and will be automatically assembled in order to check the design is production ready.<br />
<br />
===Update: 30 August 2010===<br />
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. <br />
<br />
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.<br />
<br />
===Update: 15 August 2010===<br />
ARP, ping and DHCP all working. Currently implementing OzyII discovery code.<br />
<br />
===Update: 11 August 2010===<br />
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.<br />
<br />
===Update: 1 August 2010===<br />
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]]<br />
<br />
===Update: 15 July 2010===<br />
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. <br />
<br />
===Update: 23 May 2010===<br />
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. <br />
Comments, corrections and suggestions via the openHPSDR reflector please. <br />
<br />
===Update: 8 April 2010===<br />
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. <br />
<br />
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.<br />
<br />
===Update: 15 March 2010===<br />
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.<br />
<br />
===Update: 5 March 2010===<br />
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.<br />
<br />
===Update: 2 March 2010===<br />
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.<br />
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.<br />
<br />
===Update: 11 February 2010===<br />
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.<br />
<br />
Now looking at implementing a soft core uP as an alternative to doing the Discovery code in Verilog.<br />
<br />
===Update: 31 January 2010===<br />
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 :)<br />
<br />
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]]<br />
<br />
===Update: 29 January 2010===<br />
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]].<br />
<br />
===Update: 14 January 2010===<br />
I've completed modifying K.I.S.S. Konsole to work with Ethernet data rather than USB by replacing libUSB with SharpPcap.<br />
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.<br />
<br />
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.<br />
<br />
A prototype PCB is presently being layed out.<br />
<br />
===Update: 27 October 2009===<br />
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.<br />
<br />
Lyle, KK7P, commenced drawing the schematic for OzyII. <br />
<br />
===Update: 27 September 2009===<br />
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. <br />
<br />
===Update: 26 September 2009.===<br />
I'm making good progress with the development of a Gigabit interface to the Atlas bus i.e. OzyII (Aussie2).<br />
<br />
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 <br />
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 <br />
PCB. It's also only needs a single supply, is small, low power and low cost.<br />
<br />
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 <br />
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).<br />
<br />
This has an Eternet connector, access to the RGMII pins and a USB interface. TheUSB interface provides access to read/write all the internal <br />
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.<br />
<br />
I've been able to interface the evaluation board to an Ozy board (see nearby photo) <br />
so that I can write FPGA code to test the PHY in ernest.<br />
<br />
[[Image:Test.JPG|thumb|600px|Micrel evaluation board piggy-backed onto an Ozy board. 26 September 2009]]<br />
<br />
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. <br />
Similarly, any Ethernet frames the PHY receives are by sent to the FPGA and thence via Ozy's USB port back to the PC.<br />
<br />
Thanks to Bill, KD5TFD, for this suggestion - it has certainly speeded up development.<br />
<br />
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.<br />
<br />
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 <br />
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 <br />
nearby.<br />
[[Image:Success.JPG|thumb|300px|PC code to send & receive Ethernet frames from OzyII. 26 September 2009]]<br />
<br />
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 <br />
working in C# then I can port it to Verilog.<br />
<br />
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 <br />
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 <br />
the PHY board.<br />
<br />
This will be a useful developement platform as we move to more advanced protocols in the future.<br />
<br />
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 <br />
and append the CRC32.<br />
<br />
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).<br />
<br />
Once that is working I can grab Mercury I & Q data off the Atlas bus and <br />
send that to the PC via Ethernet. Similary, the demodulated audio and I & Q <br />
data can be returned via Ethernet. We will need a modified version of <br />
PowerSDR/KK to test this and Bill KD5TFD is already working on ways to do <br />
this.<br />
<br />
In order to use this initial software it will be necessary to program the <br />
MAC address of the PC you intend to use with OzyII into the board. We will <br />
provide a Flash memory chip on the PCB that will be programmed with the <br />
boards MAC address during manfacture.<br />
<br />
With the FPGA <> PHY hardware interface working we can start designing the <br />
schematic for OzyII and Lyle KK7P will commence that after his holidays.<br />
<br />
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<br />
<br />
Initially we will use the Gigabit PHY as just a fast connection to the PC and use raw frames to communicate. <br />
<br />
Feedback and comments are requested via the HPSDR reflector. <br />
<br />
Ethernet Notes:<br />
<br />
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.<br />
<br />
===Useful info:===<br />
http://www.wireshark.org/<br />
<br />
http://www.techonline.com/article/pdf/showPDFinIE.jhtml?id=2088017281<br />
<br />
http://www.cs.rice.edu/CS/Architecture/docs/shafer-tree0611.pdf<br />
<br />
Altera White paper on Ethernet using Cyclone III and NIOS soft core<br />
<br />
http://cm.altera.com/g/?QYKFH2NRLY:SU6QAW3Y1V=ssID:480603690<br />
<br />
[[Category:Hardware nearing completion]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=PowerSDR&diff=3817PowerSDR2010-10-24T19:50:52Z<p>VK2NRA: sp, close up blank lines, make path all in pre-formated block</p>
<hr />
<div>[[Image:PowerSDR1.19.3.jpg|thumb|400px|PowerSDR in operation by Ron, W9KFB ]]<br />
'''PowerSDR''' is the Microsoft Windows based client [[HPSDR related software|software]] created by [http://www.flex-radio.com/Products.aspx?topic=powersdr1x Flexradio] to operate their software defined radios.<br />
<br />
It has been adapted (primarily by Bill Tracey, KD5TFD and Doug Wigley, W5WC) to work with the HPSDR [[MERCURY|Mercury]], [[PENELOPE|Penelope]], [[OZY|Ozy]], [[MAGISTER|Magister]], and [[EXCALIBUR|Excalibur]] boards. Features of the software also support the [[ANTENNA SWITCH|Antenna Switch]], [[ALEXIARES|Alexiares]], and the [[HERCULES|Hercules 100 Watt Amplifier]]. <br />
<br />
As of this writing (May 2010) the latest HPSDR modified version of PowerSDR can be found on the HPSDR source code management system ([[How to use SVN|SVN]]). The address (URL) to use is: <br /> svn://64.245.179.219/svn/repos_sdr_hpsdr/trunk/W5WC/PowerSDR_HPSDR_1.19.3/bin/Release<br />
To use this software you will also need to download a "Skins folder". Currently the quickest/easy way to get this folder is to download and install a related program called "PowerSDR-IF Stage" which can be found at URL: http://www.wu2x.com/sdr.html#download<br />
<br />
This Skins folder must be placed in a folder as follows on Windows XP Professional operating systems:<br />
\Documents and Settings<br />
\<username> (Has to be a name other than Administrator, All Users, or Default User)<br />
\Application Data (you must turn on hidden files to see this branch)<br />
\FlexRadio Systems<br />
\PowerSDR ("PowerSDR v 1.19.3" won't work) <br />
\Skins<br />
<br />
On Vista the path is:<br />
Windows Disk (C:)<br />
Users<br />
<username> (Has to be a name other than Administrator, All Users, or Default User)<br />
AppData (you must turn on hidden files to see this branch)<br />
Roaming<br />
FlexRadio Systems<br />
PowerSDR ("PowerSDR v 1.19.3" won't work) <br />
Skins<br />
<br />
PowerSDR is licensed under the GPL.<br />
<br />
See the [[Quick Startup Guide]] for installation and configuration notes.<br />
<br />
See also [[PowerSDR Keyboard Shortcut List]].<br />
<br />
[[Category:PowerSDR| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=User_talk:KV0S&diff=3809User talk:KV0S2010-10-19T22:07:35Z<p>VK2NRA: note on moving pages</p>
<hr />
<div>== Editing under your user ID ==<br />
<br />
Dave - I think it is a great idea that you have started editing using your user login; that gives you credit for your contributions. It will also reduce the use of the WikiSysop ID which I think is off-putting to 'normal' users. Regards, [[User:VK2NRA|Richard Ames, VK2NRA]] 21:33, 15 August 2009 (UTC)<br />
<br />
<br />
== Photos uploaded that can't be used ==<br />
<br />
Dave, I inadvertently Uploaded 7 Photos that can't be used because the name has a space embedded in it. Is there a way to clear out the orphans? Most of them start with "Antec ####" and one starts with 'IMG ####". They were uploaded last night at 00:39 to 1:00 UTC. Thanks,--[[User:W9KFB|Ron Cox, W9KFB]] 06:57, 16 August 2009 (UTC)<br />
<br />
== Moving Pages OZYII / METIS ==<br />
<br />
Dave, When you created a new page for [[METIS]] you lost the edit history and discussion pages that were part of the [http://openhpsdr.org/wiki/index.php?title=OZYII&redirect=no OZYII] article. A better way of doing this would have been to move the page... that preserves the talk pages and article history. I have edited the OZYII page so that people will be redirected to the METIS page. <br />
<br />
You may choose to improve my solution by moving the old OZYII page over the new METIS page. The process for doing this would be:<br />
<br />
# Undo my edit to the OZYII page which added the REDIRECT. To do this go [http://openhpsdr.org/wiki/index.php?title=OZYII&curid=294&diff=3808&oldid=3640 here] and click the '''undo''' link.<br />
# Move the OZYII page over the existing METIS page. See the instructions [http://en.wikipedia.org/wiki/Help:Moving_a_page here] and specifically [http://en.wikipedia.org/wiki/Help:Moving_a_page#Moving_over_an_existing_page here].<br />
<br />
Regards, [[User:VK2NRA|Richard Ames, VK2NRA]] 22:07, 19 October 2010 (UTC)</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=METIS&diff=3808METIS2010-10-19T21:41:09Z<p>VK2NRA: redirect to metis</p>
<hr />
<div>#REDIRECT [[METIS]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Multi-Receiver&diff=3806Multi-Receiver2010-10-07T00:47:07Z<p>VK2NRA: sp in caption, close up lead paragraph, make section head for config</p>
<hr />
<div>[[Image:dualmercury.jpg|thumb|400px|Example of the connection points on the mercury board (Click for a larger image)]]<br />
The openHPSDR receiver can be run in several configurations. Stand-alone, multiple receivers on a single [[MERCURY]] (one common antenna), and two or more [[MERCURY]] boards plugged into a single [[ATLAS]] (this allows two or more antennas). Each of these configurations require different hardware and software support but all have been successfully accomplished using [[MERCURY]] boards.<br />
<br />
==Stand-Alone==<br />
<br />
The options is supported by all software and all versions of the verilog code.<br />
<br />
Current verilog code is Mercury 2.9 and Ozy 1.7<br />
<br />
==Multiple Receivers on a single Mercury==<br />
<br />
This options is supported by [[KISS Konsole]] on Windows and [[ghpsdr3]] on Linux and (Windows under development).<br />
<br />
This option is only supported by the Ozy 1.8 and Mercury 3.0 verilog code.<br />
<br />
==Multiple Mercury boards==<br />
<br />
This option is supported by KISS Konsole versions >1.0.6 on Windows and [[ghpsdr3]] on Linux and most recently by a modified test version of PowerSDR v1.19.3.1 on Windows, called PowerSDR v1.19.3.1.diversity9 (K5SO 5OCT2010), that simultaneously supports the multiple receivers option mentioned above and dual Mercury boards (HPSDR downloads page at http://k5so.com). <br />
<br />
"Multiple Mercury boards" is supported by Ozy v1.8 and later and by Mercury v3.0 and later FPGA/Verilog code. Note, however, that Ozy v1.8 does NOT sync the second Mercury board data stream properly so a new version that does sync the second stream properly is currently under development. K5S0 is successfully using a test version of Ozy FPGA code that does sync the second Mercury board data stream. The test version is available at the website of K5SO mentioned above as a temporary solution until a new Ozy version can be released. <br />
<br />
For dual Mercury boards on Atlas it is necessary to use Mercury v3.0 or later in the Mercury FPGAs. Mercury v3.0 code is compatible with the current versions of Bill KD5TFD's (7May2010) PowerSDR v1.10.4, KISS Konsole, and PowerSDR v1.19.3.1 therefore it is not necessary to reload the FPGAs in the Mercury boards when switching between these programs and PowerSDR v1.19.3.1.diversity9. Simply power cycling the HPSDR board set (or alternatively, re-running initozy11.bat without power cycling) is all that is necessary to be able to switch between the programs.<br />
<br />
Also, the second Mercury board can remain on the Atlas bus while running the other programs with no ill effects; the second Mercury board is simply ignored by the other programs.<br />
<br />
<br />
==REQUIRED HARDWARE CONFIGURATIONS TO USE MULTIPLE MERCURY BOARDS==<br />
<br />
Each Mercury board must have jumpers in place to specify an address for the board. Each board will have a different jumper-selected address. The address is specified by placing jumpers on J5 (GPIO pins) on the Mercury board. Looking at the Mercury board with the Atlas bus connector down, the GPIO pins on J5 are arranged such that the lowest pair of pins (closest to F1) are GPIO pins 1,0. Without a jumper, the logic value for the GPIO pin pair is "0", with a jumper across the pins the logic value is "1". The Mercury board address is specified as a 3-bit address according to the jumpers placed on J5. The GPIO pins on J5 are assigned as follows: <br />
<br />
GPIO pairs:<br />
<br />
9,8 = Mercury ID bit 2,<br />
<br />
7,6 = Mercury ID bit 1,<br />
<br />
5,4 = Mercury ID bit 0,<br />
<br />
3,2 = Channels_8_1 bit<br />
<br />
1) When using multiple Mercury boards ALL of the Mercury boards must have GPIO pins 3,2 jumpered. This jumper specifies that the data from the board will be sent to a single, board-specific Atlas bus line that is associated with the address indicated on GPIO pins 9-8, 7-6, and 5-4; as opposed to sending its data to Ozy over eight Atlas bus lines as is the case when there is no jumper across GPIO pins 3-2. <br />
<br />
2) The address of the first Mercury board should be "000", selected by having no jumpers on GPIO pins 9-8, 7-6, or 5-4. The address of the second Mercury board should be "001", selected by having a jumper on GPIO pins 5-4; and so on for any additional Mercury boards present. <br />
<br />
Therefore, for dual Mercury boards, the 3,2 GPIO jumper pair should be on both Mercury cards, the first Mercury board is set for Merc_ID = 000 (no jumpers on pins 9-8, 7-6, or 5-4) and the 2nd Mercury card is set for Merc_ID = 001 (a jumper across the 5,4 pair).<br />
<br />
<br />
3) Connecting the 122.88MHz clocks on Mercury (photos at http://k5so.com/Clock%20connections.html): <br />
<br />
3a) place a jumper on the CLKSEL "I" pins (lower two pins of the three CLKSEL pins) on each of the Mercury boards,<br />
<br />
3b) place a jumper on JP9 (enabling the 122.88MHz oscillator) on each Mercury board<br />
<br />
3c) place a jumper from the Atlas C16 pin to J8 (Aux Clk input) pin nearest the FPGA<br />
<br />
3d) in PowerSDR, select Setup>Excalibur, then on the Mercury boards<br />
<br />
Now both Mercury board 122.88 MHz oscillators will be phased locked to the 10MHz clock on Atlas C16 coming from Excalibur (or whatever external 10 MHz source you use). No jumpers between the Mercury boards is necessary in this configuration.<br />
<br />
<br />
4) 10 MHz clock on Mercury: The 10MHz clock for the Mercury boards should be taken from Excalibur (or whatever external 10MHz source you use) via the Atlas C16 pin, with Mercury jumpered as noted in 3d above.<br />
<br />
<br />
COMMENTS ON PowerSDR v1.19.3.1.diversity9 (K5SO 5OCT2010)<br />
<br />
The program has inherited some known bugs from PowerSDR v1.19.3.1 including: <br />
<br />
- KNOWN BUG: Should you exit the program while in FULL SCREEN mode you will be "trapped" in full screen mode thereafter when trying to run the program. To recover from this condition you must replace the database.xml file in your C:\Documents and Settings\<your user name>\Application Data\FlexRadio Systems\PowerSDR v1.19.3 folder with the database.xml file provided in this distribution package. To avoid this condition for the time being do not exit the program when in FULL SCREEN display mode, return to NORMAL view first then exit the program.<br />
<br />
- KNOWN BUG: When in FULL SCREEN display mode the Pan control is stretched horizontally and if the control is set beyond mid range the slider will not be visible when returning to NORMAL screen display. <br />
<br />
-KNOWN BUG: The band edge position (upper band edge marker anyway) does not appear on the panadapter display when the "Zoom" control scale is set to "0.5x".</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=METIS&diff=3640METIS2010-08-30T20:54:00Z<p>VK2NRA: /* Update: 30 August 2010 */ sp</p>
<hr />
<div>[[Image:OzyII_Block_Diagram_V1.9.jpg|thumb|600px| Block diagram for OzyII V1.0 23 May 2010]]<br />
'''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.<br />
<br />
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. <br />
<br />
Initial thoughts are around an Atlas size board that contains a large, leaded, Altera Cyclone III FPGA connected to a Gigabit Ethernet PHY. <br />
<br />
User input relating to the design and features is requested via the HPSDR reflector.<br />
<br />
Project Leader: Phil, VK6APH <br />
<br />
===Update: 30 August 2010===<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Update: 15 August 2010===<br />
<br />
ARP, ping and DHCP all working. Currently implementing OzyII discovery code.<br />
<br />
===Update: 11 August 2010===<br />
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.<br />
<br />
===Update: 1 August 2010===<br />
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]]<br />
<br />
===Update: 15 July 2010===<br />
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. <br />
<br />
===Update: 23 May 2010===<br />
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. <br />
Comments, corrections and suggestions via the openHPSDR reflector please. <br />
<br />
===Update: 8 April 2010===<br />
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. <br />
<br />
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.<br />
<br />
===Update: 15 March 2010===<br />
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.<br />
<br />
===Update: 5 March 2010===<br />
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.<br />
<br />
===Update: 2 March 2010===<br />
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.<br />
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.<br />
<br />
===Update: 11 February 2010===<br />
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.<br />
<br />
Now looking at implementing a soft core uP as an alternative to doing the Discovery code in Verilog.<br />
<br />
===Update: 31 January 2010===<br />
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 :)<br />
<br />
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]]<br />
<br />
===Update: 29 January 2010===<br />
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]].<br />
<br />
===Update: 14 January 2010===<br />
I've completed modifying K.I.S.S. Konsole to work with Ethernet data rather than USB by replacing libUSB with SharpPcap.<br />
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.<br />
<br />
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.<br />
<br />
A prototype PCB is presently being layed out.<br />
<br />
===Update: 27 October 2009===<br />
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.<br />
<br />
Lyle, KK7P, commenced drawing the schematic for OzyII. <br />
<br />
===Update: 27 September 2009===<br />
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. <br />
<br />
===Update: 26 September 2009.===<br />
I'm making good progress with the development of a Gigabit interface to the Atlas bus i.e. OzyII (Aussie2).<br />
<br />
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 <br />
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 <br />
PCB. It's also only needs a single supply, is small, low power and low cost.<br />
<br />
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 <br />
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).<br />
<br />
This has an Eternet connector, access to the RGMII pins and a USB interface. TheUSB interface provides access to read/write all the internal <br />
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.<br />
<br />
I've been able to interface the evaluation board to an Ozy board (see nearby photo) <br />
so that I can write FPGA code to test the PHY in ernest.<br />
<br />
[[Image:Test.JPG|thumb|600px|Micrel evaluation board piggy-backed onto an Ozy board. 26 September 2009]]<br />
<br />
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. <br />
Similarly, any Ethernet frames the PHY receives are by sent to the FPGA and thence via Ozy's USB port back to the PC.<br />
<br />
Thanks to Bill, KD5TFD, for this suggestion - it has certainly speeded up development.<br />
<br />
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.<br />
<br />
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 <br />
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 <br />
nearby.<br />
[[Image:Success.JPG|thumb|300px|PC code to send & receive Ethernet frames from OzyII. 26 September 2009]]<br />
<br />
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 <br />
working in C# then I can port it to Verilog.<br />
<br />
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 <br />
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 <br />
the PHY board.<br />
<br />
This will be a useful developement platform as we move to more advanced protocols in the future.<br />
<br />
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 <br />
and append the CRC32.<br />
<br />
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).<br />
<br />
Once that is working I can grab Mercury I & Q data off the Atlas bus and <br />
send that to the PC via Ethernet. Similary, the demodulated audio and I & Q <br />
data can be returned via Ethernet. We will need a modified version of <br />
PowerSDR/KK to test this and Bill KD5TFD is already working on ways to do <br />
this.<br />
<br />
In order to use this initial software it will be necessary to program the <br />
MAC address of the PC you intend to use with OzyII into the board. We will <br />
provide a Flash memory chip on the PCB that will be programmed with the <br />
boards MAC address during manfacture.<br />
<br />
With the FPGA <> PHY hardware interface working we can start designing the <br />
schematic for OzyII and Lyle KK7P will commence that after his holidays.<br />
<br />
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<br />
<br />
Initially we will use the Gigabit PHY as just a fast connection to the PC and use raw frames to communicate. <br />
<br />
Feedback and comments are requested via the HPSDR reflector. <br />
<br />
Ethernet Notes:<br />
<br />
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.<br />
<br />
===Useful info:===<br />
http://www.wireshark.org/<br />
<br />
http://www.techonline.com/article/pdf/showPDFinIE.jhtml?id=2088017281<br />
<br />
http://www.cs.rice.edu/CS/Architecture/docs/shafer-tree0611.pdf<br />
<br />
Altera White paper on Ethernet using Cyclone III and NIOS soft core<br />
<br />
http://cm.altera.com/g/?QYKFH2NRLY:SU6QAW3Y1V=ssID:480603690<br />
<br />
[[Category:Hardware nearing completion]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=GRIFFIN&diff=3638GRIFFIN2010-08-25T04:20:03Z<p>VK2NRA: make thumb</p>
<hr />
<div>'''GRIFFIN - Stand alone beacon board'''<br />
[[Image:Griffin_Block_Diagram_Rev_1_0.jpg|thumb|500px|Block diagram as of 23 Aug 2010. Click for full size.]] <br />
<br />
Many will be aware of the work undertaken by Bill, KD5TFD, to develop FPGA<br />
code that enables Penelope to operate as a stand alone WSPR beacon. Not<br />
only does his code allow a full implementation of the WSPR protocol, without<br />
the need to connect to a PC, it also enables multiple beacons to operate<br />
simultaneously on multiple bands. This is the dual of multiple independent<br />
receives in a Mercury - multiple independent transmitters in a Penny.<br />
<br />
More details of Bill's work can be found here:<br />
<br />
svn://64.245.179.219/svn/repos_sdr_hpsdr/trunk/PennyWSPR <br />
<br />
There's a README file at:<br />
<br />
svn://64.245.179.219/svn/repos_sdr_hpsdr/trunk/PennyWSPR/README.txt<br />
<br />
One of the advantages we have in the way that HPSDR has evolved is the<br />
ability to try new modes without the need to build or buy new hardware.<br />
Here's another example.<br />
<br />
Many CW operators will remember the time when a CW report, say 559, also<br />
sometimes included a 'C' at the end (e.g. 559C) which indicated the received<br />
signal had a 'chip' i.e. unstable when keyed, FM etc.<br />
<br />
Chirp was regarded as an undesirable feature and best to let the operator<br />
know. There was also the practice of adding an 'H' to the report<br />
indicating Hum. The story goes that the difficulty in obtaining high<br />
voltage smoothing capacitors in Eastern Europe resulted in some operators<br />
applying un-smoothed rectified mains to the anode/plate of the PA stage<br />
giving it a distinctive err... note. However, a story for another day<br />
perhaps.<br />
<br />
The introduction of digital/HDTV in many parts of the world has triggered <br />
the removal of the analogue TV broadcasters that are/were located adjacent <br />
to the 6m band. Magic Band operators often use these stations as an indicator<br />
of propagation conditions. Since they typically run much higher ERP than<br />
Amateur stations, 10's of kW, they were/are an ideal source of propagation<br />
beacons.<br />
<br />
With the removal of these services in many parts of the world 6m operators<br />
loose a very valuable source of propagation information. It's just this <br />
problem that has lead Andrew Martin, VK30E, to develop an alternative that can be used<br />
in either a RADAR or beacon mode.<br />
<br />
Andrew describes his technique fully in the 2/2010 edition of DUBUS<br />
<br />
http://www.marsport.org.uk/dubus/last.htm<br />
<br />
but here's the basic idea.<br />
<br />
We deliberately, repeatedly, linearly sweep the frequency of a carrier over<br />
1kHz in one second. The nominal frequency of the carrier is derived from a<br />
GPS locked 10MHz reference. The start of the one second sweep is<br />
synchronised to the 1 PPS signal from a GPS.<br />
<br />
At the receiver we use a matched filter, again triggered from a 1 PPS signal<br />
from a GPS, to detect the signal. The matched filter in this case runs on<br />
your PC and uses your sound card or VAC to digitise the received signal.<br />
<br />
The effect is similar to WSPR. However, we trade RF bandwidth for time - in<br />
which case the output of the matched filter is available every second rather<br />
then every few minutes as in the case of WSPR. We also gain a signal<br />
processing advantage over WSPR which typically can decode at -26dB in a<br />
2.7kHz bandwidth. 'Chirp' will decode at -36dB in the same bandwidth. If we<br />
integrate multiple chirp signals over say 1 minute then the processing gain<br />
increases to -54dB.<br />
<br />
So if we run a 100W amateur beacon by applying a chirp to the signal we<br />
effectively have a 400kW signal - in line with the TV transmitters we are<br />
trying to replace.<br />
<br />
Initial tests on 20m between Andrew and Don, VK6HK over a 2700Km path, have <br />
shown the technique to work such that a barely audible SSB signal gives a <br />
spike with a 45dB S/N ratio at the output of the matched filter.<br />
<br />
This is chirp in the beacon mode.<br />
<br />
Alternatively, one station can transmit a<br />
chirp signal, using full power and a beam, in a certain direction and<br />
another station listens beaming in the same direction. The stations need to<br />
be sufficiently far apart such that the transmitting station does not<br />
overload the receiver of the receiving station.<br />
<br />
The receiving station will then receive echoes of the transmitted signal<br />
from the various mediums in the direction he is beaming. Since his matched<br />
filter is triggered at exactly the same time as the transmitting station he<br />
can plot of graph of signal strength against distance in miles/km. Such a<br />
graph can clearly show the presence of single and multi hop E's and their<br />
intensity. Andrew's DUBUS article has some very interesting examples of<br />
enhanced 6m propagation that chirp is able to identify.<br />
<br />
The free sound card software Spectrum Lab:<br />
<br />
http://www.qsl.net/dl4yhf/spectra1.html <br />
<br />
will both generate and demodulate chirp signals.<br />
<br />
What would be interesting would be to have a single board that generates a<br />
chirp modulated carrier and could be used as the replacement for the low<br />
level drive stage in a conventional 6m beacon. You guessed it - Penelope!<br />
<br />
Bill kindly offered to take on this 'Weekender Project' (which did actually<br />
fit in a weekend for once!) and produced a version of his PennyWSPR code<br />
that included BOTH a chirp and WSPR beacon and would trigger on the 1 PPS<br />
from a GPS receiver. The nominal frequency of the beacons is at 50.3MHz<br />
(for initial testing) with the chirp extending from 300Hz to 1300Hz above<br />
this and the WSPR beacon 1500Hz above. The WSPR beacon is 6dB below the<br />
power level of the chirp beacon.<br />
<br />
Since VHF beacons in VK are allocated on a 2kHz channel spacing the spectrum <br />
of the two signals fits nicely within an allocated channel.<br />
<br />
Work is also in progress to look at including an aural CW ident on the <br />
allocated carrier frequency.<br />
<br />
Testing is about to start and I'll report progress in due course.<br />
<br />
If testing is successful then we intend to develop an FPGA based PCB that <br />
will provide a 6m/2m beacon exciter stage. The board is intended to be used <br />
as a replacement for the low level driver board in an existing beacon. As <br />
well as the FGPA, power supplies etc, it will include a GPS receiver and <br />
oven controlled 10MHz reference.<br />
<br />
The project leaders for the board was Phil VK6APH and Kevin M0KHZ.<br />
<br />
<br />
[[Category:Future hardware]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=GRIFFIN&diff=3637GRIFFIN2010-08-25T04:16:26Z<p>VK2NRA: change to jpeg image</p>
<hr />
<div>'''GRIFFIN - Stand alone beacon board'''<br />
<br />
[[Image:Griffin_Block_Diagram_Rev_1_0.jpg]] <br />
<br />
Many will be aware of the work undertaken by Bill, KD5TFD, to develop FPGA<br />
code that enables Penelope to operate as a stand alone WSPR beacon. Not<br />
only does his code allow a full implementation of the WSPR protocol, without<br />
the need to connect to a PC, it also enables multiple beacons to operate<br />
simultaneously on multiple bands. This is the dual of multiple independent<br />
receives in a Mercury - multiple independent transmitters in a Penny.<br />
<br />
More details of Bill's work can be found here:<br />
<br />
svn://64.245.179.219/svn/repos_sdr_hpsdr/trunk/PennyWSPR <br />
<br />
There's a README file at:<br />
<br />
svn://64.245.179.219/svn/repos_sdr_hpsdr/trunk/PennyWSPR/README.txt<br />
<br />
One of the advantages we have in the way that HPSDR has evolved is the<br />
ability to try new modes without the need to build or buy new hardware.<br />
Here's another example.<br />
<br />
Many CW operators will remember the time when a CW report, say 559, also<br />
sometimes included a 'C' at the end (e.g. 559C) which indicated the received<br />
signal had a 'chip' i.e. unstable when keyed, FM etc.<br />
<br />
Chirp was regarded as an undesirable feature and best to let the operator<br />
know. There was also the practice of adding an 'H' to the report<br />
indicating Hum. The story goes that the difficulty in obtaining high<br />
voltage smoothing capacitors in Eastern Europe resulted in some operators<br />
applying un-smoothed rectified mains to the anode/plate of the PA stage<br />
giving it a distinctive err... note. However, a story for another day<br />
perhaps.<br />
<br />
The introduction of digital/HDTV in many parts of the world has triggered <br />
the removal of the analogue TV broadcasters that are/were located adjacent <br />
to the 6m band. Magic Band operators often use these stations as an indicator<br />
of propagation conditions. Since they typically run much higher ERP than<br />
Amateur stations, 10's of kW, they were/are an ideal source of propagation<br />
beacons.<br />
<br />
With the removal of these services in many parts of the world 6m operators<br />
loose a very valuable source of propagation information. It's just this <br />
problem that has lead Andrew Martin, VK30E, to develop an alternative that can be used<br />
in either a RADAR or beacon mode.<br />
<br />
Andrew describes his technique fully in the 2/2010 edition of DUBUS<br />
<br />
http://www.marsport.org.uk/dubus/last.htm<br />
<br />
but here's the basic idea.<br />
<br />
We deliberately, repeatedly, linearly sweep the frequency of a carrier over<br />
1kHz in one second. The nominal frequency of the carrier is derived from a<br />
GPS locked 10MHz reference. The start of the one second sweep is<br />
synchronised to the 1 PPS signal from a GPS.<br />
<br />
At the receiver we use a matched filter, again triggered from a 1 PPS signal<br />
from a GPS, to detect the signal. The matched filter in this case runs on<br />
your PC and uses your sound card or VAC to digitise the received signal.<br />
<br />
The effect is similar to WSPR. However, we trade RF bandwidth for time - in<br />
which case the output of the matched filter is available every second rather<br />
then every few minutes as in the case of WSPR. We also gain a signal<br />
processing advantage over WSPR which typically can decode at -26dB in a<br />
2.7kHz bandwidth. 'Chirp' will decode at -36dB in the same bandwidth. If we<br />
integrate multiple chirp signals over say 1 minute then the processing gain<br />
increases to -54dB.<br />
<br />
So if we run a 100W amateur beacon by applying a chirp to the signal we<br />
effectively have a 400kW signal - in line with the TV transmitters we are<br />
trying to replace.<br />
<br />
Initial tests on 20m between Andrew and Don, VK6HK over a 2700Km path, have <br />
shown the technique to work such that a barely audible SSB signal gives a <br />
spike with a 45dB S/N ratio at the output of the matched filter.<br />
<br />
This is chirp in the beacon mode.<br />
<br />
Alternatively, one station can transmit a<br />
chirp signal, using full power and a beam, in a certain direction and<br />
another station listens beaming in the same direction. The stations need to<br />
be sufficiently far apart such that the transmitting station does not<br />
overload the receiver of the receiving station.<br />
<br />
The receiving station will then receive echoes of the transmitted signal<br />
from the various mediums in the direction he is beaming. Since his matched<br />
filter is triggered at exactly the same time as the transmitting station he<br />
can plot of graph of signal strength against distance in miles/km. Such a<br />
graph can clearly show the presence of single and multi hop E's and their<br />
intensity. Andrew's DUBUS article has some very interesting examples of<br />
enhanced 6m propagation that chirp is able to identify.<br />
<br />
The free sound card software Spectrum Lab:<br />
<br />
http://www.qsl.net/dl4yhf/spectra1.html <br />
<br />
will both generate and demodulate chirp signals.<br />
<br />
What would be interesting would be to have a single board that generates a<br />
chirp modulated carrier and could be used as the replacement for the low<br />
level drive stage in a conventional 6m beacon. You guessed it - Penelope!<br />
<br />
Bill kindly offered to take on this 'Weekender Project' (which did actually<br />
fit in a weekend for once!) and produced a version of his PennyWSPR code<br />
that included BOTH a chirp and WSPR beacon and would trigger on the 1 PPS<br />
from a GPS receiver. The nominal frequency of the beacons is at 50.3MHz<br />
(for initial testing) with the chirp extending from 300Hz to 1300Hz above<br />
this and the WSPR beacon 1500Hz above. The WSPR beacon is 6dB below the<br />
power level of the chirp beacon.<br />
<br />
Since VHF beacons in VK are allocated on a 2kHz channel spacing the spectrum <br />
of the two signals fits nicely within an allocated channel.<br />
<br />
Work is also in progress to look at including an aural CW ident on the <br />
allocated carrier frequency.<br />
<br />
Testing is about to start and I'll report progress in due course.<br />
<br />
If testing is successful then we intend to develop an FPGA based PCB that <br />
will provide a 6m/2m beacon exciter stage. The board is intended to be used <br />
as a replacement for the low level driver board in an existing beacon. As <br />
well as the FGPA, power supplies etc, it will include a GPS receiver and <br />
oven controlled 10MHz reference.<br />
<br />
The project leaders for the board was Phil VK6APH and Kevin M0KHZ.<br />
<br />
<br />
[[Category:Future hardware]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=File:Griffin_Block_Diagram_Rev_1_0.jpg&diff=3636File:Griffin Block Diagram Rev 1 0.jpg2010-08-25T04:13:25Z<p>VK2NRA: </p>
<hr />
<div></div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=METIS&diff=3613METIS2010-08-11T06:53:14Z<p>VK2NRA: remove blank lines to tighten displayed page</p>
<hr />
<div>[[Image:OzyII_Block_Diagram_V1.9.jpg|thumb|600px| Block diagram for OzyII V1.0 23 May 2010]]<br />
'''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.<br />
<br />
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. <br />
<br />
Initial thoughts are around an Atlas size board that contains a large, leaded, Altera Cyclone III FPGA connected to a Gigabit Ethernet PHY. <br />
<br />
User input relating to the design and features is requested via the HPSDR reflector.<br />
<br />
Project Leader: Phil, VK6APH <br />
<br />
===Update: 11 August 2010===<br />
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.<br />
<br />
===Update: 1 August 2010===<br />
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]]<br />
<br />
===Update: 15 July 2010===<br />
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. <br />
<br />
===Update: 23 May 2010===<br />
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. <br />
Comments, corrections and suggestions via the openHPSDR reflector please. <br />
<br />
===Update: 8 April 2010===<br />
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. <br />
<br />
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.<br />
<br />
===Update: 15 March 2010===<br />
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.<br />
<br />
===Update: 5 March 2010===<br />
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.<br />
<br />
===Update: 2 March 2010===<br />
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.<br />
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.<br />
<br />
===Update: 11 February 2010===<br />
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.<br />
<br />
Now looking at implementing a soft core uP as an alternative to doing the Discovery code in Verilog.<br />
<br />
===Update: 31 January 2010===<br />
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 :)<br />
<br />
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]]<br />
<br />
===Update: 29 January 2010===<br />
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]].<br />
<br />
===Update: 14 January 2010===<br />
I've completed modifying K.I.S.S. Konsole to work with Ethernet data rather than USB by replacing libUSB with SharpPcap.<br />
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.<br />
<br />
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.<br />
<br />
A prototype PCB is presently being layed out.<br />
<br />
===Update: 27 October 2009===<br />
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.<br />
<br />
Lyle, KK7P, commenced drawing the schematic for OzyII. <br />
<br />
===Update: 27 September 2009===<br />
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. <br />
<br />
===Update: 26 September 2009.===<br />
I'm making good progress with the development of a Gigabit interface to the Atlas bus i.e. OzyII (Aussie2).<br />
<br />
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 <br />
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 <br />
PCB. It's also only needs a single supply, is small, low power and low cost.<br />
<br />
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 <br />
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).<br />
<br />
This has an Eternet connector, access to the RGMII pins and a USB interface. TheUSB interface provides access to read/write all the internal <br />
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.<br />
<br />
I've been able to interface the evaluation board to an Ozy board (see nearby photo) <br />
so that I can write FPGA code to test the PHY in ernest.<br />
<br />
[[Image:Test.JPG|thumb|600px|Micrel evaluation board piggy-backed onto an Ozy board. 26 September 2009]]<br />
<br />
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. <br />
Similarly, any Ethernet frames the PHY receives are by sent to the FPGA and thence via Ozy's USB port back to the PC.<br />
<br />
Thanks to Bill, KD5TFD, for this suggestion - it has certainly speeded up development.<br />
<br />
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.<br />
<br />
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 <br />
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 <br />
nearby.<br />
[[Image:Success.JPG|thumb|300px|PC code to send & receive Ethernet frames from OzyII. 26 September 2009]]<br />
<br />
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 <br />
working in C# then I can port it to Verilog.<br />
<br />
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 <br />
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 <br />
the PHY board.<br />
<br />
This will be a useful developement platform as we move to more advanced protocols in the future.<br />
<br />
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 <br />
and append the CRC32.<br />
<br />
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).<br />
<br />
Once that is working I can grab Mercury I & Q data off the Atlas bus and <br />
send that to the PC via Ethernet. Similary, the demodulated audio and I & Q <br />
data can be returned via Ethernet. We will need a modified version of <br />
PowerSDR/KK to test this and Bill KD5TFD is already working on ways to do <br />
this.<br />
<br />
In order to use this initial software it will be necessary to program the <br />
MAC address of the PC you intend to use with OzyII into the board. We will <br />
provide a Flash memory chip on the PCB that will be programmed with the <br />
boards MAC address during manfacture.<br />
<br />
With the FPGA <> PHY hardware interface working we can start designing the <br />
schematic for OzyII and Lyle KK7P will commence that after his holidays.<br />
<br />
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<br />
<br />
Initially we will use the Gigabit PHY as just a fast connection to the PC and use raw frames to communicate. <br />
<br />
Feedback and comments are requested via the HPSDR reflector. <br />
<br />
Ethernet Notes:<br />
<br />
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.<br />
<br />
===Useful info:===<br />
http://www.wireshark.org/<br />
<br />
http://www.techonline.com/article/pdf/showPDFinIE.jhtml?id=2088017281<br />
<br />
http://www.cs.rice.edu/CS/Architecture/docs/shafer-tree0611.pdf<br />
<br />
Altera White paper on Ethernet using Cyclone III and NIOS soft core<br />
<br />
http://cm.altera.com/g/?QYKFH2NRLY:SU6QAW3Y1V=ssID:480603690<br />
<br />
[[Category:Hardware nearing completion]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Ghpsdr3&diff=3610Ghpsdr32010-08-07T21:48:21Z<p>VK2NRA: move images closer to referring content</p>
<hr />
<div>===Server/Client version of ghpsdr===<br />
[[Image:ghpsdr4.png|thumb|400px|right|Screenshot of the ghpsdr3 GUI on 20 meters. (Click to enlarge)]]<br />
[[Image:Screenshot-JMonitor - Mozilla Firefox.png|thumb|400px|right|Screenshot of the java in a web browser GUI on 40 meters. (Click to enlarge)]]<br />
'''ghpsdr3''' is a software defined radio server/client or server/dspserver/client format program written specifically for HPSDR by John Melton, G0ORX/N6LYT. <br />
<br />
The software is being developed on the Ubuntu version of Linux (specifically version 9.10).<br />
The server and dspserver have been ported to run on Windows--<br />
* [[How to set up on Windows]]<br />
<br />
This version of '''ghpsdr3''' allows for the server and client to be on the same machine or separate machines. The servers are written in C and run on linux machines. John and others are working on a full set of clients to run on multiple machines connecting to the servers through TCP/IP protocals.<br />
<br />
To follow the development of this code look at John's Blog http://g0orx.blogspot.com/<br />
<br />
===SVN===<br />
The software is available from SVN and includes a precompiled executable in the bin directory. There are now a compiled version of the 64-bit linux version, 32-bit linux version and the MacOS version. The README explains how to compile the source if you wish to modify the code.<br />
<br />
Since this code does not currently run on Windows here is the Linux svn command,<br />
<br />
svn co svn://64.245.179.219/svn/repos_sdr_hpsdr/trunk/N6LYT/ghpsdr3<br />
<br />
===Libraries===<br />
It uses a modifed version of DttSP that is ported from the Windows version. DttSP is built as a static library that is linked with the GUI code. The DttSP code is provided with the SVN distribution.<br />
<br />
You will need a couple of libraries to run this code, they include:<br />
* '''libfftw3''' - FFTW is a C subroutine library for computing the discrete Fourier transform (DFT) in one or more dimensions, of arbitrary input size, and of both real and complex data (as well as of even/odd data, i.e. the discrete cosine/sine transforms or DCT/DST).<br />
* '''libgtk2''' - GTK+ is a highly usable, feature rich toolkit for creating graphical user interfaces which boasts cross platform compatibility and an easy to use API.<br />
* '''libusb-1.0''' - libusb is an open source library that allows you to communicate with USB devices from userspace.<br />
These can be obtain with your package installer.<br />
<br />
===Architecture===<br />
[[Image:ghpsdr3.png|thumb|400px|right|Architecture of the server/dspserver/client configuration. (Click to enlarge)]]<br />
The image illustrates the architecture of the ghpsdr3 software chain. The software works with either the single receiver verilog code (Mercury 2.9) or the multiple receiver verilog code or (Mercury 3.0 experimental). If Mercury 2.9 is install only one receiver can be accessed. (Please not that there is a matching ozyfw-sdr1k.hex and Ozy_Janus.rbf file to go with the different versions of the Mercury code).<br />
<br />
'''HPSDR''' box represented the hardware and the Mercury/Ozy,Penelope, Mercury/Magister,Penelope, or Mercury/OzyII,Penelope <br />
<br />
'''Link between HPSDR and Server''' uses the communication protocol documented in USB Protocol v1.27 at the link on this page or in the SVN in the Documentation directory.<br />
<br />
'''Server''' box is a software multiplexer. It takes the multiple receiver communication protocol and divides it in to single receiver channels. <br />
<br />
'''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. <br />
<br />
'''Receiver Clients''' can be in many forms and it was designed to foster experimentation. The first client is the same interface used in '''ghpsdr'''. The second interface is a simple waterfall called '''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.<br />
<br />
In an effort to demonstrate world wide access to your receiver a third approach was developed. In this method the receiver client is a '''dspserver''' that take the output of the '''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 '''dspserver''' also accepts commands from the client. To run multiple low bandwidth clients you must run a separate copy of '''dspserver''' for each client. <br />
<br />
The base code for the current '''jmonitor''' is written in java. It can be run as a program on a computer or within a webbrowser. This code has also been ported to the iphone and 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.<br />
<br />
<br />
Links to other pages:<br />
<br />
* [[ghpsdr3 FAQ|Frequently Asked Questions]]<br />
* [http://www.tapr.org/pdf/2010-G0ORX-N6LYT-Putting-HPSDR-on-Internet.pdf John Melton's 2010 Dayton presentation on ghpsdr3]<br />
* [[Media:ghpsdr3-protocols2010-08-07.pdf|ghpsdr3 communication protocols 2010-08-07]]<br />
* [http://www.n9vv.com/N6LYT-Online-Mercury-Receiver.pdf Ken Hoppers N9VV online documentation of the online multi-receiver setup.]<br />
* [[How to set up on Windows]]<br />
* Features List [[ghpsdr3 Requests|requests]]<br />
* Programmers Notes<br />
* - [[ghpsdr3 Ports|Ports]]<br />
* Known [[ghpsdr3 Bugs|bugs]]<br />
<br />
[[Category:ghpsdr3| ]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=Community_Communication_-_Teamspeak&diff=3341Community Communication - Teamspeak2010-04-30T23:59:40Z<p>VK2NRA: update to delete indexing para</p>
<hr />
<div>There is a weekly forum on Saturday (UTC time which is Friday evening in the US -- see chart below) called Flex-Radio-Friends weekly Teamspeak forum, where folks discuss the projects they are working on, or resolutions to problems they are having. The weekly forum audio is usually posted on http://www.hamsdr.com Forums>Teamspeak. The link to the audio is posted on the HPSDR mailing list.<br />
<br />
Information for getting Started, in PDF format can be found at http://openhpsdr.org/Teamspeak_Quickstart_Guide.pdf.<br />
<br />
Please see the Quickstart guide for current client set up information and password.<br />
<br />
'''October 10, 2009: New URL for Teamspeak''' <br />
<br />
We have a new URL for Teamspeak, An upgrade by the server host has changed the URL for the HPSDR Teamspeak to 74.54.205.236:8802 all other information in the start up guide is the same.<br />
<br />
The Free Windows, Linux and Mac Client programs can be found at at http://www.goteamspeak.com/ Click on the "Download Now" button to the right of the page.<br />
<br />
Due to several time challenged hams, the attendees on Teamspeak sessions have agree to use 01:00 UTC during US daylight time days and 02:00 UTC during standard time days. This leaves the US time for the Teamspeak session constant and the rest of the world shifts by one hour unless they have daylight time shifts.<br />
:0200 UTC Saturday<br />
::2100 EST Friday (9 p.m.)<br />
::2000 CST Friday (8 p.m.)<br />
::1900 MST Friday (7 p.m.)<br />
::1800 PST Friday (6 p.m.)<br />
:0100 UTC Saturday<br />
::2200 EDT Friday (9 p.m.)<br />
::2100 CDT Friday (8 p.m.)<br />
::2000 MDT Friday (7 p.m.)<br />
::1900 PDT Friday (6 p.m.)<br />
<br />
[[Category:Community]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=User_talk:OZ1HFT&diff=3069User talk:OZ1HFT2010-01-26T02:55:13Z<p>VK2NRA: welcome</p>
<hr />
<div>== Welcome ==<br />
<br />
I notice a large number of edits.... and perceive some experience in wiki editing. Thanks!<br />
<br />
I think you name is Glenn and you are in Denmark??? (from Google).<br />
<br />
Welcome and Regards, [[User:VK2NRA|Richard Ames, VK2NRA]] 02:55, 26 January 2010 (UTC)</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=User:VK2NRA&diff=3068User:VK2NRA2010-01-26T02:51:18Z<p>VK2NRA: /* Current Status */ away</p>
<hr />
<div><nowiki>{{userpage}}</nowiki><br />
<br />
== Current Status ==<br />
<br />
<!-- Between vacations! :-) --><br />
I am traveling --- so will be less frequently on the wiki.<br />
<br />
== Introducing myself ==<br />
<br />
My name is Richard Ames and I live in Sydney, Australia.<br />
<br />
I dreamed of being a 'ham' or Amateur license holder as teenager but never did it. I received my 'Standard'<ref>http://www.acma.gov.au/WEB/STANDARD/pc=PC_1255#lo</ref> license in March 2009 and I'm learning the techniques and customs of this hobby.<br />
<br />
Regarding this wiki - I would like to see it used and improved by more of the project participants - users/customers / software people / hardware people.... Have a go - improve something - If there is something I did that you can improve; please do it.!<br />
<br />
== My work aids ==<br />
<br />
[[SandBox1|Sandbox in main space.... don't use for personal work.]]<br />
<br />
[[/sandbox|Sandbox in my user area.]]<br/><br />
[[/sandbox2|Sandbox2 in my user area.]]<br/><br />
[[/sandbox3|Sandbox3 in my user area.]]<br/><br />
[[/sandbox4|Sandbox4 in my user area.]]<br />
<br />
<nowiki><br />
{{User committed identity|ee3023bfe42abfd8d87bbb9703ef8ae7b47c6df204de075a6e423a86ad9783f28dceba42d84658f4a49fba58dbcbab2742a6b6e18968832f50d207fe705d47e7}}</nowiki><br />
<br />
==Notes==<br />
<br />
<references /><br />
<br />
__NOTOC__</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=How_to_use_SVN&diff=2831How to use SVN2009-12-20T19:43:31Z<p>VK2NRA: /* Ozy FX2 */ rem space</p>
<hr />
<div>Most of the HPSDR [[HPSDR related software|software]] repositories are managed by '''Subversion''', which is a popular collaborative software/firmware development tool for open-source projects. This is a code database repository that is developed with all copies of all code that has been checked in by developers. With a system like this you can go back and check out any previous version of the the software. Wikipedia has an overview of SVN at [http://en.wikipedia.org/wiki/Svn_(software) http://en.wikipedia.org/wiki/Svn_(software)]. <br />
<br />
To access this software you will need to install and use a Subversion (SVN) client. There are several clients listed at the above Wikipedia page. Some of our users have found TortoiseSVN for Windows XP easy to use; it can be downloaded from: [http://tortoisesvn.net/ http://tortoisesvn.net/]. The Tortoise documentation is at [http://tortoisesvn.net/support http://tortoisesvn.net/support] or can be accessed by pressing the F1 key in any Tortoise dialog box.<br />
<br />
A free book on subversion is available at: http://svnbook.red-bean.com/<br />
<br />
==Downloading with TortoiseSVN==<br />
<br />
This is meant to be a simplified procedure to use the Windows SVN client 'TortoiseSVN'.<br />
<br />
*You have TortoiseSVN installed and working.<br />
<br />
*Create a new empty directory, Give it a name appropriate to the item(s) you are downloading.<br />
<br />
*Go to that empty directory, right click in the empty directory and from the menu choices choose 'SVN Checkout'. Enter the svn address of the item you want in the box titled 'URL of repository:'. A typical entry would be:<br />
<br />
::svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
*Click OK.<br />
<br />
It should download all the data into the directory.....<br />
<br />
== Our SVN repository ==<br />
<br />
The open HPSDR project maintains a SVN for the the members of the project. The top address of the repository is: <br />
<br />
svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk<br />
<br />
'''Please do not try to check out the entire SVN it is over 2.5 GB'''. Because of problems the root is no longer browsable. The following directories are under the trunk and are browsable.<br />
<br />
Code is not generally erased from a repository. So many of the some of the directories are very active and may change daily other may have not changes in years. Check the dates on the files to determine when tey were lats updated. Your SVN program will help you keep a up to date copy of the code on your computer and you can easily update the directory with a single command. <br />
<br />
The repository evolves over time so the organization is not usually for the new viewer but for those that post code. To help people find things here is an index of major folders. Several directories were not included in this list as they are empty.<br />
<br />
==SVN Directories==<br />
<br />
====AE6VK====<br />
Chris Day's on OzyJanus to be used with SDR1000 from 2007<br />
====Atlas====<br />
Reference files of the the [[ATLAS]] connections to other boards<br />
====CyclopsII====<br />
Verilog and C# code for [[CYCLOPS]]<br />
====Documentation====<br />
USB '''HPSDR''' protocol definitions, [[ATLAS|Atlas]] buss pin definitions<br />
<br />
====I2PHD====<br />
Code by Alberto DiBene for HPSDR Winrad<br />
====Janus-CPLDV2====<br />
Verilog code for Janus Version 2<br />
====Janus-CPLDV3====<br />
Verliog code for Janus Version 3<br />
====K5FR====<br />
Steve Nance's C# code for DDUtil<br />
====KA6S====<br />
Steve Wilson's code for verilog code for i2c simulation<br />
====KD5TFD====<br />
Bill Tracey's utility code for testing a large number of interfaces.<br />
====Mercury====<br />
First version of the Mercury verilog code<br />
====Mercury V2====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.7====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.8====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.9====<br />
Second version of the Mercury verilog code<br />
====N4HY====<br />
Bob McGwier's proposal and Documents of Horton and Odyssey<br />
====N6LYT====<br />
John Melton's code for [[ghpsdr]] (single machine no server) and ghpsdr3 (multiple receiver multi machine) code build for Linux systems. Uses DttSP, FFTw3, libusb1.0 and gtk+.<br />
====N8VB====<br />
Phil Covington's code for MercScope, Ozy V1, and SharpDSP<br />
====OZY2-test====<br />
C and Verilog code for test Ozy2<br />
====Ozy V1.2====<br />
First version of the Ozy verilog code<br />
====Ozy V1.4====<br />
First version of the Ozy verilog code<br />
====Ozy V1.5====<br />
First version of the Ozy verilog code<br />
====Ozy V1.6====<br />
First version of the Ozy verilog code<br />
====Ozy V1.7====<br />
First version of the Ozy verilog code<br />
====OzyFX2====<br />
C# code to talk with FX2<br />
<br />
====OzyII====<br />
C and Verilog code for Ozy II<br />
====OzyJanus-Jack====<br />
C code to allow powerSDR to talk to SDR1000 through [[JANUS]] and Jack<br />
====Ozy-JanusV2====<br />
Verilog code for Ozy-Janus from 2006<br />
====OzyUtil-NativeWin====<br />
C code to initalize Ozy on a Windows system<br />
====OzyV2-JanusV2====<br />
Verilog code for Ozy-Janus based on new [[OZY]] code.<br />
====Penelope====<br />
Initial version verilog code for [[PENELOPE]].<br />
====Penelope V1.2====<br />
First version of the [[PENELOPE]] verilog code<br />
====Phoenix====<br />
Verilog code and documentation for [[PHOENIX]].<br />
====PowerSDR-ForJanusOzy-LatestReleaseBinaries====<br />
PowerSDR files from 2007, PowerSDR code for HPSDR is on the Flex SVN<br />
====ProjectDiagrams====<br />
Diagrams for Atlas and Janus from 2006<br />
====VE3NEA====<br />
Alex Shovkoplyas's verilog and firmware code for HPSDR<br />
====VK6APH====<br />
Phil Harmon's verilog and C# code for various projects<br />
====vu3rdd====<br />
Ramakrishnan Muthukrishnan's code to the USB-Blaster using an Ozy board.<br />
====WA2DFI====<br />
Scotty Cowling information of the code loaded in to production boards.<br />
====WD5Y====<br />
Joe Torrey's code fro PowerSDR using portAudio</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=How_to_use_SVN&diff=2734How to use SVN2009-12-06T22:37:38Z<p>VK2NRA: /* Downloading with TortoiseSVN */ rem blank line</p>
<hr />
<div>Most of the HPSDR [[HPSDR related software|software]] repositories are managed by '''Subversion''', which is a popular collaborative software/firmware development tool for open-source projects. This is a code database repository that is developed with all copies of all code that has been checked in by developers. With a system like this you can go back and check out any previous version of the the software. Wikipedia has an overview of SVN at [http://en.wikipedia.org/wiki/Svn_(software) http://en.wikipedia.org/wiki/Svn_(software)]. <br />
<br />
To access this software you will need to install and use a Subversion (SVN) client. There are several clients listed at the above Wikipedia page. Some of our users have found TortoiseSVN for Windows XP easy to use; it can be downloaded from: [http://tortoisesvn.net/ http://tortoisesvn.net/]. The Tortoise documentation is at [http://tortoisesvn.net/support http://tortoisesvn.net/support] or can be accessed by pressing the F1 key in any Tortoise dialog box.<br />
<br />
A free book on subversion is available at: http://svnbook.red-bean.com/<br />
<br />
==Downloading with TortoiseSVN==<br />
<br />
This is meant to be a simplified procedure to use the Windows SVN client 'TortoiseSVN'.<br />
<br />
*You have TortoiseSVN installed and working.<br />
<br />
*Create a new empty directory, Give it a name appropriate to the item(s) you are downloading.<br />
<br />
*Go to that empty directory, right click in the empty directory and from the menu choices choose 'SVN Checkout'. Enter the svn address of the item you want in the box titled 'URL of repository:'. A typical entry would be:<br />
<br />
::svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
*Click OK.<br />
<br />
It should download all the data into the directory.....<br />
<br />
== Our SVN repository ==<br />
<br />
The open HPSDR project maintains a SVN for the the members of the project. The top address of the repository is: <br />
<br />
svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk<br />
<br />
Code is not generally erased from a repository. So many of the some of the directories are very active and may change daily other may have not changes in years. Check the dates on the files to determine when tey were lats updated. Your SVN program will help you keep a up to date copy o the code on your computer and you can easily update the directory with a single command. <br />
<br />
The repository evolves over time so the organization is not usually for the new viewer but for those that post code. To help people find things here is an index of major folders. Several directories were not included in this list as they are empty.<br />
<br />
==SVN Directories==<br />
<br />
====AE6VK====<br />
Chris Day's on OzyJanus to be used with SDR1000 from 2007<br />
====Atlas====<br />
Reference files of the the [[ATLAS]] connections to other boards<br />
====CyclopsII====<br />
Verilog and C# code for [[CYCLOPS]]<br />
====Documentation====<br />
USB '''HPSDR''' protocol definitions, [[ATLAS|Atlas]] buss pin definitions<br />
<br />
====I2PHD====<br />
Code by Alberto DiBene for HPSDR Winrad<br />
====Janus-CPLDV2====<br />
Verilog code for Janus Version 2<br />
====Janus-CPLDV3====<br />
Verliog code for Janus Version 3<br />
====K5FR====<br />
Steve Nance's C# code for DDUtil<br />
====KA6S====<br />
Steve Wilson's code for verilog code for i2c simulation<br />
====KD5TFD====<br />
Bill Tracey's utility code for testing a large number of interfaces.<br />
====Mercury====<br />
First version of the Mercury verilog code<br />
====Mercury V2====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.7====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.8====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.9====<br />
Second version of the Mercury verilog code<br />
====N4HY====<br />
Bob McGwier's proposal and Documents of Horton and Odyssey<br />
====N6LYT====<br />
John Melton's code for [[ghpsdr]] (single machine no server) and ghpsdr3 (multiple receiver multi machine) code build for Linux systems. Uses DttSP, FFTw3, libusb1.0 and gtk+.<br />
====N8VB====<br />
Phil Covington's code for MercScope, Ozy V1, and SharpDSP<br />
====OZY2-test====<br />
C and Verilog code for test Ozy2<br />
====Ozy V1.2====<br />
First version of the Ozy verilog code<br />
====Ozy V1.4====<br />
First version of the Ozy verilog code<br />
====Ozy V1.5====<br />
First version of the Ozy verilog code<br />
====Ozy V1.6====<br />
First version of the Ozy verilog code<br />
====Ozy V1.7====<br />
First version of the Ozy verilog code<br />
====Ozy FX2====<br />
C# code to talk with FX2<br />
====OzyII====<br />
C and Verilog code for Ozy II<br />
====OzyJanus-Jack====<br />
C code to allow powerSDR to talk to SDR1000 through [[JANUS]] and Jack<br />
====Ozy-JanusV2====<br />
Verilog code for Ozy-Janus from 2006<br />
====OzyUtil-NativeWin====<br />
C code to initalize Ozy on a Windows system<br />
====OzyV2-JanusV2====<br />
Verilog code for Ozy-Janus based on new [[OZY]] code.<br />
====Penelope====<br />
Initial version verilog code for [[PENELOPE]].<br />
====Penelope V1.2====<br />
First version of the [[PENELOPE]] verilog code<br />
====Phoenix====<br />
Verilog code and documentation for [[PHOENIX]].<br />
====PowerSDR-ForJanusOzy-LatestReleaseBinaries====<br />
PowerSDR files from 2007, PowerSDR code for HPSDR is on the Flex SVN<br />
====ProjectDiagrams====<br />
Diagrams for Atlas and Janus from 2006<br />
====VE3NEA====<br />
Alex Shovkoplyas's verilog and firmware code for HPSDR<br />
====VK6APH====<br />
Phil Harmon's verilog and C# code for various projects<br />
====vu3rdd====<br />
Ramakrishnan Muthukrishnan's code to the USB-Blaster using an Ozy board.<br />
====WA2DFI====<br />
Scotty Cowling information of the code loaded in to production boards.<br />
====WD5Y====<br />
Joe Torrey's code fro PowerSDR using portAudio</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=How_to_use_SVN&diff=2730How to use SVN2009-12-06T22:25:51Z<p>VK2NRA: /* Documentation */ fix link</p>
<hr />
<div>Most of the HPSDR [[HPSDR related software|software]] repositories are managed by '''Subversion''', which is a popular collaborative software/firmware development tool for open-source projects. This is a code database repository that is developed with all copies of all code that has been checked in by developers. With a system like this you can go back and check out any previous version of the the software. Wikipedia has an overview of SVN at [http://en.wikipedia.org/wiki/Svn_(software) http://en.wikipedia.org/wiki/Svn_(software)]. <br />
<br />
To access this software you will need to install and use a Subversion (SVN) client. There are several clients listed at the above Wikipedia page. Some of our users have found TortoiseSVN for Windows XP easy to use; it can be downloaded from: [http://tortoisesvn.net/ http://tortoisesvn.net/]. The Tortoise documentation is at [http://tortoisesvn.net/support http://tortoisesvn.net/support] or can be accessed by pressing the F1 key in any Tortoise dialog box.<br />
<br />
A free book on subversion is available at: http://svnbook.red-bean.com/<br />
<br />
==Downloading with TortoiseSVN==<br />
<br />
This is meant to be a simplified procedure to use the Windows SVN client 'TortoiseSVN'.<br />
<br />
*You have TortoiseSVN installed and working.<br />
<br />
*Create a new empty directory, Give it a name appropriate to the item(s) you are downloading.<br />
<br />
*Go to that empty directory, right click in the empty directory and from the menu choices choose 'SVN Checkout'. Enter the svn address of the item you want in the box titled 'URL of repository:'. A typical entry would be:<br />
<br />
::svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
*Click OK.<br />
<br />
It should download all the data into the directory.....<br />
<br />
<br />
== Our SVN repository ==<br />
<br />
The open HPSDR project maintains a SVN for the the members of the project. The top address of the repository is: <br />
<br />
svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk<br />
<br />
Code is not generally erased from a repository. So many of the some of the directories are very active and may change daily other may have not changes in years. Check the dates on the files to determine when tey were lats updated. Your SVN program will help you keep a up to date copy o the code on your computer and you can easily update the directory with a single command. <br />
<br />
The repository evolves over time so the organization is not usually for the new viewer but for those that post code. To help people find things here is an index of major folders. Several directories were not included in this list as they are empty.<br />
<br />
==SVN Directories==<br />
<br />
====AE6VK====<br />
Chris Day's on OzyJanus to be used with SDR1000 from 2007<br />
====Atlas====<br />
Reference files of the the [[ATLAS]] connections to other boards<br />
====CyclopsII====<br />
Verilog and C# code for [[CYCLOPS]]<br />
====Documentation====<br />
USB '''HPSDR''' protocol definitions, [[ATLAS|Atlas]] buss pin definitions<br />
<br />
====I2PHD====<br />
Code by Alberto DiBene for HPSDR Winrad<br />
====Janus-CPLDV2====<br />
Verilog code for Janus Version 2<br />
====Janus-CPLDV3====<br />
Verliog code for Janus Version 3<br />
====K5FR====<br />
Steve Nance's C# code for DDUtil<br />
====KA6S====<br />
Steve Wilson's code for verilog code for i2c simulation<br />
====KD5TFD====<br />
Bill Tracey's utility code for testing a large number of interfaces.<br />
====Mercury====<br />
First version of the Mercury verilog code<br />
====Mercury V2====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.7====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.8====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.9====<br />
Second version of the Mercury verilog code<br />
====N4HY====<br />
Bob McGwier's proposal and Documents of Horton and Odyssey<br />
====N6LYT====<br />
John Melton's code for [[ghpsdr]] (single machine no server) and ghpsdr3 (multiple receiver multi machine) code build for Linux systems. Uses DttSP, FFTw3, libusb1.0 and gtk+.<br />
====N8VB====<br />
Phil Covington's code for MercScope, Ozy V1, and SharpDSP<br />
====OZY2-test====<br />
C and Verilog code for test Ozy2<br />
====Ozy V1.2====<br />
First version of the Ozy verilog code<br />
====Ozy V1.4====<br />
First version of the Ozy verilog code<br />
====Ozy V1.5====<br />
First version of the Ozy verilog code<br />
====Ozy V1.6====<br />
First version of the Ozy verilog code<br />
====Ozy V1.7====<br />
First version of the Ozy verilog code<br />
====Ozy FX2====<br />
C# code to talk with FX2<br />
====OzyII====<br />
C and Verilog code for Ozy II<br />
====OzyJanus-Jack====<br />
C code to allow powerSDR to talk to SDR1000 through [[JANUS]] and Jack<br />
====Ozy-JanusV2====<br />
Verilog code for Ozy-Janus from 2006<br />
====OzyUtil-NativeWin====<br />
C code to initalize Ozy on a Windows system<br />
====OzyV2-JanusV2====<br />
Verilog code for Ozy-Janus based on new [[OZY]] code.<br />
====Penelope====<br />
Initial version verilog code for [[PENELOPE]].<br />
====Penelope V1.2====<br />
First version of the [[PENELOPE]] verilog code<br />
====Phoenix====<br />
Verilog code and documentation for [[PHOENIX]].<br />
====PowerSDR-ForJanusOzy-LatestReleaseBinaries====<br />
PowerSDR files from 2007, PowerSDR code for HPSDR is on the Flex SVN<br />
====ProjectDiagrams====<br />
Diagrams for Atlas and Janus from 2006<br />
====VE3NEA====<br />
Alex Shovkoplyas's verilog and firmware code for HPSDR<br />
====VK6APH====<br />
Phil Harmon's verilog and C# code for various projects<br />
====vu3rdd====<br />
Ramakrishnan Muthukrishnan's code to the USB-Blaster using an Ozy board.<br />
====WA2DFI====<br />
Scotty Cowling information of the code loaded in to production boards.<br />
====WD5Y====<br />
Joe Torrey's code fro PowerSDR using portAudio</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=How_to_use_SVN&diff=2729How to use SVN2009-12-06T22:25:01Z<p>VK2NRA: edit to merge in SVN article</p>
<hr />
<div>Most of the HPSDR [[HPSDR related software|software]] repositories are managed by '''Subversion''', which is a popular collaborative software/firmware development tool for open-source projects. This is a code database repository that is developed with all copies of all code that has been checked in by developers. With a system like this you can go back and check out any previous version of the the software. Wikipedia has an overview of SVN at [http://en.wikipedia.org/wiki/Svn_(software) http://en.wikipedia.org/wiki/Svn_(software)]. <br />
<br />
To access this software you will need to install and use a Subversion (SVN) client. There are several clients listed at the above Wikipedia page. Some of our users have found TortoiseSVN for Windows XP easy to use; it can be downloaded from: [http://tortoisesvn.net/ http://tortoisesvn.net/]. The Tortoise documentation is at [http://tortoisesvn.net/support http://tortoisesvn.net/support] or can be accessed by pressing the F1 key in any Tortoise dialog box.<br />
<br />
A free book on subversion is available at: http://svnbook.red-bean.com/<br />
<br />
==Downloading with TortoiseSVN==<br />
<br />
This is meant to be a simplified procedure to use the Windows SVN client 'TortoiseSVN'.<br />
<br />
*You have TortoiseSVN installed and working.<br />
<br />
*Create a new empty directory, Give it a name appropriate to the item(s) you are downloading.<br />
<br />
*Go to that empty directory, right click in the empty directory and from the menu choices choose 'SVN Checkout'. Enter the svn address of the item you want in the box titled 'URL of repository:'. A typical entry would be:<br />
<br />
::svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
*Click OK.<br />
<br />
It should download all the data into the directory.....<br />
<br />
<br />
== Our SVN repository ==<br />
<br />
The open HPSDR project maintains a SVN for the the members of the project. The top address of the repository is: <br />
<br />
svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk<br />
<br />
Code is not generally erased from a repository. So many of the some of the directories are very active and may change daily other may have not changes in years. Check the dates on the files to determine when tey were lats updated. Your SVN program will help you keep a up to date copy o the code on your computer and you can easily update the directory with a single command. <br />
<br />
The repository evolves over time so the organization is not usually for the new viewer but for those that post code. To help people find things here is an index of major folders. Several directories were not included in this list as they are empty.<br />
<br />
==SVN Directories==<br />
<br />
====AE6VK====<br />
Chris Day's on OzyJanus to be used with SDR1000 from 2007<br />
====Atlas====<br />
Reference files of the the [[ATLAS]] connections to other boards<br />
====CyclopsII====<br />
Verilog and C# code for [[CYCLOPS]]<br />
====Documentation====<br />
USB '''HPSDR''' protocol definitions, [[Atlas]] buss pin definitions<br />
====I2PHD====<br />
Code by Alberto DiBene for HPSDR Winrad<br />
====Janus-CPLDV2====<br />
Verilog code for Janus Version 2<br />
====Janus-CPLDV3====<br />
Verliog code for Janus Version 3<br />
====K5FR====<br />
Steve Nance's C# code for DDUtil<br />
====KA6S====<br />
Steve Wilson's code for verilog code for i2c simulation<br />
====KD5TFD====<br />
Bill Tracey's utility code for testing a large number of interfaces.<br />
====Mercury====<br />
First version of the Mercury verilog code<br />
====Mercury V2====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.7====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.8====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.9====<br />
Second version of the Mercury verilog code<br />
====N4HY====<br />
Bob McGwier's proposal and Documents of Horton and Odyssey<br />
====N6LYT====<br />
John Melton's code for [[ghpsdr]] (single machine no server) and ghpsdr3 (multiple receiver multi machine) code build for Linux systems. Uses DttSP, FFTw3, libusb1.0 and gtk+.<br />
====N8VB====<br />
Phil Covington's code for MercScope, Ozy V1, and SharpDSP<br />
====OZY2-test====<br />
C and Verilog code for test Ozy2<br />
====Ozy V1.2====<br />
First version of the Ozy verilog code<br />
====Ozy V1.4====<br />
First version of the Ozy verilog code<br />
====Ozy V1.5====<br />
First version of the Ozy verilog code<br />
====Ozy V1.6====<br />
First version of the Ozy verilog code<br />
====Ozy V1.7====<br />
First version of the Ozy verilog code<br />
====Ozy FX2====<br />
C# code to talk with FX2<br />
====OzyII====<br />
C and Verilog code for Ozy II<br />
====OzyJanus-Jack====<br />
C code to allow powerSDR to talk to SDR1000 through [[JANUS]] and Jack<br />
====Ozy-JanusV2====<br />
Verilog code for Ozy-Janus from 2006<br />
====OzyUtil-NativeWin====<br />
C code to initalize Ozy on a Windows system<br />
====OzyV2-JanusV2====<br />
Verilog code for Ozy-Janus based on new [[OZY]] code.<br />
====Penelope====<br />
Initial version verilog code for [[PENELOPE]].<br />
====Penelope V1.2====<br />
First version of the [[PENELOPE]] verilog code<br />
====Phoenix====<br />
Verilog code and documentation for [[PHOENIX]].<br />
====PowerSDR-ForJanusOzy-LatestReleaseBinaries====<br />
PowerSDR files from 2007, PowerSDR code for HPSDR is on the Flex SVN<br />
====ProjectDiagrams====<br />
Diagrams for Atlas and Janus from 2006<br />
====VE3NEA====<br />
Alex Shovkoplyas's verilog and firmware code for HPSDR<br />
====VK6APH====<br />
Phil Harmon's verilog and C# code for various projects<br />
====vu3rdd====<br />
Ramakrishnan Muthukrishnan's code to the USB-Blaster using an Ozy board.<br />
====WA2DFI====<br />
Scotty Cowling information of the code loaded in to production boards.<br />
====WD5Y====<br />
Joe Torrey's code fro PowerSDR using portAudio</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=SVN&diff=2727SVN2009-12-06T22:20:39Z<p>VK2NRA: redirect to existing article</p>
<hr />
<div>#REDIRECT [[How to use SVN]]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=How_to_use_SVN&diff=2725How to use SVN2009-12-06T22:18:12Z<p>VK2NRA: add in SVN page</p>
<hr />
<div>Most of the HPSDR [[HPSDR related software|software]] repositories are managed by '''Subversion''', which is a popular collaborative software/firmware development tool for open-source projects. Wikipedia has an overview of SVN at [http://en.wikipedia.org/wiki/Svn_(software) http://en.wikipedia.org/wiki/Svn_(software)]. <br />
<br />
To access this software you will need to install and use a Subversion (SVN) client. There are several clients listed at the above Wikipedia page. Some of our users have found TortoiseSVN for Windows XP easy to use; it can be downloaded from: [http://tortoisesvn.net/ http://tortoisesvn.net/]. The Tortoise documentation is at [http://tortoisesvn.net/support http://tortoisesvn.net/support] or can be accessed by pressing the F1 key in any Tortoise dialog box.<br />
<br />
A free book on subversion is available at: http://svnbook.red-bean.com/<br />
<br />
==Downloading with TortoiseSVN==<br />
<br />
This is meant to be a simplified procedure to use the Windows SVN client 'TortoiseSVN'.<br />
<br />
*You have TortoiseSVN installed and working.<br />
<br />
*Create a new empty directory, Give it a name appropriate to the item(s) you are downloading.<br />
<br />
*Go to that empty directory, right click in the empty directory and from the menu choices choose 'SVN Checkout'. Enter the svn address of the item you want in the box titled 'URL of repository:'. A typical entry would be:<br />
<br />
::svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk/USBBlaster-Binaries<br />
<br />
*Click OK.<br />
<br />
It should download all the data into the directory.....<br />
<br />
<br />
== SVN ==<br />
<br />
SVN stands for the '''Subversion''' is an open source version control system. This is code database repository that is developed with all copies of all code that has been checked in by developers. With a system like this you could go back and check out any previous version of the the software.<br />
<br />
The open HPSDR project maintains a SVN for the the members of the project. The top address of the repository is: <br />
<br />
svn://206.216.146.154/svn/repos_sdr_hpsdr/trunk<br />
<br />
Web browser usually do not browser subversion repositories. You will need some SVN software to access the repository. The names and types of software vary by your operating system. <br />
<br />
Code is not generally erased from a repository. So many of the some of the directories are very active and may change daily other may have not changes in years. Check the dates on the files to determine when tey were lats updated. Your SVN program will help you keep a up to date copy o the code on your computer and you can easily update the directory with a single command. <br />
<br />
The repository evolves over time so the organization is not usually for the new viewer but for those that post code. To help people find things here is a index major folders.<br />
<br />
==SVN Directories==<br />
====AE6VK====<br />
Chris Day's on OzyJanus to be used with SDR1000 from 2007<br />
<br />
====Atlas====<br />
Reference files of the the [[ATLAS]] connections to other boards<br />
====CyclopsII====<br />
Verilog and C# code for [[CYCLOPS]]<br />
====Documentation====<br />
USB '''HPSDR''' protocol definitions, [[Atlas]] buss pin definitions<br />
====I2PHD====<br />
Code by Alberto DiBene for HPSDR Winrad<br />
====Janus-CPLDV2====<br />
Verilog code for Janus Version 2<br />
====Janus-CPLDV3====<br />
Verliog code for Janus Version 3<br />
====K5FR====<br />
Steve Nance's C# code for DDUtil<br />
====KA6S====<br />
Steve Wilson's code for verilog code for i2c simulation<br />
====KD5TFD====<br />
Bill Tracey's utility code for testing a large number of interfaces.<br />
====Mercury====<br />
First version of the Mercury verilog code<br />
====Mercury V2====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.7====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.8====<br />
Second version of the Mercury verilog code<br />
====Mercury V2.9====<br />
Second version of the Mercury verilog code<br />
====N4HY====<br />
Bob McGwier's proposal and Documents of Horton and Odyssey<br />
====N6LYT====<br />
John Melton's code for [[ghpsdr]] (single machine no server) and ghpsdr3 (multiple receiver multi machine) code build for Linux systems. Uses DttSP, FFTw3, libusb1.0 and gtk+.<br />
====N8VB====<br />
Phil Covington's code for MercScope, Ozy V1, and SharpDSP<br />
====OZY2-test====<br />
C and Verilog code for test Ozy2<br />
====Ozy V1.2====<br />
First version of the Ozy verilog code<br />
====Ozy V1.4====<br />
First version of the Ozy verilog code<br />
====Ozy V1.5====<br />
First version of the Ozy verilog code<br />
====Ozy V1.6====<br />
First version of the Ozy verilog code<br />
====Ozy V1.7====<br />
First version of the Ozy verilog code<br />
====Ozy FX2====<br />
C# code to talk with FX2<br />
====OzyII====<br />
C and Verilog code for Ozy II<br />
====OzyJanus-Jack====<br />
C code to allow powerSDR to talk to SDR1000 through [[JANUS]] and Jack<br />
====Ozy-JanusV2====<br />
Verilog code for Ozy-Janus from 2006<br />
====OzyUtil-NativeWin====<br />
C code to initalize Ozy on a Windows system<br />
====OzyV2-JanusV2====<br />
Verilog code for Ozy-Janus based on new [[OZY]] code.<br />
====Penelope====<br />
Initial version verilog code for [[PENELOPE]].<br />
====Penelope V1.2====<br />
First version of the [[PENELOPE]] verilog code<br />
====Phoenix====<br />
Verilog code and documentation for [[PHOENIX]].<br />
====PowerSDR-ForJanusOzy-LatestReleaseBinaries====<br />
PowerSDR files from 2007, PowerSDR code for HPSDR is on the Flex SVN<br />
====ProjectDiagrams====<br />
Diagrams for Atlas and Janus from 2006<br />
====VE3NEA====<br />
Alex Shovkoplyas's verilog and firmware code for HPSDR<br />
====VK6APH====<br />
Phil Harmon's verilog and C# code for various projects<br />
====vu3rdd====<br />
Ramakrishnan Muthukrishnan's code to the USB-Blaster using an Ozy board.<br />
====WA2DFI====<br />
Scotty Cowling information of the code loaded in to production boards.<br />
====WD5Y====<br />
Joe Torrey's code fro PowerSDR using portAudio<br />
<br />
<br />
Several directories were not included in this list as they are empty.</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=FAQ&diff=2661FAQ2009-12-02T23:09:09Z<p>VK2NRA: /* HERMES */ move image out of box</p>
<hr />
<div>== The HPSDR Project ==<br />
<br />
Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''<br />
<br />
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).<br />
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.<br />
<br />
----<br />
<br />
Q. '''How do I get in direct email contact with project leaders?'''<br />
<br />
A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.<br />
<br />
----<br />
<br />
Q. '''What is the status of the various boards or modules?'''<br />
<br />
A. Here's the scoop on some as of May 23, 2009:<br />
<br />
*ATLAS - in production, order through http://tapr.org<br />
*PINOCCHIO - in production, order through http://tapr.org<br />
*OZY - 1st production run - Sold out - PCB are available. Order through http://tapr.org<br />
*JANUS - 1st production run - currently being shipped. Order through http://tapr.org<br />
*MERCURY - 1st production Order through http://tapr.org<br />
*MERCURY-EU - alpha - see Gerd, DJ8AY<br />
*PENELOPE - 1st production run - Sold Out - PCB are available Order through http://tapr.org, available from Gerd, DJ8AY<br />
*LPU - in production - available in kit form. Order through http://tapr.org<br />
*ALEX - Pre-production<br />
*PENNYWHISTLE - Pre-production<br />
*EXCALIBUR - Pre-production<br />
*PANDORA - Pre-production <br />
<br />
All others - in various stages of design/development -- see their wiki pages or the [http://openhpsdr.org HPSDR] website.<br />
<br />
----<br />
<br />
Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''<br />
<br />
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).<br />
<br />
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.”<br />
<br />
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). <br />
<br />
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. <br />
<br />
----<br />
<br />
Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''<br />
<br />
A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or<br />
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.<br />
<br />
----<br />
<br />
Q. '''Will Ozy and Janus "bare boards" be available?'''<br />
<br />
A. Bare boards (not kits of parts) are available through TAPR.<br />
<br />
----<br />
<br />
Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Why not put OZY and JANUS on a single board?'''<br />
<br />
A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation<br />
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated<br />
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<br />
and control. Flexibility is the goal.<br />
<br />
----<br />
<br />
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?'''<br />
<br />
A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.<br />
<br />
----<br />
<br />
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?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''<br />
<br />
A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH<br />
<br />
----<br />
<br />
Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''<br />
<br />
A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.<br />
<br />
----<br />
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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:<br />
<br />
*Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater<br />
<br />
*Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)<br />
<br />
----<br />
<br />
Q. '''What user name and password do I use to access the HPSDR svn repository?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
== The HPSDR Wiki ==<br />
<br />
Q. '''Do I need to log in?'''<br />
<br />
A. Those who contribute by editing the wiki need to have a login.<br />
----<br />
Q. '''How do I get a account? (a login)'''<br />
<br />
A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]<br />
----<br />
Q. '''What if I find that a correction is needed in the wiki?'''<br />
<br />
A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]<br />
----<br />
<br />
== ATLAS Backplane ==<br />
Q. '''What is the recommended means of powering ATLAS?'''<br />
<br />
A. The [[LPU]] or [[DEMETER|Demeter]] (not available yet). <br />
<br />
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.)<br />
<br />
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.)<br />
<br />
As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:<br />
<br />
Ozy/Janus<br />
+12v: 200 ma<br />
+5v: 180 ma<br />
-12v: 70 ma<br />
<br />
Obviously additional boards connected to the Atlas board will increase these numbers.<br />
<br />
Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):<br />
<br />
Penelope<br />
+12v: 200 ma<br />
+5v: 300 ma<br />
<br />
Mercury<br />
+12v: 200 ma<br />
+5v: 500 ma<br />
<br />
Q. '''Will the Atlas be offered assembled?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will a larger (or smaller?) number of slots version be offered?'''<br />
<br />
A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).<br />
<br />
----<br />
<br />
Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''<br />
<br />
A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.<br />
<br />
== PINOCCHIO Extender ==<br />
<br />
Q. '''Availability?'''<br />
<br />
A. The bare board and connectors are now available from TAPR http://tapr.org <br />
<br />
== OZY ==<br />
<br />
Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
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.'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
== JANUS ==<br />
<br />
Q. '''Is Janus a "sound card" ?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''<br />
<br />
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!<br />
<br />
----<br />
<br />
<br />
<br />
== PENELOPE ==<br />
<br />
Q. '''Why are there no output RF filters on the Penelope PCB?'''<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
An external set of filters will be provided as part of the Alex project. <br />
<br />
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.<br />
<br />
== HERMES ==<br />
<br />
[[Image:Image2.jpg]]<br />
<br />
Q. '''What is the Hermes HPSDR Project?'''<br />
<br />
A. [http://openhpsdr.org/hermes.html Hermes] extends the successful OpenHPSDR Mercury, Penelope and Atlas on one PCB board with one FPGA. We do not see Hermes as the ultimate project, just a convenient version in a small package. Many will find the small package inconvenient for the add-on like Excalibur or specialized experimentation.<br />
<br />
Hermes is an experimental platform for future development. Hermes is '''NOT''' a commercial turn-key product. If you are looking for a full featured out-of-the-box SDR transceiver, you should look at the units from [http://wwww.flex-radio.com Flex-Radio] or similar companies. <br />
<br />
Q. '''Where is the Hermes Project Wiki?'''<br />
<br />
A. see [[HERMES]]<br />
<br />
Q. '''What is the History of the Hermes Project?'''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
Hermes - A proposed DUC/DDC Transceiver <br />
<br />
Project Leader: Kevin M0KHZ <br />
<br />
Following the outstanding success of Mercury and Penelope, and while investigating the verilog code for both, I had the insane idea of merging the verilog code of Mercury and Penelope into a single fpga! I played around with this idea for a while and the more I thought about it the more I liked the idea. <br />
<br />
So here is the proposal, to develop a single board HPSDR based on the hardware of Mercury and Penelope and a single large fpga. <br />
<br />
This board would have PC connectivity by USB. I’m planning to squeeze this all onto Euro Card sized PCB (100 x 160 mm), and if I utilize both sides I might even have room for a Pennywhistle type PA :). <br />
<br />
<br />
Q. '''What are the Objectives of the Hermes Project? '''<br />
<br />
A. http://openhpsdr.org/hermes.html Hermes is simply the Mercury, Penelope and Atlas on one board with one FPGA. We do not see Hermes as the ultimate project, just a convenient version in a small package. Many will find the small package inconvenient for the add-on like Excalibur. <br />
<br />
Hermes is an experimental platform for future development. Hermes is '''NOT''' a commercial turn-key product. If you are looking for a full featured out-of-the-box SDR transceiver, you should look at the units from Flex-Radio or similar companies. <br />
<br />
<br />
Q. '''How does the Hermes architecture work? '''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the software and firmware for Hermes?'''<br />
<br />
A. The proposed OpenHPSDR Hermes software implementations are:<br />
:*[[PowerSDR]]<br />
:*[[ KISS Konsole]]<br />
:*[[Ghpsdr]]<br />
:*[[ATHENA|Athena]] Software Framework<br />
:*[http://www.uwsdr.net/ uWSDR] John Melton UK<br />
<br />
<br />
Q. '''Where are the schematics?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Where are the board layout files?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Where are the VHDL files?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Where is the Users Manual?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Where is the Builders Manual?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Where is the Troubleshooting Guide?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Is there an in-depth technical manual?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Where can I get the orientation and training DVD?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Where can I get a power point presentation for my club meeting?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Is there an online Internet Hermes/Apollo radio for me to control remotely?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''Where is the Teamspeak voice over Internet activity?'''<br />
<br />
A.<br />
:*http://www.teamspeak.com/ Teamspeak download website<br />
<br />
:*174.132.74.55:9274 OpenHPSDR Teamspeak IP address<br />
<br />
:*Reference to the Teamspeak Users Installation Guide (pdf)<br />
<br />
<br />
Q. '''What is a DDC receiver [http://openhpsdr.org/mercury.html see Mercury]?'''<br />
<br />
A. DDC is the abbreviation for the term Digital Down Conversion. DDC receivers are able to finally fulfill the dream that has been expressed in Ham Radio magazines for 50 years – to place the digital processing of analog RF information closer to the antenna. The OpenHPSDR Mercury receiver accomplishes that goal. In the OpenHPSDR Mercury and Hermes projects, the antenna is connected to a modern integrated circuit chip. The chip in this case is a '''very''' fast Analog to Digital<br />
conversion device called the LTC2208. The Mercury and Hermes designs are designed to be supplemented by bandpass, attenuation, and pre-amp circuits.<br />
<br />
<br />
Q.'''How does the ADC (Analog to Digital) chip work?'''<br />
<br />
A. The Linear Technologies 2208 is a high speed, state-of-the-art, Analog to Digital conversion integrated circuit. The specifications for the LTC2208 can be found on the [http://www.linear.com/ Linear Technologies website]. The LTC-2208 illustrates the beginning of a most exciting new era in Ham Radio. The ADC offers us the ability to convert analog RF signals to digital signals. The conversions happen in the Mercury and Hermes at the blazing rate of 125 Million Samples Per Second! I realize that this is a difficult concept to grasp. There is a great deal of helpful material available on the Internet and from various magazines and books. The ARRL DSP book written by Doug Smith KF6DX has several chapters devoted to various aspects of digital sampling of analog signals. New Linear Technologies devices allow experimetners to build affordable equipment that processes the digital representation of the entire RF spectrum throughout the HF bands (.05Mhz through 55Mhz). Digital processing gives us extraordinary filters, AGC, MDS, BDR and other level handling that is far beyond any of our older analog circuit designs. The software doesn't change values as equipment heats up and image rejection is always at it's mathematically optimum value. The ability of the LTC-2208 to sustain 125 million samples per second couples it to various algebraic and mathematical methods that are processed easily inside a miniature computer like the Cyclone-III FPGA. A CW signal on 3.552Mhz appears on the output pins of the LTC-2208 among the stream of discrete numerical values ranging from -32768 to +32767. The LTC-2208 converts the RF impulses to decimal values using all sixteen bits of it's internal circuitry. During every tick of your wall clock, the LTC-2208 presents one hundred and twenty five million samples of the RF spectrum at it's output pins. Each numerical sample is an aggregate value of the RF energy throughout the HF spectrum. It is the job of the logic elements in the Cyclone III FPGA to interpret, separate, filter, convert, and prepare the numerical values so that they can be post-processed by the Athena software framework. The Athena software will convert the numerical data back into human viewable form using the magic of DSP and Fourier transforms. The digital signals from the LTC-2208 are passed without interference to the Cyclone-III FPGA in a continuous stream where they are processed in real time. The LTC-2208 includes specialized randomization technology that can be selectively turned on to clarify the signal to noise ratio of it's digital output. You may wish to read some of the excellent digital signal processing material available at no cost on the World Wide Web. Terminology such as “time domain” and “frequency domain” will easily be related to oscilloscope patterns that we are all familiar with. In addition to the ARRL DSP book, another popular text is [http://www.dspguide.com The Scientist and Engineer's Guide to Digital Signal Processing By Steven W. Smith, Ph.D.]<br />
<br />
<br />
Q. '''What is a DUC transmitter or exciter?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''What are the Hermes performance specifications?'''<br />
<br />
A. (to be developed)<br />
<br />
<br />
Q. '''What is the function of the Cyclone FPGA Chip?'''<br />
<br />
A. FPGA is the abbreviation for a '''Field Programmable Gate Array'''. One of the best discussions about FPGA's is on the [http://en.wikipedia.org/wiki/Field-programmable_gate_array Wikipedia]. An FPGA is a reconfigurable and programmable set of basic logic elements like gates. All the computers (CPU's) that we use have similar basic logic elements at their most detailed level. Wikipedia says that applications of FPGA's include digital signal processing, software defined radio, aerospace, defense systems, medical imaging, computer vision, speech recognition, cryptography, bioinformatics, and computer hardware emulation. Fortunately, the exciting complexity and reconfigurability of these logic elements can be expressed in human readable form by using a Hardware Description (programming) Language from Verilog(R) called VHDL.<br />
<br />
<br />
Q. '''What is the "CORDIC" algorithm?'''<br />
<br />
A. (from the Wikipedia webpage [http://en.wikipedia.org/wiki/CORDIC CORDIC])<br />
<br />
CORDIC '''CO'''ordinate '''R'''otation '''DI'''gital '''C'''omputer is a simple and efficient algorithm to calculate hyperbolic and trigonometric functions. It is commonly used when no hardware multiplier is available (e.g., simple microcontrollers and FPGAs) as the only operations it requires are addition, subtraction, bitshift and table lookup.<br />
<br />
The modern CORDIC algorithm was first described in 1959 by Jack E. Volder. It was developed at the aeroelectronics department of Convair to replace the analog resolver in the B-58 bomber's navigation computer,[1] although it is similar to techniques published by Henry Briggs as early as 1624. John Stephen Walther at Hewlett-Packard further generalized the algorithm, allowing it to calculate hyperbolic and exponential functions, logarithms, multiplications, divisions, and square roots.<br />
<br />
Originally, CORDIC was implemented using the binary numeral system. In the 1970s, decimal CORDIC became widely used in pocket calculators, most of which operate in binary-coded-decimal (BCD) rather than binary. CORDIC is particularly well-suited for handheld calculators, an application for which cost (eg, chip gate count has to be minimised) is much more important than is speed. Also the CORDIC subroutines for trigonometric and hyperbolic functions can share most of their code.<br />
<br />
Some good web references are:<br />
:*http://www.itl.nist.gov/div897/sqg/dads/HTML/cordic.html<br />
:*http://www.andraka.com/cordic.htm<br />
:*http://www.jacques-laporte.org/cordic_for_dummies.htm<br />
:*http://www.dspguru.com/dsp/faqs/cordic<br />
:*http://en.wikipedia.org/wiki/CORDIC<br />
<br />
<br />
Q. '''How do signals get from the Analog (RF) to the Digital (I/Q) domain?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do analog (microphone) signals get to the digital domain?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the three "Generations" of SDR technology?'''<br />
<br />
A. The three "Generations" are:<br />
:# the Analog Phasing or "Weaver" method<br />
:# the "Tayloe" or QSD (Quadrature Sampling Detector/mixer)<br />
:# the Direct Down Conversion (DDC/ADC) method<br />
<br />
<br />
<br />
Q. '''Are there any other Generation-III transceivers?'''<br />
<br />
A. Yes there are several that have appeared in various magazines:<br />
:* [http://www.i0cg.com/sdr-x.htm I0CG SDRx Rx/Tx]<br />
:* Peter Martinez G3PLX RADCOM April 2009<br />
:* [http://www.ettus.com/products Ettus Research LLC] USRP2<br />
:* The full HPSDR Atlas + Mercury(Rx) + Pennywhistle(Tx) [[Main_Page|OpenHPSDR]]<br />
<br />
<br />
<br />
Q. '''What is the purpose of the I2C bus in the Hermes project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Why did OpenHPSDR decide to make this an Open Source design?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the overall architecture of the Hermes Transceiver?'''<br />
<br />
A. [insert picture here showing block diagram]<br />
Athena Software Framework <---> Hermes <---> Apollo <---> Antenna<br />
<br />
<br />
Q. '''Will Hermes be a truly "TOR" capable QSK CW rig? (where ARRL defines TOR = T/R time < 20ms)<br />
<br />
A.<br />
<br />
<br />
Q. '''Will Hermes operate on popular digital modes such as PSK31, ALE, and EasyPal digital SSTV?'''<br />
<br />
A.<br />
<br />
<br />
Q. ''' What is the Apollo part of the OpenHPSDR project?"<br />
<br />
A. Apollo is to be a companion 15W PA and Low Pass Filter for Hermes, see: [[APOLLO]]<br />
<br />
<br />
Q. '''Where is the QSD that I see in so many other SDR designs?'''<br />
<br />
A. There is no Quadrature Sampling Detector or Mixer in the Hermes design. All that work is done with clever mathematics inside the Cyclone FPGA chip using the digitized RF directly from the LTC-2208 Analog to Digital (ADC) chip connected to the antenna (via bandpass/preamp).<br />
<br />
<br />
Q. '''Can I build it into my own enclosure (chassis)?'''<br />
A. Yes. The design is flexible and you are encouraged to build Hermes into whatever configuration pleases you. HPSDR hopes to offer a chassis for Hermes that will be pre-punched for all the attachments and connectors.<br />
<br />
<br />
Q. '''Can I build Hermes into my own OEM product for sale?'''<br />
<br />
A. No, the open hardware license allows you to build and enjoy the Hermes transceiver, however you may not build your own commercial product using the HPSDR copyrighted boards and design.<br />
<br />
<br />
Q. '''Where is the Rx Image Rejection adjustment?'''<br />
<br />
A. Image rejection is done with 30 digit floating point precision inside the FPGA where it surpasses any analog design in performance across the entire Rx/Tx spectrum.<br />
<br />
<br />
Q. '''Is the Hermes transceiver reverse polarity protected?'''<br />
<br />
A. Yes, there is protection in the power supply and on each board. Of course the builder should take every possible protection to insure that the power supply is connected properly.<br />
<br />
<br />
Q. '''What is the Dynamic Range of the Hermes (Mercury) receiver?'''<br />
<br />
A. 130dBm<br />
<br />
<br />
Q. '''What are the plans for support of "Gig-E" ethernet?'''<br />
<br />
A. Built into your mITX computer supporting the Hermes.<br />
<br />
<br />
Q. '''What are the plans for support of USB-3?'''<br />
<br />
A. USB-3 has just appeared in various exotic motherboards. We do not expect USB-3 to be an important factor for Hermes until 2011.<br />
<br />
<br />
Q. '''What is Undersampling?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How is Hermes/Apollo different from the [http://www.flex-radio.com/ Flex-Radio(c)] 5000, 3000, and 1500?<br />
<br />
A. <br />
<br />
<br />
Q. '''What is the difference between the Hermes [http://openhpsdr.org/mercury.html Mercury] DDC Rx and the [http://www.srl-llc.com/QS1R QuickSilver] from Phil N8VB Software Radio Laboratory LLC?<br />
<br />
A.<br />
<br />
<br />
Q. '''What power supply is recommended?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What High Voltage MOSFET's are used in the Power Amplifier?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Does Hermes include a "Class-A" bias adjustment?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What commercial Linear Amplifiers will Hermes work with?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can Hermes operate in the VHF/UHF spectrum?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the future plans for the Hermes OpenHPSDR Project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the Apollo board and do I need it?'''<br />
<br />
A. [http://openhpsdr.org/wiki/index.php?title=Apollo_-_Development_Discussion Apollo Discussion]<br />
<br />
<br />
Q. '''How is the Apollo board integrated or connected to the Hermes transceiver?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the OpenHPSDR mailing list?'''<br />
<br />
A.<br />
http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ archives<br />
<br />
http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org subscriptions<br />
<br />
http://openhpsdr.org/ main organization webpage<br />
<br />
<br />
Q. '''How do I record I/Q (RF) data?'''<br />
<br />
A. <br />
<br />
<br />
Q. ''' How do I record Rx audio for later playback?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''I am a talented programmer, how can I help?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do multiple receiver channels work?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How much data can I expect to pump through a USB 2.0 connection?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there a Linux version of the server and GUI?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there an iMAC version of the server and GUI?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is this the Flex-Radio(R) PowerSDR(c) software in disguise?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How is Hermes software different from PowerSDR(c)?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What have you changed in the Dttsp module?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will Hermes software work with the G3UKB Acorn project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can I resize the Hermes GUI to fit my large expensive monitor?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Do you offer color choices or "skins" for the GUI? like a Collins gray or Heathkit green?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do I compile the source code on my MAC/LIN/WIN machine?'''<br />
<br />
A.<br />
<br />
<br />
Q. ''' How do I add a feature to the GUI?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How wide is the panadapter (spectrum) display?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will you ever implement the Cathy Moss 3D waterfall?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will the Hermes GUI work on my Netbook or small laptop?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will the Hermes server work on my Netbook or small laptop?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will the Hermes server and GUI work remotely from each other across the Internet?<br />
<br />
A.<br />
<br />
<br />
Q. '''What is your plan for OpenGL display enhancement?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is your plan for DirectX on Windows platforms?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will Hermes server and GUI work on WindowsXP, Vista, Windows-7?<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the server commands?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the CAT commands and how are they implemented?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What support is available?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can I subscribe to future upgrades and support options?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is custom programming available?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How large is the OpenHPSDR organization?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Do you have a European distributor or dealer?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Do you have an .AU or .NZ distributor or dealer?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can I purchase bare boards and populate them myself?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can I buy the chips individually?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How are the Hermes hardware and software legally protected?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is your Intellectual Property copyrighted or otherwise protected?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the Warranty period?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What does the warranty cover?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What shipping and insurance options are available?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do I avoid the excessive "VAT" tax in my country?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Do you accept payment via PayPal(R)?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Who do I call for help?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How can I contribute to the future success of the Hermes project?'''<br />
<br />
A.<br />
<br />
==NOTES==<br />
<references/><br />
<br />
== Miscellaneous ==<br />
<br />
Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."<br />
<br />
General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=FAQ&diff=2635FAQ2009-12-02T05:44:42Z<p>VK2NRA: /* HERMES */ make internal links internal</p>
<hr />
<div>== The HPSDR Project ==<br />
<br />
Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''<br />
<br />
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).<br />
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.<br />
<br />
----<br />
<br />
Q. '''How do I get in direct email contact with project leaders?'''<br />
<br />
A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.<br />
<br />
----<br />
<br />
Q. '''What is the status of the various boards or modules?'''<br />
<br />
A. Here's the scoop on some as of May 23, 2009:<br />
<br />
*ATLAS - in production, order through http://tapr.org<br />
*PINOCCHIO - in production, order through http://tapr.org<br />
*OZY - 1st production run - Sold out - PCB are available. Order through http://tapr.org<br />
*JANUS - 1st production run - currently being shipped. Order through http://tapr.org<br />
*MERCURY - 1st production Order through http://tapr.org<br />
*MERCURY-EU - alpha - see Gerd, DJ8AY<br />
*PENELOPE - 1st production run - Sold Out - PCB are available Order through http://tapr.org, available from Gerd, DJ8AY<br />
*LPU - in production - available in kit form. Order through http://tapr.org<br />
*ALEX - Pre-production<br />
*PENNYWHISTLE - Pre-production<br />
*EXCALIBUR - Pre-production<br />
*PANDORA - Pre-production <br />
<br />
All others - in various stages of design/development -- see their wiki pages or the [http://openhpsdr.org HPSDR] website.<br />
<br />
----<br />
<br />
Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''<br />
<br />
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).<br />
<br />
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.”<br />
<br />
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). <br />
<br />
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. <br />
<br />
----<br />
<br />
Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''<br />
<br />
A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or<br />
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.<br />
<br />
----<br />
<br />
Q. '''Will Ozy and Janus "bare boards" be available?'''<br />
<br />
A. Bare boards (not kits of parts) are available through TAPR.<br />
<br />
----<br />
<br />
Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Why not put OZY and JANUS on a single board?'''<br />
<br />
A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation<br />
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated<br />
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<br />
and control. Flexibility is the goal.<br />
<br />
----<br />
<br />
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?'''<br />
<br />
A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.<br />
<br />
----<br />
<br />
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?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''<br />
<br />
A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH<br />
<br />
----<br />
<br />
Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''<br />
<br />
A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.<br />
<br />
----<br />
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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:<br />
<br />
*Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater<br />
<br />
*Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)<br />
<br />
----<br />
<br />
Q. '''What user name and password do I use to access the HPSDR svn repository?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
== The HPSDR Wiki ==<br />
<br />
Q. '''Do I need to log in?'''<br />
<br />
A. Those who contribute by editing the wiki need to have a login.<br />
----<br />
Q. '''How do I get a account? (a login)'''<br />
<br />
A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]<br />
----<br />
Q. '''What if I find that a correction is needed in the wiki?'''<br />
<br />
A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]<br />
----<br />
<br />
== ATLAS Backplane ==<br />
Q. '''What is the recommended means of powering ATLAS?'''<br />
<br />
A. The [[LPU]] or [[DEMETER|Demeter]] (not available yet). <br />
<br />
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.)<br />
<br />
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.)<br />
<br />
As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:<br />
<br />
Ozy/Janus<br />
+12v: 200 ma<br />
+5v: 180 ma<br />
-12v: 70 ma<br />
<br />
Obviously additional boards connected to the Atlas board will increase these numbers.<br />
<br />
Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):<br />
<br />
Penelope<br />
+12v: 200 ma<br />
+5v: 300 ma<br />
<br />
Mercury<br />
+12v: 200 ma<br />
+5v: 500 ma<br />
<br />
Q. '''Will the Atlas be offered assembled?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will a larger (or smaller?) number of slots version be offered?'''<br />
<br />
A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).<br />
<br />
----<br />
<br />
Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''<br />
<br />
A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.<br />
<br />
== PINOCCHIO Extender ==<br />
<br />
Q. '''Availability?'''<br />
<br />
A. The bare board and connectors are now available from TAPR http://tapr.org <br />
<br />
== OZY ==<br />
<br />
Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
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.'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
== JANUS ==<br />
<br />
Q. '''Is Janus a "sound card" ?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''<br />
<br />
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!<br />
<br />
----<br />
<br />
<br />
<br />
== PENELOPE ==<br />
<br />
Q. '''Why are there no output RF filters on the Penelope PCB?'''<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
An external set of filters will be provided as part of the Alex project. <br />
<br />
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.<br />
<br />
== HERMES ==<br />
<br />
Q. '''What is the Hermes HPSDR Project?'''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
<br />
Q. '''Where is the Hermes Project Wiki?'''<br />
<br />
A. see [[HERMES]]<br />
<br />
<br />
Q. '''what is the History of the Hermes Project?'''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
<br />
Q. '''What are the Objectives of the Hermes Project? '''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
<br />
Q. '''How does the Hermes architecture work? '''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the software and firmware for Hermes?'''<br />
<br />
A. The Mercury and Hermes software implementations are:<br />
:*[[PowerSDR]]<br />
:*[[ KISS Konsole]]<br />
:*[[Ghpsdr]]<br />
:*[[ATHENA|Athena]] Software Framework<br />
<br />
<br />
Q. '''Where are the schematics?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where are the board layout files?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where are the VHDL files?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Users Manual?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Builders Manual?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Troubleshooting Guide?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there an in-depth technical manual?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where can I get the orientation and training DVD?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where can I get a power point presentation for my club meeting?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there an online Internet Hermes/Apollo radio for me to control remotely?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Teamspeak voice over Internet activity?'''<br />
<br />
A.<br />
:*http://www.teamspeak.com/ Teamspeak download website<br />
<br />
:*174.132.74.55:9274 OpenHPSDR Teamspeak IP address<br />
<br />
:*Reference to the Teamspeak Users Installation Guide (pdf)<br />
<br />
<br />
Q. '''What is a DDC receiver [http://openhpsdr.org/mercury.html see Mercury]?'''<br />
<br />
A. <br />
<br />
<br />
Q.'''How does the ADC (Analog to Digital) chip work?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is a DUC transmitter or exciter?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the Hermes performance specifications?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the function of the Cyclone FPGA Chip?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the "CORDIC" algorithm?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do signals get from the Analog (RF) to the Digital (I/Q) domain?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do analog (microphone) signals get to the digital domain?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the three "Generations" of SDR technology?'''<br />
<br />
A. The three "Generations" are:<br />
:# the Analog Phasing or "Weaver" method<br />
:# the "Tayloe" or QSD (Quadrature Sampling Detector/mixer)<br />
:# the Direct Down Conversion (DDC/ADC) method<br />
<br />
<br />
<br />
Q. '''Are there any other Generation-III transceivers?'''<br />
<br />
A. Yes there are several that have appeared in various magazines:<br />
:* [http://www.i0cg.com/sdr-x.htm I0CG SDRx Rx/Tx]<br />
:* Peter Martinez G3PLX RADCOM April 2009<br />
:* [http://www.ettus.com/products Ettus Research LLC] USRP2<br />
:* The full HPSDR Atlas + Mercury(Rx) + Pennywhistle(Tx) [[Main_Page|OpenHPSDR]]<br />
<br />
<br />
<br />
Q. '''What is the purpose of the I2C bus in the Hermes project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Why did OpenHPSDR decide to make this an Open Source design?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the overall architecture of the Hermes Transceiver?'''<br />
<br />
A. [insert picture here showing block diagram]<br />
Athena Software Framework ---> Hermes ---> Apollo ---> Antenna<br />
<br />
<br />
Q. '''Will Hermes be a truly "TOR" capable QSK CW rig? (where ARRL defines TOR = T/R time < 20ms)<br />
<br />
A.<br />
<br />
<br />
Q. ''' What is the Apollo part of the OpenHPSDR project?"<br />
<br />
A. Apollo is to be a companion 15W PA and Low Pass Filter for Hermes, see: [[APOLLO]]<br />
<br />
<br />
Q. '''Where is the QSD that I see in so many other SDR designs?'''<br />
<br />
A. There is no Quadrature Sampling Detector or Mixer in the Hermes design. All that work is done with clever mathematics inside the Cyclone FPGA chip using the digitized RF directly from the antenna (via bandpass/preamp).<br />
<br />
<br />
Q. '''Can I build it into my own enclosure (chassis)?'''<br />
A. Yes. The design is flexible and you are encouraged to build Hermes into whatever configuration pleases you. HPSDR hopes to offer a chassis for Hermes that will be pre-punched for all the attachments and connectors.<br />
<br />
<br />
Q. '''Can I build Hermes into my own OEM product for sale?'''<br />
<br />
A. No, the open hardware license allows you to build and enjoy the Hermes transceiver, however you may not build your own commercial product using the HPSDR copyrighted boards and design.<br />
<br />
<br />
Q. '''Where is the Rx Image Rejection adjustment?'''<br />
<br />
A. Image rejection is done with 30 digit floating point precision inside the FPGA where it surpasses any analog design in performance across the entire Rx/Tx spectrum.<br />
<br />
<br />
Q. '''Is the Hermes transceiver reverse polarity protected?'''<br />
<br />
A. Yes, there is protection in the power supply and on each board. Of course the builder should take every possible protection to insure that the power supply is connected properly.<br />
<br />
<br />
Q. '''What is the Dynamic Range of the Hermes (Mercury) receiver?'''<br />
<br />
A. 130dBm<br />
<br />
<br />
Q. '''What are the plans for support of "Gig-E" ethernet?'''<br />
<br />
A. Built into your mITX computer supporting the Hermes.<br />
<br />
<br />
Q. '''What are the plans for support of USB-3?'''<br />
<br />
A. USB-3 has just appeared in various exotic motherboards. We do not expect USB-3 to be an important factor for Hermes until 2011.<br />
<br />
<br />
Q. '''What is Undersampling?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How is Hermes/Apollo different from the [http://www.flex-radio.com/ Flex-Radio(c)] 5000, 3000, and 1500?<br />
<br />
A. <br />
<br />
<br />
Q. '''What is the difference between the Hermes [http://openhpsdr.org/mercury.html Mercury] DDC Rx and the [http://www.srl-llc.com/QS1R QuickSilver] from Phil N8VB Software Radio Laboratory LLC?<br />
<br />
A.<br />
<br />
<br />
Q. '''What power supply is recommended?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What High Voltage MOSFET's are used in the Power Amplifier?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Does Hermes include a "Class-A" bias adjustment?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What commercial Linear Amplifiers will Hermes work with?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can Hermes operate in the VHF/UHF spectrum?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the future plans for the Hermes OpenHPSDR Project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the Apollo board and do I need it?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How is the Apollo board integrated or connected to the Hermes transceiver?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the OpenHPSDR mailing list?'''<br />
<br />
A.<br />
http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ archives<br />
<br />
http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org subscriptions<br />
<br />
http://openhpsdr.org/ main organization webpage<br />
<br />
<br />
Q. '''How do I record I/Q (RF) data?'''<br />
<br />
A. <br />
<br />
<br />
Q. ''' How do I record Rx audio for later playback?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''I am a talented programmer, how can I help?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do multiple receiver channels work?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How much data can I expect to pump through a USB 2.0 connection?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there a Linux version of the server and GUI?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there an iMAC version of the server and GUI?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is this the Flex-Radio(R) PowerSDR(c) software in disguise?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How is Hermes software different from PowerSDR(c)?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What have you changed in the Dttsp module?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will Hermes software work with the G3UKB Acorn project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can I resize the Hermes GUI to fit my large expensive monitor?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Do you offer color choices or "skins" for the GUI? like a Collins gray or Heathkit green?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do I compile the source code on my MAC/LIN/WIN machine?'''<br />
<br />
A.<br />
<br />
<br />
Q. ''' How do I add a feature to the GUI?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How wide is the panadapter (spectrum) display?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will you ever implement the Cathy Moss 3D waterfall?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will the Hermes GUI work on my Netbook or small laptop?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will the Hermes server work on my Netbook or small laptop?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will the Hermes server and GUI work remotely from each other across the Internet?<br />
<br />
A.<br />
<br />
<br />
Q. '''What is your plan for OpenGL display enhancement?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is your plan for DirectX on Windows platforms?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Will Hermes server and GUI work on WindowsXP, Vista, Windows-7?<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the server commands?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the CAT commands and how are they implemented?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What support is available?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can I subscribe to future upgrades and support options?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is custom programming available?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How large is the OpenHPSDR organization?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Do you have a European distributor or dealer?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Do you have an .AU or .NZ distributor or dealer?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can I purchase bare boards and populate them myself?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can I buy the chips individually?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How are the Hermes hardware and software legally protected?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is your Intellectual Property copyrighted or otherwise protected?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the Warranty period?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What does the warranty cover?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What shipping and insurance options are available?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do I avoid the excessive "VAT" tax in my country?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Do you accept payment via PayPal(R)?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Who do I call for help?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How can I contribute to the future success of the Hermes project?'''<br />
<br />
A.<br />
<br />
== Miscellaneous ==<br />
<br />
Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."<br />
<br />
General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=User_talk:N9VV&diff=2634User talk:N9VV2009-12-02T05:37:40Z<p>VK2NRA: FAQ placement and linking..</p>
<hr />
<div>==Internal vs External links==<br />
<br />
Hi - I changed some of the links in the [[FAQ]] to be internal. See http://openhpsdr.org/wiki/index.php?title=FAQ&diff=2626&oldid=2625<br />
<br />
That should save some typing and lets the wiki user know they are internal to the wiki. Regards, [[User:VK2NRA|Richard Ames, VK2NRA]] 21:43, 1 December 2009 (UTC)<br />
<br />
:wonderful Richard. Thank you so very much for reading down through the list. I was thinking of asking Dave to see if he can make the Hermes FAQ webpage a separate page from the rest of the FAQ because I made it so large :-) it would still show up in the contents and link properly, but I wonder if it could be separated out?<br />
<br />
:what other Q/A can you please add. Mny Tnx again for your kind help, Happpy Holidays, de Ken N9VV (recovering QuickSilver addict)<br />
<br />
::In general I think the FAQs should be separate for each subject and linked to from their 'parent' page. As an example; see the [[MERCURY]] page and its FAQ page. Possibly there should also be a FAQ index page. Regards, [[User:VK2NRA|Richard Ames, VK2NRA]] 05:37, 2 December 2009 (UTC)</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=User_talk:N9VV&diff=2627User talk:N9VV2009-12-01T21:43:49Z<p>VK2NRA: note on links</p>
<hr />
<div>==Internal vs External links==<br />
<br />
Hi - I changed some of the links in the [[FAQ]] to be internal. See http://openhpsdr.org/wiki/index.php?title=FAQ&diff=2626&oldid=2625<br />
<br />
That should save some typing and lets the wiki user know they are internal to the wiki. Regards, [[User:VK2NRA|Richard Ames, VK2NRA]] 21:43, 1 December 2009 (UTC)</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=FAQ&diff=2626FAQ2009-12-01T21:37:56Z<p>VK2NRA: /* HERMES */ make internal links internal</p>
<hr />
<div>== The HPSDR Project ==<br />
<br />
Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''<br />
<br />
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).<br />
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.<br />
<br />
----<br />
<br />
Q. '''How do I get in direct email contact with project leaders?'''<br />
<br />
A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.<br />
<br />
----<br />
<br />
Q. '''What is the status of the various boards or modules?'''<br />
<br />
A. Here's the scoop on some as of May 23, 2009:<br />
<br />
*ATLAS - in production, order through http://tapr.org<br />
*PINOCCHIO - in production, order through http://tapr.org<br />
*OZY - 1st production run - Sold out - PCB are available. Order through http://tapr.org<br />
*JANUS - 1st production run - currently being shipped. Order through http://tapr.org<br />
*MERCURY - 1st production Order through http://tapr.org<br />
*MERCURY-EU - alpha - see Gerd, DJ8AY<br />
*PENELOPE - 1st production run - Sold Out - PCB are available Order through http://tapr.org, available from Gerd, DJ8AY<br />
*LPU - in production - available in kit form. Order through http://tapr.org<br />
*ALEX - Pre-production<br />
*PENNYWHISTLE - Pre-production<br />
*EXCALIBUR - Pre-production<br />
*PANDORA - Pre-production <br />
<br />
All others - in various stages of design/development -- see their wiki pages or the [http://openhpsdr.org HPSDR] website.<br />
<br />
----<br />
<br />
Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''<br />
<br />
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).<br />
<br />
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.”<br />
<br />
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). <br />
<br />
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. <br />
<br />
----<br />
<br />
Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''<br />
<br />
A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or<br />
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.<br />
<br />
----<br />
<br />
Q. '''Will Ozy and Janus "bare boards" be available?'''<br />
<br />
A. Bare boards (not kits of parts) are available through TAPR.<br />
<br />
----<br />
<br />
Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Why not put OZY and JANUS on a single board?'''<br />
<br />
A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation<br />
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated<br />
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<br />
and control. Flexibility is the goal.<br />
<br />
----<br />
<br />
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?'''<br />
<br />
A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.<br />
<br />
----<br />
<br />
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?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''<br />
<br />
A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH<br />
<br />
----<br />
<br />
Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''<br />
<br />
A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.<br />
<br />
----<br />
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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:<br />
<br />
*Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater<br />
<br />
*Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)<br />
<br />
----<br />
<br />
Q. '''What user name and password do I use to access the HPSDR svn repository?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
== The HPSDR Wiki ==<br />
<br />
Q. '''Do I need to log in?'''<br />
<br />
A. Those who contribute by editing the wiki need to have a login.<br />
----<br />
Q. '''How do I get a account? (a login)'''<br />
<br />
A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]<br />
----<br />
Q. '''What if I find that a correction is needed in the wiki?'''<br />
<br />
A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]<br />
----<br />
<br />
== ATLAS Backplane ==<br />
Q. '''What is the recommended means of powering ATLAS?'''<br />
<br />
A. The [[LPU]] or [[DEMETER|Demeter]] (not available yet). <br />
<br />
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.)<br />
<br />
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.)<br />
<br />
As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:<br />
<br />
Ozy/Janus<br />
+12v: 200 ma<br />
+5v: 180 ma<br />
-12v: 70 ma<br />
<br />
Obviously additional boards connected to the Atlas board will increase these numbers.<br />
<br />
Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):<br />
<br />
Penelope<br />
+12v: 200 ma<br />
+5v: 300 ma<br />
<br />
Mercury<br />
+12v: 200 ma<br />
+5v: 500 ma<br />
<br />
Q. '''Will the Atlas be offered assembled?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will a larger (or smaller?) number of slots version be offered?'''<br />
<br />
A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).<br />
<br />
----<br />
<br />
Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''<br />
<br />
A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.<br />
<br />
== PINOCCHIO Extender ==<br />
<br />
Q. '''Availability?'''<br />
<br />
A. The bare board and connectors are now available from TAPR http://tapr.org <br />
<br />
== OZY ==<br />
<br />
Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
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.'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
== JANUS ==<br />
<br />
Q. '''Is Janus a "sound card" ?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''<br />
<br />
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!<br />
<br />
----<br />
<br />
<br />
<br />
== PENELOPE ==<br />
<br />
Q. '''Why are there no output RF filters on the Penelope PCB?'''<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
An external set of filters will be provided as part of the Alex project. <br />
<br />
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.<br />
<br />
== HERMES ==<br />
<br />
Q. '''What is the Hermes HPSDR Project?'''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
<br />
Q. '''Where is the Hermes Project Wiki?'''<br />
<br />
A. see [[HERMES]]<br />
<br />
<br />
Q. '''what is the History of the Hermes Project?'''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
<br />
Q. '''What are the Objectives of the Hermes Project? '''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
<br />
Q. '''How does the Hermes architecture work? '''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the software and firmware for Hermes?'''<br />
<br />
A. The Mercury and Hermes software implementations are:<br />
:*[[PowerSDR]]<br />
:*[[ KISS Konsole]]<br />
:*[[Ghpsdr]]<br />
:*[[ATHENA|Athena]] Software Framework<br />
<br />
<br />
Q. '''Where are the schematics?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where are the board layout files?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where are the VHDL files?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Users Manual?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Builders Manual?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Troubleshooting Guide?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there an in-depth technical manual?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where can I get the orientation and training DVD?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where can I get a power point presentation for my club meeting:'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there an online Internet Hermes/Apollo radio for me to control remotely?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Teamspeak voice over Internet activity?'''<br />
<br />
A.<br />
:*http://www.teamspeak.com/ Teamspeak download website<br />
<br />
:*174.132.74.55:9274 OpenHPSDR Teamspeak IP address<br />
<br />
:*Reference to the Teamspeak Users Installation Guide (pdf)<br />
<br />
<br />
Q. '''What is a DDC receiver [http://openhpsdr.org/mercury.html see Mercury]?'''<br />
<br />
A. <br />
<br />
<br />
Q.'''How does the ADC (Analog to Digital) chip work?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is a DUC transmitter or exciter?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the Hermes performance specifications?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the function of the Cyclone FPGA Chip?'''<br />
<br />
A.<br />
<br />
Q. '''What is the "CORDIC" algorithm?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do signals get from the Analog (RF) to the Digital (I/Q) domain?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do analog (microphone) signals get to the digital domain?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the three "Generations" of SDR technology?'''<br />
<br />
A. The three "Generations" are:<br />
:# the Analog Phasing or "Weaver" method<br />
:# the "Tayloe" or QSD (Quadrature Sampling Detector/mixer)<br />
:# the Direct Down Conversion (DDC/ADC) method<br />
<br />
<br />
<br />
Q. '''Are there any other Generation-III transceivers?'''<br />
<br />
A. Yes there are several that have appeared in various magazines:<br />
:* [http://www.i0cg.com/sdr-x.htm I0CG SDRx Rx/Tx]<br />
:* Peter Martinez G3PLX RADCOM April 2009<br />
:* [http://www.ettus.com/products Ettus Research LLC] USRP2<br />
:* The full HPSDR Atlas + Mercury(Rx) + Pennywhistle(Tx) + X + Y + Z<br />
<br />
<br />
<br />
Q. '''What is the purpose of the I2C bus in the Hermes project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Why did OpenHPSDR decide to make this an Open Source design?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the overall architecture of the Hermes Transceiver?'''<br />
<br />
A. [insert picture here showing block diagram]<br />
Athena Software Framework ---> Hermes ---> Apollo ---> Antenna<br />
<br />
<br />
Q. '''Where is the QSD that I see in so many other SDR designs?'''<br />
<br />
A. There is no Quadrature Sampling Detector or Mixer in the Hermes design. All that work is done with clever mathematics inside the Cyclone FPGA chip using the digitized RF directly from the antenna (via bandpass/preamp).<br />
<br />
<br />
Q. '''Can I build it into my own enclosure (chassis)?'''<br />
A. Yes. The design is flexible and you are encouraged to build Hermes into whatever configuration pleases you. HPSDR hopes to offer a chassis for Hermes that will be pre-punched for all the attachments and connectors.<br />
<br />
<br />
Q. '''Can I build Hermes into my own OEM product for sale?'''<br />
<br />
A. No, the open hardware license allows you to build and enjoy the Hermes transceiver, however you may not build your own commercial product using the HPSDR copyrighted boards and design.<br />
<br />
<br />
Q. '''Where is the Rx Image Rejection adjustment?'''<br />
<br />
A. Image rejection is done with 30 digit floating point precision inside the FPGA where it surpasses any analog design in performance across the entire Rx/Tx spectrum.<br />
<br />
<br />
Q. '''Is the Hermes transceiver reverse polarity protected?'''<br />
<br />
A. Yes, there is protection in the power supply and on each board. Of course the builder should take every possible protection to insure that the power supply is connected properly.<br />
<br />
<br />
Q. '''What is the Dynamic Range of the Hermes (Mercury) receiver?'''<br />
<br />
A. 130dBm<br />
<br />
<br />
Q. '''What are the plans for support of "Gig-E" ethernet?'''<br />
<br />
A. Built into the mITX computer supporting the Hermes.<br />
<br />
<br />
Q. '''What are the plans for support of USB-3?'''<br />
<br />
A. USB-3 has just appeared in various exotic motherboards. We do not expect USB-3 to be an important factor for Hermes until 2011.<br />
<br />
<br />
Q. '''What is Undersampling?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How is Hermes/Apollo different from the [http://www.flex-radio.com/ Flex-Radio(c)] 5000, 3000, and 1500?<br />
<br />
A. <br />
<br />
<br />
Q. '''What is the difference between the Hermes [http://openhpsdr.org/mercury.html Mercury] DDC Rx and the [http://www.srl-llc.com/QS1R QuickSilver] from Phil N8VB Software Radio Laboratory LLC?<br />
<br />
A.<br />
<br />
<br />
Q. '''What power supply is recommended?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What High Voltage MOSFET's are used in the Power Amplifier?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Does Hermes include a "Class-A" bias adjustment?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What commercial Linear Amplifiers will Hermes work with?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can Hermes operate in the VHF/UHF spectrum?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the future plans for the Hermes OpenHPSDR Project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the Apollo board and do I need it?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How is the Apollo board integrated or connected to the Hermes transceiver?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the OpenHPSDR mailing list?'''<br />
<br />
A.<br />
http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ archives<br />
<br />
http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org subscriptions<br />
<br />
http://openhpsdr.org/ main organization webpage<br />
<br />
<br />
<br />
<br />
----<br />
<br />
== Miscellaneous ==<br />
<br />
Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."<br />
<br />
General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=FAQ&diff=2625FAQ2009-12-01T21:34:01Z<p>VK2NRA: /* PENELOPE */ rem line</p>
<hr />
<div>== The HPSDR Project ==<br />
<br />
Q. '''I have a question that is not covered in this FAQ. How/who do I ask?'''<br />
<br />
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).<br />
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.<br />
<br />
----<br />
<br />
Q. '''How do I get in direct email contact with project leaders?'''<br />
<br />
A. The project leaders are active on the HPSDR Discussion List and you may contact them by posting a message to the list.<br />
<br />
----<br />
<br />
Q. '''What is the status of the various boards or modules?'''<br />
<br />
A. Here's the scoop on some as of May 23, 2009:<br />
<br />
*ATLAS - in production, order through http://tapr.org<br />
*PINOCCHIO - in production, order through http://tapr.org<br />
*OZY - 1st production run - Sold out - PCB are available. Order through http://tapr.org<br />
*JANUS - 1st production run - currently being shipped. Order through http://tapr.org<br />
*MERCURY - 1st production Order through http://tapr.org<br />
*MERCURY-EU - alpha - see Gerd, DJ8AY<br />
*PENELOPE - 1st production run - Sold Out - PCB are available Order through http://tapr.org, available from Gerd, DJ8AY<br />
*LPU - in production - available in kit form. Order through http://tapr.org<br />
*ALEX - Pre-production<br />
*PENNYWHISTLE - Pre-production<br />
*EXCALIBUR - Pre-production<br />
*PANDORA - Pre-production <br />
<br />
All others - in various stages of design/development -- see their wiki pages or the [http://openhpsdr.org HPSDR] website.<br />
<br />
----<br />
<br />
Q. '''What modules would I need to get a working HPSDR transceiver on the air?'''<br />
<br />
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).<br />
<br />
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.”<br />
<br />
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). <br />
<br />
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. <br />
<br />
----<br />
<br />
Q. '''Will the modules be offered in kit or assembled form, and what about cost?'''<br />
<br />
A. Atlas and Pinocchio are offered as a bare board and kit of parts. Ozy and Janus are offered either bare board or<br />
assembled and tested. A hard to get partial parts kit is being offered or Janus. Future module costs to be determined.<br />
<br />
----<br />
<br />
Q. '''Will Ozy and Janus "bare boards" be available?'''<br />
<br />
A. Bare boards (not kits of parts) are available through TAPR.<br />
<br />
----<br />
<br />
Q. '''Why doesn't TAPR offer a kit of parts or at least the hard to obtain parts for Ozy or Janus?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will the Gerber files (PCB artwork) be available for anyone's use?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Why not put OZY and JANUS on a single board?'''<br />
<br />
A. The overall HPSDR project design philosophy has been to partition the design into modules small enough to allow experimentation<br />
with part and design changes and to be able to put together a system meeting individual needs. Putting the ADC chip with associated<br />
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<br />
and control. Flexibility is the goal.<br />
<br />
----<br />
<br />
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?'''<br />
<br />
A. To be determined -- but of course, we expect better results. There are some preliminary results on the wiki and in the discussion list.<br />
<br />
----<br />
<br />
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?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''What will be an appropriate software for companions like Janus + Ozy + Phoenix + (Alex??) ?'''<br />
<br />
A. These boards, and also with the addition of Mercury, will run using PowerSDR. --Phil VK6APH<br />
<br />
----<br />
<br />
Q. '''Is the HPSDR project going to use Windows or some flavor of Linux?'''<br />
<br />
A. Yes! (Eventually both, that is...but, currently, the supported OS is WinXP). There is currently work being done for Linux and dttsp.<br />
<br />
----<br />
Q. '''What are the recommended minimum system requirements for the PC I will use for the HPSDR?'''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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:<br />
<br />
*Processor: Min: 1.5GHz Recommended: 3.2GHz+ or greater<br />
<br />
*Memory: Min: 512MB Recommended: 1GB+ (use the fastest RAM available)<br />
<br />
----<br />
<br />
Q. '''What user name and password do I use to access the HPSDR svn repository?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will HPSDR be developed for higher frequencies like those used for satellite and space communications, e.g. VHF, UHF and Microwave?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
== The HPSDR Wiki ==<br />
<br />
Q. '''Do I need to log in?'''<br />
<br />
A. Those who contribute by editing the wiki need to have a login.<br />
----<br />
Q. '''How do I get a account? (a login)'''<br />
<br />
A. Request it from the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]<br />
----<br />
Q. '''What if I find that a correction is needed in the wiki?'''<br />
<br />
A. Reports such as this are welcomed by the wiki system operator, email: [mailto:kv0s.dave@gmail.com Dave, KV0S]<br />
----<br />
<br />
== ATLAS Backplane ==<br />
Q. '''What is the recommended means of powering ATLAS?'''<br />
<br />
A. The [[LPU]] or [[DEMETER|Demeter]] (not available yet). <br />
<br />
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.)<br />
<br />
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.)<br />
<br />
As a reference for current requirements (reported by Bill Tracey May, 11, 2007), Ozy/Janus used by a SDR100 had the following current usage:<br />
<br />
Ozy/Janus<br />
+12v: 200 ma<br />
+5v: 180 ma<br />
-12v: 70 ma<br />
<br />
Obviously additional boards connected to the Atlas board will increase these numbers.<br />
<br />
Projections of current requirements for other boards are(as reported by Phil Harman, June 6, 2007):<br />
<br />
Penelope<br />
+12v: 200 ma<br />
+5v: 300 ma<br />
<br />
Mercury<br />
+12v: 200 ma<br />
+5v: 500 ma<br />
<br />
Q. '''Will the Atlas be offered assembled?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Can solder paste and a hot air heat gun (or oven) be used on Atlas for "all those connections" ?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will a larger (or smaller?) number of slots version be offered?'''<br />
<br />
A. Possibly, if the need and demand warrant. Nothing is in the plans right now (as of May 2007).<br />
<br />
----<br />
<br />
Q. '''I don't see assignment of all the bus pins. Is there a list somewhere?'''<br />
<br />
A. Some are not assigned a function yet, due to the developing nature of the HPSDR project and the use of the FPGA.<br />
<br />
== PINOCCHIO Extender ==<br />
<br />
Q. '''Availability?'''<br />
<br />
A. The bare board and connectors are now available from TAPR http://tapr.org <br />
<br />
== OZY ==<br />
<br />
Q. '''Will the USB connection from Ozy to my PC require anything special in terms of USB port specification or drivers?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
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.'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Is the design of Ozy such that it can be used for other purposes than SDR?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
== JANUS ==<br />
<br />
Q. '''Is Janus a "sound card" ?'''<br />
<br />
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.<br />
<br />
----<br />
<br />
Q. '''Will I be able to use Janus for other non-SDR sound applications with my PC?'''<br />
<br />
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!<br />
<br />
----<br />
<br />
<br />
<br />
== PENELOPE ==<br />
<br />
Q. '''Why are there no output RF filters on the Penelope PCB?'''<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
An external set of filters will be provided as part of the Alex project. <br />
<br />
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.<br />
<br />
== HERMES ==<br />
<br />
Q. '''What is the Hermes HPSDR Project?'''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
<br />
Q. '''Where is the Hermes Project Wiki?'''<br />
<br />
A. http://openhpsdr.org/wiki/index.php?title=HERMES<br />
<br />
<br />
Q. '''what is the History of the Hermes Project?'''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
<br />
Q. '''What are the Objectives of the Hermes Project? '''<br />
<br />
A. http://openhpsdr.org/hermes.html<br />
<br />
<br />
Q. '''How does the Hermes architecture work? '''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the software and firmware for Hermes?'''<br />
<br />
A. The Mercury and Hermes software implementations are:<br />
:*[http://openhpsdr.org/wiki/index.php?title=PowerSDR PowerSDR]<br />
:*[http://openhpsdr.org/wiki/index.php?title=KISS_Konsole KISS Konsole]<br />
:*[http://openhpsdr.org/wiki/index.php?title=Ghpsdr ghpsdr]<br />
:*[http://openhpsdr.org/wiki/index.php?title=ATHENA Athena] Software Framework<br />
<br />
<br />
Q. '''Where are the schematics?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where are the board layout files?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where are the VHDL files?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Users Manual?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Builders Manual?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Troubleshooting Guide?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there an in-depth technical manual?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where can I get the orientation and training DVD?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where can I get a power point presentation for my club meeting:'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Is there an online Internet Hermes/Apollo radio for me to control remotely?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the Teamspeak voice over Internet activity?'''<br />
<br />
A.<br />
:*http://www.teamspeak.com/ Teamspeak download website<br />
<br />
:*174.132.74.55:9274 OpenHPSDR Teamspeak IP address<br />
<br />
:*Reference to the Teamspeak Users Installation Guide (pdf)<br />
<br />
<br />
Q. '''What is a DDC receiver [http://openhpsdr.org/mercury.html see Mercury]?'''<br />
<br />
A. <br />
<br />
<br />
Q.'''How does the ADC (Analog to Digital) chip work?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is a DUC transmitter or exciter?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the Hermes performance specifications?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the function of the Cyclone FPGA Chip?'''<br />
<br />
A.<br />
<br />
Q. '''What is the "CORDIC" algorithm?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do signals get from the Analog (RF) to the Digital (I/Q) domain?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How do analog (microphone) signals get to the digital domain?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the three "Generations" of SDR technology?'''<br />
<br />
A. The three "Generations" are:<br />
:# the Analog Phasing or "Weaver" method<br />
:# the "Tayloe" or QSD (Quadrature Sampling Detector/mixer)<br />
:# the Direct Down Conversion (DDC/ADC) method<br />
<br />
<br />
<br />
Q. '''Are there any other Generation-III transceivers?'''<br />
<br />
A. Yes there are several that have appeared in various magazines:<br />
:* [http://www.i0cg.com/sdr-x.htm I0CG SDRx Rx/Tx]<br />
:* Peter Martinez G3PLX RADCOM April 2009<br />
:* [http://www.ettus.com/products Ettus Research LLC] USRP2<br />
:* The full HPSDR Atlas + Mercury(Rx) + Pennywhistle(Tx) + X + Y + Z<br />
<br />
<br />
<br />
Q. '''What is the purpose of the I2C bus in the Hermes project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Why did OpenHPSDR decide to make this an Open Source design?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the overall architecture of the Hermes Transceiver?'''<br />
<br />
A. [insert picture here showing block diagram]<br />
Athena Software Framework ---> Hermes ---> Apollo ---> Antenna<br />
<br />
<br />
Q. '''Where is the QSD that I see in so many other SDR designs?'''<br />
<br />
A. There is no Quadrature Sampling Detector or Mixer in the Hermes design. All that work is done with clever mathematics inside the Cyclone FPGA chip using the digitized RF directly from the antenna (via bandpass/preamp).<br />
<br />
<br />
Q. '''Can I build it into my own enclosure (chassis)?'''<br />
A. Yes. The design is flexible and you are encouraged to build Hermes into whatever configuration pleases you. HPSDR hopes to offer a chassis for Hermes that will be pre-punched for all the attachments and connectors.<br />
<br />
<br />
Q. '''Can I build Hermes into my own OEM product for sale?'''<br />
<br />
A. No, the open hardware license allows you to build and enjoy the Hermes transceiver, however you may not build your own commercial product using the HPSDR copyrighted boards and design.<br />
<br />
<br />
Q. '''Where is the Rx Image Rejection adjustment?'''<br />
<br />
A. Image rejection is done with 30 digit floating point precision inside the FPGA where it surpasses any analog design in performance across the entire Rx/Tx spectrum.<br />
<br />
<br />
Q. '''Is the Hermes transceiver reverse polarity protected?'''<br />
<br />
A. Yes, there is protection in the power supply and on each board. Of course the builder should take every possible protection to insure that the power supply is connected properly.<br />
<br />
<br />
Q. '''What is the Dynamic Range of the Hermes (Mercury) receiver?'''<br />
<br />
A. 130dBm<br />
<br />
<br />
Q. '''What are the plans for support of "Gig-E" ethernet?'''<br />
<br />
A. Built into the mITX computer supporting the Hermes.<br />
<br />
<br />
Q. '''What are the plans for support of USB-3?'''<br />
<br />
A. USB-3 has just appeared in various exotic motherboards. We do not expect USB-3 to be an important factor for Hermes until 2011.<br />
<br />
<br />
Q. '''What is Undersampling?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How is Hermes/Apollo different from the [http://www.flex-radio.com/ Flex-Radio(c)] 5000, 3000, and 1500?<br />
<br />
A. <br />
<br />
<br />
Q. '''What is the difference between the Hermes [http://openhpsdr.org/mercury.html Mercury] DDC Rx and the [http://www.srl-llc.com/QS1R QuickSilver] from Phil N8VB Software Radio Laboratory LLC?<br />
<br />
A.<br />
<br />
<br />
Q. '''What power supply is recommended?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What High Voltage MOSFET's are used in the Power Amplifier?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Does Hermes include a "Class-A" bias adjustment?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What commercial Linear Amplifiers will Hermes work with?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Can Hermes operate in the VHF/UHF spectrum?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What are the future plans for the Hermes OpenHPSDR Project?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''What is the Apollo board and do I need it?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''How is the Apollo board integrated or connected to the Hermes transceiver?'''<br />
<br />
A.<br />
<br />
<br />
Q. '''Where is the OpenHPSDR mailing list?'''<br />
<br />
A.<br />
http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/ archives<br />
<br />
http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org subscriptions<br />
<br />
http://openhpsdr.org/ main organization webpage<br />
<br />
<br />
<br />
<br />
----<br />
<br />
== Miscellaneous ==<br />
<br />
Project leaders, developers, documenters: feel free to contribute answers -- especially where it says "TBD" or "Answer pending."<br />
<br />
General Readership: have a suggested question that should be here? Email: [mailto:kv0s.dave@gmail.com Dave, KV0S]</div>VK2NRAhttp://openhpsdr.org/wiki/index.php?title=User:VK2NRA/sandbox4&diff=2539User:VK2NRA/sandbox42009-11-06T00:25:28Z<p>VK2NRA: blank it</p>
<hr />
<div><!-- Start --></div>VK2NRA