Phil Covington Dot Com

PowerSDR - SharpDSP Revision History - Here

Notes: For further information check my blog at http://pcovington.blogspot.com/

July 09, 2005:

Build 226 of the vCOM virtual serial port driver is released.

As I said in an earlier note, I had two reports from two different users that the vCOM driver would cause intermittent system freezes. One one system it happened only a few times and on the other system it happened very often. The system that had frequent system hangs was a hyper-threaded box. There can be only a few causes of system freezes and deadlock is the most likely in multiprocessor and hyperthread systems. I had a race condition caused by excessive use of spinlocks resulting in a deadlock. The probablity of the deaklock happening is much higher in a multiprocessor/hyperthreaded system. This is corrected in build 226.

Important: You will need to edit the N8VBvCOM.inf file to match your current inf file before updating the driver. Once you have the inf edited you can run the update.bat file to update the driver.

June 07, 2005:

Build 224 of the vCOM virtual serial port driver is released.

There were two reports by two different people that vCOM build 222 would hand their system. Not BSOD, but just freeze. I have adjusted the thread priorities in build 224 out of the real-time range where they were set in build 222. I think that perodically the threads priority would be boosted above the GUI's thread priority causing a deadlock.

Important: You will need to edit the N8VBvCOM.inf file to match your current inf file before updating the driver. Once you have the inf edited you can run the update.bat file to update the driver.

July 5, 2005:

I have started a blog at http://pcovington.blogspot.com/

Please check my blog for information about the current development efforts. I will rearrange this webpage so it is easier to find installation and configuration information for the vCOM driver.

June 30, 2005:

Note:

Please refer to notes for June 28 and June 29 about TCP to serial bridge support in PowerSDR: You can run multiple instances of the Serial To TCP Bridge application. Each instance will allow you to connect two serial ports (two applications) to the TCP Server. If you need to connect more programs you can run another instance of Serial To TCP Bridge to give you two more ports. This can be repeated up to the maximum TCP Server connections set in PowerSDR (by default it is 10). Each instance of the Serial To TCP Bridge app takes up ONE connection to the TCP Server in PowerSDR.

I started to take a look at creating a virtual sound card driver for use with PowerSDR. Here are two ways that I thought about doing it:

vsc1

In the above figure we create two virtual sound card instances. They are virtually hooked together as depicted above. The advantage is that they appear to each application as a sound card so MME and DS can be used in both programs.

vsc3

In the above diagram, the driver creates one virtual sound card device and the third party program talks to it as normal using MME or DS.

PowerSDR talks to the driver using normal file read/write IO and custom IOCTL commands instead of through PortAudio's MME or DS.

Which one is preferred? Comments: Email Me

June 29, 2005:

I have a preliminary serial to TCP bridge app. Here are some screenshots:

(click on the image for a full size version)

In the image above PowerSDR's TCP Listener is enabled to listen for connections on port 4444 as in the notes for June 28, 2005 below.

I have two pairs of vCOM ports enabled: The first pair is COM4 and COM5, the second pair is COM6 and COM7.

The Serial To TCP Bridge app connects the virtual com ports to TCP. The app connects to PowerSDR as a client on port 4444.

In the screenshot above HRD is set to connect to COM5. MixW is set to connect to COM7. In the Serial To TCP Bridge app above, COM4 and COM6 are set to bridge to TCP port 4444. Refer to the screenshot below:

bridge

The IP Address is the address of the computer where PowerSDR is running. It can be an IP address or a machine name (or "localhost").

The TCP Port Number must be the port that the PowerSDR TCP Server is listening to for connections (here 4444).

COM Port 1 is the virtual com port that you want to bridge to TCP in the first pair of ports you have installed.   The Enable check box enables COM Port 1.

COM Port 2 is the virtual com port that you want to also bridge to TCP in the second pair of ports you have installed. If you have only one pair of ports installed then you should not enable the COM Port 2 selection.    The Enable check box enables COM Port 2.

The Monitor check boxes determine whether commands can be sent from the virtual com port to the PowerSDR TCP Server or not. If checked, the virtual com port only receives from the TCP Server. Any commands sent to the com port in Monitor mode are not transmitted to the PowerSDR TCP Server. If unchecked the communication is both ways - any commands sent to that virtual port will be sent to the TCP Server. Using Monitor mode another radio can be slaved to PowerSDR.

The Connect button will attempt to connect to the PowerSDR TCP Server with the selected settings. The progress will be reported in the status window.   If a successful connect is made the Serial To TCP Bridge form with minimize, otherwise it will report the error.

The Disconnect button will disconnect from the PowerSDR TCP Server. It also closes the Serial To TCP Bridge application.

Here is the source code diffs and the binaries (based on 1.3.12) to play with. You will have to copy the PowerSDR.exe binary over an existing installed PowerSDR 1.3.12.

Note that the N8VB Serial To TCP Bridge application has to be running on the same computer that HRD, MixW, etc... is running. With just the TCP CAT enabled in PowerSDR you do not have to have the virtual com ports installed on the PowerSDR machine (unless you are running all applications on the same computer).

Here is a diagram of how it is set up:

how it works

If you have only one pair of vCOM ports enabled then COM6 and COM7 above would not exist.

We can get more sophisticated in the monitoring setting by possibly filtering commands on the monitored port. It could be set up so that only query commands such as FA; or FB; can be transmitted to the PowerSDR TCP Server from the monitored port. Any set commands would be filtered out and not sent. We will have to explore these possibilites based on what users want to do with all of it.

Also, to use the bridge with a read hardware port we would need to put settings for the com ports on the bridge form. Right now it is hard coded in the software for 9600, 8, n, 1

June 28, 2005:

I have added preliminary support for TCP in an experimental version of PowerSDR1.3.12. Here are a few screenshots:

(click on the image for a full size version)

The windows titled "TestClient" is just a fast app I wrote to test the CSocketClient and CSocketServer classes that I wrote. I am using it to send and receive to/from PowerSDR. The four windows represent four different simultaneous connections to PowerSDR.

I added a few items to the setup form:

setup

You can enable either CAT via Serial or TCP or both. For TCP you can set the maximun connections allowed and which port number the TCP server listens to for connections from clients.

I used an umodified PowerSDR 1.3.12 as a base so the new serial port code is not in it. This was just for testing purposes though. As Bill, KD5TFD brought up in an email conversation, we will probably have to serialize access to the PowerSDR CAT and a good place might be in the command parser.

The TCP stuff will probably not be integrated into the console until after 1.4.0 is out.

Here is a view of the two new files (3 classes CSocketClient, CSocketServer, TCPListener) added to make it work:

new

SocketUtilites.cs contains the asynchronous CSocketServer and CSocketClient classes.

TCPListener basically has the same function as SIOListener.

The next step is to create a TCP Client to Serial bridge what will allow you to connect to a virtual com port and send/rx data to/from the TCP server in PowerSDR.

COMMENT: I must say that Bob, K5KDN and Bill, KD5TFD have made it very easy to extend the CAT support based on their excellent code.

June 24, 2005:

I wanted to add some additional fixed filter buttons to PowerSDR as well as two sliders for setting the filter low and filter high for the variable filters. PowerSDR is running out of room for all these "enhancements" so I added a tabbed control to the filter selection section of the screen to try to get some more room. See below:

one

When you select either one of the Var buttons on the Fixed Tab it automatically takes you to the Variable tab.

Oh, the above console has not been calibrated with my signal generator yet...

Can we gain some more room by putting some of the other controls on tabs?   Comments, suggestions, hate mail: Email Me

June 22, 2005:

Build 222 of the vCOM virtual serial port driver is released.

New Features:

Build 222 will now allow you to create up to 10 virtual com port pairs.    Each pair acts like a virtual null modem cable.

By default, the inf file that comes with the download will create 1 pair (COM4 and COM5) by default. To change there settings you have to edit the inf file as follows:

Look for the section titled "Localizable Strings"

-------------------------------------------------------------------------------
; *******Localizable Strings*******
N8VB= "N8VB vCOM"
Desc_x860= "N8VB vCOM MultiportSerialdrivers"
N8VBvCOMDesc= "N8VB vCOM Virtual Serial Port Driver"

;NOTE: Edit the following to change com port number and amount of paired ports

;Number Of Pairs
;************
PAIRS=0x01
;PAIRS=0x02
;PAIRS=0x03
;PAIRS=0x04
;PAIRS=0x05
;PAIRS=0x06
;PAIRS=0x07
;PAIRS=0x08
;PAIRS=0x09
;PAIRS=0x0A
;NOTE: MAX is 10 pairs

;Pair 1
;************
PORT1="COM4"
PORT2="COM5"

;Pair 2
;************
PORT3="COM6"
PORT4="COM7"

;Pair 3
;************
PORT5="COM8"
PORT6="COM9"

;Pair 4
;************
PORT7="COM10"
PORT8="COM11"

;Pair 5
;************
PORT9="COM12"
PORT10="COM13"

;Pair 6
;************
PORT11="COM14"
PORT12="COM15"

;Pair 7
;************
PORT13="COM16"
PORT14="COM17"

;Pair 8
;************
PORT15="COM18"
PORT16="COM19"

;Pair 9
;************
PORT17="COM20"
PORT18="COM21"

;Pair 10
;************
PORT19="COM22"
PORT20="COM23"
-------------------------------------------------------------------------------

To change how many port pairs the driver creates you must uncomment one of the settings in the ";Number Of Pairs" table above. By default it is PAIRS=0x01.   To create two pairs you need to comment out PAIRS=0x01 by putting a semicolon in front of that line (;PAIRS=0x01) and then uncomment PAIRS=0x02 by deleting the semicolon in front of that entry.

To change what port numbers are used for each pair you must edit the Pair(n) tables where n is 1 through 10. You must not use com port numbers that are created by a real hardware com port or driver installlation will fail.

Bug Fixes:

It is worthwhile to upgrade to build 222 even if you do not intend to use more than one pair of virtual com ports. I found a few bugs in the DeleteDevice section of the driver that caused problems with creating symbolic links if the driver was previously installed and them removed. The symbolic links were not being deleted correctly. This could either cause BSODs or failure of the driver to reinstall.   Since I had to completely rwrite the AddDevice and DeleteDevice functions within the driver I corrected the bugs and now deletion of the symbolic links appears to work correctly.

See the installation procedure below for updating to build 222. Once this installation procedure is done and build 222 is on your system you should be able to uninstall, make changes to the inf file and then reinstall the driver without having to reboot the system. Also, future builds will be able to be installed without rebooting (hopefully ;-)).

Installing Build 222:

To upgrade to build 222 for an earlier build:

1. Go to Control Panel->System->Hardware->Device Manager and uninstall the current vCOM driver. It will be under Multi-port Serial Adapters in Device Manager.

2. Open Start->Run->RegEdit. In RegEdit navigate to HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM. If you see any entries named \Device\vComDrvx where x = 0...n, right click on these entries and select delete. This will delete any symbolic links that were supposed to be deleted when build 114 or earlier was uninstalled.

3. REBOOT your computer. This is important! Do not try to install build 222 until after you have rebooted your computer.

4. Go to Control Panel->System->Hardware->Device Manager and verify that the vCOM driver has not been loaded.

5.   Edit the N8VB_vCOM.inf file as described above to select your virtual com ports and number of pairs.

6.   Navigate to the N8VB_vCOMBuild222 folder and run install.bat (make sure you have admin privileges!). Some users have reported that just double clicking on install.bat in a Windows Explorer window does not work for them. It appears to be releated to Windows XP Home Edition.   They have reported success by first opening a console window and running install.bat from there.

HRD NOTES:

To use PowerSDR with Ham Radio Deluxe you should select TS-50S for the radio type. The current CAT command support in PowerSDR does not implement all of the TS-2000 commands so HRD will update very slowly if you set it for TS-2000.   Eventually HRD will support the SDR-1000, but right now selecting TS-50S works ok.

OTHER NOTES:

Eventually the vCOM driver will have a proper installation program that will make it easier to configure all of the settings.

June 13, 2005:

Build 114 of the vCOM virtual serial port driver is released.

Bug Fix: (reported by Bill KD5TFD, Mel K0PFX , and Gary AI4IN)
The RTS/DTR logic in the driver was reversed. This was corrected with a test release or build 113. After additional testing I found another bug in the IOCTL_SERIAL_GET_MODEMSTATUS that caused the driver to return invalid state status of the CTS and DSR lines.

General Notes:
The driver will work with Windows 2000 and Windows XP. It will not work with Windows 98/ME.
By default the virtual com port pair is set to COM4 and COM5 in the N8VB_vCOM.inf file. If you want to use other port numbers you must edit the inf file.

Look for this section in the .inf file:

[Strings]

; *******Localizable Strings*******
N8VB= "N8VB vCOM"
Desc_x860= "N8VB vCOM MultiportSerialdrivers"
N8VBvCOMDesc= "N8VB vCOM Virtual Serial Port Driver"
PORT1="COM4"
PORT2="COM5"

Change "COM4" or "COM5" to your desired port numbers, but do not set them to ports that already exist on your system.

June 09, 2005:

Build 112 of the vCOM virtual serial port driver is released.

Bug Fix: (reported by Bob K5KDN)
A bug has been fixed that causes vCOM to stop responding when using DXLabCommander. This was related to the vCOMReadFast function not signalling an Event properly.

Other Changes:

Each vCOM virtual serial port has three threads associated with it - the writethread, transferthread, and readthread. The writethread transfers data into the device's input buffer. Once the data is transfered to the device's input buffer an event is signaled that causes the transferthread to run. The transferthread removes data from the device's input buffer and writes it to its twin device's outputbuffer. The transferthread then signals an event that causes the twin com port's readthread to run if it was waiting on data. This process limits the speed at which the vCOM driver can send/receive data due to the system thread scheduling. Doing some testing it still appears that the data transfer was extremely fast - faster than we will probably ever use. Still, there was a way to optimize the driver so I did it. I added three new functions vCOMFastRead, vCOMFastWrite, and vCOMFastTransfer to the driver. Basically it allows read and writes to the driver to bypass waiting on the three threads described above to do the work. If the operation can be done immediately and synchronous with the read or write request the driver fulfills the request without using the request queues or associated threads. This should reduce system load and increase the data throughput rate on a heavily loaded system. Anyway, I couldn't resist an optimization.

I built a fast and dirty program that simulates talking to a Kenwood radio via CAT commands for use in testing the vCOM driver. It is a SharpDevelop project but can easily be converted to VS 2003. It includes the binary and source. It works with HRD, DXLab Commander, BandMaster, and MixW (at least that is what I have used it with). It may help those who want to make sure everything is working with vCOM. You don't need SharpDevelop to use it since it includes the executable (in the Release folder).

Here is a couple of screen shots:

test1

test2

June 07, 2005:

Build 110 of the vCOM virtual serial port driver is released.

Earlier I reported that vCOM build 107 would work with DXLab Commander. This was only half true. It was one way communication - to the SDR. DXLab Commander would not read from the SDR. When I tried to verify that DXLab Commander worked with Build 107 I had inadvertently left the com ports set for the MixW driver instead of vCOM. I was testing both MixW and vCOM loaded together on the same machine and it was kind of late and I was kind of tired...and well... vCOM build 107 did not work with DXLab Commander.

I emailed Dave, AA6YQ, the author of DXLab and he immediately responded with information that helped me track down the problem. DXLab Commander uses the MSCOMM serial control for serial communication. After doing some searching with Google I found this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;318784

All read requests in builds 107 and earlier were serialized on a read queue. When the read request was placed on the queue I returned STATUS_PENDING. When the read thread in the driver would run the request was dequeued and then completed with STATUS_SUCCESS. It turns out that MSCOMM does not like this. It does not want to see a STATUS_PENDING response when in a certain mode (when the timeouts are set in such a way as to make the driver immediately return with whatever is in the read buffer).

Build 110 of vCOM has been modified to process a read request immediately (not putting it on the read queue) when the timeouts are set so that the driver should return immediately with whatever is in the read buffer (even if there is nothing in the read buffer).

The MixW driver did work with DXLab Commander because the MixW driver blocks on a read (and in doing so never returns STATUS_PENDING to mess up MSCOMM).

I have tested the new driver with HRD, OmniRig/BandMaster, DXLab Commander, and MixW.

Please try the new version of the driver and report any problems. Thanks to everyone who reported the problems with build 107.

See info in notes below for installation instructions.

ALSO: Bill, KD5TFD has made a correction to the CAT support in PowerSDR to make it work with com ports with numbers greater than 9. It was another Microsoft Glitch that had to be dealt with in a different way than what the MS documentation described.

June 03, 2005:

Build 107 of the vCOM virtual serial port driver is released.

It appears that I have finally eradicated the BAD_POOL_HEADER bug that caused problems in Builds 72 and earlier. There has been a considerable rewrite of the code.

I have tested the new driver with HRD, OmniRig/BandMaster, DXLab Commander, and MixW.

Please try the new version of the driver and report any problems.

May 26, 2005:

Build 72 of the vCOM virtual serial port driver is released.

* Some changes to the source code were made to make it work smoothly with Ham Radio Deluxe (HRD).

Also, I had to modify the CAT code in PowerSDR 1.3.4 so it would work with HRD. If you would like to try PowerSDR1.3.4 with HRD here is the binary and source changes.
Copy the binary over the original PowerSDR.exe binary in the PowerSDR1.3.4 folder. In HRD select Kenwood TS-50S. The CAT code responds to the FA; and FB; queries as well as the SM; query (S-meter reading). Right now the s-meter will just read zero on HRD. I was too lazy to return the value from PowerSDR since my object was just to make HRD happy enough so it would talk to the SDR-1000.

I have an issue with using HRD and PowerSDR1.3.4 with build 72 of the vCOM driver on one of my machines. Periodically I will get a BSOD (BAD_POOL_HEADER) if I move the tuning sliders in HRD too fast. Obviously it is some timing issue in the driver but I have been unable to track it down. It is not reproducable on my debug machine. I will look closer into this next week. My two other machines do not show this problem.

I will be out of town on vacation from May 26 through May 30 so I won't be able to respond to email questions about vCOM until I get back.

See instructions below for installation.

Here is a (large) screenshot:

powersdr-hrd

May 24, 2005:

Build 70 of the vCOM virtual serial port driver is released.

* Some changes to the driver's unload function should reduce problems with upgrading to a newer build.

* Code was cleaned up a bit.

See notes below for installation.

May 20, 2005:

Build 55 of the vCOM virtual serial port driver is released. I know, I know... your head is getting dizzy with all these updates!

A few small changes were needed to how the driver handles IOCTL_SERIAL_PURGE requests to make the driver work with OmniRig which is a freeware rig control engine used by Band Master. I was clearing the event mask on a SERIAL_PURGE_RXCLEAR which caused OmniRig to stall on its last IOCTL_SERIAL_WAIT_ON_MASK.

Also, I had to add support for the FA; and FB; CAT commands in PowerSDR1.3.4 as well as remove the FBxxx...; that was tacked on to the IFxxx..; response.

Here is a picture of all working together:

omnirig

Sorry for the big picture size. The window above PowerSDR is Portmon from http://www.sysinternals.com/ which allows you to monitor serial port activity on your system. I use it a lot for serial troubleshooting. Some people, I am sure, will notice the temperature on the right side bottom of the screen in the icon tray. It is °C not °F. My wife is from Europe and insists that it stay that way! I can't even think in °F anymore...

The serial ports that you decided to use when you installed the vCOM driver can be changed after installation by editing the registry. Here is a screenshot of the place in the registry where vCOM gets its information as to which COM ports to use:

ports

If you edit the values for PortNumber1 and PortNumber2 they will take effect on the next reboot of the system. The port numbers that you use do not have to be sequential. For example, you could use COM9 and COM22 for the vCOM pair if you wanted. You can see by the registry path that the vCOM driver is a root enumerated device. There is no PnP bus driver to load the vCOM driver since it just emulates COM ports. Anything specified in the Enum\Root section is loaded when the system starts up whether the PnP manager has detected a real device or not. This is also why you have to reboot your system when you make changes to the driver. The driver doesn't know about them until the next reboot.

I think I will write a little utility program that will allow people to change the serial ports without having to edit the registry when I get a chance.

If after installing the vCOM driver you want to make sure that it is really installed and you have the correct version you can use device manager:

devman

If you right click on N8VB vCOM Virtual Serial Port Driver and select properties you will see:

devman1

Select the Driver tab and then click on Driver Details. You will see the following window:

devman3

You can now see that you have File version 0.0.0.55 installed which is Build 55. (This assumes WinXP and you have installed build 55 of course).

Here is a screenshot of the source code inside of Source Insight. Don't worry you don't have to have Source Insight to work with the source code. Even notepad will do :-)

si1

See the notes from May 14 through May 19, 2005 for installation instructions.

It should be pretty easy to write a program that listens on a socket and transfers bytes to and from one of the vCOM ports. That way the serial ports on remote machines can be linked together through a network or over the internet. Each computer would have the vCOM driver installed along with the application that transfers the data over a socket.

May 19, 2005:

Build 50 of the vCOM virtual serial port driver is released.

Here are the changes in this build:

* The driver now implements write timeouts properly. Previous versions would not timeout correctly if the FIFO was full.

* The driver now resizes the FIFOs on a IOCTL_SERIAL_SET_QUEUE_SIZE. Previous versions just set a fixed FIFO size of 32768 bytes. Now the driver will resize the FIFO as requested.

* Further redundancy in the code has been removed and the code has been cleaned up.

* There is now an Update.bat and Remove.bat in addition to the Install.bat files. The bat files use the devcon.exe program to do installs, updates, and removals instead of having to use the Add Hardware Wizard or Device Manager. Of course you can use the other ways too.

* You no longer have to first remove the driver before updating to a new version. You can now just update the driver and things will work correctly.
NOTE: This only applies to Build 50 and later. If you have a build previous to build 50 installed you still have to first uninstall the driver and reboot before installing the new driver. After you have build 50 installed you can update the driver without first uninstalling from then on. If you have a build prior to build 50 installed and you do not first uninstall and reboot before installing build 50 or later you will get a BSOD. This was a bug in the driver previous to build 50 and it has been corrected in build 50.

I use a cool editor called Source Insight to write C programs. Unlike most editors it analyzes the source code in real time and builds a code completion database. It gives you code completion and function parameter hints just like Visual Studio does. Also you get call graphs and class tree diagrams. It does source code formatting and highlighting too. Unfortunately it isn't free: http://www.sourceinsight.com/

May 18, 2005:

Build 40 of the vCOM virtual serial port driver is released. In this build the code is cleaned up a bit and redundancy removed in parts of the source code.

May 17, 2005:

Build 37 of the vCOM virtual serial port driver is released.

This version has a much cleaner FIFO implementation.   It uses less system resources also.

Build 37 has been verified to work with WinXP and W2K.

See notes for May 14 for installation instructions. Any earlier versions of the driver should be uninstalled first and the system rebooted before installing this version. Do not select "upgrade" in the Add Hardware Wizard. Uninstall the old driver first.

May 16, 2005:

The virtual serial port driver will now work with Windows 2000. A minor modification was needed to the Sources file and the vcom.h file. It has been tested with W2K. See notes below for installation.

I want to improve the buffers in the vCOM driver. I am working on a cleaner FIFO implementation instead of the quick and dirty implementation that exists now.

May 14, 2005:

This is the initial release of the virtual com port driver. It will create two com ports that are connected in a null modem configuration. The zip file contains the source code and the free and checked build versions of the driver.

The driver supports all timeout types, events, etc... It tries to emulate a virtual Null Modem cable in that the virtual RTS line of the first port is connected to the virtual CTS line of the second port and vise versa. The virtual DTR line is connected to the virtual DSR line of the twin com port. The CTS and DSR events are supported.

The driver also supports the RXCHAR and RXFLAG as well as the BRK events. The RING and RLSD (CD) events are never fired right now. If these events are needed for some reason I can add them.

There is probably no good reason to stop using the MixW virtual port driver until the new vCOM driver is tested with the current CAT code. It works with MixW now. It will not work with HRD until support is added in the CAT code. To use it with PowerSDR you do not select MixW virtual port in the setup page. You select the com port just like you are connecting to a hardware port.

If you want to install the driver it is best to uninstall the MixW driver first and REBOOT your system. To install the driver you can either use the Control Panel's Add Hardware Wizard or you can use the install.bat file in the driver's source code folder. Install.bat calls the DDK's tool called devcon.exe which will install the driver without having to use the Hardware Wizard. You can choose to install either the checked build of the driver or the free build.    Unless you know something about Kernel debugging the free build is the one you will want to install. The free build is in the folder objfre_wxp_x86\i386. The checked build is in the folder objchk_wxp_x86\i386.   The driver file is called vcom.sys. When asked for the location of the driver file select Browse and go to the objfre_wxp_x86\i386 or objchk_wxp_x86\i386 folder and select vcom.sys.

Right now the installation of the driver is kind of clunky. I will write a proper installer so it will be easier for people to install the driver.

BEFORE you install the vCOM driver you need to decide which pair of virtual COM port numbers you want the driver to use. The default is COM4 and COM5. If you want to use other COM port numbers you must decide which ones you want to use *before* installing the driver. To change the COM port pair numbers you need to edit the N8VB_vCOM.inf file. If you scroll down to the bottom your will see a few lines like this:

; *******Localizable Strings*******
N8VB= "N8VB vCOM"
Desc_x860= "N8VB vCOM MultiportSerialdrivers"
N8VBvCOMDesc= "N8VB vCOM Virtual Serial Port Driver"
PORT1="COM4"
PORT2="COM5"

On the lines that say PORT1="COM4" and PORT2="COM5" you will change the COMx strings to the numbers you want. For example if you want COM9 and COM10 you need to edit the file like this:

; *******Localizable Strings*******
N8VB= "N8VB vCOM"
Desc_x860= "N8VB vCOM MultiportSerialdrivers"
N8VBvCOMDesc= "N8VB vCOM Virtual Serial Port Driver"
PORT1="COM9"
PORT2="COM10"

MAKE SURE YOU DO NOT SELECT COM PORT NUMBERS THAT ALREADY ARE IN USE!
I will make it easier to select and install the driver with a seperate program in the future. For now, this is the way you have to do it.

WARNING: The driver has been tested on a few systems with Microsoft's driver verifier. I cannot guarantee that you will not get a BSOD or two at this point.

If you want to uninstall the vCOM driver you need to REBOOT your system after uninstalling the driver. This is a root enumerated driver.

May 7, 2005:

The virtual com port driver (or maybe it should be called virtual null modem cable?) is coming along. It is reading and writing data between the two virtual ports. I am adding in the additional functionality in the DeviceIoControl.   Timeouts seem to be working. I should have something to release for testing by the middle of next week if all goes well with debugging. This weekend I am writing a test program to stress the driver by sending huge amounts of data back and forth.

I have not done any work with SharpDSP or the alternative console since April 20. After the virtual com port driver is working I may take a stab at a virtual sound card driver if there is any interest.

May 3, 2005:

I have been working on a virtual com port driver. It is about 80% done and I hope to have it finished by the end of the week. It will support timeouts which the MixW driver does not. It will also support Async I/O and events. This will allow it to work with programs like Ham Radio Deluxe. I wrote this driver from the ground up and it takes a lot of testing and debugging. It will be released under GPL and the source will be available here and maybe on Sourceforge in the future.

April 20, 2005:

PowerSDR - SharpDSP0.0.11 has been posted.

This release is to let users play around with the different audio routing capabilities for the Main and Sub RX. Some of the controls have been temporarily moved below the slider for the second RX frequency. If you drag the bottom of the form down you will see them.

This is not the final implementation of the RX audio routing/mixing as I am still trying to decide how it should behave. I am hoping to get some feedback on this from users.

In the screen capture below you can see that on the left side there are two sliders. They control the left and right audio levels for the main RX. Below them are radio buttons that let you select the audio routing behavior of the main RX object. Play with the different settings there in combination with the sub RX settings to see what happens.

On the bottom right you will see the Sub RX group box. Checking 2nd RX enables the sub RX by cloning the current Main RX settings. You can play with the audio routing/mixing there as well as the left/right output levels.

Be aware that what is left or right on your system may be different (swapped) from what is left or right on my system because of cabling.

The VS 2003 and SharpDevelop project versions of SharpDSP and SDRAudio have been updated also today. The SDRAudio class library was updated because of the audio mixing I implemented in SharpDSP. In PortAudio the output buffers pointed to by the callback contains the data written to the output from the previous cycle. My audio mixer in SharpDSP uses whatever is in the output buffer and adds the current output to it to allow mixing of the audio from the Main RX and Sub RX(es). I now zero the output buffers at the beginning of the callback.

Because the Sub RX is cloned from the Main RX you will notice that when you change modes and filters (and many other settings) of the Main RX, the sub RX's settings do not change. They are stuck at whatever state they were when the cloning happened. So if your Main RX's mode was LSB and then you enable Sub RX (2nd RX), if you change the Main RX mode to AM the Sub RX mode will stay on LSB.   Same way with the filters, AGC, etc... The Sub RX needs its own controls on the console form for filter, mode, etc... There is not enough room for this on the console form right now.

# A few people have emailed me and asked me if I ever sleep. I actually do. I spend about 4 hours per day on the SDR stuff right now.

# If you need to fine tune with the Sub RX slider, you can click with the mouse to the right or left of the slider knob and the frequency will be incremented or decremented.

April 19, 2005:
PowerSDR - SharpDSP0.0.10 has been posted. This release includes minor changes to SharpDSP as well as a few bug fixes where the Noise Reduction and Notch Filter were not being initialized properly. There were a few places in SharpDSP where I decided I could do things more efficiently.

I am also working on a paper that will discuss my justification for doing the DSP processing within the audio callback. Both Bob N4HY and Frank AB2KT, authors of the DttSP code used in the offcial Flex-Radio Console, have said that such an approach is a step backwards. I disagree and I think I can offer a pretty good justification for what I have done in SharpDSP. Keep an eye on the website for the paper.

April 18, 2005:

PowerSDR - SharpDSP0.0.9 has been posted. This version reflects a change to the SharpDSP class library. There is now a Receiver object. The Receiver object can be cloned to make as many sub receivers as you want. This is a preview release for the SDR community.

You will notice two radio butons have been added. This is just to demonstrate the sub RX audio routing feature. The RX object actually supports Right, Left, Both, and None right now. I will add support for mixing the audio from the main RX and sub RX together in addition to being able to route it to the right or left outputs.

The link to downloading the SharpDSP code only has been updated also - both VS 2003 and SharpDevelop project versions.

2ndrxb

April 12, 2005:

New PowerSDR - SharpDSP enabled console posted with preliminary 2nd RX support enabled.
This console is meant to be a demonstration of second RX support in SharpDSP. It is no where near its final form and the implementation in this version of the console is for demonstration purposes only. Bascially the second RX just clones the settings of the main RX DSP chain for now. This is just to demonstrate the possibilities only.

The slider lets you offset the 2nd RX frequency from the main frequency. It works best if you have a sound card that supports 96 Khz like the Delta 44. The 2nd RX frequency is shown below the CPU %. The 2nd RX checkbox enables 2nd RX mode. Right now when in 2nd RX mode the main RX comes out the left channel and the 2nd RX comes out the right channel. This is just for demo purposes, in the future this all can be configurable. Please don't complain to me about the slider. It is just a quick way for me to demo the 2nd RX mode. I am not suggesting that there should be a nasty looking slider on the console!

April 11, 2005:

New PowerSDR - SharpDSP enabled console posted. This version corrects a bug in the panadapter and spectrum display. In both normal or pan-adapter spectrum modes, a single carrier did not show up as a single thin vertical line but a waveform with a shape that looked like an ideal filter response for a spectrum analyzer. In the PowerSpectrum class I was windowing the signal with a window that was double the size it should have been. It was actually spreading out signals over all fft bins. This version now has a correct powerspectrum calculation.
Version is PowerSDR - SharpDSP0.0.7

April 10, 2005:

New PowerSDR - SharpDSP enabled console posted. This version corrects a bug where the panadapter and spectrum display were not initialized correctly on starup when a blocksize other than 2048 was selected. Version is PowerSDR - SharpDSP0.0.6

April 08, 2005:

New PowerSDR - SharpDSP enabled console posted. This version corrects a bug in the panadapter display with the cross-hair tuning. Even though the bandwidth of the panadapter display is adjustable up to 96000 Hz, the point and click tuning was locked at 20000 Hz. This has been corrected so now the cross-hair tuning works over the full range of the panadapter bandwidth.

April 07, 2005:

New PowerSDR - SharpDSP enabled console posted. This version uses the new SharpDSP, SDRHardware, and SDRAudio DLLs. with serialization support.

Note that on the console there are three buttons - Serialize SharpDSP, Serialize SDRAudio, and Serialize SDRHardware. These buttons are for demonstration of the XML serialization support in the new class libraries. When you click on these buttons, the states of the three objects will be written to an XML file in the console's folder. You can open these XML files to view the data they contain. These buttons are just for demonstration purposes... they will be removed later...

Other than bug fixes, I will now start working on the SDR Command Interpreter as described below in the April 07 update.

Future Remoting Support, XML, etc...

The three class libraries SharpDSP, SDRAudio, and SDRHardware have been cleaned up. The official PowerSDR Console uses static classes for the Audio, and DSP objects. In the three class libraries all classes are not static. An instance of each object must be created. This is a much cleaner way of doing things.

I am now adding XML serialization support to the three class libraries. The public properties of each object can be serialized to a XML file and then the objects can be recreated (deserialized) later. I prefer this method of saving the state of the SDR over using a Microsoft Access database like the official console does. The XML files become configuration files for each object - SharpDSP, SDRAudio, and SDRHardware.

I want to write a server application that runs a command interpreter that accepts commands either through the serial port (or virtual serial port) and through TCP/IP. Configuation data for the SDR will be stored in the XML files. The command interpreter will accept commands in the Kenwood protocol format. Other protocols can be easily added also. The first implementation will emulate a Kenwood TS-480 since it support serial port data rates up to 115200. This means that most third party programs written to communicate with the TS-480 supports the 115200 rate.

SDR Command Interpreter and the Serial to TCP/IP Server are apps that I will write. The Serial to TCP/IP server will run on a remote machine and allow third party apps to talk to the MixW virtual Com port. The Serial to TCP/IP Server will communicate with the second pair of the MixW virtual Com port and will convert the serial commands to data to be sent over TCP/IP. The Serial to TCP/IP Server will connect remotely to the SDRCommand Interpreter on a Socket.

Note that the "Third Party Program" can be something like Ham Radio Deluxe. It can also be your own GUI app that you create. I will release a version of PowerSDR Console that uses this scheme. Your own GUI console app can just communicate with the SDR Command Interpreter via the TCP/IP interface for speed instead of through the Com port.

The remote Audio scheme will be worked out later...

April 06, 2005:

No new PowerSDR Console updates. I am cleaning up the interface of the SDRAudio.DLL.

Info concerning support of M-Audio Delta 44 Sound Card:

In PortAudio the MME and DirectX Host APIs represent the M-Audio Delta 44 as follows:

MME:

Inputs:
M-Audio Delta 44 Multi - device with 2 channel input capability (2 channels grouped as stereo pair inputs 1 and 2), no outputs
M-Audio Delta 44 1/2 - device with 2 channel input capability (2 channels grouped as stereo pair inputs 1 and 2), no outputs
M-Audio Delta 44 3/4 - device with 2 channel input capability (2 channels grouped as stereo pair inputs 3 and 4), no outputs
M-Audio Delta 44 Mon. Mixer - device with 2 channel input capability (2 channels grouped as stereo pair inputs 1 and 2), no outputs

Outputs:
M-Audio Delta 44 Multi - device with 2 channel output capability (2 channels grouped as stereo pair outputs 1 and 2), no inputs
M-Audio Delta 44 1/2 - device with 2 channel output capability (2 channels grouped as stereo pair output 1 and 2), no inputs
M-Audio Delta 44 3/4 - device with 2 channel output capability (2 channels grouped as stereo pair output 3 and 4), no inputs

DirectX:

Inputs:
M-Audio Delta 44 Multi - device with 6 channel input capability (channels 1,2,3,4 and two channels from Mixer (5,6)), no outputs
M-Audio Delta 44 1/2 - device with 2 channel input capability (2 channels grouped as stereo pair inputs 1 and 2), no outputs
M-Audio Delta 44 3/4 - device with 2 channel input capability (2 channels grouped as stereo pair inputs 3 and 4), no outputs
M-Audio Delta 44 Mon. Mixer - device with 2 channel input capability (2 channels grouped as stereo pair inputs 1 and 2), no outputs

Outputs:
M-Audio Delta 44 Multi - device with 2 channel output capability (2 channels grouped as stereo pair outputs 1 and 2), no inputs
M-Audio Delta 44 1/2 - device with 2 channel output capability (2 channels grouped as stereo pair output 1 and 2), no inputs
M-Audio Delta 44 3/4 - device with 2 channel output capability (2 channels grouped as stereo pair output 3 and 4), no inputs

Note the differences between MME and DirectX representations of the M-Audio Delta 44 Multi input device. In MME, it is represented as having 2 input channels (HW1/2). In DirectX it is represented as having 6 input channels (HW1/2/3/4 and Mixer 5/6). In DirectX the M-Audio Delta 44 Multi output device is represented as having only 2 output channels. MME and DirectX represent the M-Audio Delta 44 as 7 devices.

In PortAudio the ASIO Host Api represents the M-Audio Delta 44 as follows:

M-Audio Delta ASIO - device with 6 channel input capability (channels 1,2,3,4 and two channels from Mixer (5,6)) , 4 channel output capability (channels 1,2,3,4).

PortAudio ASIO represents the device as a single device with both input and output capability.

I am adding multiple sound card support to SDRAudio.DLL. Since I would like to access the Delta 44 with the ASIO driver (for low latency) I have added support specifically for the Delta 44 in SDRAudio.DLL. I want to use channels 1/2 as the RX sound card and channels 3/4 as the TX soundcard in PowerSDR Console. All four input and output channels are processed in one callback under PortAudio ASIO. SDRAudio.DLL raises seperate events for channels 1/2 and channels 3/4. This will allow processing of the two groups as seperate audio streams (one RX and one TX).

Other notes on SDRAudio.DLL:

SDRAudio.DLL hides the PortAudio interface to the sound system. This will allow support for non-soundcard audio input such as A/D board input.

The SinLCosR and SinLSinR functions have been implemented as methods of a class in SDRAudio.DLL called GeneratorFunctions.

The PIPE function is now a method of the class GeneratorFunctions in SDRAudio.DLL.

The PortAudio callbacks are hidden within the SDRAudio.DLL. Within the callbacks, events are generated to indicate that a block of audio is ready for processing. Four different events can be generated:

SDRAudio Event 1 - indicates that stream1's audio block is ready for processing. Stream1 represents one 2 channel (input/output) soundcard.
SDRAudio Event 2 - indicates that stream2's audio block is ready for processing. Stream2 represents one 2 channel (input/output) soundcard.

The above two events are for supporting two different soundcards.

SDRAudio_Delta44 Event 1 - indicates that the Delta 44's stream channels 1/2 audio block (RX) is ready for processing.
SDRAudio_Delta44 Event 2 - indicates that the Delta 44's stream channels 3/4 audio block (TX) is ready for processing.

The above two events are to support the Delta 44's 4 input and 4 output channels. Channels 1/2 will be for RX, and channels 3/4 will be for TX.

The events are actually multicast delegates so many different objects can subscribe to be notified by any one event. The order that a function is added to the event list is the order that the event notifies the subscribing object. In this way any object can intercept the audio stream before or after DSP processing by SharpDSP.

The wave play/record functions will probably be added to the SDRAudio.DLL as a class.

April 03, 2005:

PowerSDR - SharpDSP Console now allows you to select the panadapter bandwidth from the setup page. It will support panadapter bandwidths up to 96000 Hz.

I am now working on the SDRAudio, SDRHardware, and SharpDSP DLLs to better define each inteface. From this point forward the PowerSDR Console will be changed to adapt to the new interfaces supplied by these DLLs instead of the other way around. Up to this point the DLLs, particularly the SharpDSP.DLL, was written to conform to what PowerSDR Console expected (the DttSP interface). To move forward with modularization this needs to be changed.

April 02, 2005:

PowerSDR -SharpDSP Console has been resized to take advantage of larger screen areas. Minimum screen resolution for this version is
1024x768. Making the display area larger has also slightly increased the CPU usage when the display is turned on.
PowerSDR - SharpDSP 0.0.2 - PowerSDR04022005SDK1.1

April 01, 2005:

PowerSDR -SharpDSP Console now supports all display modes for any blocksize selected.
The following block sizes can now be selected:
64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384
Support for IF frequencies higher than 20000 Hz is now supported when using sample rates higher than 48000.

March 31, 2005:

PowerSDR -SharpDSP Console now supports selectable block sizes, sampling rates, and IF frequency. Note that right now the display (panadapter, spectrum, scope, etc...) does not work correctly for block sizes less than 2048.

March 30, 2005:

The above Source Code and Executable was compiled with Visual Studio 2003 and .NET SDK 1.1