undefined reference to `rtlsdr_get_freq'

[alphafox02]

Using 20.04's librtlsdr-dev on x64 I see the following when running make. I wasn't sure if it's just me, just the version of librtlsdr in 20.04, or something else as it appears others are compiling this without error.

Commenting out 756 and un-commenting line 757 that has the note of "original imprecise version" allows make to complete and the project builds.

rtlsdr.c: In function ‘set_correct_freq’:
rtlsdr.c:756:15: warning: implicit declaration of function ‘rtlsdr_get_freq’; did you mean ‘rtlsdr_get_xtal_freq’? [-Wimplicit-function-declaration]
  756 |   double tf = rtlsdr_get_freq(sdr->device);
      |               ^~~~~~~~~~~~~~~
      |               rtlsdr_get_xtal_freq
rtlsdr.c: In function ‘main’:
rtlsdr.c:289:3: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result [-Wunused-result]
  289 |   asprintf(&sdr->frequency_file,"%s/tune-rtlsdr.%llx",VARDIR,(unsigned long long)sdr->SN);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc -L/usr/local/lib -o rtlsdr rtlsdr.o libradio.a -lrtlsdr -lavahi-client -lavahi-common -lbsd -lm -lpthread
/usr/bin/ld: rtlsdr.o: in function `set_correct_freq':
rtlsdr.c:(.text+0xa9f): undefined reference to `rtlsdr_get_freq'
collect2: error: ld returned 1 exit status
make: *** [Makefile:95: rtlsdr] Error 1

[ka9q]

I was waiting for someone to notice that! This is an unreleased version of librtlsdr-dev that I hacked locally to add a call to precisely set the RTL-SDR tuner taking into account its fraction-N synthesizer error. I had been doing this inside rtlsdr.c but thought it would be cleaner to move it into the library since many other second-generation SDRs (AMSAT UK Funcube, Airspy) have the same problem. Ideally I'd like to push my changes into the upstream version of librtlsdr-dev, but until then I should probably move them back into rtlsdr.c. I hate to create yet another fork of someone else's code. --Phil

…

On 4/18/22 03:36, alphafox02 wrote: Using 20.04's librtlsdr-dev on x64 I see the following when running make. I wasn't sure if it's just me, just the version of librtlsdr in 20.04, or something else as it appears others are compiling this without error. Commenting out 756 and un-commenting line 757 that has the note of "original imprecise version" allows make to complete and the project builds. |rtlsdr.c: In function ‘set_correct_freq’: rtlsdr.c:756:15: warning: implicit declaration of function ‘rtlsdr_get_freq’; did you mean ‘rtlsdr_get_xtal_freq’? [-Wimplicit-function-declaration] 756 | double tf = rtlsdr_get_freq(sdr->device); | ^~~~~~~~~~~~~~~ | rtlsdr_get_xtal_freq rtlsdr.c: In function ‘main’: rtlsdr.c:289:3: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result [-Wunused-result] 289 | asprintf(&sdr->frequency_file,"%s/tune-rtlsdr.%llx",VARDIR,(unsigned long long)sdr->SN); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc -L/usr/local/lib -o rtlsdr rtlsdr.o libradio.a -lrtlsdr -lavahi-client -lavahi-common -lbsd -lm -lpthread /usr/bin/ld: rtlsdr.o: in function `set_correct_freq': rtlsdr.c:(.text+0xa9f): undefined reference to `rtlsdr_get_freq' collect2: error: ld returned 1 exit status make: *** [Makefile:95: rtlsdr] Error 1 | — Reply to this email directly, view it on GitHub <#6>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJDI4YL6C2QAO5YFSVFE63VFU3KXANCNFSM5TVRMDNQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[alphafox02]

I see, now it makes sense. I can close this if you’d like. I want to incorporate this into my DragonOS project someday. Maybe having it preinstalled or capable of working with another project like SigDigger etc.

[ka9q]

Leave it open, I'll revert to an earlier version of rtlsdr.c that does the synthesizer corrections. Then I'll close it.

…

On 4/18/22 04:57, alphafox02 wrote: I see, now it makes sense. I can close this if you’d like. I want to incorporate this into my DragonOS project someday. Maybe having it preinstalled or capable of working with another project like SigDigger etc. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJDI42WLLRHNTGRB6DBJMDVFVE37ANCNFSM5TVRMDNQ>. You are receiving this because you commented.Message ID: ***@***.***>

[ka9q]

I just committed a version of rtlsdr.c that works with the old librtlsdr that doesn't perform the R820T tuner fractional-N synthesizer frequency corrections. I added a compile-time option to re-enable use of rtlsdr_get_freq() in a future version of librtlsdr that provides it. Background: Tuners like the Rafael Micro R820T use a fractional-N synthesizer that cannot tune to arbitrarily exact frequencies. The actual tuning steps depend on the reference crystal frequency and the frequency band in use. Higher bands give bigger tuning steps, which IIRC can be a few hundred hertz. That's way too much for many narrowband modes like SSB. A digital downconverter (like the one in ka9q-radio) can easily correct for these inaccuracies by adjusting its own local (software) local oscillator *IF* it knows the actual tuner frequency. So the rtlsdr_get_freq() function that I added to my experimental version of librtlsdr returns the actual tuner frequency as a double, limited only by the reference oscillator accuracy.  This change to the rtlsdr.c component of ka9q-radio re-incorporates the exact tuner frequency calculation so it can be linked with the existing version of librtlsdr. I haven't re-tested this code yet, so if you could beat me to it and let me know if it works, that would be great. But at least 'make' will no longer fail with an unresolved symbol at link time. --Phil

…

On 4/18/22 03:36, alphafox02 wrote: Using 20.04's librtlsdr-dev on x64 I see the following when running make. I wasn't sure if it's just me, just the version of librtlsdr in 20.04, or something else as it appears others are compiling this without error. Commenting out 756 and un-commenting line 757 that has the note of "original imprecise version" allows make to complete and the project builds. |rtlsdr.c: In function ‘set_correct_freq’: rtlsdr.c:756:15: warning: implicit declaration of function ‘rtlsdr_get_freq’; did you mean ‘rtlsdr_get_xtal_freq’? [-Wimplicit-function-declaration] 756 | double tf = rtlsdr_get_freq(sdr->device); | ^~~~~~~~~~~~~~~ | rtlsdr_get_xtal_freq rtlsdr.c: In function ‘main’: rtlsdr.c:289:3: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result [-Wunused-result] 289 | asprintf(&sdr->frequency_file,"%s/tune-rtlsdr.%llx",VARDIR,(unsigned long long)sdr->SN); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc -L/usr/local/lib -o rtlsdr rtlsdr.o libradio.a -lrtlsdr -lavahi-client -lavahi-common -lbsd -lm -lpthread /usr/bin/ld: rtlsdr.o: in function `set_correct_freq': rtlsdr.c:(.text+0xa9f): undefined reference to `rtlsdr_get_freq' collect2: error: ld returned 1 exit status make: *** [Makefile:95: rtlsdr] Error 1 | — Reply to this email directly, view it on GitHub <#6>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJDI4YL6C2QAO5YFSVFE63VFU3KXANCNFSM5TVRMDNQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[alphafox02]

Thank you for the explanation, would've never known that. I just pulled down the code, this time on aarch64 20.04 and compiled with issue your new changes. I've not yet fully understood how to run/use it, but that's my next step. I think the original ticket is resolved, however, I can try (hopefully) and test the code before closing.

Edit:

Well good news, bad news. I figured out how to use my remote Pi/airspy setup by running airspy 2m (after I changed the serial number in the conf), but I think because it took control or did something with eth0/network - I lost my remote connection.. ha! But progress and the airspy did set itself up.

[ka9q]

What do you mean by 'lost your remote connection'? Depending on how many channels you have active the 'radio' program can generate a lot of multicast traffic, and if you don't have a smart switch that only sends it where it needs to go you have to be careful about not swamping your other computers. The front end programs (airspy, rtlsdr, etc) generate even more multicast traffic (sustained 250 Mb/s for the Airspy R2) but by default it doesn't leave the local machine since the only consumer is usually the 'radio' program running on the same machine.

…

On 4/19/22 16:44, alphafox02 wrote: Well good news, bad news. I figured out how to use my remote Pi/airspy setup by running airspy 2m (after I changed the serial number in the conf), but I think because it took control or did something with eth0/network - I lost my remote connection.. ha! But progress and the airspy did set itself up. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJDI44BTOZFXW2GHHX7F6TVF5AOTANCNFSM5TVRMDNQ>. You are receiving this because you commented.Message ID: ***@***.***>

[alphafox02]

I think because maybe the conf file was doing something with eth0 and my remote Pi was on WiFi - I immediately lost realvnc connection when the application started. It’s no biggie, just have to wait for someone to reset the Pi for me.

[ka9q]

Hmm, that shouldn't happen. The 'iface' entry in the conf file specifies the interface to be used for multicasting specifically to keep multicast traffic away from the wifi interface, should it be used as the default route. I've had my stuff route multicast to wifi by accident, and when it does it pretty much makes it unusable. I want to stomp this problem out, it could make me rather unpopular.

…

On 4/20/22 00:15, alphafox02 wrote: I think because maybe the conf file was doing something with eth0 and my remote Pi was on WiFi - I immediately lost realvnc connection when the application started. It’s no biggie, just have to wait for someone to reset the Pi for me. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJDI42EQKO5CCV3LT2CN6TVF6VIJANCNFSM5TVRMDNQ>. You are receiving this because you commented.Message ID: ***@***.***>

[alphafox02]

Later today or tomorrow I’ll setup something locally where I have the ability to see what happens on screen if/when the disconnect happens. To clarify, the Pi4 is setup on WiFi and the connection was via a RealVNC server/client configuration. Once I get another system locally setup, I can also try out the rtlsdr for this particular ticket.

[ka9q]

Great. FYI, I haven't used rtlsdr for a while, and I don't yet have systemd scripts to control it. You have to run it from the command line.

…

On 4/20/22 02:14, alphafox02 wrote: Later today or tomorrow I’ll setup something locally where I have the ability to see what happens on screen if/when the disconnect happens. This will also let me try out the rtlsdr for this particular ticket. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJDI47WP74LP47TQXDHWIDVF7DHNANCNFSM5TVRMDNQ>. You are receiving this because you commented.Message ID: ***@***.***>

[ka9q]

rtlsdr should now compile cleanly with old version of librtlsdr-dev