alancorey at yahoo.com
Sat Apr 20 03:59:34 UTC 2013
> 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.
> Currently OpenBSD's "undefined behaviour" in this case is to
> abort(), which has helped debug problems with some threaded programs.
> You can change this behaviour by hacking librthread/rthread_sync.c:218
> and building/installing new librthread, this gets rid of the crash but
> does not make things work properly; like rtl_test, rtl_fm doesn't stop
> when you ^C. I don't get any output from rtl_fm instead I get high
> system cpu usage. I suspect this is some issue (quite possibly kernel
> driver) with bulk transfers.
I wonder if the not stopping is because the low level acquisition, possibly a different thread, isn't getting stopped.
> 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.
> 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. There are also Gnuradio sources that can work from rtl_tcp.
> OpenBSD isn't the only system which has the realtime functions
> in libc; this might be more generally applicable but note I have
> not tested it on a system which *does* have librt.
I could in principle do that. I can boot this box into an old Debian and try that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the osmocom-sdr