stu at spacehopper.org
Sat Apr 20 09:51:33 UTC 2013
On 2013/04/19 20:59, Alan Corey wrote:
> > I've just got hold of a card and looking into this.
> Do you mean a dongle? I got one of the $20 ones, which works pretty
> well in Windows with SDR# and RTL1090, so I bought a second one.
> > By specification, pthread_mutex_unlock() has undefined behaviour when
> > unlocking a mutex which is already unlocked.
> I wondered about that. If it wasn't either locking something already
> locked our unlocking something already unlocked. I stuck a bunch of
> extra printfs in the code and was trying to keep track of what it was
> doing. It works under Linux, but that's like saying a web page works
> fine in IE. Too sloppy to do otherwise.
Linux doesn't have this strict checking, it was specifically added to
try to flush out bugs in programs using mutexes.
> I wonder if the not stopping is because the low level acquisition,
> possibly a different thread, isn't getting stopped.
I've talked to another developer and we don't have good support for
usb transfer with asynchronous events yet, somebody is already looking
at this though. So for this side of things, it probably makes sense
to wait until that's available as this is likely to be the main
problem. (this is separate to the strict mutex checks mentioned above).
However I've just tried a few things in synchronous mode (rtl_test -S,
rtl_sdr -S, and RTLSDR-Scanner which uses sync mode anyway) and those
*do* seem to work.
> > Info: This tool will continuously read from the device, and report if
> > samples get lost. If you observe no further output, everything is
> I seem to always have samples getting lost, no matter what I do I
> think it's also supposed to give you a ppm adjustment figure, but I
> worked out mine from tuning in a few stations and seeing how far off
> frequency they were (with SDR#). One dongle is off 102 ppm, the other
> 62 ppm.
> I forgot to mention it, but rtl_sdr (the simplest one) also doesn't
> work. I was looking at trying to adapt them to use the Gnu pth
I think Pth won't help things on OpenBSD versions which already use
kernel threads (5.2+), and unlikely to have helped earlier versions
with userland threads either, the problem with userland thread
implementations is how file descriptor blocking is handled.
> > Notably the two programs which do seem to work correctly are
> > and rtl_tcp (at least I get some data from rtl_tcp but don't have
> > anything setup to use it yet) - notably these two do *not* use
> > rtlsdr_read_sync i.e. bulk transfers.
> There's a scanning client for rtl_tcp somebody wrote, but they did it
> in Python. It has one dependency that seems badly packaged. I don't
> have it working yet. I was thinking of writing a command line scanner
> in C that has hopefully no dependencies.
> Are you sure your rtl_tcp is actually working? Mine stops after a
> while. You could test it by running SDR# on a Windows machine and
> having the source of that be the rtl_tcp on an OpenBSD box, just enter
> the IP address and port. I think it's a lot of network load for even
> 100baseTX though.
Can't test these; I can only run Windows in VM (SDR# is broken if you
have no audio device) or by dual booting my laptop (in which case
I can't use rtl_tcp on OpenBSD as a source).
> There are also Gnuradio sources that can work from rtl_tcp.
working on this ;)
More information about the osmocom-sdr