- osmocom-sdr - lists.osmocom.org

[PATCH] Support RTL-SDR Blog V4 R828D dongles
by Carl Laufer 27 Aug '23

27 Aug '23

I've just released a new R828D based dongle and it needs some code changes to work. It would be great if the osmocom drivers could support it. The dongle is based on the R828D chip, but unlike prior R828D dongles which use 16 MHz, the V4 uses a 28.8 MHz LO. Also the three RF inputs are used, and connected via a triplexer to separate them into HF, VHF and UHF bands. Finally, the open_d pin is also used to activate some notch filters for common interference bands. I've written the code so it detects an EEPROM string in the V4, and only applies the new code if that exists. This makes sure that the older R828D based dongles still work. I'm not too familiar with the patch submission process, so please let me know if something needs to be changed. And if anyone on the team needs/wants some new V4 dongles for testing, please let me know too. Thanks, Carl diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 096abae..d624732 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -119,6 +119,8 @@ struct rtlsdr_dev { int dev_lost; int driver_active; unsigned int xfer_errors; + char manufact[256]; + char product[256]; }; void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val); @@ -1430,6 +1432,16 @@ int rtlsdr_get_index_by_serial(const char *serial) return -3; } +/* Returns true if the manufact_check and product_check strings match what is in the dongles EEPROM */ +int rtlsdr_check_dongle_model(rtlsdr_dev_t *dev, char* manufact_check, char* product_check) +{ + if ((strcmp(dev->manufact, manufact_check) == 0 && strcmp(dev->product, product_check) == 0)) + return 1; + + return 0; +} + + int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) { int r; @@ -1528,6 +1540,9 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) rtlsdr_init_baseband(dev); dev->dev_lost = 0; + /* Get device manufacturer and product id */ + r = rtlsdr_get_usb_strings(dev, dev->manufact, dev->product, NULL); + /* Probe tuners */ rtlsdr_set_i2c_repeater(dev, 1); @@ -1555,6 +1570,10 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) reg = rtlsdr_i2c_read_reg(dev, R828D_I2C_ADDR, R82XX_CHECK_ADDR); if (reg == R82XX_CHECK_VAL) { fprintf(stderr, "Found Rafael Micro R828D tuner\n"); + + if (rtlsdr_check_dongle_model(dev, "RTLSDRBlog", "Blog V4")) + fprintf(stderr, "RTL-SDR Blog V4 Detected\n"); + dev->tuner_type = RTLSDR_TUNER_R828D; goto found; } @@ -1588,7 +1607,11 @@ found: switch (dev->tuner_type) { case RTLSDR_TUNER_R828D: - dev->tun_xtal = R828D_XTAL_FREQ; + /* If NOT an RTL-SDR Blog V4, set typical R828D 16 MHz freq. Otherwise, keep at 28.8 MHz. */ + if (!(rtlsdr_check_dongle_model(dev, "RTLSDRBlog", "Blog V4"))) { + fprintf(stdout, "setting 16mhz"); + dev->tun_xtal = R828D_XTAL_FREQ; + } /* fall-through */ case RTLSDR_TUNER_R820T: /* disable Zero-IF mode */ diff --git a/src/tuner_r82xx.c b/src/tuner_r82xx.c index 997abd7..9b831f4 100644 --- a/src/tuner_r82xx.c +++ b/src/tuner_r82xx.c @@ -33,6 +33,10 @@ #define MHZ(x) ((x)*1000*1000) #define KHZ(x) ((x)*1000) +#define HF 1 +#define VHF 2 +#define UHF 3 + /* * Static constants */ @@ -1098,7 +1102,14 @@ int r82xx_set_bandwidth(struct r82xx_priv *priv, int bw, uint32_t rate) int r82xx_set_freq(struct r82xx_priv *priv, uint32_t freq) { int rc = -1; - uint32_t lo_freq = freq + priv->int_freq; + + int is_rtlsdr_blog_v4 = rtlsdr_check_dongle_model(priv->rtl_dev, "RTLSDRBlog", "Blog V4"); + + /* if it's an RTL-SDR Blog V4, automatically upconvert by 28.8 MHz if we tune to HF + * so that we don't need to manually set any upconvert offset in the SDR software */ + uint32_t upconvert_freq = is_rtlsdr_blog_v4 ? ((freq < MHZ(28.8)) ? (freq + MHZ(28.8)) : freq) : freq; + + uint32_t lo_freq = upconvert_freq + priv->int_freq; uint8_t air_cable1_in; rc = r82xx_set_mux(priv, lo_freq); @@ -1109,16 +1120,60 @@ int r82xx_set_freq(struct r82xx_priv *priv, uint32_t freq) if (rc < 0 || !priv->has_lock) goto err; - /* switch between 'Cable1' and 'Air-In' inputs on sticks with - * R828D tuner. We switch at 345 MHz, because that's where the - * noise-floor has about the same level with identical LNA - * settings. The original driver used 320 MHz. */ - air_cable1_in = (freq > MHZ(345)) ? 0x00 : 0x60; + if (is_rtlsdr_blog_v4) { + /* determine if notch filters should be on or off notches are turned OFF + * when tuned within the notch band and ON when tuned outside the notch band. + */ + uint8_t open_d = (freq <= MHZ(2.2) || (freq >= MHZ(85) && freq <= MHZ(112)) || (freq >= MHZ(172) && freq <= MHZ(242))) ? 0x00 : 0x08; + rc = r82xx_write_reg_mask(priv, 0x17, open_d, 0x08); + + if (rc < 0) + return rc; + + /* select tuner band based on frequency and only switch if there is a band change + *(to avoid excessive register writes when tuning rapidly) + */ + uint8_t band = (freq <= MHZ(28.8)) ? HF : ((freq > MHZ(28.8) && freq < MHZ(250)) ? VHF : UHF); + + /* switch between tuner inputs on the RTL-SDR Blog V4 */ + if (band != priv->input) { + priv->input = band; + + /* activate cable 2 (HF input) */ + uint8_t cable_2_in = (band == HF) ? 0x08 : 0x00; + rc = r82xx_write_reg_mask(priv, 0x06, cable_2_in, 0x08); - if ((priv->cfg->rafael_chip == CHIP_R828D) && - (air_cable1_in != priv->input)) { - priv->input = air_cable1_in; - rc = r82xx_write_reg_mask(priv, 0x05, air_cable1_in, 0x60); + if (rc < 0) + goto err; + + /* activate cable 1 (VHF input) */ + uint8_t cable_1_in = (band == VHF) ? 0x40 : 0x00; + rc = r82xx_write_reg_mask(priv, 0x05, cable_1_in, 0x40); + + if (rc < 0) + goto err; + + /* activate air_in (UHF input) */ + uint8_t air_in = (band == UHF) ? 0x00 : 0x20; + rc = r82xx_write_reg_mask(priv, 0x05, air_in, 0x20); + + if (rc < 0) + goto err; + } + } + else /* Standard R828D dongle*/ + { + /* switch between 'Cable1' and 'Air-In' inputs on sticks with + * R828D tuner. We switch at 345 MHz, because that's where the + * noise-floor has about the same level with identical LNA + * settings. The original driver used 320 MHz. */ + air_cable1_in = (freq > MHZ(345)) ? 0x00 : 0x60; + + if ((priv->cfg->rafael_chip == CHIP_R828D) && + (air_cable1_in != priv->input)) { + priv->input = air_cable1_in; + rc = r82xx_write_reg_mask(priv, 0x05, air_cable1_in, 0x60); + } } err:

3 5

Osmocom discourse as alternative to mailing lists
by Harald Welte 27 Jul '23

27 Jul '23

Dear Osmocom community, while many people with a long history in FOSS development have no issues at all with mailing lists as primary form of engaging with their community, they have undoubtedly fallen out of fashion in favor of various chat/messaging systems or web based forums. In Osmocom, we've just launched an installation of the discourse forum software available at https://discourse.osmocom.org/ providing an alternative to our traditional mailing lists at https://lists.osmocom.org/ We're looking forward to see whether this web-based approach will facilitate more and/or other people to engage with the Osmocom developer/contributor community. Feel free to join and get the discussions started. If there's a need for more categories or sub-categories, just let one of the moderators know and we can help with that. The old mailing lists will continue to remain available for those who prefer them. -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

[PATCH] trl_tcp: fix for macos
by Stephen More 23 Apr '23

23 Apr '23

rtl_tcp does not work on macos: https://osmocom.org/issues/4758 sizeof(local) == 128 ai->ai_addrlen == 16 patch: % git diff *diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c* *index 8781ba9..b64f943 100644* *--- a/src/rtl_tcp.c* *+++ b/src/rtl_tcp.c* @@ -562,7 +562,7 @@ int main(int argc, char **argv) setsockopt(listensocket, SOL_SOCKET, SO_REUSEADDR, (char *)&r, sizeof(int)); setsockopt(listensocket, SOL_SOCKET, SO_LINGER, (char *)&ling, sizeof(ling)); - if (bind(listensocket, (struct sockaddr *)&local, sizeof(local))) + if (bind(listensocket, (struct sockaddr *)&local, ai->ai_addrlen)) fprintf(stderr, "rtl_tcp bind error: %s", strerror(errno)); else break; smore@Stephens-Mini rtl-sdr %

1 0

[PATCH] rtl_sdr: enable direct sampling support
by 0x4tlas 29 Mar '23

29 Mar '23

While using rtl_sdr i noticed that there was no direct sampling support, despite the rtl-sdr library supporting it, so i wrote a patch: diff --git a/src/rtl_sdr.c b/src/rtl_sdr.cindex 2c93b57..15a4212 100644 --- a/src/rtl_sdr.c +++ b/src/rtl_sdr.c @@ -55,6 +55,7 @@ void usage(void) "\t[-b output_block_size (default: 16 * 16384)]\n" "\t[-n number of samples to read (default: 0, infinite)]\n" "\t[-S force sync output (default: async)]\n" + "\t[-D direct sampling (default: 0, 1 for I branch, 2 for Q branch)]\n" "\tfilename (a '-' dumps samples to stdout)\n\n"); exit(1); } @@ -112,6 +113,7 @@ int main(int argc, char **argv) int n_read; int r, opt; int gain = 0; + int direct_sampling = 0; int ppm_error = 0; int sync_mode = 0; FILE *file; @@ -121,8 +123,8 @@ int main(int argc, char **argv) uint32_t frequency = 100000000; uint32_t samp_rate = DEFAULT_SAMPLE_RATE; uint32_t out_block_size = DEFAULT_BUF_LENGTH; - - while ((opt = getopt(argc, argv, "d:f:g:s:b:n:p:S")) != -1) { + + while ((opt = getopt(argc, argv, "d:f:g:s:b:n:p:S:D:")) != -1) { switch (opt) { case 'd': dev_index = verbose_device_search(optarg); @@ -149,6 +151,9 @@ int main(int argc, char **argv) case 'S': sync_mode = 1; break; + case 'D': + direct_sampling = atoi(optarg); + break; default: usage(); break; @@ -200,7 +205,8 @@ int main(int argc, char **argv) #endif /* Set the sample rate */ verbose_set_sample_rate(dev, samp_rate); - + /* Set direct sampling*/ + verbose_direct_sampling(dev, direct_sampling); /* Set the frequency */ verbose_set_frequency(dev, frequency);

1 0

Re: Play RTP packets payload obtained from the mobile phone in a call service
by Tomcsanyi, Domonkos 24 Feb '23

24 Feb '23

AFAIR Wireshark cannot play our RTP streams because it has a very limited set of codecs, mostly focusing on regular VoIP audio. Cheers, Domi > 24.02.2023 dátummal, 1:29 időpontban Neels Hofmeyr <nhofmeyr(a)sysmocom.de> írta: > > On Wed, Feb 22, 2023 at 11:58:24PM +0330, morteza ali Ahmadi wrote: >> I have aggregated all RTP packets payload. How can I convert the aggregated >> bytes to a hearable audio? > > Firstly you need to be aware that 3G audio uses IuUP -- the RTP payload > includes an IuUP header followed by the AMR audio data. To see this in > wireshark, you need to go to Preferences / Protocols / IuUP and mark > [x] Dissect IuUP Payload bits. > > osmo-mgw has implemented the IuUP to AMR conversion: if one side of an MGCP > endpoint has VND.3GPP.IUFP and the other has AMR, osmo-mgw will decapsulate the > AMR from the IuUP, i.e. forward plain AMR. > > Next I guess you will convert the AMR to something you can play back, AFAIK > https://gitea.osmocom.org/osmocom/gapk is capable of that? > > Also wireshark is supposed to be able to play back an RTP stream. See the menu > item Telephony / RTP. It hasn't worked for me yet, not sure what I'm doing > wrong, but I also never tried for more than two minutes. > > This is a rough outline, you'll have to figure out all the details... > > ~N

2 1

OsmoDevCall on Feb 15, 2023: Long range communications in the HF band
by Harald Welte 14 Feb '23

14 Feb '23

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: February 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall This time, @rafael2kwill be presenting on Long range communications in the HF band This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - 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)

1 0

Re: [patch] Pass additional library arguments to ld
by Paul R. Tagliamonte 10 Jan '23

10 Jan '23

I did send this to the right place! I had to go onto IRC to confirm - and someone was nice enough to start a review. May be good for others waiting for feedback to join the IRC and do the same. I suspect this ML is a bit disused for contributions. From the conversation on IRC which I'm putting into the email thread to keep everything in one place, here's what I learned: MSVC requires this manual path work, so the first patch isn't going to work, since those values need to be hardcoded for that platform. This just leaves patch #2 for review. After a bit of confusion during the review regarding cmake's behavior and how the CMake in rtl-sdr was causing the build failure not cmake itself (confusion here may explain why no one triaged?) the feedback on the review *appears* to be: | <> so something like https://pastebin.com/CxXiGakh | <> the "beauty" is that this does not just add random lib search paths to | the targets that affect the other libs (which we don't have) Pastebin contents at the bottom at [0]. I have not revised the patches to use this approach, and I don't think I plan to - I haven't gotten very positive vibes on contributing (nor any indication anyone seems to mind the build system is broken?), so I'm not driving this anymore. If the core team needs someone to do the work, maybe another contributor will step forward in a few months. There's also a related PR against the mirror as PR 68, which fixes this issue -- turns out it impacts OSX (not just OpenBSD) at https://github.com/steve-m/librtlsdr/pull/68 -- it has another solution I overlooked -- using LIBUSB_LINK_LIBRARIES. I can confirm this patch also works on OpenBSD. If someone wouldn't mind merging one of the three patches or taking none of them with an independent fix, I'd be very grateful to get this off my mental queue. As I I said on IRC I'd leave it here and help review any patches the team comes up with if they want testing before a push. I'm no longer driving these patches or trying to drive them into main. I don't even run OpenBSD; this was a fix I wanted to send in when I hit a build failure targeting a friend's OS choice figuring it'd be a helpful time-saver for the project and its users after I debugged where exactly the librtlsdr CMake was broken and fixed it locally. paultag [0]: | if(PKG_CONFIG_FOUND) | pkg_check_modules(LIBUSB libusb-1.0 IMPORTED_TARGET) | if(LIBUSB_FOUND) | find_library ( | LIBUSB_LIBRARIESX | NAMES ${LIBUSB_LIBRARIES} | PATHS ${LIBUSB_LIBRARY_DIRS} | ) | set(LIBUSB_LIBRARIES ${LIBUSB_LIBRARIESX} CACHE INTERNAL "full libusb path") | #message(WARNING ${LIBUSB_LIBRARIES}) | endif() | else() | set(LIBUSB_LIBRARIES "" CACHE STRING "manual libusb path") | set(LIBUSB_INCLUDE_DIRS "" CACHE STRING "manual libusb includepath") | endif()

1 0

gr-osmosdr bias-tx runtime switching feature request
by Paul Bongaerts 01 Jan '23

01 Jan '23

Hello everyone, I would like to know if it's possible to switch the bias-tee / phantom power to the hackrf one at runtime in the osmocom-sink block. At the moment it's possible to change the gains and switch the 14 db amp at runtime. Only the bias-tee is en/disabled with device arguments "hackrf=0,bias-tx=0|1" which must be set at startup. Would like to be able to switch this when the flowgraph is running. I haven't figured out how to change device arguments after startup. Or would this require a change on the sink block adding something like a bias-tee option? Thanks and best wishes for the new year. Paul

1 0

Request to reactivate Miri support
by MarcHOsmo＠gmx-topmail.de 30 Dec '22

30 Dec '22

Hello everyone, Short story: I would like to ask if it is possible to bring back the Miri support that was removed in October 2020? The market for cheap SDR receivers has changed in recent years and there are now more good boards with Miri chipsets. Long story: I work as an industrial mechanic, but my secret loves since many years are electronics and amateur radio. It was GNU Radio that allowed me to learn a lot about filtering, modulation or signal mixing without the necessary technical training. I started with the RTL-SDR sticks like many others and they got me off to a good start, but the lack of ability to receive signals below 20MHz without modification makes it difficult for beginners to experiment. This is where the cheap Miri Boards come into play today. I ordered boards with Miri chipset from China for 18€ delivered to Germany. They have a good performance for beginners and signals above 10kHz can also be received well. My plan is to develop cheap open source boards for amateur radio beginners that are connected directly to the Miri boards. Based on the NE555 and the Si5351A, basics such as filters, attenuators, mixing and modulating frequencies should be explained and tested. My biggest problem is that I'm not a good programmer, so I can't manage to re-implement Miri support myself and compile gr-osmosdr to get it running on Windows (yes, I'll burn in hell for it one day). Hence my request to resume Miri support in gr-osmosdr or the question of whether someone can help me to create a fork that can be compiled with Miri Support under Windows. Offtopic: After all these years of using gr-osmosdr, I would like to take this opportunity to thank everyone involved for their time and dedication, which enables people like me to learn and develop with simple means and without expensive equipment. Thanks for your time and Merry Christmas to everyone! Marc

3 3

[patch] Pass additional library arguments to ld
by Paul R. Tagliamonte 26 Dec '22

26 Dec '22

Hey osmocom-sdr, I've got a choose your own adventure patch set here for the adventurous reviewer. On OpenBSD (but not specific to OpenBSD) libusb-1.0 lives in /usr/local/lib. The default linker (lld 13.0.0 on 7.2) doesn't include /usr/local/lib in its out of the box search path, which triggers a build failure in rtl-sdr because the -L argument(s) aren't passed through to ld. The root cause here is that we pass ${LIBUSB_LIBRARIES} to target_link_libraries, which is only the -lfoo arguments, but not the -L/foo/bar arguments. This tends to work on most systems, since libusb is usually in a place ld will search anyway. There's two ways I could see to do this. Here comes the choose your own adventure part: 1) The first is to use the PkgConfig::LIBUSB helper, which can be passed directly to `target_link_libraries`, which allows all the arguments to be passed through. This means the existing hooks to pass in a manual path would be dropped and building without pkg-config against libusb won't be supported anymore. This is the attached git format-patch entitled "0001-Use-the-PkgConfig-imported-target-rather-than-_LIBRA.patch". 2) Punch the -L arguments through next to the LIBUSB_LIBRARIES argument to `target_link_libraries`, add a new knob to set the values ("manual libusb librarypath"), and when using pkg-config, generate the arguments with a FOREACH. This is the attached git format-patch "0001-Pass-additional-library-directory-arguments-to-ld.patch". Both patch flavors build on my Debian sid box and an OpenBSD 7.2 box. paultag -- :wq

2 1