digital drop receivers

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

digital drop receivers

Rob Janssen
Tobias,

I see that recently you are doing work on the digital drop receivers feature.
As you know, we have used it for some time and it works very nicely.

At the moment, we are running a WebSDR (the wellknown program written by PA3FWM) on
our system.   This enables us to see what is happening in the band and allows others to listen.
See http://websdr.pi1utr.ampr.org/

Unfortunately, the RTL stick can be used only by a single program, so now we cannot use
it with svxlink.  However, as far as I can see this could be solved.

We have used both the rtl_tcp mode and the native USB mode once it became available.
Both methods are single-client only, but I think it would be possible to modify rtl_tcp to allow
more clients.  One of the clients would be the primary client that has full control over the stick,
i.e. it can set the parameters.   The other clients (that connect on another port or are deemed
to be secondary because they connected last) can only receive the sample stream but will
have to live with the parameters as set by the primary client.

Do you agree that this is possible, or do you see a reason why that would not work?
When it is possible to work in an environment like that, I could modify the rtl_tcp code in a fork
of your librtlusb repository.
As far as I see now there are no success/failure return codes from rtl_tcp so it will probably
be tricky, requiring the configuration of svxlink to precisely set the frequency to the value that
is also in the WebSDR configuration (not calculate it).  Maybe I could add another command that
returns the parameters that the stick has been set to.

However, there is one problem: both WebSDR and Svxlink (the primary candidates to share
the stick for now) have a limited set of samplerates that can be selected.

Svxlink: 960000 and 2400000 samples/s.
WebSDR: 256000, 512000, 768000, 1024000, 1536000, 2048000 and 2880000 samples/s.

As you see, they don't have a common sample rate.   Most WebSDRs (including ours) are
using 2048000 samples/s as that creates a convenient 2MHz wide band.   I have run the WebSDR
at 2880000 for some days and my impression was that it performed a little worse.  But it was not
really measured.

My question: is it possible with reasonable effort to add more samplerates to Svxlink, especially
2048000 from that list?

Rob

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: digital drop receivers

Tobias Blomberg
On Friday 15 May 2015 20:35:32 Rob Janssen wrote:

> Tobias,
>
> I see that recently you are doing work on the digital drop receivers
> feature. As you know, we have used it for some time and it works very
> nicely.
>
> At the moment, we are running a WebSDR (the wellknown program written by
> PA3FWM) on our system.   This enables us to see what is happening in the
> band and allows others to listen. See http://websdr.pi1utr.ampr.org/
>
> Unfortunately, the RTL stick can be used only by a single program, so now we
> cannot use it with svxlink.  However, as far as I can see this could be
> solved.
>
> We have used both the rtl_tcp mode and the native USB mode once it became
> available. Both methods are single-client only, but I think it would be
> possible to modify rtl_tcp to allow more clients.  One of the clients would
> be the primary client that has full control over the stick, i.e. it can set
> the parameters.   The other clients (that connect on another port or are
> deemed to be secondary because they connected last) can only receive the
> sample stream but will have to live with the parameters as set by the
> primary client.
>
> Do you agree that this is possible, or do you see a reason why that would
> not work? When it is possible to work in an environment like that, I could
> modify the rtl_tcp code in a fork of your librtlusb repository.

If you are going to modify librtlsdr it's probably better to try to send the
patches to the official mailing list. I had no luck getting my patches accepted
but you may have more luck.

I'm not going to maintain my copy of librtlsdr since I now have the
functionality I need implemented in the devcal utility. It can measure both
frequency error and deviation for FM transmitters.

Since the protocol is very simple I guess it would not be too big of a job to
extend SvxLink with a TCP port that speak the rtl_tcp protocol. That way
SvxLink can be in full control of the receiver but allow other clients to use
it.


> As far as I see now there are no success/failure return codes from rtl_tcp
> so it will probably be tricky, requiring the configuration of svxlink to
> precisely set the frequency to the value that is also in the WebSDR
> configuration (not calculate it).  Maybe I could add another command that
> returns the parameters that the stick has been set to.
>
> However, there is one problem: both WebSDR and Svxlink (the primary
> candidates to share the stick for now) have a limited set of samplerates
> that can be selected.
>
> Svxlink: 960000 and 2400000 samples/s.
> WebSDR: 256000, 512000, 768000, 1024000, 1536000, 2048000 and 2880000
> samples/s.
>
> As you see, they don't have a common sample rate.   Most WebSDRs (including
> ours) are using 2048000 samples/s as that creates a convenient 2MHz wide
> band.   I have run the WebSDR at 2880000 for some days and my impression
> was that it performed a little worse.  But it was not really measured.
>
> My question: is it possible with reasonable effort to add more samplerates
> to Svxlink, especially 2048000 from that list?

I've been meaning to review the sampling frequencies supported now. I more or
less just picked them. The rates you list above is probably better in many
ways. I'll see when I find some time to fix that.

73's de SM0SVX / Tobias


>
> Rob


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|

Re: digital drop receivers

Rob Janssen
SM0SVX wrote:
> If you are going to modify librtlsdr it's probably better to try to send the
> patches to the official mailing list. I had no luck getting my patches accepted
> but you may have more luck.

That is why I considered it better to maintain a separate version for those that want the
changes.  But when I go that route I will try submitting it.

>
> Since the protocol is very simple I guess it would not be too big of a job to
> extend SvxLink with a TCP port that speak the rtl_tcp protocol. That way
> SvxLink can be in full control of the receiver but allow other clients to use
> it.

That is another possibility.  Fortunately WebSDR neatly recovers when rtl_tcp is restarted
under it.  After a number of seconds it just reconnects the TCP port and resumes operation.
So it will be no problem when remotetrx is restarted while WebSDR is running.

It may be a better solution because svxlink can watch the parameters that WebSDR requests
and maybe adapt to the situation (e.g. a setting of the center frequency that is different from
what was calculated before).  And svxlink can use the USB library, which probably
is more efficient than having rtl_tcp inbetween.

> I've been meaning to review the sampling frequencies supported now. I more or
> less just picked them. The rates you list above is probably better in many
> ways. I'll see when I find some time to fix that.
>

Ok great!

Rob

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel