szpajder / dumphfdl Goto Github PK

Hi
When i want to try compiling under debian 12 bookworm, i've got an error

[100%] Linking C executable dumphfdl /usr/bin/ld : CMakeFiles/dumphfdl_base.dir/fastddc.o : dans la fonction « fastddc_init » : fastddc.c:(.text+0x80) : référence indéfinie vers « is_integer » collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/dumphfdl.dir/build.make:156 : dumphfdl] Erreur 1 make[1]: *** [CMakeFiles/Makefile2:129 : CMakeFiles/dumphfdl.dir/all] Erreur 2 make: *** [Makefile:136 : all] Erreur 2
What can i do to pass that ?

Thanks

Jeff

Hi,

This is my output of cmake..
Checking for module 'libacars-2>=2.1.0'
-- Found libacars-2, version 2.1.3
-- Checking for module 'libconfig++'
-- Found libconfig++, version 1.7.3
-- Checking for SoapySDR
-- SoapySDR found, /usr/local/include, SoapySDR
-- Found SQLite3: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/usr/include (found version "3.36.0")
-- Checking for module 'libzmq>=3.2.0'
-- Found libzmq, version 4.3.4
-- dumphfdl configuration summary:
-- - SDR drivers:
-- - soapysdr: requested: ON, enabled: TRUE
-- - Other options:
-- - Etsy StatsD: requested: ON, enabled: FALSE
-- - SQLite: requested: ON, enabled: TRUE
-- - ZeroMQ: requested: ON, enabled: TRUE
-- - Profiling: requested: OFF, enabled: FALSE
-- - Multithreaded FFT: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/Loewal/Downloads/dumphfdl/build

Output of make:
[100%] Linking C executable dumphfdl
[100%] Built target dumphfdl

Output of sudo make install:
[ 97%] Built target fec
[100%] Linking C executable dumphfdl
ld: library not found for -lacars-2
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/dumphfdl] Error 1
make[1]: *** [src/CMakeFiles/dumphfdl.dir/all] Error 2

Ain't this strange?

Hello. If there's a better place to ask, please let me know. I've included dumphfdl into DragonOS Focal, a linux distro geared towards SDRs. I noticed your screenshots using Grafana. I've did a quick setup in the past for another project using Grafana, but found it interesting what you were able to do with dumphfdl data.

Would you happen to have any notes or directions I could follow to do the same thing? I'd in turn share the setup. Thank you.

Hi Szpajder

Awesome work here. Was looking for this decoder within Linux for some time.

I've been using 'Kiwi_nc.py' to connect to a KiwiSDR to pipe streams from SDR over the network to an ICECast server using FFMPEG and the icecast output:

kiwi_nc.py --log=info -s --user --password -p 8073 -f 5515 -m usb | ffmpeg -v info -f s16le -ar 12000 -i pipe:0 -f ogg -content_type application/ogg icecast://source::@/test.mp3

Any chance I can pipe from Kiwi_nc into dumphfdl to process audio from a KiwiSDR rather than from an IQ file or Soapy? Be great to utilise any audio input.

Thanks

Mo

It would be fantastic if we could have the full output as JSON format option.

I am trying to compile dumphfdl on Debian 12 but:

$ cmake ../
-- The C compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to Release
-- Performing Test CC_HAS_PTHREAD
-- Performing Test CC_HAS_PTHREAD - Success
-- Performing Test CC_HAS_FFAST_MATH
-- Performing Test CC_HAS_FFAST_MATH - Success
-- Performing Test CC_HAS_FNO_COMMON
-- Performing Test CC_HAS_FNO_COMMON - Success
-- Looking for pthread_barrier_wait
-- Looking for pthread_barrier_wait - found
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.8.1")
-- Found liquid includes: /usr/include/liquid/liquid.h
-- Found liquid library: /usr/lib/x86_64-linux-gnu/libliquid.so
-- Performing Test LIQUIDDSP_VERSION_CHECK
-- Performing Test LIQUIDDSP_VERSION_CHECK - Failed
CMake Error at src/CMakeLists.txt:76 (message):
LiquidDSP library is too old or missing (min. version required: 1.3.0)

-- Configuring incomplete, errors occurred!
See also "/opt/linux/dumphfdl/build/CMakeFiles/CMakeOutput.log".
See also "/opt/linux/dumphfdl/build/CMakeFiles/CMakeError.log".

$ cat /opt/linux/dumphfdl/build/CMakeFiles/CMakeError.log
Performing C SOURCE FILE Test LIQUIDDSP_VERSION_CHECK failed with the following compile output:
Change Dir: /opt/linux/dumphfdl/build/CMakeFiles/CMakeScratch/TryCompile-NYffxH

Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_7fe3e/fast && /usr/bin/gmake -f CMakeFiles/cmTC_7fe3e.dir/build.make CMakeFiles/cmTC_7fe3e.dir/build
gmake[1]: Entering directory '/opt/linux/dumphfdl/build/CMakeFiles/CMakeScratch/TryCompile-NYffxH'
Building C object CMakeFiles/cmTC_7fe3e.dir/src.c.o
/usr/bin/cc -DLIQUIDDSP_VERSION_CHECK -Wall -Wextra -o CMakeFiles/cmTC_7fe3e.dir/src.c.o -c /opt/linux/dumphfdl/build/CMakeFiles/CMakeScratch/TryCompile-NYffxH/src.c
Linking C executable cmTC_7fe3e
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_7fe3e.dir/link.txt --verbose=1
/usr/bin/cc -Wall -Wextra -rdynamic CMakeFiles/cmTC_7fe3e.dir/src.c.o -o cmTC_7fe3e /usr/lib/x86_64-linux-gnu/libliquid.so
gmake[1]: Leaving directory '/opt/linux/dumphfdl/build/CMakeFiles/CMakeScratch/TryCompile-NYffxH'

...and run output:
/opt/linux/dumphfdl/build/CMakeFiles/CMakeScratch/TryCompile-NYffxH/src.c:8: error: invalid liquid runtime library
header version : 1005000
library version : 1003002

Return value: 1
Source file was:

#include <stdio.h>
#include <stdlib.h>
#include <liquid/liquid.h>
#if LIQUID_VERSION_NUMBER < 1003000
#error LiquidDSP library is too old
#endif
int main(void) { LIQUID_VALIDATE_LIBVERSION return 0; }

Similar to --freq-as-squawk, can the ground station be added into a field in VRS that's not used in HFDL? VRS has a User Tag field in the aircraft details that's not being shown or used by default which would be good for this. The Tag field, when this option is added to the aircraft details pane, appears just below Notes. It's also available in the List. It would be very nice to know what ground stations I'm receiving messages from in addition to the frequencies. If used along with the --system-table option it could show the "friendly names" of the ground stations. Otherwise, to find this information I'd have to look up the frequency, and in the case of the same freq being used by more than one station I still wouldn't know for sure which one sent the message.

Hello
dumphfdl ok on my raspberry with rsp1A.

have another pi with reads & tar1090 combine

how can l send dumphfdl tcp/udp to reads ?

did not undertound what dumphfdl --output help said

I'm feeding HFDL messages to a few aggregators including an under-development HFDL ingest that @kevinelliot is working on for airframes.io, and as his site aggregates messages from many ACARS and VDL feeders he'll need a way to tell who's sending him HFDL data. I'm feeding airframes.io JSON-formatted messages. It's basically for the same (or a similar) reason that's stated in the dumpvdl2 FAQ in its readme.

Thank you.

When using liquid-dsp 1.6.0 on Archlinux no messages are decoded but after downgrading to liquid-dsp 1.5.0 it works as expected.

feature - pse add grafana json

feature req - able to set freq offset for usage with spyverter etc.

Hello.
Would it be possible to have the option for dumpHFDL to output a Basestation format msg for those a/c where there is not a position or the position given is not valid. That way VRS would show a list of a/c, some with and some with out a position, but it would allow users to log aircraft from which they have had messages even if they do not have a position.
e.g. from these msgs

and

Thank you for you consideration.

OSoapySDR device ' driver=uhd,': readStream failed: OWERFLOW

This message comes when using usrp b210. But RTLsdr works fine.

Also there's no output when using dumphfdl versions (1.3 and 1.4). 1.2.0 is working fine with RTLsdr. However readStream failed message comes across all versions while using usrp ( driver=uhd)

Doing some testing today I realized that last week's force AGC to disabled devel branch commit causes a problem with Airspy Mini devices. (When I thought I tested it last week I was actually still using a binary built from Master)

Tested on two Airspy Mini devices back and forth with Master and Devel binaries. With binaries built from devel, if I add --gain-elements LNA=0,MIX=0,VGA=4 to dumphfdl config, the AGC (all gain) is off. There's no gain whatsoever until I remove --gain-elements and restart the dumphfdl instance. Using --gain-elements fine if I switch back to a dumphfdl binary built from Master. (Airspy autogain still works with devel binary as long as I don't use --gain-elements)

FYI - these older issues may be related to Airspy's soapy plugins instead of dumphfdl - unrelated to devel branch.

1. While --gain-elements works with Airspys, there's a small glitch. If I reboot with the --gain-elements flag in the dumphfdl config file (with dumphfdl as a systemd service to load at boot), the expected gain doesn't activate. It appears that the gain is really low, maybe AGC off. Simple work around is to remove --gain-elements before rebooting. Or just remove it after rebooting, restart dumphfdl, and re-add --gain-elements. Gain resumes as expected. (Oddly, after reboot, restarting dumphfdl service multiple times with --gain-elements still in the dumphfdl config doesn't work. I actually have to remove --gain-elments, then restart, then add it back in.). Perhaps I can test delaying service start after reboot, or adding some Wants or Wait-for-service in the systemd service config to see if this helps.
2. Another possible glitch, or possibly working as designed. Airspys will keep the same gain after I remove the --gain-elements flag and restart dumphfdl. Whatever the --gain-elements gain was set to before removing, is what I get after removing and restarting the dumphfdl instance. To reset autogain, the Airspy user must reboot without --gain-elements used in the config...
3. --gain-elements seems to have no effect with AirspyHF+ Discovery. Quick searching around made believe that this is because the SoapyAirspyHF plugin does not expose gain controls.

Hi,
I made some successful tests with I/Q data written by gnuradio. Needed gnuradio because there is no HPSDR support from SoapySDR.

Do you think it is possible to get this data through a simple TCP connection? Then there is no need to record to a file / stop recording / decoding / write new file. Then decoding would be like realtime receiption.

Would be a great improvement!

Would it be possible to feed dumphfdl with various ZMQ feeds? I suppose even if it could read one ZMQ feed a user could just open it multiple times.

I saw on Twitter someone asked about using a Red Pitaya that can deliver 8 udp streams, so I thought maybe gnuradio udp input to zmq output to dumphfdl or maybe somehow it could just go direct to dumphfdl w/ added udp input?