Hi Chris thanks for the feedback.

1) real machine. I'm aware of the temp fix, and have a cable at home for the 'HW' loopback method (though thats cheating when your trying to build an SDR ground station :-))

2) Working through using JACK and ALSA virtual devices, but like I said I'm new to it.

3) I'm using a .wav file sink in gnuradio. But instead of actually recording the audio and generate a true wav file (that could be imported by foxtelem later) the 'file' it is writing to is a FIFO buffer (aka pipe, created using the 'mkfifo' command). FoxTelem is then reading a wave file which is that same buffer. The goal being as bits get written into the FIFO from gnuradio, they get read out of the buffer by FoxTelem.

What it looks like is exactly what you said. GNU radio is writing to the 'file' or FIFO at a fixed 48k sample rate. FoxTelem is probably trying to 'load the entire file' and is not throttling the rate those bits come in to match the 48k rate from gnuradio, thus resulting in 'EOF-type' errors and ultimately crashing.

I think the quickest path to gettng up and running is the virtual audio cable piping method (for a pure SW solution). Downside of this is the loss of the ability to deliver the SNR and doppler metrics to the AMSAT network.

So at some point I'll try to revisit the IQ pipe ideas (though plan A of faking it with an 'IQ wav file' will result in similar crashes).

I'm not sure how FoxTelem handles interfacing with the funcube dongle or 'other SDRs.' I think it would auto-populate the option to select the funcube source if I actually had one plugged into my laptop and make use of the drivers for accessing the IQ stream, rather than 'reading a whole file'. What would be cool is if FoxTelem had some kind of 'generic IQ client mode' that could be selected. The idea would be when you select that option you enter in an IP and port #. Then foxtelem could be interfaced with things like the 'rtl_tcp' application for RTL-SDRs running on RPis or beaglebones or to the TCP sinks in GNU Radio.

easy for me though to offer up ideas like that when I'm not the one that has to code it up though :-).

Thanks again for the feedback.

-Zach, KJ4QLP

On 10/08/2015 03:01 PM, Chris Thompson wrote:

Zach,

Are you running Linux on a virtual machine or a real machine? If its a real machine with a sound card, you can probably use a physical cable temporarily while we work out how to pipe the audio. Most modern sound cards allow you to feed the audio out of the speaker and back into the mic.

I think Jack Audio will be the best approach, but the virtual audio products can be complex. I am not familiar with Jack but we have used Virtual Audio Cable and other software on Windows.

If you are creating a "virtual wav file", I presume that file gets written to disk and then you are opening it in FoxTelem? Is that right? The issue with this is that FoxTelem will read it faster than it gets filled. It won't wait for more audio - like it does with a soundcard - and will think it has reached the end of the file, or crashes as you indicated.

Chris

On Thu, Oct 8, 2015 at 1:20 PM, Zach Leffke <[email protected] mailto:[email protected]> wrote:

Hello Everyone,
    I am frantically rushing to get GNU Radio to 'play nice' with
foxtelem.  I'm running all linux here.  I'm hoping someone can
maybe throw me a few pointers on getting the fox telem software to
work with external SDR applications.  I'm attempting to pipe
signals from GNU Radio in three ways, all met with failure:

First is by running an FM receiver flowgraph and then trying to
pipe the audio out via a Linux FIFO using the 'Wav File Sink'
block in GR.  I point the SDR flowgraph to my pipe, and then I
point the FoxTelem software to the same pipe and fire the programs
up.  I've successfully used this method in the past to feed a
sound streaming application that "thinks" is reading from a
standard wav file, but is actually the GR flowgraph audio output. 
GNU Radio seems to run for a second or two (probably the amount of
time it takes to fill the buffer) then the Fox Telem Software
crashes with exceptions:

'javax.sound.sampled.UnsupportedAudioFileException:  could not get
the audio input stream from input file.'

In gnu radio I'm using the wav file sink with a single port and
sample rate of 48k and 16bits.  This "appears" to match what
FoxTelem is expecting, but I'm getting the crashes.

An alternative method I'm attempting is to use a standard audio
sink in gnuradio (I can hear the audio on my laptop speakers) and
then try to pipe that into the fox sw with a virtual audio cable. 
I'm attempting to use JACK and qjackctl, but I have little
experience with this and so far have failed to get it to do
anything other than listen to the soundcard mic and line in
ports.  If someone knows of a simple to use Virtual Audio Cable
for Linux so that I can pipe the audio via the sound card that
would be great and I can give that a go.

The third method I'm trying to get working is by placing the fox
sw in IQ mode and again attempting to use a 'wave file source' in
foxtelem pointed at a FIFO to pipe the IQ data from GNU radio into
foxtelem.  again I get the exception mentioned above.  This would
be the preferred method in my case over the audio piping.  If
someone has any experience with this that would be great.  For
those familiar with GNU Radio I'm taking the complex stream
(250ksps), reesampling to 192ksps, converting to float, then
taking the real and complex streams and feeding them into a 'Wav
file sink' with TWO ports pointed at the fifo, again with 16 bit
depth and set to 192ksps.  Foxtelem is looking for a wav file at
192ksps.  I'm hoping the two port file sink allows I data on the
right channel (in0) and Q data on the left channel (in1).


Any and all pointers would be welcome.

Thanks,
Zach, KJ4QLP
_______________________________________________
Sent via [email protected] <mailto:[email protected]>. AMSAT-NA
makes this open forum available
to all interested persons worldwide without requiring membership.
Opinions expressed
are solely those of the author, and do not reflect the official
views of AMSAT-NA.
Not an AMSAT-NA member? Join now to support the amateur satellite
program!
Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb

-- Chris E. Thompson [email protected] mailto:[email protected] [email protected] mailto:[email protected]