Hello
its great idea !
I think the next step (small for man big form mankind) should be decoding
(based on rtl_fm) APRS messages and putting into APRS-IS Servers !
with regards
Pawel, SQ7MRU
http://sq7mru.blogspot.com/
> Hi,
>
> The grab connection doesn't work :(
>
> 73, Murat TA1DB
If you're running a recent version of Linux, it will load DVB drivers
so you can watch TV with the device. You'll have to unload these to
make the device available for use:
sudo rmmod dvb_usb_rtl28xxu rtl2832 e4000
(assuming an e4000 device, not sure what module to unload for other
tuners, lsmod will tell you.)
Cheers,
Adam.
Hi.
Device removal detection code in _libusb_callback in librtlsdr.c may be
buggy. Every time we get any status other than LIBUSB_TRANSFER_COMPLETED
(including LIBUSB_TRANSFER_ERROR) the code doesn't resubmit current
buffer, and we get the real number of working buffers decreased by one.
If that number goes down to 0, rtlsdr_read_async() will hang.
Linux version tries to control it by counting the number of
LIBUSB_TRANSFER_ERROR buffers that came in row in dev->xfer_errors. But
if we already have _one_ failed buffer during the whole transfer up to
the moment, that counter will never reach dev->xfer_buf_num.
So it seems more straightforward to 1. count the failed buffers and
rtlsdr_cancel_async() when it reaches 0 or some sensible threshold, and
2. maybe resubmit some kinds of the failed buffers other than
LIBUSB_TRANSFER_COMPLETED, if it makes sense. I am not a libusb guru and
it's not well documented in this part, so I am not sure about my second
point.
Hoping some librtlsdr developers will appear on this list.
--
GPG fp: 6DFA 1186 7576 DE60 6CCB EB39 AD81 1733 EEBB 970A
Hi.
I noticed there is a 1 second delay in librtlsdr between calling
rtlsdr_cancel_async and releasing from rtlsdr_read_async. I'm writing a
radio scanner and this delay limits scanning speed considerably. I
tracked the delay down to this piece of code in librtlsdr.c:
while (RTLSDR_INACTIVE != dev->async_status) {
r = libusb_handle_events_timeout(dev->ctx, &tv);
[...]
if (RTLSDR_CANCELING == dev->async_status) {
next_status = RTLSDR_INACTIVE;
[...]
if (dev->dev_lost || RTLSDR_INACTIVE == next_status) {
>>>> libusb_handle_events_timeout(dev->ctx, &tv);
break;
}
The marked line is almost always(?) invoked when all the events are
already processed, hence it blocks for tv = 1 second. In fact I don't
understand what this `if' is supposed to do at all. I tried to modify
this line by changing the delay to 0 making it a non-blocking call
(leaving the timeout of 1 sec for the former
libusb_handle_events_timeout call). This worked with my project and the
1 second delay disappeared. So, I suppose, it's better to either a)
remove the whole `if' or b) make the latter libusb_handle_events_timeout
non-blocking as I did. I checked that b) works for me, and didn't test
a) yet.
The question is: what that `if (dev->dev_lost ...' is supposed to do?
And the two possible fixes for 1 second delay bug depending on the
answer are (diffs):
===
1630a1631
> struct timeval tv_nb = { 0, 0 };
1696c1697
< libusb_handle_events_timeout(dev->ctx, &tv);
---
> libusb_handle_events_timeout(dev->ctx, &tv_nb);
===
===
1694,1698d1693
<
< if (dev->dev_lost || RTLSDR_INACTIVE == next_status) {
< libusb_handle_events_timeout(dev->ctx, &tv);
< break;
< }
===
--
GPG fp: 6DFA 1186 7576 DE60 6CCB EB39 AD81 1733 EEBB 970A
Hi All,
After more than 2 weeks of endless trials to build, install and run
gr-osmosdr and/or gr-baz in Windows 7 to have an RTL2832 source in GNU Radio
- GRC without success I really wander if anybody exists and running these
programs under Windows?
Do you know anybody who succeeded to build and install gr-osmosdr and/or
gr-baz in Windows?
Regards,
Mu
