January 2022 - osmocom-sdr - lists.osmocom.org

OsmoDevCon 2022 ?

by Harald Welte

Dear fellow Osmocom developers, as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021, trying to compensate it at least to some extent with our OsmoDevCall every two weeks. The COVID-19 pandemic is far from over, and we don't know what the upcoming winter season will bring. Nevertheless, I think it would be a good idea to start a discussion of whether we should plan for an OsmoDevCon in 2022. I personally would say let's plan for the usual late April 2022 time frame, and if the pandemic situation deteriorates, we can still cancel it with something like one month lead time. I would also personally suggest to limit attendance to people who are fully vaccinated, and in addition do a self-test for all participants every morning. In terms of venue, we might also consider to move to a venue that allows better ventilation. Irrespective of the above we can also bring the air filters from the sysmocom office. So with that as an input statement, I would like to hear your opinion on the above proposals. Who would want to attend? Any complaints against the "vaccinated only plus daily self-tests in the morning" approach? Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 1 month

2
4
0 0

[PATCH] call libsub_intertrupt_event_handler in rtlsdr_cancel_async

by Jasper

Please find below a patch as per suggestion of Martin Ling: call libusb_interrupt_event_handler in rtlsdr_cancel_async to trigger the event loop handler to look at the async_cancel variable. (https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/thr…) I have tested timings on a windows 11 machine with and without the patch when running a async transfer at two different sampling rates: sample rate with without theory 1536K 0 - 2 ms 0 - 84 ms 85 ms 288K 0 - 4 ms 0 - 457 ms 455 ms The table shows the range of timings to cancel the async transfer as measured over a couple of runs. The "theory" column shows the theoretical time to complete one transfer at the particular sampling rate (i.e. driven by the size of a transfer buffer). And indeed, on some machines it appears that cancelling the async transfer, if unlucky, can take as much time as waiting for a full transfer to complete. The call to libsub_intertrupt_event_handler fixes that. For large transfer buffers and/or low sample rates this can make a difference. Thanks to Martin for sharing the insight. Jasper Author: jvde.github <jvde.github(a)gmail.com> Date: Wed Jan 26 19:00:55 2022 +0100 call interrupt_event_handler in cancel_async diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 67e30c4..b949692 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1948,6 +1948,9 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev) if (RTLSDR_RUNNING == dev->async_status) { dev->async_status = RTLSDR_CANCELING; dev->async_cancel = 1; + + libusb_interrupt_event_handler(dev->ctx); + return 0; }

2 years, 2 months

1
0
0 0

[PATCH] count number of open transfers and ensure zero open transfers before freeing memory

by Jasper

Hi all, As per discussion with Martin Ling on this mailing list, please find below a proposed patch that simplifies the async_read, keeps track of open tranfers and checks for zero open transfers before closing to avoid unidentified behaviour at close. Thanks, Jasper commit 4b06ae321e91296f13355a0715e9a961b4f57e45 Author: jvde.github <jvde.github(a)gmail.com> Date: Mon Jan 24 20:15:34 2022 +0100 count live transfers before close diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 096abae..67e30c4 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -119,6 +119,7 @@ struct rtlsdr_dev { int dev_lost; int driver_active; unsigned int xfer_errors; + int live_transfers; }; void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val); @@ -1695,11 +1696,15 @@ static void LIBUSB_CALL _libusb_callback(struct libusb_transfer *xfer) { rtlsdr_dev_t *dev = (rtlsdr_dev_t *)xfer->user_data; + dev->live_transfers --; + if (LIBUSB_TRANSFER_COMPLETED == xfer->status) { if (dev->cb) dev->cb(xfer->buffer, xfer->actual_length, dev->cb_ctx); - libusb_submit_transfer(xfer); /* resubmit transfer */ + if(!dev->async_cancel) + if( libusb_submit_transfer(xfer) == 0) /* resubmit transfer */ + dev->live_transfers++; dev->xfer_errors = 0; } else if (LIBUSB_TRANSFER_CANCELLED != xfer->status) { #ifndef _WIN32 @@ -1847,9 +1852,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, { unsigned int i; int r = 0; + int ret = 0; struct timeval tv = { 1, 0 }; - struct timeval zerotv = { 0, 0 }; - enum rtlsdr_async_status next_status = RTLSDR_INACTIVE; + struct timeval canceltv = { 0, 50 }; if (!dev) return -1; @@ -1863,6 +1868,7 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, dev->cb = cb; dev->cb_ctx = ctx; + if (buf_num > 0) dev->xfer_buf_num = buf_num; else @@ -1875,6 +1881,8 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, _rtlsdr_alloc_async_buffers(dev); + dev->live_transfers = 0; + for(i = 0; i < dev->xfer_buf_num; ++i) { libusb_fill_bulk_transfer(dev->xfer[i], dev->devh, @@ -1894,64 +1902,41 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, "echo 0 > /sys/module/usbcore" "/parameters/usbfs_memory_mb\n", i); dev->async_status = RTLSDR_CANCELING; + ret = -3; break; } + else + dev->live_transfers++; } - while (RTLSDR_INACTIVE != dev->async_status) { + while (RTLSDR_RUNNING == dev->async_status) { r = libusb_handle_events_timeout_completed(dev->ctx, &tv, - &dev->async_cancel); + &dev->async_cancel); if (r < 0) { /*fprintf(stderr, "handle_events returned: %d\n", r);*/ if (r == LIBUSB_ERROR_INTERRUPTED) /* stray signal */ continue; - break; + rtlsdr_cancel_async(dev); + ret = -4; } + } - if (RTLSDR_CANCELING == dev->async_status) { - next_status = RTLSDR_INACTIVE; + if (!dev->xfer) return -5; - if (!dev->xfer) - break; + for(i = 0; i < dev->xfer_buf_num; ++i) + if (dev->xfer[i]) + libusb_cancel_transfer(dev->xfer[i]); - for(i = 0; i < dev->xfer_buf_num; ++i) { - if (!dev->xfer[i]) - continue; + for (i = 0; i < dev->xfer_buf_num && dev->live_transfers > 0; ++i) + libusb_handle_events_timeout_completed(dev->ctx, &canceltv, NULL); - if (LIBUSB_TRANSFER_CANCELLED != - dev->xfer[i]->status) { - r = libusb_cancel_transfer(dev->xfer[i]); - /* handle events after canceling - * to allow transfer status to - * propagate */ -#ifdef _WIN32 - Sleep(1); -#endif - libusb_handle_events_timeout_completed(dev->ctx, - &zerotv, NULL); - if (r < 0) - continue; - - next_status = RTLSDR_CANCELING; - } - } - - if (dev->dev_lost || RTLSDR_INACTIVE == next_status) { - /* handle any events that still need to - * be handled before exiting after we - * just cancelled all transfers */ - libusb_handle_events_timeout_completed(dev->ctx, - &zerotv, NULL); - break; - } - } - } + if(dev->live_transfers > 0) return -6; _rtlsdr_free_async_buffers(dev); - dev->async_status = next_status; + dev->async_status = RTLSDR_INACTIVE; - return r; + return ret; } int rtlsdr_cancel_async(rtlsdr_dev_t *dev)

2 years, 2 months

1
0
0 0

[PATCH] librtlsdr: force wait state after lib_cancel_transfer to avoid crash on close in windows

by Jasper van den Eshof

Good day! I was struggling with an occasional crash of the rtl-sdr tools on windows when closing the device after pressing CTRL-C. Both with the versions as provided with VCPKG and when directly compiling the latest version in MSVC (with latest of libusb). It is a bit difficult to spot a crash at close as usually it is silent but you can see it running it from MSVC or in a debugger. It does not happen always but frequent enough. Also, consider this example for the binary versions from Jan 2 (https://ftp.osmocom.org/binaries/windows/rtl-sdr/): C:\>rtl_adsb.exe Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner .... Signal caught, exiting! User cancel, exiting... C:\>echo %ERRORLEVEL% -1073741819 After investigation of the libusb logs and experimentation I think this crash can be avoided by 1) defining zerotv in rtlsdr_read_async as 1 ms instead of zero (see libusb/libusb#1043) or 2) include a short call to Sleep to allow async operations to finish. Please find below a patch for the latter fix for your consideration. More information, here: https://github.com/osmocom/rtl-sdr/pull/18 and here: https://github.com/libusb/libusb/issues/1043 Thanks for your great work on the rtlsdr library and kind regards. Author: jvde.github <jvde.github(a)gmail.com> Date: Sat Jan 8 13:30:34 2022 +0100 force wait state after cancel of usb transfer and before handling usb events diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 0146298..2682d77 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1930,6 +1930,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, /* handle events after canceling * to allow transfer status to * propagate */ +#ifdef _WIN32 + Sleep(1); +#endif libusb_handle_events_timeout_completed(dev->ctx, &zerotv, NULL); if (r < 0)

2 years, 2 months

4
6
0 0

[PATCH] fix build issue on macOS by adding libusb shared lib directory to search path

by Jasper

Hi all, on some systems building librtlsdr can fail when libusb-1.0 is not installed in the standard library locations (e.g. macOS with libusb installed via homebrew can have the shared library in /usr/local/Cellar/libusb/1.0.24/lib). The below patch includes LIBUSB_LIBRARY_DIRS in the search path for the linker to correct this issue. For your kind consideration. Thanks, Jasper Author: jvde.github <jvde.github(a)gmail.com> Date: Mon Jan 24 19:21:44 2022 +0100 fix build for macOS diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index 7b47309..3b8060b 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -21,6 +21,7 @@ add_library(rtlsdr SHARED librtlsdr.c tuner_e4k.c tuner_fc0012.c tuner_fc0013.c tuner_fc2580.c tuner_r82xx.c) target_link_libraries(rtlsdr ${LIBUSB_LIBRARIES} ${THREADS_PTHREADS_LIBRARY}) +target_link_directories(rtlsdr PUBLIC ${LIBUSB_LIBRARY_DIRS}) target_include_directories(rtlsdr PUBLIC $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include> $<INSTALL_INTERFACE:include> # <prefix>/include

2 years, 2 months

1
0
0 0

[PATCH] rfspace: Add PPM correction

by argilo＠gmail.com

From: Clayton Smith <argilo(a)gmail.com> This patch was originally written by Alexandru Csete and posted at https://github.com/csete/gr-osmosdr-gqrx/commit/d66df300. The only change I made was to rename the _freq_corr_ppm variable to _freq_corr, since many other devices use that name. This patch used to be included in Gqrx releases, so it should work correctly. --- lib/rfspace/rfspace_source_c.cc | 17 +++++++++++++---- lib/rfspace/rfspace_source_c.h | 2 ++ 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/lib/rfspace/rfspace_source_c.cc b/lib/rfspace/rfspace_source_c.cc index 314dfc732d..113588a5d4 100644 --- a/lib/rfspace/rfspace_source_c.cc +++ b/lib/rfspace/rfspace_source_c.cc @@ -103,6 +103,7 @@ rfspace_source_c::rfspace_source_c (const std::string &args) _nchan(1), _sample_rate(NAN), _bandwidth(0.0f), + _freq_corr(0.0), _fifo(NULL) { std::string host = ""; @@ -446,6 +447,8 @@ rfspace_source_c::rfspace_source_c (const std::string &args) _thread = gr::thread::thread( boost::bind(&rfspace_source_c::tcp_keepalive_task, this) ); } + _center_freq = get_center_freq(); + #if 0 std::cerr << "sample_rates: " << get_sample_rates().to_pp_string() << std::endl; std::cerr << "sample rate: " << (uint32_t)get_sample_rate() << std::endl; @@ -600,7 +603,7 @@ static size_t read_bytes( int fd, char *data, size_t size, bool &run ) int nread = read( fd, &data[nbytes], 1 ); if ( nread == 0 ) - continue; + continue; if ( nread < 0 ) break; @@ -1378,7 +1381,10 @@ osmosdr::freq_range_t rfspace_source_c::get_freq_range( size_t chan ) double rfspace_source_c::set_center_freq( double freq, size_t chan ) { - uint32_t u32_freq = freq; + uint32_t u32_freq; + + u32_freq = freq * (1.0 + _freq_corr * 0.000001); + _center_freq = freq; /* SDR-IQ 5.2.2 Receiver Frequency */ /* SDR-IP 4.2.2 Receiver Frequency */ @@ -1395,7 +1401,7 @@ double rfspace_source_c::set_center_freq( double freq, size_t chan ) transaction( tune, sizeof(tune) ); - return get_center_freq( chan ); + return _center_freq; } double rfspace_source_c::get_center_freq( size_t chan ) @@ -1423,12 +1429,15 @@ double rfspace_source_c::get_center_freq( size_t chan ) double rfspace_source_c::set_freq_corr( double ppm, size_t chan ) { + _freq_corr = ppm; + set_center_freq( _center_freq, chan ); + return get_freq_corr( chan ); } double rfspace_source_c::get_freq_corr( size_t chan ) { - return 0; + return _freq_corr; } std::vector<std::string> rfspace_source_c::get_gain_names( size_t chan ) diff --git a/lib/rfspace/rfspace_source_c.h b/lib/rfspace/rfspace_source_c.h index 996f47b392..42bb6de6ac 100644 --- a/lib/rfspace/rfspace_source_c.h +++ b/lib/rfspace/rfspace_source_c.h @@ -145,6 +145,8 @@ private: /* members */ size_t _nchan; double _sample_rate; double _bandwidth; + double _center_freq; + double _freq_corr; gr::thread::thread _thread; bool _run_usb_read_task; -- 2.25.1

2 years, 2 months

1
0
0 0

[PATCH] Stop applying workaround for libusb < 1.0.9

by argilo＠gmail.com

From: Clayton Smith <argilo(a)gmail.com> Librtlsdr has a workaround for libusb versions that lack libusb_handle_events_timeout_completed, which was added in version 1.0.9 (released 2012-04-02). The workaround is always applied unless the HAVE_LIBUSB_HANDLE_EVENTS_TIMEOUT_COMPLETED macro is set, but the cmake code that sets this macro was removed in 849f8efca42b659bf7e8fe17156ee0aa67b47233. As a result, the workaround is now always applied. This results in an extra 1-second delay whenever a GNU Radio flowgraph containing an RTL-SDR block is stopped, which makes operations like switching between demodulators in Gqrx annoyingly slow. To solve this problem, I've simply removed the workaround, as it should no longer be needed. I wonder if perhaps the workaround recently applied in 2659e2df31e592d74d6dd264a4f5ce242c6369c8 might stem from the same bug. --- src/librtlsdr.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 2682d77ec2..096abaeffc 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -39,12 +39,6 @@ #define LIBUSB_CALL #endif -/* libusb < 1.0.9 doesn't have libusb_handle_events_timeout_completed */ -#ifndef HAVE_LIBUSB_HANDLE_EVENTS_TIMEOUT_COMPLETED -#define libusb_handle_events_timeout_completed(ctx, tv, c) \ - libusb_handle_events_timeout(ctx, tv) -#endif - /* two raised to the power of n */ #define TWO_POW(n) ((double)(1ULL<<(n))) -- 2.25.1

2 years, 3 months

2
1
0 0

[PATCH] Show readable error when hackrf start/stop fails

by Martin Ling

Error codes from libhackrf are not very legible, and in the case of HACKRF_ERROR_LIBUSB, don't uniquely describe the cause of the error. Calling hackrf_error_name() provides a human-readable message, and in the case of libusb errors, identifies the actual cause rather than just indicating that the error came from libusb. This came up whilst trying to diagnose a libhackrf bug which showed up when using libhackrf, via gr-osmosdr, via gqrx: https://github.com/greatscottgadgets/hackrf/issues/883 --- lib/hackrf/hackrf_source_c.cc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc index 03ea3bd..2826924 100644 --- a/lib/hackrf/hackrf_source_c.cc +++ b/lib/hackrf/hackrf_source_c.cc @@ -170,7 +170,8 @@ bool hackrf_source_c::start() hackrf_common::start(); int ret = hackrf_start_rx( _dev.get(), _hackrf_rx_callback, (void *)this ); if ( ret != HACKRF_SUCCESS ) { - std::cerr << "Failed to start RX streaming (" << ret << ")" << std::endl; + const char *msg = hackrf_error_name( (enum hackrf_error) ret ); + std::cerr << "Failed to start RX streaming (" << ret << ": " << msg << ")" << std::endl; return false; } return true; @@ -184,7 +185,8 @@ bool hackrf_source_c::stop() hackrf_common::stop(); int ret = hackrf_stop_rx( _dev.get() ); if ( ret != HACKRF_SUCCESS ) { - std::cerr << "Failed to stop RX streaming (" << ret << ")" << std::endl; + const char *msg = hackrf_error_name( (enum hackrf_error) ret ); + std::cerr << "Failed to stop RX streaming (" << ret << ": " << msg << ")" << std::endl; return false; } return true; -- 2.30.2

2 years, 3 months

1
0
0 0

lists.osmocom.org migrated to mailman3

by Harald Welte

Dear Osmocom community, today our mailing list server lists.osmocom.org has finally been migrated from mailman2-on-freebsd to mailman3-on-linux. This also included a variety of changes to DNS. I'll spare you the details, but everything _should_ be up and running now. * The List-Id headers should not have changed. * all list subscriptions + user accounts have been converted. * old 'static html' archives are still available (read only) at URLs like https://lists.osmocom.org/pipermail/baseband-devel/ * old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel are redirected to their respective modern counterparts In case you notice any mailing list related problem, please don't hesitate to contact me. Happy hacking, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 3 months

1
0
0 0

None

by None

o decode the VOR's morse code station ID. From that, I will have a shor= t list of VORs that I can currently receive. From those, if the geometry is= appropriate (I know the VORs positions from a database) I can calculate a = position.<u></u><u></u></p> </div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla= ss=3D"MsoNormal">The software then just round-robin tunes the VORs in range= and continually tries to calculate positions. If too many drop out, it ret= urns to the initial scan mode.<u></u><u></u></p> </div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla= ss=3D"MsoNormal">Not being able to receive this VOR or that VOR is not gene= rally a problem, but obviously, the more the better. With extra VORs I have= better options for choosing the closest ones or the ones with the best geo= metry.<u></u><u></u></p> </div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla= ss=3D"MsoNormal"><u></u> <u></u></p></div><div><p class=3D"MsoNormal">= This is actually quite difficult to test, because VORs can generally only b= e received line-of-sight -- which means in the air. I'm a private pilot= but I found that flying and noodling with a laptop is too much trouble. Fr= om my office window, on a high floor in Oakland, CA, I can receive one VOR = from the Oakland airport. And I have now discovered a ridge near my home wi= th a scenic overlook from which I can receive two.<u></u><u></u></p> </div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla= ss=3D"MsoNormal">I've tested the software enough to know that the initi= al scan function seems to work, and the morse decoding kind of works, but I= am not confident I'll get it to work very well. (One transmitter's= dit looks a lot like another's dah.) The nav signal decoding is simple= . (A 30 Hz AM modulated tone is phase compared with a 30 Hz tone FM modulat= ed at 9960 Hz. The phase obtained is the azimuth to the station.)<u></u><u>= </u></p> </div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla= ss=3D"MsoNormal"><u></u> <u></u></p></div><div><p class=3D"MsoNormal">= If I ever get this working, I looking forward to sharing it with the commun= ity. In the process of building this, I created a simple SDR toolkit of DSP= functions. It's like Gnuradio in concept, but 16b fixed-point, and has= no external dependencies, and C89, so is easier to build on weird and limi= ted platforms. It also has perl bindings. Compared to GR, it looks like the= work of a rank amateur just learning DSP, but I do like the concept of the= re being a GR-like library out there, lightweight and embedded-friendly.<u>= </u><u></u></p> </div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla= ss=3D"MsoNormal"><u></u> <u></u></p></div><div><p class=3D"MsoNormal">= Regards,<u></u><u></u></p></div><div><p class=3D"MsoNormal">Dave J<u></u><u= ></u></p></div> <div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u= > <u></u></p><div><p class=3D"MsoNormal">On Tue, Oct 22, 2013 at 3:06 = AM, jdow <<a href=3D"mailto:jdow@earthlink.net" target=3D"_blank">jdow@e= arthlink.net</a>> wrote:<u></u><u></u></p> <p class=3D"MsoNormal">He sent me two frequencies in private email. These w= ere in the FM<br>broadcast band (in the US). He probably needs to notch the= m out<br>in order to get adequate response.<br><br>As for wanting narrow ba= ndwidth - I am not quite sure why he thinks<br> that is a benefit. I use a large FFT (about 10 Hz per bin) and use<br>the z= oom control to see fine detail. (Different FFT settings suite<br>different = uses. This one seems to be a good compromise with my two<br>needs. I'm = too lazy to change it.)<br> <br>{^_^}<u></u><u></u></p><div><div><p class=3D"MsoNormal"><br><br><br>On = 2013/10/22 02:08, Sylvain Munaut wrote:<u></u><u></u></p><blockquote style= =3D"border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;m= argin-left:4.8pt;margin-right:0cm"> <p class=3D"MsoNormal">Effective filtering must occur between antenna and r= eceiver. All the<br>problems that a saturated preamp and ADC cause can&rsqu= o;t be repaired by<br>software. Never.<u></u><u></u></p></blockquote><p cla= ss=3D"MsoNormal" style=3D"margin-bottom:12.0pt"> <br>But his original problem is not with saturated preamps or ADC ... it&#3= 9;s<br>aliasing ... and that can be solved in the digital domain provided<b= r>fast enough ADC.<br><br>Cheers,<br><br>    Sylvain<br><br><u></= u><u></u></p> </div></div></div><p class=3D"MsoNormal"><u></u> <u></u></p></div></di= v></div></div></div><p class=3D"MsoNormal"><u></u> <u></u></p></div></= div></div></div></div></div></blockquote></div><br></div> --001a11346d7c0fd5fd04f20c4ef9--

2 years, 3 months

1
0
0 0

None

by None

receive. From those, if the geometry is appropriate (I know the VORs = positions from a database) I can calculate a = position.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>The software then just round-robin tunes the VORs in = range and continually tries to calculate positions. If too many drop = out, it returns to the initial scan mode.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>Not being able to receive this VOR or that VOR is not = generally a problem, but obviously, the more the better. With extra VORs = I have better options for choosing the closest ones or the ones with the = best geometry.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>This is actually quite difficult to test, because VORs = can generally only be received line-of-sight -- which means in the air. = I'm a private pilot but I found that flying and noodling with a laptop = is too much trouble. From my office window, on a high floor in Oakland, = CA, I can receive one VOR from the Oakland airport. And I have now = discovered a ridge near my home with a scenic overlook from which I can = receive two.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>I've tested the software enough to know that the = initial scan function seems to work, and the morse decoding kind of = works, but I am not confident I'll get it to work very well. (One = transmitter's dit looks a lot like another's dah.) The nav signal = decoding is simple. (A 30 Hz AM modulated tone is phase compared with a = 30 Hz tone FM modulated at 9960 Hz. The phase obtained is the azimuth to = the station.)<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>If I ever get this working, I looking forward to = sharing it with the community. In the process of building this, I = created a simple SDR toolkit of DSP functions. It's like Gnuradio in = concept, but 16b fixed-point, and has no external dependencies, and C89, = so is easier to build on weird and limited platforms. It also has perl = bindings. Compared to GR, it looks like the work of a rank amateur just = learning DSP, but I do like the concept of there being a GR-like library = out there, lightweight and = embedded-friendly.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>Regards,<o:p></o:p></p></div><div><p = class=3DMsoNormal>Dave J<o:p></o:p></p></div><div><div><div><p = class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><o:p> </o:p></p><div><p = class=3DMsoNormal>On Tue, Oct 22, 2013 at 3:06 AM, jdow <<a = href=3D"mailto:jdow@earthlink.net" = target=3D"_blank">jdow(a)earthlink.net</a>> wrote:<o:p></o:p></p><p = class=3DMsoNormal>He sent me two frequencies in private email. These = were in the FM<br>broadcast band (in the US). He probably needs to notch = them out<br>in order to get adequate response.<br><br>As for wanting = narrow bandwidth - I am not quite sure why he thinks<br>that is a = benefit. I use a large FFT (about 10 Hz per bin) and use<br>the zoom = control to see fine detail. (Different FFT settings suite<br>different = uses. This one seems to be a good compromise with my two<br>needs. I'm = too lazy to change it.)<br><br>{^_^}<o:p></o:p></p><div><div><p = class=3DMsoNormal><br><br><br>On 2013/10/22 02:08, Sylvain Munaut = wrote:<o:p></o:p></p><blockquote style=3D'border:none;border-left:solid = #CCCCCC 1.0pt;padding:0cm 0cm 0cm = 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=3DMsoNormal>Effective = filtering must occur between antenna and receiver. All the<br>problems = that a saturated preamp and ADC cause can’t be repaired = by<br>software. Never.<o:p></o:p></p></blockquote><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><br>But his original problem is not with = saturated preamps or ADC ... it's<br>aliasing ... and that can be solved = in the digital domain provided<br>fast enough = ADC.<br><br>Cheers,<br><br>    = Sylvain<br><br><o:p></o:p></p></div></div></div><p = class=3DMsoNormal><o:p> </o:p></p></div></div></div></div></div><p = class=3DMsoNormal><o:p> </o:p></p></div></div></div></body></html> ------=_NextPart_000_0073_01CF2656.CE93A820--

2 years, 3 months

1
0
0 0

None

by None

direct sampling mode, only from signal processing view): If you already have analog signal as separated I&Q in baseband (so called zero-IF), and do I&Q two channel A/D converter, you can processing signal, highest frequency of which is less than sampling rate, without aliasing. That means, for example, you can processing signal, frequency of which is up to 28.8MHz, when sampling rate is 28.8MHz. (There is an implicit assumption that your zero-IF analog channel is ideal) If you have to do sampling on a single channel analog signal( not zero-IF, I&Q not separated by analog circuit, I&Q are still mixed together by an IF carrier/frequency), you have to ensure the highest frequency of signal less than half of sampling rate to ensure no aliasing. On Wed, Jan 29, 2014 at 7:50 AM, Richard Koch <n1gp(a)hotmail.com> wrote: > Can someone clarify what the frequency range is in Direct sampling mode. > > The rtl2832u dongle has a 28.8Mhz osc. > > So can the dongle in "direct sampling mode" (with appropriate antenna > connection) > receive > 14.4 Mhz (Nyquist) ? > > Googling I find conflicting advice. > > I've been able to receive > 14.4 Mhz in direct mode, but I'm not sure if > that's due to some non-optimal method...? > > I'm guessing it can because the tuner chip provides both I & Q data > therefore > allowing the double rate...? > > > > --047d7bf15fc8eed8c404f1137e92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>From the point of view of signal processing (not= very clear about your direct sampling mode, only from signal processing vi= ew):<br></div>If you already have analog signal as separated I&Q in bas= eband (so called zero-IF), and do I&Q two channel A/D converter, you ca= n processing signal, highest frequency of which is less than sampling rate,= without aliasing.<br> </div><div>That means, for example, you can processing signal, frequency of= which is up to 28.8MHz, when sampling rate is 28.8MHz. (There is an implic= it assumption that your zero-IF analog channel is ideal)<br><br></div>If yo= u have to do sampling on a single channel analog signal( not zero-IF, I&amp= ;Q not separated by analog circuit, I&Q are still mixed together by an = IF carrier/frequency), you have to ensure the highest frequency of signal l= ess than half of sampling rate to ensure no aliasing.<br> <br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On = Wed, Jan 29, 2014 at 7:50 AM, Richard Koch <span dir=3D"ltr"><<a href=3D= "mailto:n1gp@hotmail.com" target=3D"_blank">n1gp(a)hotmail.com</a>></span>= wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div><div dir=3D"ltr">Can someone clarify what the frequency range is in Di= rect sampling mode.<br><br>The rtl2832u dongle has a 28.8Mhz osc. <br><br>S= o can the dongle in "direct sampling mode" (with appropriate ante= nna connection)<br> receive > 14.4 Mhz (Nyquist) ?<br><br>Googling I find conflicting advice= .<br><br>I've been able to receive > 14.4 Mhz in direct mode, but I&= #39;m not sure if<br>that's due to some non-optimal method...?<br><br> I'm guessing it can because the tuner chip provides both I & Q data= therefore<br>allowing the double rate...?<br><br><br><br> </div= ></div> </blockquote></div><br></div> --047d7bf15fc8eed8c404f1137e92--

2 years, 3 months

1
0
0 0

None

by None

VOR from the Oakland airport. And I have now discovered a ridge near my home with a scenic overlook from which I can receive two. I've tested the software enough to know that the initial scan function seems to work, and the morse decoding kind of works, but I am not confident I'll get it to work very well. (One transmitter's dit looks a lot like another's dah.) The nav signal decoding is simple. (A 30 Hz AM modulated tone is phase compared with a 30 Hz tone FM modulated at 9960 Hz. The phase obtained is the azimuth to the station.) If I ever get this working, I looking forward to sharing it with the community. In the process of building this, I created a simple SDR toolkit of DSP functions. It's like Gnuradio in concept, but 16b fixed-point, and has no external dependencies, and C89, so is easier to build on weird and limited platforms. It also has perl bindings. Compared to GR, it looks like the work of a rank amateur just learning DSP, but I do like the concept of there being a GR-like library out there, lightweight and embedded-friendly. Regards, Dave J On Tue, Oct 22, 2013 at 3:06 AM, jdow <jdow(a)earthlink.net> wrote: > He sent me two frequencies in private email. These were in the FM > broadcast band (in the US). He probably needs to notch them out > in order to get adequate response. > > As for wanting narrow bandwidth - I am not quite sure why he thinks > that is a benefit. I use a large FFT (about 10 Hz per bin) and use > the zoom control to see fine detail. (Different FFT settings suite > different uses. This one seems to be a good compromise with my two > needs. I'm too lazy to change it.) > > {^_^} > > > > On 2013/10/22 02:08, Sylvain Munaut wrote: > >> Effective filtering must occur between antenna and receiver. All the >>> problems that a saturated preamp and ADC cause can=92t be repaired by >>> software. Never. >>> >> >> But his original problem is not with saturated preamps or ADC ... it's >> aliasing ... and that can be solved in the digital domain provided >> fast enough ADC. >> >> Cheers, >> >> Sylvain >> >> >> --089e01184768dfc65f04e955c0d5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I originally posted about 115.8 and 116.8 MHz, both square= in the VOR band of 108 to 117.95. I might have sent something else in a PM= , but if so it was a typo. :-) I am definitely only interested in the VOR b= and right now -- though, as you say, it is adjacent to commercial FM with i= ts high power.<div> <br></div><div>My application is simple in concept: A fully auomatic VOR-ba= sed positioning system, a fallback from GPS. I want to scan the entire VOR = band, looking for signals in the standard VOR format that can be demodulate= d. I do the initial scan with a fast sample rate and FFT, just looking for = peaks. From those, I examine the signals to see if it looks like a VOR sign= al. From that list, I will "park" on each signal long enough (~30= s) to decode the VOR's morse code station ID. From that, I will have a = short list of VORs that I can currently receive. From those, if the geometr= y is appropriate (I know the VORs positions from a database) I can calculat= e a position.</div> <div><br></div><div>The software then just round-robin tunes the VORs in ra= nge and continually tries to calculate positions. If too many drop out, it = returns to the initial scan mode.</div><div><br></div><div>Not being able t= o receive this VOR or that VOR is not generally a problem, but obviously, t= he more the better. With extra VORs I have better options for choosing the = closest ones or the ones with the best geometry.</div> <div><br></div><div><br></div><div>This is actually quite difficult to test= , because VORs can generally only be received line-of-sight -- which means = in the air. I'm a private pilot but I found that flying and noodling wi= th a laptop is too much trouble. From my office window, on a high floor in = Oakland, CA, I can receive one VOR from the Oakland airport. And I have now= discovered a ridge near my home with a scenic overlook from which I can re= ceive two.</div> <div><br></div><div>I've tested the software enough to know that the in= itial scan function seems to work, and the morse decoding kind of works, bu= t I am not confident I'll get it to work very well. (One transmitter&#3= 9;s dit looks a lot like another's dah.) The nav signal decoding is sim= ple. (A 30 Hz AM modulated tone is phase compared with a 30 Hz tone FM modu= lated at 9960 Hz. The phase obtained is the azimuth to the station.)</div> <div><br></div><div><br></div><div class=3D"gmail_extra">If I ever get this= working, I looking forward to sharing it with the community. In the proces= s of building this, I created a simple SDR toolkit of DSP functions. It&#39= ;s like Gnuradio in concept, but 16b fixed-point, and has no external depen= dencies, and C89, so is easier to build on weird and limited platforms. It = also has perl bindings. Compared to GR, it looks like the work of a rank am= ateur just learning DSP, but I do like the concept of there being a GR-like= library out there, lightweight and embedded-friendly.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><= div class=3D"gmail_extra">Regards,</div><div class=3D"gmail_extra">Dave J</= div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, O= ct 22, 2013 at 3:06 AM, jdow <span dir=3D"ltr"><<a href=3D"mailto:jdow@e= arthlink.net" target=3D"_blank">jdow(a)earthlink.net</a>></span> wrote:<br= > <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">He sent me two frequencies in private email.= These were in the FM<br> broadcast band (in the US). He probably needs to notch them out<br> in order to get adequate response.<br> <br> As for wanting narrow bandwidth - I am not quite sure why he thinks<br> that is a benefit. I use a large FFT (about 10 Hz per bin) and use<br> the zoom control to see fine detail. (Different FFT settings suite<br> different uses. This one seems to be a good compromise with my two<br> needs. I'm too lazy to change it.)<br> <br> {^_^}<div class=3D"HOEnZb"><div class=3D"h5"><br> <br> <br> On 2013/10/22 02:08, Sylvain Munaut wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Effective filtering must occur between antenna and receiver. All the<br> problems that a saturated preamp and ADC cause can=92t be repaired by<br> software. Never.<br> </blockquote> <br> But his original problem is not with saturated preamps or ADC ... it's<= br> aliasing ... and that can be solved in the digital domain provided<br> fast enough ADC.<br> <br> Cheers,<br> <br> =A0 =A0 Sylvain<br> <br> <br> </blockquote> </div></div></blockquote></div><br></div></div> --089e01184768dfc65f04e955c0d5--

2 years, 3 months

1
0
0 0

None

by None

it was a saturation issue in RF, it would show up no matter what the sample rate is. Also : - RF filter are often only band specific and not channel specific (because tunable RF filters to do channel selection would be prohibitively expensive) - IF filter (or BB filters for zero-if) are then used for channel selection. So in his case being two channel in the same band (and given the architecture of the dongles), the only saturation that IF filters would provide would be against ADC saturation and it's easy to check if this happens or not just looking at the time domain signal. Cheers, Sylvain

2 years, 3 months

1
0
0 0

None

by None

developer doesn't really know or care about corner cases and as a result it's possible for the GUI to show "green" when in fact there is actually a problem that could be detected. That said, if you've used zadig to install the driver then it should indeed work. > but I can confidently say, I've followed every instruction quite > precisely... I've tried installing the winusb stub for both > instance 0 and 1 What do you mean by instance here again? Sorry if you already mentioned that. If the device has multiple interfaces (a so-called composite device) it is important to install WinUSB for the actual device, and not for either of the two interfaces. > trying everything in both cases in the event that installing it on > the second instance is itself a problem. there's something quite > subtle wrong, given that sdrsharp works perfectly... I don't know how your .exe files were built and if they are using libusb or the hostile fork libusbx which clobbers the soname and uses the same API namespace, the latter driven by that same zadig/libwdi developer. I know the actual libusb very well and it would be interesting to see output from a debug build of my current working directory with libusb source. I've built a binary using the MS C compiler here: http://stuge.se/libusb-1.0.dll Try putting this in the same directory as the program and see if you still have the same problem. Even if the program was built using MinGW that DLL should work well. If yes, the output from the program would be interesting. Thanks //Peter

2 years, 3 months

1
0
0 0

None

by None

ioctl(5, USBDEVFS_CLAIMINTERFACE, 0x7fd063c4) = -1 ENOENT (No such file or directory) The kernel is saying that the interface doesn't exist. lsusb -v for this device run on the fritzbox would be interesting. //Peter

2 years, 3 months

1
0
0 0

None

by None

3.54 GHz. The actual mixer frequency sent to the IF stage is the VCO frequency divided by a number between 2 and 63 -- so the possible center frequency tuning range ends up being in the range of ~24 MHz to 1.77 GHz. However, I was wondering if it would be possible to use a MixDiv of 1 -- to run the mixer frequency directly on the VCO? Has anyone tried that, or would it fry the device somehow? Just wondering if the range could be extended (disregarding any sensitivity issues, of course). -- Per.

2 years, 3 months

1
0
0 0

None

by None

r feature of the device won't be of much use to me, but as for the FM, = I'm on the Ubuntu/Linux GNU platform, so I'm awaiting on the kindne= ss of strangers to perfect the kernel drivers enough to match the Windows k= it performance. But that's okay, because I'm learning a lot in the = process :)<br> <br><div class=3D"gmail_quote">On Mon, Aug 13, 2012 at 11:44 PM, Adam Niels= en <span dir=3D"ltr"><<a href=3D"mailto:a.nielsen@shikadi.net" target=3D= "_blank">a.nielsen(a)shikadi.net</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> so it is /designed/ for FM? =A0That's encouraging because mostly that i= s all I<div class=3D"im"><br> really need from it, only all my experiments so far have yielded only<br></= div> AM-quality sound, but it's good to hear because it means there's /h= ope/ and so<div class=3D"im"><br> I'll just keep hanging in there until an FM recipe surfaces :)<br> </div></blockquote> <br> Yes, because the dongles provide digital TV (via hardware) and as an extra = selling point, analogue FM radio (provided via the SDR.)<br> <br> I don't know what platform you're on or what your goals are, but I = hear the SDR# program for Windows offers excellent stereo FM support, as it= 's one of the few programs that can deal with the ~120kHz bandwidth nee= ded for a WBFM signal.<br> <br> Cheers,<br> Adam.<br> <br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div style= =3D"text-align:right"><i><span style=3D"font-size:x-small">Have Blog, Will = Travel: </span><span style=3D"font-size:x-small"><a href=3D"http://blog.tel= edyn.com" target=3D"_blank">blog.teledyn.com</a></span></i></div> <div style=3D"text-align:right"><i><span style=3D"font-size:x-small">A Serv= iceable Substitute: <a href=3D"http://post.teledyn.com" target=3D"_blank">p= ost.teledyn.com</a></span></i></div><br> --f46d042fd93a1d197104c738bd48--

2 years, 3 months

1
0
0 0

None

by None

from DVB-T (I am a complete neophyte at all of this) and so that particular feature of the device won't be of much use to me, but as for the FM, I'm on the Ubuntu/Linux GNU platform, so I'm awaiting on the kindness of strangers to perfect the kernel drivers enough to match the Windows kit performance. But that's okay, because I'm learning a lot in the process :) On Mon, Aug 13, 2012 at 11:44 PM, Adam Nielsen <a.nielsen(a)shikadi.net>wrote: > so it is /designed/ for FM? That's encouraging because mostly that is all >> I >> >> really need from it, only all my experiments so far have yielded only >> AM-quality sound, but it's good to hear because it means there's /hope/ >> and so >> >> I'll just keep hanging in there until an FM recipe surfaces :) >> > > Yes, because the dongles provide digital TV (via hardware) and as an extra > selling point, analogue FM radio (provided via the SDR.) > > I don't know what platform you're on or what your goals are, but I hear > the SDR# program for Windows offers excellent stereo FM support, as it's > one of the few programs that can deal with the ~120kHz bandwidth needed for > a WBFM signal. > > Cheers, > Adam. > > > -- *Have Blog, Will Travel: blog.teledyn.com* *A Serviceable Substitute: post.teledyn.com* --f46d042fd93a1d197104c738bd48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2 years, 3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr January 2022