AIS Monitoring - RTL SDR

Today I had a hankering to setup and monitor Maritime VHF AIS.  I've done it the past for fun and could see that our area had very good coverage by number of other enthusiasts / operators:

• Marine Rescue Bribie
• Coast Guard Redcliffe
  
• Coast Guard Brisbane
  
• Coast Guard Redland Bay
• And many many others...
  

To view area of coverage - See via MarineTraffic.com

I've always enjoyed monitoring maritime voice traffic.  I normally always have my HT or base station rig monitoring Marine VHF CH 12 (156.600 MHz) "Brisbane VTS". If I want to monitoring more I would normally spin up SDRConsoleV3 with a RTL-SDR and monitor local (CH12, CH16 CH73 etc).

If I wanted to monitor the marine VHF repeaters (at 161 MHz) I would either use the existing RTL-SDR so would need to stop listening to the simplex maritime traffic (at 156 MHz) due to the ~2MHz bandwidth window or grab another RTL-SDR plug it in and open another SDRConsole instance which starts becoming a little annoying. 

The Plan...

I've kept one eye on the "OpenWebRx" project and have been impressed with the way we can now easily set up multiple RTL-SDRs and associated profiles. Since the RasPi4 wasn't been used and I had a couple of RTLSDR not doing much I thought, OK how about we setup the following:

1. First RTLSDR would be limited to a single profile to cover the VHF Marine Repeaters and AIS
   
2. Second RTLSDR would be free to switch between multiple profiles to provide access to (FMBC, Air, Ham 2m/70cm, Maritime Simplex (156MMHz) for starters.

AIS Decoders...

Reviewed the following AIS decoders:

1. rtl_ais
2. AISRecWin
   
3. AIS-Catcher 

I tested rtl_ais and felt the decode rate was a little low.   I switched to AISRecWin and the decode count skyrocketed, however it only runs 20min for trail version.  

I then downloaded and setup AIS-Catcher and boy what a fabulous application. Not only was the decode rate better than AISRecWin, but it also provides an awesome web UI with great stats, allowing you to monitor your own data without having to publish it to one of the external sites (i.e AISHub/MarineTraffic).   

When you are ready to publish you feed,  the application provides multiple means i/e. UDP/HTTP etc.  It also include its own internal "AIS Dispatcher" (So no need to install and set up AISDispatcher.) so you can configure as many external feeds as you wish.   One great feature was ability to feed AIS data to "aprs.fi"!!   

All this from one application!!!

RTLTCP Compatible Port...

I now needed to consider how I was going to access the 2 RTLSDRs by OpenWebRx.  I could simply just configure OpenWebRx to access the devices directly (via "rtl_connector").  However this got me thinking about how best to a feed from OpenWebRx to the AIS-Catcher decoder.

OpenWebRx RTLSDR connector does provide an option to enable a "RTL_TCP" compatible like port. 

Important Note: 

• You will need to reboot OpenWebRX to ensure the connector correctly restart with the new option enabled.
• Don't forget to set the config option to "alway run the device" as it will only start an instance when a user selects the device profile.
  

I configured AIS-Catcher to point to the port and bingo it worked!  

Ok great!! but....... While I can open multiple OpenWebRx tabs and select different frequencies...  I thought if I wanted to also access the sdr feed via SDRConsole and/or SDRSharp..........

RTLTCP and RTLMUX...

RTLTCP  only allows a single client to connect.  However if we also used RTLMUX, it now allows multiple clients to connect and control the RTLSDR.

This allows us to set up each RTLSDR being made available by multiple applications without having to shut one done, start one up etc.

Installing RTL_TCP...

sudo apt install rtlsdr

sudo wget -O /etc/udev/rules.d/20-rtlsdr.rules https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules
sudo udevadm control --reload-rules && sudo udevadm trigger

 

Building and Installing TCP_MUX...

sudo apt update && sudo apt upgrade

sudo apt install -y libusb-1.0-0-dev git cmake pkg-config
sudo apt install -y libevent-dev

cd $PROJ_HOME
git clone https://github.com/slepp/rtlmux.git
cd rtlmux
make
sudo cp ./rtlmux /usr/bin/rtlmux

Running Manually...

1. Start RTL_TCP

rtl_tcp -d 1 -a 127.0.0.1 -p 4333 -n 1000 -P 2

 

2. Start RTL_MUX

rtlmux -p 4333 -h 127.0.0.1

 

3. Start AIS-catcher via MUX Port 7878

./AIS-catcher -N 8100 STATION VK4TMZ-2 LAT -27.2969 LON 152.9565 SHARE_LOC on FILE stat.bin BACKUP 5 MSG on -c AB -t 127.0.0.1 7878 -gt TUNER auto rtlagc on -p 2 -s 1536000

• Notes:
• Use one of the following rate to prevent up sampling and noise:
• 96K, 192K, 288K, 384K, 768K, 1536K, 3072K, 6144K, 12288K 
• However if you wish to also allow SDRConsole and / or SDRSharp to connect then use 2.048 MS/S as this is the only one common between the 2.  It does mean AIS-Catcher will up sample to the next double from 1536 * 2 -> 3072K

4. Monitor RTL_MUX stats

http://localhost:7879/stats.json

Notes on adding  RTL_TCP device to OpenWebRX for AIS...

• CenterFreq - 162MHz has this is where AIS-catcher defaults to.
• IMPORTANT: 
• When attaching SDRSharp, SDRConsole ensure you set CentreFreq to 162 MHZ, else it will sent through possibly bad frequency and disturn the AIS-Capture decoder.
• 1.536 MS/s allows inclusion of NOAA Weather Radio and Marine VHF Repeater Frequencies.
  

Running as Services...

The following are some commands / scripts to enable registering multiple RTLSDR instances of RTLTCP / RTLMUX services.

 

Because rtl_tcp only accesses RTLSDR using its device index and not the device serial, I've utilised the following work so I could specify serial and it will determine index:

• HOWTO: Sane management of multiple RTL dongles in Linux
  

1. Create an unprivileged user for running RTL_TCP and RTL_MUX

sudo adduser --system rtltcp
sudo addgroup rtltcp
sudo usermod -aG dialout,rtltcp,plugdev -a rtltcp

2. Following creates script for looking up serial based on device index:

sudo mkdir /opt/rtltcp
sudo tee /opt/rtltcp/rtlsn2dev.sh << 'EOF'
#!/bin/bash
# usage: ./rtlsn2dev.sh [serial number]
# returns: device ID
if [ $1 ]
then
  rtl_num_devices=$(rtl_eeprom 2>&1 >/dev/null | grep "Found [0-9][0-9]*" | sed -E 's/.*([0-9]+).*/\1/')
  if [ $rtl_num_devices ]
  then
    for i in $(seq 1 $rtl_num_devices);
    do
      rtl_device=$((i-1))
      rtl_serial=$(rtl_eeprom -d$rtl_device 2>&1 >/dev/null | grep "Serial number\:" | sed -E 's/Serial number:[[:blank:]]+//')
      if [ "$1" == "$rtl_serial" ]
      then
        echo $rtl_device
      fi
    done
  fi
fi
EOF
sudo chmod +x /opt/rtltcp/rtlsn2dev.sh
sudo chown -R rtltcp:rtltcp /opt/rtltcp

3. Create service unit template file for RTL_TCP:

sudo tee /etc/systemd/system/rtltcp@.service << 'EOF'
[Unit]
Description=rtl_tcp radio streaming service
After=network.target

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
User=%p
Restart=always
WorkingDirectory=/opt/rtltcp
ExecStart=/bin/sh -c "/usr/bin/rtl_tcp -d $(/opt/rtltcp/rtlsn2dev.sh %i) -a 0.0.0.0 -p $((7000+%i)) -n 1000"
EOF

4. Register RTL_TCP service for each dongle:

# Now reload systemd, create a couple instances of this service, and start them
sudo systemctl --system daemon-reload
sudo systemctl enable --now rtltcp@00000001.service
sudo systemctl enable --now rtltcp@00000003.service

5. Create service unit template file for RTL_MUX:

sudo tee /etc/systemd/system/rtlmux@.service << 'EOF'
[Unit]
Description=rtlmux radio streaming service
Wants=rtltcp@.service
After=rtltcp@.service

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
User=rtltcp
Restart=always
WorkingDirectory=/opt/rtltcp
ExecStart=/bin/sh -c "/usr/bin/rtlmux -h 0.0.0.0 -p $((7000+%i)) -l $((7100+(%i*10))) "
EOF

6. Register RTL_MUX service for each dongle:

# Now reload systemd, create a couple instances of this service, and start them
sudo systemctl --system daemon-reload
sudo systemctl enable --now rtlmux@00000001.service
sudo systemctl enable --now rtlmux@00000003.service

7. Test Access 

Using SDRConsole / SDRSharp and or any other tool that provide RTL_TCP connection. Don't forget to connect using he RTL_MUX Port number in my case (7110 and 7120)

My AIS feed status and coverage

• Via AISCatcher.com
  
• Via AISHub.com
  
• Via MarineTraffic.com 
  

End Note......

Its been just over 5 years since my last post here back in June 2019...   That doesn't mean I've not been still tinkering with radios, SDRs, antennas, software etc, etc   I just  haven't had anything of interest to report sorry.....  As you can see if and when I do have anything of interest to share, I've come back here and post my thoughts :)

73's

Mark (VK4TMZ)

Sending Position Reports via WinLink Express using Smartphone Internal GPS

G'Day Guys,

The WinLink Express client application used to allow operators to send emails via RF has as one of its features the application to send "Position Reports".  The position reports can contain lat/lon, comment and if desired include "weather details".  These reports are then if successfully received sent a "Position Report Acknowledgment" email to let the operator know the report has been received successfully and is now visible on the tracking map portal: https://www.winlink.org/userPositions

Via this portal you can see all the latest positions reports of all users for the last 10days. There are even link to allow you to view specific callsigns only (see bottom of the portal page).

The lat/lon for the position report can be entered manually, or it can be obtained from a NEMA compliant GPS connected to local COM port.  This is all fine and dandy if you have  one.... but we all do... kinda... we have a internal GPS on our all smartphones.  So th question is how do we get that integrated to WinLink.   A quick scan of the Android Playstore and I initially located the following:

• GPSIP
• GPS Tether
• ShareGPS

These programs provided a feature to support setting up a local TCP/IP Server on the phone which streamed the NMEA sequences from the phones internal GPS to any client connected.  I used VSPE (Virtual Serial Port tool)  to map a TcpClient to Virtual Serial Port.  The first hurdle I encountered was that it seems that the TCP service each app provided seemed to required a CRLF command sent from the PC before the application would send any data.  Then it appears that after a period of time the TCP socket for each application would close for no reason.

Taking a step back and rethinking this through, I located the follow applications which instead of providing a server to connect to,  it would act as a client and connect to your PC running a server and send NMEA sequences from the phones internal GPS.

• BlueNMEA
• Not available as a precompiled package on Playstore, needs to be compile and the resulting APK uploaded to phone.
• http://max.kellermann.name/projects/blue-nmea/
• NMEA Relay
• ShareGPS

Fortunately VSPE provided TcpServer and maps to a VSPE virutal comm port.  This allowed me to quickly configure NMEA Relay and ShareGPS to both connect as  clients sending NMEA sentences.  VPSE then mapped them over to the virutal comm port configured at 4800 which then be used by RMS Express.

Once the Lat/Lon is available on the GPS/Position Report, click the "Copy GPS Data" button.  Complete your report with a basic meaning comment or include weather data and send. A email / messages will be created and put int the Outbox ready for you to send via one of the WinLink sessions.

NMEA Via Bluetooth

ShareGPS offers another brilliant feature, that allows you to share the NMEA data via bluetooth.  This allows the phone to be connected to your PC via bluetooth and once connection established a COM port will appear on the PC which can be used by WinLink RMS Express.  Give it a go, but it will required your PC to have bluetooth capability (i.e internal or via external BT dongle).

VisualGPSView

Before I sign of, one other little gem of a tool I found while mucking around with all this was VishalGPSView.  Its free and will graphically show your GPS data and NMEA logs.


Hopefully wonderful WinLink devs will update the GPS/Position reports to provide a server which  accept NMEA data from Phone running an app like NMEA Relay / ShareGPS acting as a client.


That's all Folks,
73
de VK4TMZ (Mark)

Setting up WinLink HF / VHF Wingates

Guys,

I wont go too much into about what WinLink is as there is plenty of information on their site (https://winlink.org/). But in a nut shell - "Email over RF".

After my experience running a ALE Pilot Station and not having no much interest from local Australian operation using such mode. I decided to try my hand at setting up running HF/VHF WinLink Wingates.

Before I did this and I started of by installing the WinLink Express (client) software.  This allowed me to easily configure my Yaesu FT-991A fairly quickly.  Then via sessions I was able to try out and successfully contact and send / receive emails via HF to several other Australian operator providing Wingates supporting Winmor, ARDOP and VARA modes.

With that done and me up to speed with the client software, I turned to reading up on running HF and VHF Wingate.

WinLink VHF Packet WinGate

Starting of with the WinLink VHF Packet Wingate, I firstly decided to set up my BTECH UV-50x3 VHF/UHF rig along with my Mobilinkd Bluetooth TNC.  I was able to install the WinLink Packet application and very quickly configure it to use "KISS TNC".

HF Winlink Wingate (Winmor, ARDOP and VARA modems)

With success of easily running and operating the WinLink Express client software with the FT991A I was expecting the WinLink RMS Trimode application to be just as easy.

NOPE!!!!  First hurdle was the FT991 was not among the set of support HF rigs under server side application.  Fortunately I was able to quickly develop a little powershell script which acted as a "translator" between one of the rigs available under RMS Trimode.   I opted for Kenwood TS590 to control the Frequency and PTT control via CAT commands. Using VSPE to have 2 virtual comm ports I was able to intercept the Kenwoods CAT commands and translate and even inject extra control commands to the FT991.  My script is available on GitHub:  https://github.com/vk4tmz/rigtrans
but please note its not refined by any stretch of the imaghination, but if you know your rigs CAT commands and have a bit of understanding of powershell you'll be able to alter it to suit your own needs.  This sorts me out until hopefully the fine developers of WinLink RMS tools support FT991A.

Once I got over that little hurdle, the next challenge was finding clear frequencies that would have minimal impact on other operation as the station runs 24x7 fully automated.  The modems (Winmor, ARDOP and VARA) have "channel busy" detection of sort.  But it must be kept in mind that its up to  operator wishing to connect to my wingates to perform due diligence and ensure to the best to their awareness the frequency is not in use.  Wingates DO NOT auto beacon so until they are polled they will operate silently.

Once I had my frequencies selected which I opted to support / scan through 80-40-30-20-17-20m bands.  

PLEASE NOTE: It takes ~45 secs for RMS Trimode logic to scan through and spend ~7sec dwell time on each band. So please ensure if trying to connect to any of my wingates you give it a couple of goes incase when you tried I just missed you polling attempts.

So witth the HF and VHF set up I'm hoping this service will provide valuable to Ham both Land and Maritime Mobile on your travels.

Please drop me a email via VK4TMZ[AT]winlink.org and say gday.

Why no Pactor Modem / Support

Pactor modems are very expensive and are not opensource.  Many other stations around Australia seem to support Pactor, but at this time I've no intention to purchase one of these modems.


That's all for now folks
73
de VK4TMZ (Mark)

PC-ALE and MARS-ALE Running as a Pilot Station

Guys,

I ran PC-ALE for a period of months, and then requested access to become a Pilot Station using the MARS -ALE. I was granted access and set up successfully to allow Email to be sent via AMD commands.

Unfortunately at this time the only other Australian stations running ALE were primarily Peter VK2EHQ and more recently Peter VK4EA setup himself and our club station VK4RC.  The participation in Australia via amateur bands is virtually non-existent which is a real shame. 

I've enjoyed my time and the experience of running the Pilot Station but have ceased operation for now. I have both PCALE and MARS-ALE backed up for any EMCOMM situation and can be running in very short notice.  Perter VK4EA is looking to reestablish the original Brisbane ALE Pilot Station VK4SAA and I wish him all the best and hope it will continue to support those that want to have experience using ALE.

73
de VK4TMZ (Mark)

Mobilinkd - Bluetooth APRS / TNC (Yaesu FT-991A, Baofeng UV-5RTP and BTech UV-50x3)

G'Day Guys,

I originally purchased the Baofeng to 3.5mm 4 Pole TRRS cable from BTech (APRS-K2 TRRS CABLE) to use with APRSDroid. Unfortunately I quickly learnt that when using the Baofeng in VOX mode the time to change back from TX to RX on average was 4-5 seconds....   Not good for APRS as it would interfere with others and you will not get any traffic for up to 5 seconds hence miss immediate responses from digipeaters etc.  This is not fault of the BTech cable, just seems to be a feature of VOX.

So I then ordered myself a Mobilinkd and the following TNC cables:

• TNC Cable for Kenwood, Wouxun, Baofeng
• MiniDIN-6 TNC Cable and MiniDIN-6 1200 Baud Adapter for the Yaesu FT-991A
• Yaesu FTM-350 8 Pin Mini Din Data Port to 3.5mm TRRS Mobilinkd TNC - 1200 baud - This is for the BTech UV-50x3 

Baofeng UV-5RTP

The Mobilinkd arrived quickly 1.5 wks and out of the box was able to hook it up to the Baofeng within 5min and using the Mobilinkd android app was able to connect and adjust the input setting fairly quickly and the default for out left as they were.  For the Baofeng I have the "attenuation" enabled and adjust volume to the first red led starts to flicker and bingo I was up and running.

 Yaesu FT-991A

I'd read from others that I need to ensure I was using the 1200 baud data pin of the FT991A data port as the 9600 had low voltage / volume. Hence when I ordered from Mobilinkd the MiniDIN-6 1200 Baud Adapter.

Since I use the FT-991A for data comms via the USB I have to switch the following values back and forth when using Mobilinkd:

• #075 - FM Out - 98
• #076 - FM PKT PTT Select - DAKY
• #077 - FM PKT Port Select - DATA
• #078 - FM PKT TX Gain - default value 50 (just FYI)

Mobilinkd settings - I turned "attenuation" off.

After changing the FM PKT settings to rear and the volume out from radio I was up and running.

BTech UV-50x3

The Yaesu FTM-350 8 Pin Mini Din Data Port to 3.5mm TRRS Mobilinkd TNC arrived today and apart from having to grind the "rectangular" part of the mini din plug to allow it to plug into the  back of the BTech it was well constructed and worth the money.  Plugged in and connected up the Mobilinkd Bluetooth TNC.  Via the rigs PKT settings I set it to the "Right side VFO" and opened the SQL.  Using the Mobilinkd mobile app I had to turn of "attenuation" and got three green bars with flicker of yellow.  The advice on the app says to turn the audio until the first red bar starts to flicker but had to leave at first yellow.  When tracking started APRS signals heard were decoded and just worked perfectly.MY own APRX beaconing worked perfectly.

However!!!!!!  I quickly discovered that while monitoring VHF traffic on the left side VFO and the APRS was beaconing on the right side VFO (using the smart beaconing mode) the left side was desensitised / block / overloaded frequently.... This was even the Right Side VFO power level set to "low"....

DOH!!! What else would one expect with 2 VFO on same band....   So my options are that I monitor UHF voice on the left side or not use "Smart Beaconing" but rather periodic beaconing say every 10-15min.  This would cut down on the interference to a degree of a burst every 10-15min which is not bad....   ORRRR!! continue to use APRSDroid on APRS-IS mode while in range of mobile internet and have the Mobilinkd for all other times......

I'll continue to play around and see how the setup goes using the "Periodic beaconing", just means from a tracking resolution it may be lower to that compared to "Smart Beaconing". 


That's all Folks!
73
de VK4TMZ (Mark)

GPredict - Radio Control FT991A (via RigCtld)

G'Day Guys,

Since getting hooked on monitoring ARISS and other satellites (aka "birds") I quickly discovered several bits of software for predicting the satellite pass and ability to control your radio to account for doppler shift in both the uplink and downlink frequencies.

The bit of software I've quickly come to enjoy is called GPredict for the following reasons:

• Easy to Use
• Available for multiple platforms
• Computes and visualises multiple satellites passes
• Ability to control radio to account for doppler shift
• Ability to control antenna azimuth and elevation for controlling the antenna beam direction and tracking the satellite as we go from AOS to LOS

I downloaded the binary for windows and within a few minutes I had downloaded the latest  TLE and Transponder data from the internet. Out of the box it comes with a simple module with a few satellites that amateur operators can monitor and make contact through.

Next was to have GPredict control the radio uplink and downlink to account for doppler shift.  GPredict can be configured to update the TX/RX frequencies of the rig via sending "Rig Control" commands to a "Rig Control Daemon". By heading over to Rigctld you will find instruction on Downloading and compiling the Rigctrld code. However I took the easy path and downloaded the latest Windows Platform binaries.   There is further good information found at the "Hamlib Rigctld FAQ"

After downloading the binaries and installing (making sure the PATH was pointing to the bin folder) I was ready to start up an instance of RigCtld using the following command with the appropriate serial settings that suit my setup:

       
rigctld.exe -vvvvv -r \\.\com11 -m 135 -s 38400 -t 4532 -C "serial_speed=38400,stop_bits=2,rts_state=ON,dtr_state=OFF,serial_handshake=None"
       
 

!! Important Note!! when using COM PORTs above COM9 you can no longer use the syntax "-r COM10" but instead to "-r \\.\com11" as you can see I did. 

To test the ability to control the rig we can use the "rigclt" command line tool. The following example will query the rig to determine what "MODE" VFO A is in:

       
rigctl.exe -m 2 -r localhost:4532 m
       
 

Before we move on, one of the little limitation / feature lack of GPredict is when you select the different "transponder" to monitor and have GPredict track it only tracks the up and downlink frequencies. It DOES NOT automatically select / change the rig modes for both RX and TX.

To overcome this I created 3 simple commands which I run as needed to changes the modes quickly:

       
# For Voice
rigctl.exe -m 2 -r localhost:4532 M USB 0 X LSB 0
rigctl.exe -m 2 -r localhost:4532 M FM 0 X FM 0
rigctl.exe -m 2 -r localhost:4532 M USB 0 X USB 0

# For Digital Mode (ie APRS, etc)
rigctl.exe -m 2 -r localhost:4532 M PKTUSB 0 X PKTLSB 0
rigctl.exe -m 2 -r localhost:4532 M PKTFM 0 X PKTFM 0
rigctl.exe -m 2 -r localhost:4532 M PKTUSB 0 X PKTUSB 0
       
 

You will need to research the transponder for the requires mode on both up/downlink. But for the 1st command you can see I set the uplink to LSB and downlink to USB. This is for those linear transponders that each you to operation in this mode.

With RigCtrld now configured and running, we can now add a Interface to integrate with this Rigctrld instance.

1. GPredict via Edit->Preferences->Interface add new interface and give it appropriate name (ie "FT991A")  
   
2. Once saved then via Module "Down Down" Select Radio Control, Select the satellite and the transponder you wish to track.
3. Then Click on "Track" and "Engage"
4. You should see the frequencies start to adjust up / down accounting for doppler and be sent to the radio.

That's All Folks!!!!

73
de VK4TMZ (Mark)

OpenWebRX - CSDR Audio Stream Via IceCast (SSTV Decoding on Windows)

Guys,

With the recent ISS SSTV event, I would normally use the audio from my FT991A and leave it running with both MMSSTV and RXSSTV running for the duration of the event. However this would mean taking my OpenWebRX 2m stream offline as I'd need to use the VHF antenna.

I could easily open a web browser head over to SDR.Hu and open my OpenWebRX SDR and set the frequency to 145.8MHz and making sure the default audio is the Virtual Audio Cable input then that would be one way to do it.  But I've seen that running the OpenWebRX client to long in a web browser does consume a fair bit of memory as it build that waterfall history over time.....

But with my recent fun with using CSDR to get a audio stream for APRS decoding I thought cool lets do the same thing for SSTV.

Well creating the audio stream monitoring 145.800 MHz under Linux was easy.... but my problem was there was NO SSTV decoders that would take a audio stream piped in from STDIN.  There is QSSTV for Linux but to GUI driven / controlled.

So I thought why not stream the audio and then I can either use a Media player and pipe into a Virtual Sound Cable under windows and similar for Linux to then allow the tool of choice to decode the audio from the virtual audio cable output.

My choice of tools to achieve this was:

1. Audio from CSDR piped via STDIN into EZStream.
2. EZStream feeds to IceCast2 server
3. Windows Media Player play out to a Virtual Audio Cable In

• VB-Audio VoiceMeeter - This will provide a mixer and Virtual Audio In and Out.
• VB-Audio Audio Cable -  For free provide a single Virtual Audio cable. So with this and VoiceMeter you will have access to 2 Virtual Audio Cables...

4. MMSSTV and RXSSTV both running decoding the audio from the Virtual Audio Cable Out

Installing the required tools under Linux

sudo apt-get -y install mplayer
sudo apt-get -y install lame
sudo apt-get -y install ezstream
sudo apt-get -y install icecast2

Config Icecast

Please note I will be assuming you have configured the general IceCast config options. Please follow the ICECast doco to complete this. The following is the config for a "mount point":

sudo vi /etc/icecast2/icecast.xml

       

    <mount type="normal">
        <mount-name>/sstv.mp3</mount-name>
        <source-password>srcadmin</source-password>
        <password>password</password>
        <max-listeners>10</max-listeners>
        <burst-size>65536</burst-size>
        <hidden>1</hidden>
        <public>0</public>
    </mount>
       
 

Restart the Icecast Service

sudo service icecast2 restart

Config EZStream 

 Create a EZStream config file with the following contents:

       

<ezstream>
    <url>http://localhost:8000/sstv.mp3</url>
    <sourcepassword>password</sourcepassword>
    <format>MP3</format>
    <filename>stdin</filename>
    <svrinfoname>SSTV STREAM</svrinfoname>
    <svrinfourl>http://www.vk4tmz.com.au</svrinfourl>
    <svrinfogenre>Scanner</svrinfogenre>
    <svrinfodescription>The audio from OpenWebRX for SSTV Decoding</svrinfodescription>
    <svrinfobitrate>16</svrinfobitrate>
    <svrinfochannels>1</svrinfochannels>
    <svrinfosamplerate>11025</svrinfosamplerate>
    <svrinfopublic>0</svrinfopublic>
</ezstream>
       
 

CSDR and EZStream Commands to stream the ISS SSTV audio to IceCast Server

       

export SDR_SAMPLE_RATE=5000000
export SDR_GAIN=IFGR=35,RFGR=2
export AUDIO_SAMPLE_RATE=11025
export AUDIO_GAIN=0.42
export FREQ_CENTER=145500000
export FREQ_MON=145800000
export FREQ_MON_BW=12000
export FIR_DISC_FACTOR=`python -c "print float($SDR_SAMPLE_RATE)/float($AUDIO_SAMPLE_RATE)"`
export FIR_DISC_TRANS_BW=`python -c "print float($FREQ_MON_BW)/float($SDR_SAMPLE_RATE)"`
export SHFT_ADD_PIPE=/tmp/rigctrld_openwebrx_shift_pipe
export SHFT_ADD=`python -c "print float($FREQ_CENTER-($FREQ_MON))/$SDR_SAMPLE_RATE"`
export NFM_LOW_CUT_FREQ=-4000
export NFM_LOW_CUT=`python -c "print float($NFM_LOW_CUT_FREQ)/$AUDIO_SAMPLE_RATE"`
export NFM_HIGH_CUT_FREQ=4000
export NFM_HIGH_CUT=`python -c "print float($NFM_HIGH_CUT_FREQ)/$AUDIO_SAMPLE_RATE"`
export FIR_NFM_TRANS_BW=`python -c "print (float($NFM_HIGH_CUT_FREQ) - float($NFM_LOW_CUT_FREQ))/float($AUDIO_SAMPLE_RATE)"`
export FIR_DSSB_BW=4800
export SSB_LOW_CUT_FREQ=300
export SSB_LOW_CUT=`python -c "print float($SSB_LOW_CUT_FREQ)/$AUDIO_SAMPLE_RATE"`
export SSB_HIGH_CUT_FREQ=3000
export SSB_HIGH_CUT=`python -c "print float($SSB_HIGH_CUT_FREQ)/$AUDIO_SAMPLE_RATE"`
export FIR_SSB_TRANS_BW=`python -c "print (float($SSB_HIGH_CUT_FREQ) - float($SSB_LOW_CUT_FREQ))/float($AUDIO_SAMPLE_RATE)"`

# Stream ISS SSTV Audio to IceCast using EZStream
nc -v 127.0.0.1 4951 | csdr shift_addition_cc $SHFT_ADD  | csdr fir_decimate_cc $FIR_DISC_FACTOR $FIR_DISC_TRANS_BW HAMMING | csdr bandpass_fir_fft_cc $NFM_LOW_CUT $NFM_HIGH_CUT $FIR_NFM_TRANS_BW HAMMING | csdr fmdemod_quadri_cf | csdr limit_ff | csdr old_fractional_decimator_ff 1.00158333333 | csdr deemphasis_nfm_ff 11025 | csdr fastagc_ff 1024 | csdr gain_ff $AUDIO_GAIN | csdr convert_f_s16 |  /usr/bin/lame -r -s 11.025 -m m -b 16 --cbr - -  | /usr/bin/ezstream -qvc /home/drifter/sdr/stream/sstv_ezstream.xml

       
 

To Check all OK:

1. The output of the EZStream should be displaying the stream rate ~16Kbps.  If this is not the case check for errors and correct.
2. Goto Icecast Admin portal http://localhost:8000 and log in as admin and confirm you can see the mount point
3. let hear it so via your favorite media player tools (ie Windows media player or  Linux - MPlayer)

mplayer http://localhost:8000/sstv.mp3

With that all working I was then able to play the audio on my Windows PC pipe it into Virtual Audio Cable and run the SSTV decoding tools just fine.

The only little thing is like most "streaming" the tool "buffers" which creates a little latency.  In this case the audio when being monitoring via MPlayer or windows is ~30s delayed.  This was fine for me so I did not need to tune Icecast to minimise the latency but may be something you need to consider.

That's All Folks!! Hope you guys find this helpful :)

73
de VK4TMZ (Mark)