Showing posts with label tnc. Show all posts
Showing posts with label tnc. Show all posts

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)

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