[hpsdr] Software direction for openHPSDR...current status

Roger Rehr 73w3sz at gmail.com
Tue Aug 3 11:10:38 PDT 2010


Hi All,

I am not a software guy but have enjoyed playing with all this stuff.
I am limited in my exploits by limited temporal and intellectual resources.

One of the problems for someone new to HPSDR is knowing what is and isn't available as 'working' software on the various platforms.

As regards the question of what HPSDR-related software works/doesn't work on different platforms and across the network I have noticed the following.  All of this pertains to the single-receiver firmware code and is only my experience.

1.  I can get John's ghpsdr3 'server' to run on both Linux and OS X 10.6 on my iMac. 

2. The ghpsdr3 'receiver' client running on Linux will work very well across the network in combination with the ghpsdr3 server listed in #1.  See below for comments on the ghpsdr3 receiver client on OS X.

3.  Mac-ghpsdr by Jeremy McDermond compiles and runs fine on my iMac on OS X 10.6.  This is not for cross network operation at present.  Jeremy has moved on from this to MacHPSDR.

4. MacHPSDR by Jeremy McDermond [an Xcode Project] builds and runs fine on my iMac 10.6.  This is not for cross network operation at present.  

4.  John Melton's ghpsdr compiles and runs fine on Linux.  It is not cross network.  
John's precompiled binary for the Mac runs on my iMac but the audio cuts out frequently and is replaced by loud static.  I tried replacing the old Ozy_Janus.rbf and ozyfw-sdr1k.hex in his bin directory with newer ones but that didn't improve things.  Ghpsdr shows Ozy FX2 version: 20090524, Mercury software version 29, and Ozy software version 17 (correct).
Attempting to compile ghpsdr (using a copy of libDttSP.a that was compiled without error on the iMac) results in multiple undefined symbols and an unsuccessful build of ghpsdr.  I have greatly reduced the size of the error message that the compilation ends with in reproducing a small part of it here.  
--------------------
Undefined symbols:
  "_top", referenced from:
      _setup_local_audio in libDttSP.a(winmain.o)
      _reset_for_samplerate in libDttSP.a(winmain.o)
      _reset_for_buflen in libDttSP.a(winmain.o)
      _closeup in libDttSP.a(winmain.o)
      _reset_system_audio in libDttSP.a(winmain.o)
      _reset_system_audio in libDttSP.a(winmain.o)
      _setup in libDttSP.a(winmain.o)
      _Audio_Callback2 in libDttSP.a(winmain.o)
.
.   [removed many similar references]
.
  "_uni", referenced from:   
.
.   [removed many similar references]
.  
  "_rx", referenced from:
.
.   [removed many similar references]
.
     (maybe you meant: _right_rx_sample, _left_rx_sample )
  "_tx", referenced from:
.
.   [removed many similar references]
.
     (maybe you meant: _right_tx_sample, _txFilterHighCut , _left_tx_sample , _right_tx_buffer , _txFilterLowCut , _left_tx_buffer )
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [ghpsdr] Error 1
--------------------

5.  I get exactly the same errors as in 4. above when I compile the 'receiver' client for ghpsdr3 on the iMac, again using a copy of libDttSP.a that was compiled on the iMac without error.  The source versions of libDttSP that were used in each case were the source versions that were bundled in the ghpsdr and ghpsdr3 packages.  

 6.  Gnuradio builds and runs on both Linux and OS X.  Using John Melton's modified version of gnuradio with a new GRC block hpsdr_source as the receiver client and using his 'server' module as in #1 above, I can get received signals from Mercury across the network.  This works with either gnuradio running on Linux or OS X, and also with the server running on either Linux or OS X.  The problem is that the audio and the spectra both show major motorboating or pulsing that appears as multiple spikes on the FFT and waterfall.  To show what I mean, I put a screenshot at:  
http://www.nitehawk.com/w3sz/Screenshot-grc-mac.png
This occurs whether the server and client are on the same machine or on two machines.  Perhaps it relates to preamble bytes that need to be stripped from the packets?  I do not yet know...

7.  AFAIK there is currently no cross-network transceive solution that would permit multiple HPSDR transceivers each connected to its own transverter or antenna to be controlled from a single computer, with separate bandscopes for each.  That is MY ultimate interest.  For the past year I have used multiple instances of modified PowerSDR plus homebrew hardware and software to accomplish this.  I am hoping to eventually replace this with something like multiple instances of ghpsdr3 running on one machine with each HPSDR running on its own machine with something like John Melton's ghpsdr3 'server'.  I think everyone is aware of the interim solution that I've used for the past year.  For those who aren't, it is at:
http://www.nitehawk.com/w3sz/osxhpsdrserver.htm

8.  PowerSDR works great and is infinitely modifiable, but is windows-only.  It has been my workhorse for a long time.  I haven't played much with KISS, as it is windows only and I already have PowerSDR there.

Hope the above is helpful to those new to HPSDR who are wondering what is and isn't working at this point.

And anyone who can offer some help with #s 4,5,6 is most welcome to do so!!

73,

Roger Rehr
W3SZ
 1280859038.0


More information about the Hpsdr mailing list