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/.
Alan Corey alancorey at yahoo.com> 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 > immediately > 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. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130419/f1011fd7/attachment.htm>