26 Sep
2012
26 Sep
'12
12:23 p.m.
I've ported my app to use rtl_tcp.exe instead of the native rtlsdr libs,
and while it is partly working (samples reading correctly, no dropped
samples, etc.), I have run into two issues.
First--when I start reading samples too quickly after setting the sample
rate, I get this error:
C:\Users\Scott
Cutler\Projects\p4\0\projects\sdr\SeeDeR\SeeDeR\rtl-sdr-release\x32>rtl_tcp.exe
-f 100000000 -s 2048000
Found 1 device(s).
Found Elonics E4000 tuner
Using Generic RTL2832U (e.g. hama nano)
Tuned to 100000000 Hz.
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr)
source
to receive samples in GRC and control rtl_tcp parameters (frequency,
gain, ...).
client accepted!
set freq 105000000
set sample rate 1920000
worker cond timeout
Signal caught, exiting!
comm recv socket error
Signal caught, exiting!
all threads dead..
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr)
source
to receive samples in GRC and control rtl_tcp parameters (frequency,
gain, ...).
If I instead wait about two seconds after setting the sample rate, there
is no problem. There is also no problem if I immediately read samples
after connecting, where I set the sample rate on the command line.
The other issue is that tuning is very slow--about one second per call
to rtlsdr_set_center_freq. I had a similar problem with the rtlsdr.dll
library, and I found that tuning was very slow if performed from the
main thread, but fairly quick (maybe 10-20 hz) if done from the async
proc thread that rtlsdr_read_async launches.
That seemed a bit odd to me but it worked. I suspect that rtl_tcp.exe
is doing the same thing; calling rtlsdr_set_center_freq from the main
thread.
Ideas, anyone? Thanks!
-Scott
PS: I'm running Win7-64, in case it matters. Also using the latest
version here:
http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip
26 Sep
26 Sep
12:35 p.m.
Slight correction/clarification to the below: obviously, I am not
calling rtlsdr_set_center_freq when using rtl_tcp.exe. Instead, what I
see is that I can queue up a bunch of tuning calls, but they only kick
in at a very slow rate (1 hz). The effect is similar to when I used the
native libs, where rtlsdr_set_center_freq also took 1 s on the main thread.
-Scott
On 9/26/2012 3:23 AM, Scott Cutler wrote:
I've ported my app to use rtl_tcp.exe instead of
the native rtlsdr
libs, and while it is partly working (samples reading correctly, no
dropped samples, etc.), I have run into two issues.
First--when I start reading samples too quickly after setting the
sample rate, I get this error:
C:\Users\Scott
Cutler\Projects\p4\0\projects\sdr\SeeDeR\SeeDeR\rtl-sdr-release\x32>rtl_tcp.exe
-f 100000000 -s 2048000
Found 1 device(s).
Found Elonics E4000 tuner
Using Generic RTL2832U (e.g. hama nano)
Tuned to 100000000 Hz.
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR
(gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency,
gain, ...).
client accepted!
set freq 105000000
set sample rate 1920000
worker cond timeout
Signal caught, exiting!
comm recv socket error
Signal caught, exiting!
all threads dead..
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR
(gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency,
gain, ...).
If I instead wait about two seconds after setting the sample rate,
there is no problem. There is also no problem if I immediately read
samples after connecting, where I set the sample rate on the command line.
The other issue is that tuning is very slow--about one second per call
to rtlsdr_set_center_freq. I had a similar problem with the
rtlsdr.dll library, and I found that tuning was very slow if performed
from the main thread, but fairly quick (maybe 10-20 hz) if done from
the async proc thread that rtlsdr_read_async launches.
That seemed a bit odd to me but it worked. I suspect that rtl_tcp.exe
is doing the same thing; calling rtlsdr_set_center_freq from the main
thread.
Ideas, anyone? Thanks!
-Scott
PS: I'm running Win7-64, in case it matters. Also using the latest
version here:
http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip
1:26 p.m.
Hi Scott
On 09/26/12 12:35, Scott Cutler wrote:
Slight correction/clarification to the below:
obviously, I am not
calling rtlsdr_set_center_freq when using rtl_tcp.exe. Instead, what I
see is that I can queue up a bunch of tuning calls, but they only kick
in at a very slow rate (1 hz). The effect is similar to when I used the
native libs, where rtlsdr_set_center_freq also took 1 s on the main thread.
I experienced the same maximum 1 hz tuning rate with rtl_tcp.
A quick look at the code shows a select() call in the command_worker
thread with a timeout set to 1s, but that doesn't explain the observed
behavior, because, as I understand select(), it should return as soon as
the UDP socket has data available (the timeout is used to allow the
thread to terminate when rtl_tcp shuts down). Nevertheless, my spidey
sense tells me this is the place to look...
Regards,
Simeon.
27 Sep
27 Sep
9:05 a.m.
It appears that both of my problems are nearly the same: the "worker
cond timeout" happens because the first thing my program does is set the
sample rate, which takes a whopping 2.58 seconds. This apparently
delays rtlsdr_callback long enough that the timeout in
pthread_cond_timedwait is hit, causing tcp_worker to bail.
rtlsdr_set_center_freq takes 1.09 seconds and is unrelated to the select
call--that comes down immediately. It is something to do with the
rtlsdr library itself (or one of its dependencies). Time to investigate
more deeply.
-Scott
On 9/26/2012 4:26 AM, Simeon Miteff wrote:
Hi Scott
On 09/26/12 12:35, Scott Cutler wrote:
Slight correction/clarification to the below:
obviously, I am not
calling rtlsdr_set_center_freq when using rtl_tcp.exe. Instead, what I
see is that I can queue up a bunch of tuning calls, but they only kick
in at a very slow rate (1 hz). The effect is similar to when I used the
native libs, where rtlsdr_set_center_freq also took 1 s on the main thread.
I
experienced the same maximum 1 hz tuning rate with rtl_tcp.
A quick look at the code shows a select() call in the command_worker
thread with a timeout set to 1s, but that doesn't explain the observed
behavior, because, as I understand select(), it should return as soon as
the UDP socket has data available (the timeout is used to allow the
thread to terminate when rtl_tcp shuts down). Nevertheless, my spidey
sense tells me this is the place to look...
Regards,
Simeon.
9:35 a.m.
And another followup:
A locally-built version of rtlsdr.dll works perfectly, and only takes a
few tens of milliseconds for either rtlsdr_set_sample_rate or
rtlsdr_set_center_freq.
The binaries I am comparing against were built on 9/13 and are from this
link:
http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip
I looked through the Git commit log for the past month but didn't see
anything that seemed relevant.
Does anyone know the precise way in which these binaries were built? It
would seem very odd if some build setting caused the difference, but
that's my only idea at the moment.
-Scott
On 9/27/2012 12:05 AM, Scott Cutler wrote:
It appears that both of my problems are nearly the
same: the "worker
cond timeout" happens because the first thing my program does is set
the sample rate, which takes a whopping 2.58 seconds. This apparently
delays rtlsdr_callback long enough that the timeout in
pthread_cond_timedwait is hit, causing tcp_worker to bail.
rtlsdr_set_center_freq takes 1.09 seconds and is unrelated to the
select call--that comes down immediately. It is something to do with
the rtlsdr library itself (or one of its dependencies). Time to
investigate more deeply.
-Scott
On 9/26/2012 4:26 AM, Simeon Miteff wrote:
Hi Scott
On 09/26/12 12:35, Scott Cutler wrote:
Slight correction/clarification to the below:
obviously, I am not
calling rtlsdr_set_center_freq when using rtl_tcp.exe. Instead, what I
see is that I can queue up a bunch of tuning calls, but they only kick
in at a very slow rate (1 hz). The effect is similar to when I used
the
native libs, where rtlsdr_set_center_freq also took 1 s on the main
thread.
I experienced the same maximum 1 hz tuning rate with rtl_tcp.
A quick look at the code shows a select() call in the command_worker
thread with a timeout set to 1s, but that doesn't explain the observed
behavior, because, as I understand select(), it should return as soon as
the UDP socket has data available (the timeout is used to allow the
thread to terminate when rtl_tcp shuts down). Nevertheless, my spidey
sense tells me this is the place to look...
Regards,
Simeon.
9:43 a.m.
Hi Scott
On 09/27/12 09:05, Scott Cutler wrote:
It appears that both of my problems are nearly the
same: the "worker
cond timeout" happens because the first thing my program does is set the
sample rate, which takes a whopping 2.58 seconds. This apparently
delays rtlsdr_callback long enough that the timeout in
pthread_cond_timedwait is hit, causing tcp_worker to bail.
rtlsdr_set_center_freq takes 1.09 seconds and is unrelated to the select
call--that comes down immediately. It is something to do with the
rtlsdr library itself (or one of its dependencies). Time to investigate
more deeply.
I did a little test last night against the latest rtl_tcp code:
https://gist.github.com/3792676
On my Linux box, this script is able to command rtl_tcp to set the
sample rate and then tune successfully at 10Hz...
I would agree that there is something else causing the issues on your
system. Perhaps a USB issue?
Regards,
Simeon.
11 a.m.
Thanks for the sanity check. As I mentioned in my last email, I don't
see the same problem with the latest version from Git (able to tune at
~20 hz). It seems that the precompiled binary on the Osmocom site is
somewhat broken.
So for the moment I don't have any problems, although it would be nice
to get the public binaries updated.
-Scott
On 9/27/2012 12:43 AM, Simeon Miteff wrote:
Hi Scott
On 09/27/12 09:05, Scott Cutler wrote:
It appears that both of my problems are nearly
the same: the "worker
cond timeout" happens because the first thing my program does is set the
sample rate, which takes a whopping 2.58 seconds. This apparently
delays rtlsdr_callback long enough that the timeout in
pthread_cond_timedwait is hit, causing tcp_worker to bail.
rtlsdr_set_center_freq takes 1.09 seconds and is unrelated to the select
call--that comes down immediately. It is something to do with the
rtlsdr library itself (or one of its dependencies). Time to investigate
more deeply.
I did a little test last night against the latest rtl_tcp code:
https://gist.github.com/3792676
On my Linux box, this script is able to command rtl_tcp to set the
sample rate and then tune successfully at 10Hz...
I would agree that there is something else causing the issues on your
system. Perhaps a USB issue?
Regards,
Simeon. 
26 Sep
26 Sep
9:33 p.m.
Hi All,
The GNU licencing of rtl-sdr is the GNU GENERAL PUBLIC LICENSE.
There is also the GNU LIBRARY GENERAL PUBLIC LICENSE that
better specifies some of the concepts used by the Free
Software Foundation, Inc.
The library license states that one can change from it to
the general license but that one then not can change back:
"Once this change is made in a given copy, it is irreversible
for that copy, so the ordinary GNU General Public License
applies to all subsequent copies and derivative works made
from that copy."
I am not a lawyer, but it seems to me that this statement
implicates that the library license is more restricted and
that things you are allowed to do under the library license
are still allowed under the general license.
In the library license we can read this:
"5. A program that contains no derivative of any portion
of the Library, but is designed to work with the Library
by being compiled or linked with it, is called a "work
that uses the Library". Such a work, in isolation, is
not a derivative work of the Library, and therefore falls
outside the scope of this License."
This means you are free to use the rtlsdr dll available
at osmocom but you can not distribute an executable in
which the library is linked in.
Likewise can I distribute Linrad under Linux and give
the user the instructions how to link in librtl.so
from the osmocom site or from a complete and somewhat
modified version that I will supply myself in case
the modifications to the library I will propose will not
be accepted. The e4k tuner works very well, actually it is
very competitive when compared to the FUNcube Pro dongle,
but only with a modified library.
http://www.sm5bsz.com/linuxdsp/hware/funcube/funcube.htm
At the moment I am working with the FC0013 code. So far I
found these things:
The original code uses AGC. To disable it I change the
init for registers 0x0cc and 0x0d:
[0x0c]=0x78 (normal) or 0xb8 (-35 dB gain)
[0x0d]=0x81 (normal) or 0x89 (-60 dB gain)
Regards
Leif / SM5BSZ
PS. The reason I worry about the GNU license is that
Linrad is free software. Free for anyone to use for
any purpose. I do not want to discourage people from
using my sdr algorithms in commercial products. For that
reason I claim no copyright and do not include a GNU
license. DS.
9:52 p.m.
Hi,
"Once this change is made in a given copy, it is
irreversible
for that copy, so the ordinary GNU General Public License
applies to all subsequent copies and derivative works made
from that copy."
I am not a lawyer, but it seems to me that this statement
implicates that the library license is more restricted and
that things you are allowed to do under the library license
are still allowed under the general license.
Clearly you're not. It's pretty much exactly the opposite actually.
LGPL is _LESS_ restrictive and among those additional freedom, you can
relicense it under GPL.
In the library license we can read this:
[snip]
This means you are free to use the rtlsdr dll
available
at osmocom but you can not distribute an executable in
which the library is linked in.
??? How exactly did you go from taking a software distributed using
GPL (rtl-sdr and librtlsdr) and just apply LGPL clauses to it ???
As said above you can't do that at all.
Likewise can I distribute Linrad under Linux and give
the user the instructions how to link in librtl.so
from the osmocom site or from a complete and somewhat
modified version that I will supply myself in case
the modifications to the library I will propose will not
be accepted.
If you link to librtlsdr.so, you _have_ to be a GPL compatible license
and that's it. That's how GPL works.
Now, the only license I saw in linrad seems to be pretty much public
domain. So you _can_ link to librtlsdr.so directly without any issue.
Any distribution of binaries that are linked to it however will
effectively be GPL. But anyone is still completely free to take
whatever part of your public domain code and do whatever they want
with it. However if they also want to distribute binaries of their
modified code linked to rtlsdr, then they'll have to release those
under a GPL compatible license as well.
So there are no risk to you, anyone will still be free to extract your
sdr algorithm and use them however they want, according to your own
rules. Only the rtlsdr link will be conditional to GPL terms. For
example they'd be free to take your software, disable the rtlsdr part,
do some mods, and sell the resulting binaries.
Cheers,
Sylvain
27 Sep
27 Sep
2:12 a.m.
"Once
this change is made in a given copy, it is irreversible
for that copy, so the ordinary GNU General Public License
applies to all subsequent copies and derivative works made
from that copy."
I am not a lawyer, but it seems to me that this statement
implicates that the library license is more restricted and
that things you are allowed to do under the library license
are still allowed under the general license.
Clearly you're not. It's pretty much exactly the opposite actually. LGPL is _LESS_ restrictive and among those additional
freedom, you can
relicense it under GPL.
Yes, this is what Lief suggested.
This means you
are free to use the rtlsdr dll available
at osmocom but you can not distribute an executable in
which the library is linked in.
??? How exactly did you go from taking a software distributed using
GPL (rtl-sdr and librtlsdr) and just apply LGPL clauses to it ???
As said above you can't do that at all. If you link to librtlsdr.so, you _have_ to be a GPL
compatible license
and that's it. That's how GPL works.
If I understand correctly, Leif was suggesting a workaround. Instead of
distributing something that violates the license, you could distribute
something in two halves (each in compliance), along with instructions on how
to link them together. Once linked they can no longer be distributed, but
because you were distributing them separately you wouldn't be violating any
licenses.
I'm not sure what the legal implications of this are. On the one hand what
you're distributing complies with the license, but then by providing
instructions on how to link them together there is clear intent to bypass the
restrictions imposed by the licenses. I guess this is where advice from the
SFLC comes in.
Cheers,
Adam.
2:24 a.m.
Hi,
I think you misread Leif's message - what was said
is correct. You can take
an LGPL library and relicense it under the GPL, but you can't go back to
LGPL again. Yes, this implies the license becomes more restrictive, because
there are things you can do under the LGPL that you can no longer do once it
becomes GPL.
I think you misread it. He clearly stated "the library license is more
restricted and
that things you are allowed to do under the library license are still
allowed under the general license."
This is not the case. In LGPL you can link so closed software, in GPL
you can't. So everything allowed under LGPL is _not_ allowed under
GPL.
I think what Leif was getting at is that you can do
whatever you want if you
don't distribute it. The GPL and other licenses only come into effect once
you distribute something to someone else.
Well yes, obviously if you want to write source code just for you and
never distribute it (not even the source) that's totally fine
obviously.
If I understand correctly, Leif was suggesting a
workaround. Instead of
distributing something that violates the license, you could distribute
something in two halves (each in compliance), along with instructions on how
to link them together. Once linked they can no longer be distributed, but
because you were distributing them separately you wouldn't be violating any
licenses.
Distributing code source that cannot work without the GPL library is
not compliant.
GPL doesn't mention linking explicitely, just derivative work and a
piece of source code that can't be compiled into an executable without
the GPL piece of code linked to it would definitely be considered
derivative work. If not, the whole concept of "gpl compatible"
open-source license wouldn't make sense.
But in any case, in his case it's completely irrelevant because the
open source license he chooses _is_ GPL compatible so there is no
issues to start with.
Cheers,
Sylvain
8:03 a.m.
Hej Leif!
Leif Asbrink wrote:
This means you are free to use the rtlsdr dll
available
at osmocom but you can not distribute an executable in
which the library is linked in.
I'm afraid it's not so simple.
Likewise can I distribute Linrad under Linux and give
the user the instructions how to link in librtl.so
from the osmocom site or from a complete and somewhat
modified version that I will supply myself in case
the modifications to the library I will propose will not
be accepted.
You can do that, but Linrad will also be GPL.
Your software (both source and binaries) undisputably constitutes a
derivative work of rtl-sdr, because it calls rtl-sdr.
A consequence is that your software is not really in the public
domain, as long as it calls rtl-sdr.
Also keep in mind that the concept of public domain is problematic
across international copyright law. All nations do not allow an
author to abstain their copyright; I believe that's the case here
in Europe for example.
For maximum freedom I like to use the MIT license:
http://opensource.org/licenses/MIT
I understand the only requirement to be that copyright notices and
the license itself are also copied, when copying the source code.
The e4k tuner works very well, actually it is
very competitive when compared to the FUNcube Pro dongle,
but only with a modified library.
http://www.sm5bsz.com/linuxdsp/hware/funcube/funcube.htm
I urge you to work with the rtl-sdr maintainers to find how your
improvements can be reworked so that they are included in rtl-sdr.
It is a waste of everyone's time that you keep some local changes.
PS. The reason I worry about the GNU license is that
Linrad is free software. Free for anyone to use for
any purpose. I do not want to discourage people from
using my sdr algorithms in commercial products. For that
reason I claim no copyright and do not include a GNU
license. DS.
I hope it is clear that the way you currently do this doesn't work,
or that it at the very least is more problematic than it needs to be.
Any software which calls rtl-sdr automatically becomes GPL.
It is of course easy to accomplish what you want. Just like those who
wish to distribute their software with a less free license than GPL
you must create an abstraction in Linrad where the only calls to
rtl-sdr occur in a process which is separate from Linrad. The source
code of that (small) program will always be GPL. Linrad which
communicates with that (small) program can use another license.
One easy solution is to just use the rtl-sdr TCP protocol, but you
may have some reason to create a different abstraction. With an
abstraction over TCP you have isolated your software from rtl-sdr.
Like authors of closed software you are circumventing the intent of
the rtl-sdr authors, but that is of course your prerogative.
To make your software unproblematic for others to use I urge you to
choose a permissive license that you like, in the list of popular
approved open source licenses. Here's the list:
http://opensource.org/licenses/category
MIT is IMO the shortest and simplest of them. That's why I like it a
lot for maximum freedom software.
//Peter
2 Oct
2 Oct
12:49 a.m.
Hello Peter,
I sent some
suggestions to Steve Markgraf. I hope he finds
the mods I need to get good performance suitable for the rtl-sdr
library.
Your software (both source and binaries) undisputably
constitutes a
derivative work of rtl-sdr, because it calls rtl-sdr.
Well, my software will not
call rtl-sdr if that package is not
installed. I do not think "derivative" would be an appropriate
description. What I want to achieve is that anyone who wants
to use the dsp code that I wrote myself should be allowed
to extract whatever he wants and use it in whatever way he
wants.
A consequence is that your software is not really in
the public
domain, as long as it calls rtl-sdr.
Also keep in mind that the concept of public domain is problematic
across international copyright law. All nations do not allow an
author to abstain their copyright; I believe that's the case here
in Europe for example.
I talked to a specialist. Sure I can abstain my copyright,
but
you are right - I am allowed to change my mind afterwords so
anyone who uses it without a license faces a risk that I may
change my mind. That is no good, seems I have to change my mind...
For maximum freedom I like to use the MIT license:
http://opensource.org/licenses/MIT
I understand the only requirement to be that copyright notices and
the license itself are also copied, when copying the source code.
OK. Seems to
solve all the problems, the cruicial thing is "substantial"
here: "shall be included in all copies or substantial portions of
the Software." It will be ok for anyone to take blocks from the dsp
code and add into proprietary code without adding the license text.
I do not think anyone would be interested in substantial portions
of Linrad for other projects. My programming style is far from
modern...
The e4k tuner
works very well, actually it is
very competitive when compared to the FUNcube Pro dongle,
but only with a modified library.
http://www.sm5bsz.com/linuxdsp/hware/funcube/funcube.htm
I urge you to work with the rtl-sdr maintainers to find how your
improvements can be reworked so that they are included in rtl-sdr.
It is a waste of everyone's time that you keep some local changes. Like authors of closed software you are circumventing
the intent of
the rtl-sdr authors, but that is of course your prerogative.
I actually find this
hard to understand. What do you mean that
their "intent" is?
To make your software unproblematic for others to use
I urge you to
choose a permissive license that you like, in the list of popular
approved open source licenses. Here's the list:
http://opensource.org/licenses/category
MIT is IMO the shortest and simplest of them. That's why I like it a
lot for maximum freedom software.
Fine. It seems to do exactly what I want:-) Once
I have given a
license I can not change my mind. Or at least I will not easily
be able to hurt someone who used it:-)
Regards
Leif / SM5BSZ
4230
days inactive
4235
days old
12 comments
6 participants
participants (6)
-
Adam Nielsen -
Leif Asbrink -
Peter Stuge -
Scott Cutler -
Simeon Miteff -
Sylvain Munaut