V5 Chapter 35


196. 2010-02-17 Logical View of HPSDR

I'm using Intel's 'USB Design by Example' by John Hyde and looking at Figure 1-8 for reference.

195. 2010-02-15 Command Organization

The packet layout in item 191 is realized for a call to the DeepSoftware library to retrieve the firmware version number.

Function GetOzyVersion

function TForm1.GetOzyVersion: string;
i: integer;
buf: array[1..8] of char;
request: TnrUsbRequest;
// prepare request ...
request.ReqType := urtVendor; // (urtStandard , urtClass ,urtVendor )
request.ReqDirection := urdDeviceToHost; // (urdHostToDevice, urdDeviceToHost);
request.ReqRecipient := urrDevice; // (urrDevice, urrInterface, urrEndpoint, urrOther);
request.Index := 0;
request.Value := SDR1KCTRL_READ_VERSION;
request.Request := VRQ_SDR1K_CTL;
request.Length := SizeOf(buf);
request.Data := @buf;

// send request to device
for i := 1 to 8 do
Buf[i] := Char(buf[i]);
Result := buf;

The library is called down near the bottom with nrUSB1.ControlRequest(request). The request type TnrUsbRequest is constructed just above it.

  • The ReqType possibility is set to 'Vendor'
  • ReqDirection is Device (Ozy) to Host (the computer)
  • ReqRecipient is Device. This is where the command is sent. The defination of 'Device' is shown below
  • Index is unused
  • Request is the command sent to the Device to cause it to return the firmware string
  • Length is the size I have setup to capture the return string (8 bytes) of character type
  • Data is a pointer to the buffer that captures the return data (array of 8 characters in this case)

The library itself unwinds the request and sets the bits that correspond to Request Type, Request, Data Value, Index Value and Length in the final call to Windows.

194. 2010-02-14 Moving to nrUSB.Lib

When I started this project (Oh so long ago) I knew that I had to control the High Performance Software Defined Radio (HPSDR) using my programming language of choice - Delphi. I did a few Google searches and came up with a Russian group, DeepSoftware, that was selling a Delphi based USB control library. I purchased the library and started to try to use it on the HPSDR. I failed. I didn't understand the USB nightmare unleashed on the unsuspecting world by Microsoft well enough to get it running. It was simply above my level of understanding to be able to make a translation from the HPSDR software (Kiss Konsole) to a Delphi equivalent.

One of the things I quickly found out was that the few Delphi USB example applications that I found on the net were closely coupled to the hardware that they were intended to control and so there was very little to be learned unless you happen to have that exact same hardware. So I suggested to DeepSoftware that they write an example application that would control the OSR FX2 demonstration hardware. The idea was that I could purchase a OSR kit and run the demo on that hardware and could finally understand how to convert the code to Delphi. DeepSoftware agreed with my idea and started work on the demo application.

As I was waiting for DeepSoftware I decided to switch from a WinUSB driver, like the model being used by DeepSoftware to a libusb0 model used by the base software for the HPSDR (The KISS Konsole written in C#). I thought this would be simpler to get running since I could step through the C# code on the original HPSDR application and make sure it worked like the Delphi code as I translated. So I switched to a Delphi libusb0 library that I was able to download from the web and got a little further but then ran into the next level of USB complexity. The dreaded Enumeration logic. I could not get the Delphi translation past the point of device discovery and enumeration in Delphi.

But then, last week, DeepSoftware came through with a new release of there library (8.0) and a good working demo for the OSR FX2 hardware. I downloaded the new release and the example and quickly had a base point that I could move to using the WinUSB model of a driver and the example code in Delphi. With this release the DeepSoftware library takes care of all the messy stuff like device recognition and enumeration and lets me concentrate on the workings of the Delphi application that I need to write.

So that is the latest in the conversion of the C# KISS Konsole to a Delphi equivalent. I still need to give it a name.

193. 2010-01-27 Still Struggling with SDR

I am still learning how to program the HPSDR receiver. I can now load its FPGA's and am about 1/2 though a translation of the KISS Konsole for HPSDR, which is written in C# to Delphi.

Stay tuned.

192. 2009-10-15 Recording Audio in VISTA

Tonight I came to a problem that I have had to solve over and over. This is a record of the solution so that I don't have to keep re-inventing the damn wheel.

The problem is recording audio with Vista. To night I wanted to analyze a WAV file my system had captured in the course of monitoring the WOW signal area. I could get the WAV file up and playing thorough the audio player (I use WinAmp) but I could not get the audio piped to my Spectrum Analyzer so that I could view it. To view it I have to set the audio subsystem to record from the mixer. Problem is the Mixer does not show up on the audio control panel. After hunting for a way to enable recording of WAV data as it is played I finally found it. This is the trick:

The Trick to recording in VISTA

Select sound from the control panel.
Select the recording tab.
Right click on the background of the tab and choose "show disabled devices."
Right click on Stereo Mix and click enable.

Why Microsoft would make the recording setup this complex is beyond me but I guess they are trying to save Vista users from themselves.

191. 2009-09-02 Working WinUSB FX2 Driver in Delphi (its a start)

I have a first cut at a Delphi driver for the OSR FX2 Learning Kit. It really isn't difficult once you understand it (where have you heard that before). The nice part of the learning kit is that you have a baseline to work from when you tryout new ideas in software. The whole lash up consists of the following:

  • The FX2 kit itself. See the picture below.

  • An INF file that Windows uses to install the drivers needed to interface the hardware to the USB subsystem in Windows (Vista in my case)

  • Two installers. I used WdfCoInstaller01007.dll and WinUSBCoInstaller.dll that I got from Microsoft in their WinDDK

  • The Delphi application that I wrote. It makes use of the WinUSB.dll to control the FX2 board. This includes the source code and executable.

The idea is that you should be able to convert from my straight forward Delphi code to any language you would like. Once you know how to hook up a WinUSB driver and application you can move to another device. My next device will be the HPSDR.

The layout of a packet sent to the OSR FX2 kit is best understood graphically:


Request Type


7 6 5 4 3 2 1 0
Value 1 1 0 0 0 0 1 0


DIR Type Recipient

0= Host to Device

1= Device to Host

0= Standard

1= Class

2= Vendor

3= Reserved


1= Interface

2= Endpoint



$D4 = Read 7 Seg Display

$D6 = Read switches

$D7= Read Bargraph Display

$D8= Set Bargraph Display

$D9= Is High Speed

$DB = Set 7 Seg Display




Length of packet


Value to send/receive

190. 2009-08-20 Down and Dirty with a WinUSB Driver

I thought this would be simple. Buy the SDR, Plug it in, Interface my software with the USB driver so that I could control it and then start using it as the back end of my Radio Astronomy receiver - I shoulda known that wouldn't happen.

It turns out that there are three types of drivers for USB devices that run under Vista. The one that makes the most sense is the latest one, WinUSB from Microsoft. It is a standard drive that handles the interface between the USB ports on the computer and the operating system. To make use of it I have to write a sort of pre-driver that makes the connection between my SETI software and WinUSB. It has to be written in Delphi, which is my development language of choice, so that I can hook it to the SETI software that I have written over the years.

Building a USB driver is difficult at best. There are a huge number of things going on between when you plug in that USB device and when it makes that first cheery two tone up beat. I thrashed my way through a bunch of Microsoft development documents and finally decided that I could build what I want but it would not be simple.

The first step along this path was to order an Open Systems Resources (OSR) tool to learn how to write the code. I expect the kit to show up tomorrow (Friday or Saturday latest).

I'll try to keep this web page up to date as I work though it For details on this kit follow this link OSR USB FX2 Learning Kit.

This board has the same Cypress Semiconductor USB FX2 chipset on it that my HPSDR Ozy board has. Using the kit I expect to be able to write a driver, using OSR's example code that will control the kit Led's and read the DIP switches. Then I can move the Delphi code to the Ozy board itself.

Its a learning process.

189. 2009-08-13 Software and Firmware Update process for HPSDR

Install PowerSDR and HPSDR

  1. Installed USBIO Driver from FlexRadio Systems (Downloads.aspx-id=50). Installation directory is: C:\Program Files\FlexRadio Systems\USBIO Driver

  2. Can't Installed .Net Framework 2.0 on a Vista machine so - go ahead.

  3. Install PowerSDR using TortoiseSVN. Tortoise is a version control system that lets you download the latest software directly from developers machines.

  4. Create directory structure


  5. Navigate to HPSDR

  6. Right click on the directory and select SVN Checkout and cut 'n past this:


  7. Tortoise downloads the current release version of PowerSDR for HPSDR

  8. Create a PowerSDR shortcut (find the PowerSDR.exe file in C:\HPSDR\Release, right click it and select Create Shortcut. Drag shortcut to your desktop)

  9. Double click the shortcut and wait through the one time only startup process. Follow the startup Lizard and select your combination of hardware (for me its Mercury and Ozy).

  10. When It finishes select Start button (top left) to listen to the audio from Mercury headphone jack. If you get a failure at this point it probably because you haven't installed the USB driver for HPSDR.

  11. Your Computer Management console, Device Manager should look like below.


Update Firmware

  1. Created a directory C:\HPSDR\USB Blaster

  2. Right click on it and select SVN Checkout. The directory is loaded

  3. Find Read Me.

  4. Logged into Altera and created an account (JB 66).

  5. Downloaded the download manager and then the Quartus II Programmer and Signal Tap II. Installed in:

  6. Installed just the Ozy board, cabled it up and turned it on. Nice connect sound.

  7. Ran the file usbblaster.bat by double clicking on it, It disconnect Ozy and reconnected a couple of times then completed.

  8. Opened the Device Manager and got it to scan for new hardware since this seems to be what the Altera instructions wants. Vista went out looking through its updates (couldn't stop it from trying) but finally came back and asked me where to look. I entered the location of the driver in the Altera directory.

  9. This did work and the Device Manager now shows \Universal Serial Bus controllers\Altera USB-Blaster.

  10. Set the jumper on the JTAG JP7 for Mercury (slot 5).

  11. Turned on the system and ran the Program-Mecury-EPCS16.bat script. Many errors came up to do with:
    " Could not find: VID and PID". Then I moved Mercury to slot J6 and Ozy to slot J7 and ran the bat again.

SETI Net Driver

The above is for a standard PowerSDR install. This section is for installation of the SETI Net driver for the HPSDR

  1. Run the SETI Net Driver software. The resulting Device Manager should look like this

At this point I don't know why there are two drivers installed for Ozy.

188. 2009-08-01 USB Driver for HPSDR

I'm working on the USB driver for the Ozy board on the HPSDR. The picture below is the driver setup necessary to run PowerSDR with the Mercury receiver. It's here because I'm going to screw with it a lot and need a way to get back to a working system.

Notice that the driver came from FlexRadio Systems/HPSDR.org and is version but it was created under a GPL available at SourceForge. It is an off shoot of libusb-win32. Interesting.

PowerSDR and WWV

PowerSDR (the software) using the FlexRadio USB driver and listening to WWV @ 20 MHz. The dark green band is where I have the bandwidth set for this shot. The large 'hump' is the 20 MHz carrier of WWV and the two smaller are the upper and lower sidebands of the modulation at the time. WWV was transmitting at 1 KHz tone along with the clicks. That even larger hump up band is some sort of local trash probably from one of my (many) computers.

187. 2009-07-04 Radio Astronomy Receiver

I am *really* not happy with the RA Receiver that came with the SRT (the original system). It is very difficult to program it and it doesn't work very well when it works at all. I'm throwing in the towel.

Now I have to decide what RA receiver to use and it boils down to a Software Defined Receiver (SDR) that can be used for RA. These are the choices.

  • HPSDR - High Performance SDR. An open source group that sells the hardware through TAPR

  • WiNRADiO - From Australia. This group that makes fine radios - I have a 1500i myself

  • SDR-14 - from RFSpace - They also make the SDR-IQ

  • USRP - From Ettus Research.

  • Perseus - From SSB Electronics

I have chosen the HPSDR because its an open source project and the software is Windows based. I'm getting a lot of good advice from Joe Martin (K5SO) who has a massive dish that he uses for Earth-Moon-Earth experiments. He has both a HPSDR and a SDR-14 and also recommends the HPSDR. I have a set of boards on order now.

This will be a test setup for the HPSDR when it arrives:

High Performance Software Defined Radio (HPSDR)

The unit as received. The standard ATX power supply connector on the left side, the Ozy board with its USB connector to my development machine (Zeke) and the Mercury receiver with the RG-8 going up to a small antenna on my roof.

I have purchased a new piece of test equipment to aid in this project. An HP 8558B mounted in a HP 180D Oscilloscope Mainframe

This unit covers from 100kHz to 1500MHz with a digital readout for a bit of frequency measurement. Its calibrated so it will be good for power measurements.

I bought this on EBay and then made a run to riverside this morning to pick it up ($250).