Saturday 4 August 2018

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:
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)

Saturday 7 July 2018

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)

Accessing OpenWebRX SDR Stream via Linux Command line and MPlayer

G'Day Guys,

In my previous posts I outlined decoding APRS using Direwolf from an audio feed extracted from my OpenWebRX Stream using the CSDR command line tools.

The following is an update on the calculations for parameters needed for the CSDR commands and I've provided an improved NFM (actually what OpenWebRX uses) as the NFM_OLD was just not 100% clear or right and I could not work it out.

I've also included USB too.


       

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=145175000
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)"`


# NEW NFM
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 | mplayer -quiet -rawaudio samplesize=2:channels=1:rate=$AUDIO_SAMPLE_RATE -demuxer rawaudio 

# OLD NFM
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 fmdemod_quadri_cf | csdr limit_ff | csdr deemphasis_nfm_ff $AUDIO_SAMPLE_RATE | csdr fastagc_ff | csdr gain_ff $AUDIO_GAIN | csdr convert_f_s16 |  mplayer -quiet -rawaudio samplesize=2:channels=1:rate=$AUDIO_SAMPLE_RATE -demuxer rawaudio -

# USB
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 $SSB_LOW_CUT $SSB_HIGH_CUT $FIR_SSB_TRANS_BW | csdr realpart_cf | csdr agc_ff | csdr limit_ff | csdr gain_ff $AUDIO_GAIN | csdr convert_f_s16 |  mplayer -quiet -rawaudio samplesize=2:channels=1:rate=$AUDIO_SAMPLE_RATE -demuxer rawaudio -



       
 

Friday 15 June 2018

PCSAT (NO-84) - Successfully Digipeated (Worked)

Guys,

So after setting up the monitoring of the Satellite APRS/Packet @ 145.825 MHz, I hadn't heard anything in almost 24hrs. My reading indicated that ISS  (ARISS) may be non-operational but there were a few other satellites such as NO-44 (PCSAT) and NO-84 (PSAT) that also provide APRS / Packet digipeating.

So last night I was just before shutting down for the night I took a look at the pass predictions for NO-44 and NO-84 satellites and luckily the NO-84 was about to have a great night pass right over head north - south direction @ 10:35pm  so thought lets see if I can beacon NO-84 and see if anyone is listening and can pick up my digipeated beacon.

Items needed for this little experiment:
  1. Thermal mug of coffee
  2. Android Phone running APRSDroid
  3. Handheld (BaoFeng uv-5rtp) using the vehicle antenna Diamond SG7400 
  4. Warm Jumper and Socks as in OZ is winter and a Low was making its way up from south so it was a little chilli.
Tune Handheld to 145.825 MHz

Setting up APRSDroid for Satellite Digipeating requires that you set the "path" to:
ARISS,WIDE1-1
Interfacing Android Phone to the BaoFeng can easily be done using the "APRS-K2 TRRS CABLE" which adapts the accessory jack on your BaoFeng (or similar) radio to a 3.5MM TRRS (Tablet, Phone, Computer)".   If you wanted to home brew your own take a look at Will Bradley's blog post "Cable for connecting APRSdroid to a Baofeng UV-82 Radio (APRS via RF)".

However!! since my cable is on order from BTECH, I used the coupling method of placing the phones external speaker on top of the Baofeng's mic port, set APRSDroid to use "Ringtone" output and set the ringtone level to about 3/4 volume (IMPORTANT!! use ringtone as this will provide louder audio as to activate the VOX which is set to level 1). This is not optimal as you now have to listen to the Packet burst, but small price to pay to have a little fun.

So all setup in the car @10:30pm on a cold Brisbane evening and waiting!!  Via tablet I was monitoring the pass via "Satellite Tracking for NO-84" and @ 10:35p started sending out manual beacon bursts every 45-60s. During the pass I did not hear anything from the NO-84.  So once LOS was reached I packed heading back into the warm house.

 Once back in the house went to see all "APRS Traffic Heard by NO-84"  and BAM!!!  there I was "VK4TMZ-9" listed as being heard by "VK3KAW-4"

One very happy Camper!! and my very first deliberate RF traffic to and through a Satellite!!!

That's all Folks!!!

73 de VK4TMZ

PS I've include snapshots of the sites showing my call and the raw decode traffic:




Thursday 14 June 2018

Setting up Satellite APRS/Packet IGate - with OpenWebRx, Direwolf and CDR - Linux

We'll I wanted to see if the ISS APRS / Packet radios actually in operation and being actively used. Based on the information @ ARISS Home Site there is activity in the last 3-7 days.
2018-Jun-25 - In the last 24 hrs I've been reading that there are in fact several other satellites that provide APRS / Packet Digipeater via same frequency 145.825 MHz. Also its looking more and more like the ISS is not functioning correctly or at all. So I'll continue to monitor and see what I can hear.  For now have rename the title of this post from "ISS APRS/Packet IGate" to hopefully more generic "Satellite APRS/Packet IGate"
So with the same method I'm monitoring our local APRS @ 145.175 NFM (see "Setting up an APRS IGate with OpenWebRx, Direwolf and CDR - Linux" ) I've set up the following monitoring of Satellite APRS / Package activity on 145.825 MHz NFM:
       

export SDR_SAMPLE_RATE=5000000
export SDR_GAIN=IFGR=35,RFGR=2
export AUDIO_SAMPLE_RATE=48000
export AUDIO_GAIN=0.32
export FREQ_CENTER=145500000
export FREQ_MON=145825000
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=`python -c "print float($FREQ_CENTER-$FREQ_MON)/$SDR_SAMPLE_RATE"`
export DW_HOME=/home/drifter/sdr/aprs/sat
export DW_CFG=$DW_HOME/direwolf-sat.conf
export DW_LOG=$DW_HOME/logs
 
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 fmdemod_quadri_cf | csdr limit_ff | csdr deemphasis_nfm_ff $AUDIO_SAMPLE_RATE | csdr fastagc_ff | csdr gain_ff $AUDIO_GAIN | csdr convert_f_s16 |  direwolf -c $DW_CFG -l $DW_LOG -a 10 -t 1 -n 1 -r $AUDIO_SAMPLE_RATE -b 16 -d aupim -

       
 

Lets see how it goes over the next week or so

73 de VK4TMZ

Setting up an APRS IGate with OpenWebRx, Direwolf and CDR - Linux

G'Day Guys,

In my previous post "Setting up APRS IGate - Windows via SoundCard" I outlined how to straight forward it was to setup and APRS IGate under Windows was using a Soundcard to decode VHF APRS signals.

Well for me I thought this is cool, but hang on a second!!!  I'm currently making available for internet users access to our local 2m VHF spectrum using OpenWebRx and SDRPlay RSP2Pro.  You can tune in to 145.175 MHz and hear the APRS digital signals. So from my experience of OpenWebRx its a great tool which does the following:

  • Using rtl_sdr or rx_sdr tools will start up a session to your SDR what whatever bandwidth you'd like to offer via OpenWebRX.  In my case I've configured the "rx_sdr" to sample and provide a bandwidth of 5MHz which allows me to offer the 2m VHF from 143MHz through to 148 MHz. This feed is then made available via "127.0.0.1:4951"
  • The OpenWebRx application creates a single set of process that then samples the SDR feed and present a fantastic waterfall and means for multiple users to select a frequency and mode to listen via a web interface.
  • When a user finally connects up and mind you there is a limit to the number of concurrent users that can access the portal and individual select any frequency and mode within the allocated frequency range.   When the user connects up OpenWebRx starts a separate set of CSDR processes pipe-lined together to extract and transform the desired frequency and mode and audio outputted to the users browser.
So with that little bit of background on how OpenWebRx works, then I thought hey why can't I start my own CDR pipeline for APRS tuned to 145.175MHz NFM and pipe the audio through to a APRS decoding tool ?

It didn't take me long to come across "Direwolf " via GitHub.  

Dire Wolf is a software "soundcard" AX.25 packet modem/TNC and APRS encoder/decoder. It can be used stand-alone to observe APRS traffic, as a tracker, digipeater, APRStt gateway, or Internet Gateway (IGate). For more information, look at the bottom 1/4 of this page and in https://github.com/wb2osz/direwolf/blob/dev/doc/README.md  
Follow the instructions on the "GitHub" Readme to download, compile and install "direwolf".

Now before I continue I will also assume you have setup OpenWebRx or you have configure a "rtl_sdr" or "rx_sdr" process which is available via network or to be pipped into the CSDR tool.  Take a look at my post "Getting Your RTLSDR Online Using OpenWebRx" :)

Ok!!! what the dickens is this CSDR?  head on over to GitHub  project CSDR by "Simonyi Károly College for Advanced Studies"

csdr is a command line tool to carry out DSP tasks for Software Defined Radio.
It can be used to build simple signal processing flow graphs, right from the command line.
The included libcsdr library contains the DSP functions that csdr makes use of. It was designed to use auto-vectorization available in gcc, and also has some functions optimized with inline assembly for ARM NEON to achieve some speedup by taking advantage of SIMD command sets available in today's CPUs.
Feel free to use it in your projects.
Most of the code is available under the permissive BSD license, with some optional parts under GPL. For additional details, see licensing.
csdr has already been used to build:
  • AM, FM, SSB, CW and BPSK31 demodulators and waterfall display in OpenWebRX,
  • AM, FM, SSB modulators in qtcsdr that can also be used standalone with rpitx,
  • a demodulator for FSK transmissions sent with the CC1111 wireless MCU, and also a standalone RTTY demodulator.
 On the project page there is a document that outlines of the CSDR functions and their parameters and included examples.  The examples are using "rtl_sdr" to start a SDR stream and pipe through the CSDR tools.

GOTCHA #1

The first gotcha that almost drove me bonkers was that the "rtl_sdr" and "rx_sdr" tool command line arguments are fairly similar. Since my OpenWebRX was configured to use rx_sdr I made a stupid very STUPID assumption / did not pay attention to the fact the CSDR examples used "rtl_sdr" and the very first CSDR function was to conbert to U8_f which caused the sample rate to be 4 times what I needed it since the OpenWebRx passed CF32 option !!  BIG DOH!!!  So basically I just had to exclude the "csdr convert_u8_f" command and leave it as C32F for the next CSDR command.
Once I had that little gem sorted, then everything worked as expected, but the CSDR notes where not 100% clear to me for some of the CSDR function paramters but I was able to reverse the values and work them out.  So below I have used variable to hold important values and results of calculation that help clearly show how the arguments to these CSDR function are calculated.  It also allows you to quickly and safely alter / play with values.

The first actually passes the stream to "mplayer" to allow you to hear it. The second is example of passing the stream to "Direwolf"

Example 1: MPlayer

       

export SDR_SAMPLE_RATE=5000000
export SDR_GAIN=IFGR=35,RFGR=2
export AUDIO_SAMPLE_RATE=48000
export AUDIO_GAIN=0.32
export FREQ_CENTER=145500000
export FREQ_MON=145175000
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=`python -c "print float($FREQ_CENTER-$FREQ_MON)/$SDR_SAMPLE_RATE"`
 
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 fmdemod_quadri_cf | csdr limit_ff | csdr deemphasis_nfm_ff $AUDIO_SAMPLE_RATE | csdr fastagc_ff | csdr gain_ff $AUDIO_GAIN | csdr convert_f_s16 |  mplayer -cache 1024 -quiet -rawaudio samplesize=2:channels=1:rate=$AUDIO_SAMPLE_RATE -demuxer rawaudio -

       
 


Example 2: Direwolf

       

export SDR_SAMPLE_RATE=5000000
export SDR_GAIN=IFGR=35,RFGR=2
export AUDIO_SAMPLE_RATE=48000
export AUDIO_GAIN=0.32
export FREQ_CENTER=145500000
export FREQ_MON=145175000
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=`python -c "print float($FREQ_CENTER-$FREQ_MON)/$SDR_SAMPLE_RATE"`
export DW_HOME=/home/drifter/sdr/aprs/noniss
export DW_CFG=$DW_HOME/direwolf-local.conf
export DW_LOG=$DW_HOME/logs
 
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 fmdemod_quadri_cf | csdr limit_ff | csdr deemphasis_nfm_ff $AUDIO_SAMPLE_RATE | csdr fastagc_ff | csdr gain_ff $AUDIO_GAIN | csdr convert_f_s16 |  direwolf -c $DW_CFG -l $DW_LOG -a 10 -t 1 -n 1 -r $AUDIO_SAMPLE_RATE -b 16 -d aupim -

       
 


You can substitute the "nc -v 127.0.0.1 4951" with the one of the following if testing outside of OpenWebRx:

For RTL SDR Dongles (just remember to adjust the SDR_SAMPLE_RATE to something more suitable for the RTL SDR ie 2400000):

rtl_sdr -s $SDR_SAMPLE_RATE -f 145000000 -g 44 - | csdr convert_u8_f 

For SDR configured and available via RX_SDR:

8Bit examples:

rx_sdr -F CU8 -s $SDR_SAMPLE_RATE -f $FREQ_CENTER -g $SDR_GAIN - | csdr convert_u8_f 

32Bit Example:

rx_sdr -F CF32 -s $SDR_SAMPLE_RATE -f $FREQ_CENTER -g $SDR_GAIN -

That's All Folks, Hope this helps you out with you APRS and any other digital decoding project you be having in conjunction with your OpenWebRx portal.

73 de VK4TMZ

Wednesday 13 June 2018

Setting up APRS IGate - Windows via SoundCard

APRS is a very useful aspect of the amateur radio hobby. If you haven't heard of APRS (Automatic Packet Reporting System) then check out Eric (KJ4YZI) from HamRadioConcepts . As Eric points out the main point of APRS is MORE than just vehicle tracking its about linking and sharing information via radio.

For me to get started I used the YAESU FT991A which has the onboard sound card so its ready to go. Around the world different regions will use different frequencies for APRS so for Australia we will be tuning into 145.175MHz. But please lookup and use the appropriate APRS frequency for your region.

There are multiple tools to decode APRS as well as pushing all the decoded APRS messages up to APRS servers to share this is were you act as a IGate.  

AFSK1200 decoder for APRS 

  • Once you have the sound level right the APRS messages should start appearing.

Setting up an IGate - Windows 

  • If you which to partake an become an IGate and upload the APRS messages you are decoding then again there are many options however for this article I will focus on using "APRSIS32" (APRS UI and IGate application) and "AGWPE" (TNS/Packet Engine that can decode APRS signals via Soundcard).
  • Download the "free" version of the AGWPE and review the following information for installing and configuring AGWPE via SoundCard - "Basic AGWPE Program Configuration".
  • To publish APRS messages you need to request a "passcode".  There is a online passcode generator that I found afterwards. But I'd recommend you follow the process of requesting as it does not take long for them to response with the code.

That's All Folks!

Stay tuned for my next post where I integrate "Direwolf" linux based KISS/TNS tool to decode APRS traffic from a feed tied into my SDRPlay RSP2PRo which is available online via SDR.hu call VHF (2m Amateur band) - Brisbane, Australia (VK4TMZ)(OpenWebRx).

73 de VK4TMZ

Friday 19 January 2018

Configuring your FT991A for Digital and Gotcha's

This post doesn't go into to much detail about HOW-TO configure your FT-991A for digital modes as this has been covered very well by Bob's (KR4DA) HOW-TO Guide for setting up FT-991A with FLDigi

This post is about those little things that I've encountered and how to I've corrected or overcome them

Features I'm encountered while using Digital Modes and how I addressed them.
Feature / IssuerDescription / Resolution
PTT works, but no Audio via FLdigiI was a little stumped with this one, as all my digital mode applications (ie WSTJ-X, WSPR, MRP40, MMSSTV) would key-up and audio come via the radio fine (ie tune) except for FLDigi (which mind you had been working previously) . After reviewing the settings under MENU I found the little bugger. I'd for some reason recently change item "070 - DATA IN SELECT" to "MIC". When I changed it back to "REAR" all audio started working again via FLDigi.

Note: This post will continue to grow as and when I encounter more of these little gems :) 73 De VK4TMZ

Saturday 6 January 2018

Allowing Multiple Applications To Control your Rig(s) - Dealing with "Exclusive Serial Port Locking"

Until yesterday, when I finally decided to do a little review of my logging and rig control software, I'd been using DXLab Suite for Logging (DXKeeper), Rig Control (DXLab Commander).  WSJT-X was able to natively talk to "DXLab Commander" and setting up virtual "cat" under DxLab Commander  N1MM was able to also access VFO etc.  FLDigi was able to access DXCommander via a nice little bridging tool developed by N2AMG called "Fldigi-DxLabs Gateway". But it always annoyed me that I was not able to run RCForb (server) while DXCommander was running due to the serial port being exclusively locked.

So I remembered a little tools called "Omnirig" which I installed and quickly had WSTJ-X configured as it could natively integrate with it.  Next looking round the web for a new Logging application I came across "Log4OM" which also natively integrates with Omnirig and its a slick and easy to use UI as well as all the external logging (eSQL, QRZ.com, LoTW, ClubBook, HamQTH, etc).  As a bonus now that Omnirig was running a contest logging software I use "VK Contest Logger - VKCL" was able to also integrate with it too!.  However I was to quickly learn N1MM did not integrate with Omnirig nor did many of my other applications (PC-ALE, RCForb, MRP40 (CW RX/TX) etc) so back to square one kinda!.

So a little more googling, I saw reference to using to a little gem off a tool by Eterlogic called VSPE which offers "virtual serial port splitting".  The tool is free to download, and use but you will be reminded to purchase a "64-bit License" which I highly recommend for such a great little tool.

This tool appears to take care of the "exclusive serial port locking" by creating a "virtual serial port split" from the source serial port.

  • Note: The only hassle I had is that RCForb needs to be started first, after that any and all applications work running at the same. I've not dug any further as to why RCForb has requires this but hey there's a work around.

Here is overview of my serial port topology / application integration:




Here is my VSPE config - "vpse_ft991a_virtual_split.vspe" which has both my FT-991A's serial ports (Enhanced / Standard) configured as "Virtual split".  Your ports may and will mostly differ but, the port settings will most likely be the same......

That's All Folks!   I hope this post helps you out to get all your applications that all want to talk and control the rigs working in harmony :)

73
Mark (de VK4TMZ)


Thursday 4 January 2018

Getting Your RTLSDR Online Using OpenWebRx

Over the Christmas break a few like minded folk including myself monitor and share each others HF/VHF comms of the Sydney To Hobart Yacht Race (S2H) via the internet.  This year we were missing someone to help cover the NSW south / mid coast. Searching the web I stumbled onto "SDR.HU" which has a heap of online KiwiSDRs plus a few RTLSDR online and free to access.  (Note: the KiwiSDR project has forked code from a project known as "OpenWebRx").

The KiwiSDRs allows a bandwidth of 30MHz which covers the HF spectrum and allow (depending on processing power) up to 4 concurrent users to each have a virtual RX and tune to any frequency within the 30MHz.  This is a fantastic feature as most other online receivers  either only a single user can tune the spectrum (ie GlobalTuners), or most of the Multi user WebSDR ones are fixed to a set of bands usually the Ham bands which means does not cover the 4483 / 6516 kHz which are the frequencies used during the S2H yacht race.

On the SDR.HU site there was about 6 online KiwiSDR's online located in (SA, VIC, NSW and TAS).  Fortunately 2 of the Kiwi had fairly good antennas connected and in good locations:

  1. SDRTAS - Launceston, Tasmania
  2. Tecsun Radios Australia - Goulburn NSW
The Tecsun KiwiSDR was fantastic and we had great coverage of the start of the race until the yachts got near Bass Strait / Tasmania were the Tasman KiwiSDR and our groups coverage took over.

For Christmas Santa had brought me a SDRPlay RSP2Pro and I loved the idea of this this online, so I took a look at what was involved and had it online fairly quickly.  This post is not about the SDRPlay and I'll cover that in another post.  This post is about getting your RTLSDR online.  You do not need to register it under SDR.HU if you wish to have it private, but why not! the more the merrier right!

Even thought you the bandwidth of the  RTLSDR is around 2.048 MHz (without too much stress on CPU or loss of quality) and  if like me you have more than one it can put each one online and provide coverage of  a single large or even multiple band segments.

There are many useful HOW-TOs out there that can get you quickly up and running such as:

  1. Getting RTLSDR and OpenWebRx installed and running.
  2. Compile and installign SoapySDR and SoapyRTLSDR libraries and utilities.
  3. Compile and install RX_Tools and SoapySDR 

From the above sources of HOW-TOs I've put together a single script / set of commands that is needed to install the (Development Tools, OpenWebRx, Rx_Tools, SoapySDr, SoapRTLSDR etc)

Download - "install_openwebrx_rtlsdr.sh"

Testing RTLSDR device

Once you have installed the necessary libraries etc, you can now plug in your RTLSDR(s) .  The following are example commands to (find / probe) the RTLSDR dongles.

rtl_test -t



SoapySDRUtil --probe



SoapySDRUtil --find



If you do not successfully see your RTLSDR listed, then please go back over the HOW-TOs and my script to see where the error may have occurred or step omitted and apply corrective actions.

Setting up OpenWebRx

If you have used my install script there is a folder "~/sdr/openwebrx" which contains the OpenWebRX project.  You can copy / clone and rename as many of these folders as you need for each RTLSDR you wish to run.

I will not be going into any detail about each of the config items but I have included two versions of the config files that I use when running my 2 RTLSDRs on the same PC.

  1. NooElec (see photo) - config_webrx.pl (configured to Monitor UHF Satellite and Repeater Output segments 436.9 - 439 MHz) 
  2. UV_HF (see photo) - config_webrx.pl (Configured to Monitor VHF Marine Simplex 156-158 MHz)
(FYI: I actually originally wanted to monitor the whole UHF Ham Satellite and Repeater Ouput 435 - 439 MHz but the UV_HF seems a little deaf on UHF even with the RF gain set to 49.6, note to self get another SDR to replace the UV_HF. On another note and not to be greedy, but another RTLSDR (or SDRPlay) would nice to monitor the Maritime Repeater Output between 160-162 MHz)

What I will make note of is that in both config files the "rtl_sdr" and "rx_sdr" config sections are valid and working.  I do have them currently on "rx_sdr" as I like it better because unlike the "rtl_sdr" were I can only specific a device number via the "-d" option, the "rx_sdr" allows you to specify a query so in my case its the "serial number".  This means if I unplug one of the devices the correct devices will be found and the issue of the ordering device number changing does not come into play.

Helpful hint: Tor working out what waterfall max/min level values to use go via your browser hit the button to auto-adjust the via the browser debugger looks at the values stored in "waterfall_min_level" and "waterfall_max_level" and update your config file accordingly.

That's all folks!! Hope the above get you online and sharing your RTLSDRs!
73
Mark (VK4TMZ)