ka9q / ka9q-radio Goto Github PK

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

Concerning the AirspyR2 I see mention of a 10 Mhz bandwidth, but then it says it is limited to 9 MHz to have no aliasing.

The 'r' value passes if less than 125,000 which would be what you would get for a (frontend - tune value) of 10 MHz.
(well, if my math is correct): i.e., N = 250000, M = 50,001, samplerate = 10000000

Code in question:
https://github.com/ka9q/ka9q-radio/blob/main/radio.c#L646

I was wondering if this should be:

if (abs(r) >= N/2)

To prevent aliasing.

Question: on both Linux and MacOS/UNIX, multicast groups are joined on a per-interface basis. For those programs within ka9q-radio that transmit, it's important to limit them to particular interfaces (usually Ethernet) to avoid flooding a WiFi network. But what about receiving? Should the monitor program, which only receives, automatically join a multicast group on all available interfaces?

If radiod is restarted while monitor is running, then duplicate rows begin appearing in monitor's table. It looks like this happens because the UDP source port differs, so lookup_session considers the session to be new:

Perhaps only the source address should be compared?

Valgrind also complains that uninitialized memory is read here. I expect this happens because sockaddr_storage is padded so as to be large enough to hold any of the various sockaddr structures.

==1526506== Conditional jump or move depends on uninitialised value(s)
==1526506==    at 0x485207E: bcmp (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1526506==    by 0x10F837: lookup_session (monitor.c:1090)
==1526506==    by 0x10CBC2: sockproc (monitor.c:395)
==1526506==    by 0x4B05B42: start_thread (pthread_create.c:442)
==1526506==    by 0x4B96BB3: clone (clone.S:100)

I expect the sockaddr structures will need to be compared more carefully to avoid this.

Phil
In support of my QRA-Skimmer for your software it would help if I could pass/define a filename to your "pcmrecord" on the command line so I don't have to parse standard output and wait for you to autogenerate one.

Thanks!

andyz - K1RA

I'm running the packet program with the -v option to watch APRS packets, and it looks like only about 25% of packets transmitted by my local digipeater (which is less than 1 km away) are printed.

Before I dig into this, I wondered whether you might already know the cause @ka9q.

Hi, Just tried to install ka9q-radio for first time on a Ubuntu system. See attached screenshot for make error messages.

Thanks for any assistance.
Regards Alan VK2ATW

When I run control, it immediately exits with the following error:

*** buffer overflow detected ***: terminated
Aborted (core dumped)

It appears this happens because Frontend.input.status_fd is -1 when it is used in FD_ISSET on line 519:

It seems to be timing-dependent, since the problem vanished when I attempted to investigate the problem by changing compiler settings or using valgrind.

Are there any plans for an FT4 decoder?

Thanks & 73

andyz - K1RA

make clean deletes everything in the DAEMONS list, which includes start-ka9q-horus.sh. But that script is not a build artifact.

The provided docs at https://github.com/ka9q/ka9q-radio/blob/main/docs/airspy.md give instructions for how to get the serial number for an Airspy device using the airspy_info command.

This doesn't work if you have an Airspy HF+; instead, you need the airspyhf_info command, which can be found in this repo:

https://github.com/airspy/airspyhf

I found it necessary to build this from source on Debian 10 ("buster"), but it looks like there's a package for Debian 11 ("bullseye").

https://packages.debian.org/bullseye/airspyhf

Note that you may need to run the command as root.

(this took far too long to figure out on my own, so the hope is that an issue here will contribute to the next person along the way).

The automatic build tests for MacOS are regularly failing now. They seem to fail while still constructing the test environment, even before it gets to my code. I don't understand how this system works; can anybody easily figure out what's going on?

Phil
This isn't an issue but just somewhere in your domain that I can provide some details and start a conversation about my QRA-Skimmer app (restating I'm build on the backs of others) to hopefully help provide some feedback that might help to tune/tweak KA9Q-Radio and your supporting apps for external app usage.

In my radiod.conf file I currently set up many individual multicast addresses each for a single frequency representing a band/mode. Is there any performance hit for doing this vs an all in one as per your examples? For example I do something like, abbreviated to pertinent variables below:

[FT4_20m]
data = ft4_20m.local
freq = 14m080000

I have a config file in my app that defines a time span and then lists a number of band/modes to simultaneously capture/decode during that time. During the appropriate time I spawn/queue your "pcmrecord" for the interval associated with a mode along with the mode's multicast name from a template/lookup table ( [MODE_BANDm] / mode_bandm.local ) as seen above. I scan stdout and extract your generated filename.

After a record completes I then rename the file it, as required by the decoders, and pass it to the appropriate command line decoder for the associated mode. Decodes are parsed by WSJTX jt9, wsprd, or JS8CALL js8 command line apps for Linux that ingest WAV files. Their text output is processed and uploaded to the appropriate online reporting services. I also have a DXcluster like telnet server and WSJTX multicast/uni-cast broadcaster that can also take decodes and make data available through those apps/modules/protocols.

I know you have a "control" program that may be useful for changing the frequency of a multicast stream, but I could not get that to work when playing with "monitor". Therefore I'm pursuing how best to change band/mode combos and teardown old and setup new multicast streams for CPU's that might not be able to handle numerous simultaneous recorders/decoders. Currently I'm running 28 virtual band/mode receivers (160-10m)/(FT8, FT4, WSPR) on a 8-core Xeon and still have plenty of head room to add alternate/secondary band/modes above as well as new band/modes JT9, JS8, FST4W, etc, I realize not everyone will have that luxury of monitoring all band/modes all the time. So...

I am thinking about simply and programmatically generating a new radiod.conf file (using some template) to generate single stream name and single frequency sections as above and then "systemctl restart radiod" service. There does seem to be some start up time/delay in doing this, but it seems "pcmrecord" doesn't care or at least times out and eventually retries and picks up at the next available record/decode cycle. BTW, I'm using /dev/shm for all the WAV file writing as not to wear out my SSD.

So there it is in a nutshell, not rock science, but surely a fun science project :) I'll share more as requested and as I make more progress.

73

andyz - K1RA

I'm using

This is not really an issue; please feel free to close it anytime.

I thought it might be a useful addition to also have a front-end for the SDRplay RSP devices ('sdrplayd'); while working on it I also fixed a few things with multicast and the Avahi client code, so it should now consistently support a default interface for multicast (or an interface specified as the suffix ',iface' at the end of the DNS name).

I also found and fixed a possible problem where it looks like the software LO was not being initialized (i.e. 'set_osc()' was not being called) when the initial value of 'remainder' is 0, so I added a call to 'set_osc()' in main.c.

I ran a quick test here and I was able to listen to a local FM broadcast station using the programs 'control' and 'monitor'.

You can find the code in this repo: https://github.com/fventuri/ka9q-radio - to make it easier to look at those individual changes and enhancements, I created several branches, where each one of them contains the commits for that specific change; for instance the branch 'sdrplay' contains just the code I changed to add the front-end for the SDRplay devices, and so on. I also created a branch called 'all-changes' that has exactly the code as I am running it here.

Let me know what you think; if you would like to integrate some/all of this changes into your main repo, I'll be happy to help.

Regards,
Franco Venturi K4VZ

Valgrind reports that estimate_n0 reads uninitialized memory:

==12481== Conditional jump or move depends on uninitialised value(s)
==12481==    at 0x1134D5: estimate_n0 (radio.c:137)
==12481==    by 0x5C906DA: start_thread (pthread_create.c:463)
==12481==    by 0x636761E: clone (clone.S:95)

It seems this is because fdomain is not initialized. I don't yet know why that occurs.

Trying to compile and install on Ubuntu 22.04 I get a Make error that wspr-decoded is not found (but it is specified in the EXECS line). It looks like this may be in state of flux, as I see comments that wspr-decoded was merged with jt-decoded.

Is there a needed update in the Makefile.linux?
Can I just remove the wspr-decoded from EXECS?

Excuse me if I am just not understanding the Makefile. No expert in that area

73,

Tom, KG3V

As promised, I was able to try this out again (still remote). I did a git pull of the latest ka9q-radio from this repo, compiled the code, and to the best of my understanding attempted to run it with ./airspy 2M.

It's possible that I'm doing it all wrong, but what I can say is that upon running that command the last line mentions eth0 not found and then I immediately lose the RealVNC connection to the Raspberry Pi. The Pi4 is connected to a network using it's internal wireless card. Sorry for being short on details, happy to investigate further.

Screen attached.

How difficult would it be to integrate "sdr" hardware like :
-Red Pitaya
-Hermes Lite v2
-SDRplay RSP1a
-KiWiSDR
-QDX
-FiFi SDR
into this software.
And what are the "general" requirements on "integrate-able" hardware?
Is having a broadband I/Q stream enough?

Thanks
Erwin / F4VTQ / PE3ES

In attr.c it has:

#ifdef __linux__
#include <attr/xattr.h>
#else
#include <sys/xattr.h>
#endif

But on Ubuntu the include is in the sys directory. Changed to:

#include <sys/xattr.h>

Maybe other linux versions differ, which will complicate the #ifdef

I'm attempting to run ka9q-radio completely local on an Ubuntu PC and desire NOT to multicast out over my wired LAN. I read there is a "iface" setting in the global section of radiod.conf which I've used, as follows:

[global]
iface = lo

But sniffing my LAN I still see traffic go out over the main ethernet interface from my private 192.168 host IP.

I've found someone suggest turning off multicast on my main interface using "sudo ifconfig eno1 -multicast" and ensure its enabled on localhost "sudo ifconfig lo multicast" resulting in:

eno1: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet 192.168.2.228 netmask 255.255.255.0 broadcast 192.168.2.255
ether b0:4f:13:00:c0:a5 txqueuelen 1000 (Ethernet)
RX packets 32472 bytes 22294178 (22.2 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 749027 bytes 396046200 (396.0 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0x92f00000-92f20000

lo: flags=4169<UP,LOOPBACK,RUNNING,MULTICAST> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 1798 bytes 316424 (316.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1798 bytes 316424 (316.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

But restarting radiod service still pushes multicast data out eno1 onto my LAN. Has anyone successfully used "lo" and ensured they aren't really still sending over their LAN?

Suggestions where to look or what to try next?

Thanks & 73

andyz - K1RA

New jt-decoded encoded date in the ALL_WSPR.TXT file as 1018_1 when it should be 1018 for today

1018_1 1000 -17 0.37 14.0970026 WA6HEW EM11 23 0 0.55 1 1 0 0 21 1 471
1018_1 1000 -20 0.24 14.0970151 AJ4EO/2 23 0 0.33 2 1 0 0 34 4685 -109
1018_1 1000 -14 0.32 14.0970167 W3ENR FM28 23 0 0.27 1 1 0 0 19 1 227
1018_1 1000 -21 0.28 14.0970258 W4DES EL97 37 0 0.21 1 1 0 0 30 7 101
1018_1 1000 2 0.19 14.0970414 N8NJ EN81 30 0 0.84 1 1 0 0 19 1 385

it should be
1018 1000 -17 0.37 14.0970026 WA6HEW EM11 23 0 0.55 1 1 0 0 21 1 471
1018 1000 -20 0.24 14.0970151 AJ4EO/2 23 0 0.33 2 1 0 0 34 4685 -109
1018 1000 -14 0.32 14.0970167 W3ENR FM28 23 0 0.27 1 1 0 0 19 1 227
1018 1000 -21 0.28 14.0970258 W4DES EL97 37 0 0.21 1 1 0 0 30 7 101
1018 1000 2 0.19 14.0970414 N8NJ EN81 30 0 0.84 1 1 0 0 19 1 385

My collaborators Franco K4VZ and Clint KA7OEI have introduced me to your work which I think might be of great value to the Wsprdaemon (WD) software project currently in use at most of the top WSPR spotting stations worldwide.

WD is an open source (https://github.com/rrobinett/wsprdaemon) Linux service which records wav files from one or more KiwiSDRs, decodes them from those files in multiple formats now offered by WSJTx (WSPR-2, FST4W-120,-300,-900,-1800) and posts the found spots to wsprnet.org. In addition, WD posts enhanced versions of those spots to a public WD database which includes background noise level and millihertz resolution frequency values . That additional spot information has led us to new insights into HF radio propagation as is shown in a paper presented by our collaborator Gwyn G3ZIL at last month's HascSCI workshop: http://wsprdaemon.org/ewExternalFiles/Griffiths_FST4W_2023_HamSCI.pdf

The KiwiSDR is a marvellous tool for WSPR recording and serious scientific research, and John Seamons has enhanced the kwirecorder client utility used by WD so much that the Kiwi the only SDR I have seriously supported. But as I'm sure you know the Kiwi is no longer being manufactured, and we are also starting to exceed the limits of its capabilities for example in the number of simultaneous channels. Some of the WD sites are operating 7 of the GPSDO Kiwis in 14 channel mode and are still running short of receive channels. Furthermore I am currently adding support for doppler shift measurements of all 5 WWV signals in addition to the 14 LF/MF/HF WSPR bands, which would require 3 Kiwis running in 8 channel mode.

While ADC + FPGA devices like the RedPitaya offer one path to a Kiwi successor, I prefer that we migrate all possible signal processing out of hardware and into open source software, even at the cost of a more expensive host PC. Your recent presentation in San Diego and your DCC paper form 2021 persuades me that your ka9q-radio service, when fed by a 16 bit (or higher) resolution ADC, could meet our multichannel needs while being easily integrated within WD's software architecture.

However there are a least three scientific requirements of our system which I don't know if a GPSDO-RX-888 + ka8q-radio frontend could meet:

1. Tuning frequency accuracy derived from the accuracy of the GPSDO. On the 10M WSPR band a GPSDO-Kiwi can tune with 0.001 Hz or better accuracy and IQ output slowly drifts at most +-180 degrees over a 10 minute measurement period.
2. The IQ wav files recorded by the kwirecorder utility include a start sample timestamp derived from the GPS clock with a (I think)1 microsecond or better time resolution.
3. A deterministic temporal delay between the RF sample time and the demodulated output samples. That delay need not be the same for each channel, but it needs to be known so it can be incorporated into the signal processing SW

I encourage Franco and Clint to correct, comment and expand on these requirements.

So before Franco and Clint invest development time in the RX888 and your ka6q-radio, it would help us if you can comment if that system could meet those requirements.

It looks like hackrf support is not implemented.

• There is a [email protected]
• There is relevant line in Makefile.linux

but it looks like hackrf.c does not exists. The implementation is missign right?

Btw would make more sense to implement it specifically for HackRF or just use somethink like soapysdr?