Slaved Consoles


Simon HB9DRV <simon@...>
 

Hi All,

 

A request from a SDR-IQ user in Essex: run multiple instances of the console connected to the same radio.

 

The first instance actually talks to the radio and the other instances get the IQ data over UDP. Obviously the other instances will be tuned to the same band.

 

Now then - what else needs doing - think about this, what have I forgotten? How could this idea be extended?

 

Simon Brown, HB9DRV

http://sdr-radio.com

 


vbifyz
 

My understanding is that you want to demodulate multiple audio outputs from the same I/Q stream.
You can probably achieve this with a single instance of the software, but the interface to control those multiple outputs would become awkward. Simultaneous demodulation to Right and Left soundcard outputs should still be ok and is nice to have. They can even be in the same mode/filter settings. Say, left mouse button tunes the left channel, while right mouse button tunes the right channel.

I would leave more exotic configurations for offline post-processing, when you can start multiple instances to read from the same I/Q file.

--- In sdr-radio-com@..., "Simon HB9DRV" <simon@...> wrote:

Hi All,



A request from a SDR-IQ user in Essex: run multiple instances of the console
connected to the same radio.



The first instance actually talks to the radio and the other instances get
the IQ data over UDP. Obviously the other instances will be tuned to the
same band.



Now then - what else needs doing - think about this, what have I forgotten?
How could this idea be extended?



Simon Brown, HB9DRV

http://sdr-radio.com


Simon HB9DRV <simon@...>
 

Hi,

 

All understood - sometime, somehow I'll add usable support for demod of multiple channels at the same time.

 

Simon Brown, HB9DRV

http://sdr-radio.com

 

From: sdr-radio-com@... [mailto:sdr-radio-com@...] On Behalf Of vbifyz

My understanding is that you want to demodulate multiple audio outputs from the same I/Q stream.
You can probably achieve this with a single instance of the software, but the interface to control those multiple outputs would become awkward. Simultaneous demodulation to Right and Left soundcard outputs should still be ok and is nice to have. They can even be in the same mode/filter settings. Say, left mouse button tunes the left channel, while right mouse button tunes the right channel.

I would leave more exotic configurations for offline post-processing, when you can start multiple instances to read from the same I/Q file.

 


rfnoise@gmail.com <rfnoise@...>
 

I would like to see an IQ pipe server added to the master console so that
multiple decoders can exist on the local machine.

Joe
k6sat

Hi All,



A request from a SDR-IQ user in Essex: run multiple instances of the console
connected to the same radio.



The first instance actually talks to the radio and the other instances get
the IQ data over UDP. Obviously the other instances will be tuned to the
same band.



Now then - what else needs doing - think about this, what have I forgotten?
How could this idea be extended?



Simon Brown, HB9DRV

http://sdr-radio.com




Leif Asbrink
 

Hi Simon and All,

A request from a SDR-IQ user in Essex: run multiple instances of the console
connected to the same radio.

The first instance actually talks to the radio and the other instances get
the IQ data over UDP. Obviously the other instances will be tuned to the
same band.
This is exactly how it is done in Linrad. I think it would be very
nice if sdr-radio would use the same format for the UDP transmissions.
It would then be possible to run both SDR programs simultaneously on the
same radio:-)

73

Leif / SM5BSZ


Simon HB9DRV <simon@...>
 

Maybe we should propose a standard for this. I'll also be sending over fields such as frequency, bandwidth, radio model etc. Also I'll allow either console to tune the radio (set sample info etc.), once I get this working I'll publish this spec.

 

Simon Brown, HB9DRV

http://sdr-radio.com

 

From: sdr-radio-com@... [mailto:sdr-radio-com@...] On Behalf Of Leif Asbrink
Sent: 11 June 2010 23:32
To: sdr-radio-com@...
Subject: [sdr-radio-com] Re: Slaved Consoles

 

 

Hi Simon and All,

> A request from a SDR-IQ user in Essex: run multiple instances of the console
> connected to the same radio.
>
> The first instance actually talks to the radio and the other instances get
> the IQ data over UDP. Obviously the other instances will be tuned to the
> same band.
This is exactly how it is done in Linrad. I think it would be very
nice if sdr-radio would use the same format for the UDP transmissions.
It would then be possible to run both SDR programs simultaneously on the
same radio:-)

73

Leif / SM5BSZ


rfnoise <rfnoise@...>
 

The reason for this feature is that sdr-console will not be providing decoders for everything yet it will make a great way to observe the spectra; the addition of an IQ pipe server will allow multiple decoders to be deployed without the added redundancy of having to develop a FFT viewer :)

Joe
k6sat

On Jun 11, 2010, at 2:03 PM, rfnoise@... wrote:

 

I would like to see an IQ pipe server added to the master console so that
multiple decoders can exist on the local machine.

Joe
k6sat

> Hi All,
>
>
>
> A request from a SDR-IQ user in Essex: run multiple instances of the console
> connected to the same radio.
>
>
>
> The first instance actually talks to the radio and the other instances get
> the IQ data over UDP. Obviously the other instances will be tuned to the
> same band.
>
>
>
> Now then - what else needs doing - think about this, what have I forgotten?
> How could this idea be extended?
>
>
>
> Simon Brown, HB9DRV
>
> http://sdr-radio.com
>
>
>
>



Simon HB9DRV <simon@...>
 

Something else - I expect that 'other' consoles will maybe want the IQ data with a different bandwidth, for example 48kHz. If so I could mix and decimate and send at the required rate. I'll do this to drive my own digital mode software.

 

Simon Brown, HB9DRV

http://sdr-radio.com

 

From: sdr-radio-com@... [mailto:sdr-radio-com@...] On Behalf Of rfnoise

The reason for this feature is that sdr-console will not be providing decoders for everything yet it will make a great way to observe the spectra; the addition of an IQ pipe server will allow multiple decoders to be deployed without the added redundancy of having to develop a FFT viewer :)

 


Leif Asbrink
 

Hi Simon,

Maybe we should propose a standard for this. I'll also be sending over
fields such as frequency, bandwidth, radio model etc. Also I'll allow either
console to tune the radio (set sample info etc.), once I get this working
I'll publish this spec.
I would suggest you send all the extra stuff via a reliable connection.
That would allow others to silently read the UDP packages and use them
for whatever purpose. The packages would have to contain a counter
to keep track of lost packages plus the current center frequency and
the sampling rate. It could also be a good idea to send info about
the format:
No of RF channels
No of bits per sample (In Linrad one can choose between 16,18 and 24)
Presumably you will allow those things to change and it would be convenient
for a user to have any listening software notice automatically.

A Linrad master runs a server into which all the slaves log in.
Then they can request whatever info they want about and also
suggest things to the master.

The Linrad network was originally designed for multioperator EME
contest stations where slave operators should not be allowed to
change anything for the master operator. I understand you design
for other usages, but I hope you find it a good idea to keep
the bi-directional control interface separate from the UDP data
stream.

73

Leif / SM5BSZ


rfnoise <rfnoise@...>
 

That works for me - as long as we can also get full BW as well. Are you thinking about pipe as well as UDP or just UDP? pipe works great for local operation and is fast and easy to implement and packets never get dropped :)

Joe
k6sat

On Jun 11, 2010, at 4:03 PM, Simon HB9DRV wrote:

 

Something else - I expect that 'other' consoles will maybe want the IQ data with a different bandwidth, for example 48kHz. If so I could mix and decimate and send at the required rate. I'll do this to drive my own digital mode software.

 

Simon Brown, HB9DRV

http://sdr-radio.com

 

From: sdr-radio-com@yahoogroups.com [mailto:sdr-radio-com@yahoogroups.com] On Behalf Of rfnoise

The reason for this feature is that sdr-console will not be providing decoders for everything yet it will make a great way to observe the spectra; the addition of an IQ pipe server will allow multiple decoders to be deployed without the added redundancy of having to develop a FFT viewer :)

 




Simon HB9DRV <simon@...>
 

First UDP, then a pipe if needed but I would prefer UDP.

 

Simon Brown, HB9DRV

http://sdr-radio.com

 

From: sdr-radio-com@... [mailto:sdr-radio-com@...] On Behalf Of rfnoise
 

That works for me - as long as we can also get full BW as well. Are you thinking about pipe as well as UDP or just UDP? pipe works great for local operation and is fast and easy to implement and packets never get dropped :)

 


Simon HB9DRV <simon@...>
 

 

 

Simon Brown, HB9DRV

http://sdr-radio.com

 

From: sdr-radio-com@... [mailto:sdr-radio-com@...] On Behalf Of Leif Asbrink
Sent: 12 June 2010 01:04
To: sdr-radio-com@...
Subject: [sdr-radio-com] Re: Slaved Consoles

 

 

Hi Simon,

> Maybe we should propose a standard for this. I'll also be sending over
> fields such as frequency, bandwidth, radio model etc. Also I'll allow either
> console to tune the radio (set sample info etc.), once I get this working
> I'll publish this spec.
I would suggest you send all the extra stuff via a reliable connection.
That would allow others to silently read the UDP packages and use them
for whatever purpose. The packages would have to contain a counter
to keep track of lost packages plus the current center frequency and
the sampling rate. It could also be a good idea to send info about
the format:
No of RF channels
No of bits per sample (In Linrad one can choose between 16,18 and 24)
Presumably you will allow those things to change and it would be convenient
for a user to have any listening software notice automatically.

A Linrad master runs a server into which all the slaves log in.
Then they can request whatever info they want about and also
suggest things to the master.

The Linrad network was originally designed for multioperator EME
contest stations where slave operators should not be allowed to
change anything for the master operator. I understand you design
for other usages, but I hope you find it a good idea to keep
the bi-directional control interface separate from the UDP data
stream.

73

Leif / SM5BSZ


Simon HB9DRV <simon@...>
 

Heh,

 

OK - exactly what I have in mind.

 

Simon Brown, HB9DRV

http://sdr-radio.com

 

From: sdr-radio-com@... [mailto:sdr-radio-com@...] On Behalf Of Leif Asbrink
Sent: 12 June 2010 01:04
To: sdr-radio-com@...
Subject: [sdr-radio-com] Re: Slaved Consoles

 

 

Hi Simon,

> Maybe we should propose a standard for this. I'll also be sending over
> fields such as frequency, bandwidth, radio model etc. Also I'll allow either
> console to tune the radio (set sample info etc.), once I get this working
> I'll publish this spec.
I would suggest you send all the extra stuff via a reliable connection.
That would allow others to silently read the UDP packages and use them
for whatever purpose. The packages would have to contain a counter
to keep track of lost packages plus the current center frequency and
the sampling rate. It could also be a good idea to send info about
the format:
No of RF channels
No of bits per sample (In Linrad one can choose between 16,18 and 24)
Presumably you will allow those things to change and it would be convenient
for a user to have any listening software notice automatically.

A Linrad master runs a server into which all the slaves log in.
Then they can request whatever info they want about and also
suggest things to the master.

The Linrad network was originally designed for multioperator EME
contest stations where slave operators should not be allowed to
change anything for the master operator. I understand you design
for other usages, but I hope you find it a good idea to keep
the bi-directional control interface separate from the UDP data
stream.

73

Leif / SM5BSZ


Phil Harman
 

There is a compelling reason for keeping the control data and signal data in the same UPD frame.
 
When working full break-in CW having a delay between the control and signal data is a disaster.  We imbedded control and signal data in the USB frames in the original HPSDR USB protocol and have carried this forward into the UDP implementation.  It was the only way we could obtain acceptable  break-in performance.
 
Its ironic that the simplest communications mode, CW, places the highest demands on SDR software :)
 
Phil....VK6APH
 
 
 
 

----- Original Message -----
Sent: Saturday, June 12, 2010 7:04 AM
Subject: [sdr-radio-com] Re: Slaved Consoles

 

Hi Simon,

> Maybe we should propose a standard for this. I'll also be sending over
> fields such as frequency, bandwidth, radio model etc. Also I'll allow either
> console to tune the radio (set sample info etc.), once I get this working
> I'll publish this spec.
I would suggest you send all the extra stuff via a reliable connection.
That would allow others to silently read the UDP packages and use them
for whatever purpose. The packages would have to contain a counter
to keep track of lost packages plus the current center frequency and
the sampling rate. It could also be a good idea to send info about
the format:
No of RF channels
No of bits per sample (In Linrad one can choose between 16,18 and 24)
Presumably you will allow those things to change and it would be convenient
for a user to have any listening software notice automatically.

A Linrad master runs a server into which all the slaves log in.
Then they can request whatever info they want about and also
suggest things to the master.

The Linrad network was originally designed for multioperator EME
contest stations where slave operators should not be allowed to
change anything for the master operator. I understand you design
for other usages, but I hope you find it a good idea to keep
the bi-directional control interface separate from the UDP data
stream.

73

Leif / SM5BSZ



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.829 / Virus Database: 271.1.1/2931 - Release Date: 06/11/10 14:35:00


Simon HB9DRV <simon@...>
 

Hi,

 

It'll be interesting to see how fast I can get QSK working, mustn't talk too much about the new RFspace radios though, sworn to secrecy etc.

 

Simon Brown, HB9DRV

http://sdr-radio.com

 

From: sdr-radio-com@... [mailto:sdr-radio-com@...] On Behalf Of Phil Harman

 

Its ironic that the simplest communications mode, CW, places the highest demands on SDR software :)