<html><body><div style="color:; background-color:; font-family:arial, helvetica, sans-serif;font-size:13px">> I've just got hold of a card and looking into this.<br><div><div><br>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.<br><br>> <br>> By specification, pthread_mutex_unlock() has undefined behaviour when<br>> unlocking a mutex which is already unlocked.<br><br>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.<br><br>> <br>> Currently OpenBSD's "undefined behaviour" in this case is to <br>> immediately<br>> abort(), which has helped debug problems with
some threaded programs.<br>> <br>> You can change this behaviour by hacking librthread/rthread_sync.c:218<br>> and building/installing new librthread, this gets rid of the crash but<br>> does not make things work properly; like rtl_test, rtl_fm doesn't stop<br>> when you ^C. I don't get any output from rtl_fm instead I get high<br>> system cpu usage. I suspect this is some issue (quite possibly kernel<br>> driver) with bulk transfers.<br><br>I wonder if the not stopping is because the low level acquisition, possibly a different thread, isn't getting stopped.<br><br>> Info: This tool will continuously read from the device, and report if<br>> samples get lost. If you observe no further output, everything is fine.<br><br>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.<br><br>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.<br><br>> Notably the two programs which do seem to work correctly are rtl_eeprom<br>> and rtl_tcp (at least I get some data from rtl_tcp but don't have<br>> anything setup to use it yet) - notably these two do *not* use<br>> rtlsdr_read_sync i.e. bulk transfers.<br><br>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.<br><br>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.<br><br>> <br>> OpenBSD isn't the only system which has the realtime functions<br>> in libc; this might be more generally applicable but note I have<br>> not tested it on a system which *does* have librt.<br><br>I could in principle do that. I can boot this box into an old Debian and try that.<br><br> Alan<br></div> </div> </div></body></html>