Second build sold out. Message will appear here when store is ready for third build ordering.

DGPS Stations in the NDB Utility Band.

edited January 2017 in Signals Received
Experimenting tonight with MultiPSK decoding DGPS stations. It seems to work OK, but not sure what I'm looking at. In any event I'm using a Linux desktop and Pulse Audio to route the audio from the KiwiSDR instance in the Chrome Web Browser to MultiPSK to decode the signals. See the screen shots below.
Ron - KA7U


Attachments:
https://forum.kiwisdr.com/uploads/Uploader/0f/2966e15a26afd666837edc15bf6553.png
https://forum.kiwisdr.com/uploads/Uploader/ba/fe75f9fd7d74af67743527f6b885e7.png

Comments

  • edited November 2016
    DGPS DX for tonight is: Station 824, DGPS,Andenes Andoya NOR 311.0 Khz TXID 515 100bps.

    Distance from Weiser, Idaho to Andenes Andoya, Norway = 4234 Miles.
    Ron - KA7U
  • The standard reference for DGPS DXing is here: http://www.ndblist.info/datamodes/worldDGPSdatabase.pdf
    The best DX I have from NZ based on good decodes is Cape Mendocino, Calif. I'm pretty sure I was hearing Essex and Abq, NM also before they went QRT in August.
    I hear a couple in Hawaii and there are a bunch in Australia.

    DGPS is one decoder I'd like the Kiwi to have. But I've had trouble finding source code for a practical MSK demodulator. It's a little bit tricky from everything I've read.

  • John, I doubt there is much I could suggest about source code for a MSK/DGPS decoder that you haven't already considered, but I do wonder if an HTML controlled application such as Spectrumlab could be incorporated into KiwiSDR?

    I use mulitPSK because it is quick and user friendly and Patrick Lindecker, the author, has already created formatted output on some of the decoders. 
    Ron - KA7U
  • The problem is virtually none of the standalone signals analysis / decoder programs have source code available, much less have open source licensing terms. This is quite understandable of course. People want some compensation for their hard work or don't want a million clones out there. The KiwiSDRs use of OpenWebRX being a case in point.

    I thought about approaching some of these people to ask if they would let me develop a version of their software for the Kiwi where the majority of the code ran as an opaque binary on the Beagle with a simplified UI in Javascript on the browser (which of course can always be dumped or reverse engineered). Perhaps even as a paid add-on if the package itself is not distributed for free. This has implications for the open source licensing of the Kiwi code of course and has to be handled carefully, e.g. probably as an extension and using LGPL or Affero GPL (I am not that knowledgable about how this would work).
  • John, the extensions are a very elegant way to use decoders and it would be wonderful to have a full compliment of decoder extensions, but as you point out, without available source code, the work is very hard and time consuming, I think. Even with existing source code, it would still need to be translated into Java or other languages that are compatible with the KiwiSDR project, and that is a formidable task too.  

    It is not difficult for me to use Pulse Audio to feed 3rd party decoders such as MixW, Fldigi, or MultiPSK. It would be nifty if there was a way to change frequency and mode between the KiwiSDR and the 3rd Party applications that support reading and writing to a file like is done between MixW and the TenTec Pegasus, or by using virtual serial cables like is done between HDSDR and CAT equipped radios. I successfully run an integrated station using a Softrock with HDSDR, N4PY Software controlling an ORIONII, and MixW coordinating with the ORIONII using the pegasus.exe file that both the N4PY and MixW software read and write to and from. Certainly a kludge compared to the KiwiSDR extension system, but it is an adaptation that works with my existing equipment.

    I had a Flex 6700 in the shack for time and used virtual audio cables and virtual serial cables to use 3rd party decoder programs too. So I want it all, but if I am to have, I need to work with the various ways to adapt. At present my way to adapt with KiwiSDR and the radio is to manually tune the KiwiSDR to find a station to talk to and then tune the radio to talk with it. I do have an adaptation though the ORIONII to share an antenna with the KiwiSDR when I use the transmitter, but while transmitting it takes the KiwiSDR off line. Of course if I use remote KiwiSDR I can let it continue to run while I'm transmitting and depending on what that remote unit hears, that works just fine.

    I'm rambling. Sorry about that. I'll post a link to a video that might interest some and move on to another function. Hi Hi


  • Ron KA7U:

    which Linux do you run and since MultiPSK is Windows do you run it in a VM?





  • James - WA2ZKD,
    I used openSUSE 42.1 in this particular video and MultiPSK is being run under the WINE API without any additional DLL files. MultiPSK is not fully supported in as much as the 3rd party "hooks" don't work for plotting maps and stuff, but the decoders and logbook work fine. MultiPSK also works fine under WINE in the Debian branch of Linux, for example I use it with my Chromebook in developer mode and Crouton script installed Ubuntu. To fully realize all the parts of MultiPSK it should be run in Windows. A VM running Windows should fully accommodate it as well. 
    Ron - KA7U
  • One other thought, the WINE API currently requires an X86 type processor. It does not work with the ARM processors.
    Ron - KA7U
Sign In or Register to comment.