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.
Yes..
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
fine.
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
threads.
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
rtl_eeprom
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 ;)