This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
Stuart Henderson stu at spacehopper.orgOn 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 ;)