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
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
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.
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.
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.
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.
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.
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.
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
"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.
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.
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.
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.
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.
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
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
Hello Peter,
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. 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.
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
participants (6)
-
Adam Nielsen -
Leif Asbrink -
Peter Stuge -
Scott Cutler -
Simeon Miteff -
Sylvain Munaut