Bob Bruninga, WB4APR put out this call to determine the data mode being used by Garmin to transmit packet data.


I am on a mission to identify the mode. My belief is it is one of the FKS protocols. by law it has to be AFSK, FSK, or PSK.? Have any of you looked into this. Any ideas on how to sniff it out? Thank you. WS7PB

Re: my version of cmake:

cmake-3.20.5-1.fc34.x86_64

________________________________________
From: [email protected] <[email protected]> on behalf of David Ranch <direwolf-groupsio@...>
Sent: Thursday, November 24, 2022 12:37 PM
To: [email protected]
Subject: Re: [direwolf] strange CMake warnings building direwolf


Hello Andrew,

On 11/24/2022 06:58 AM, Andrew P. wrote:

Greetings.

I just pulled the latest from the git repo and built it on my Fedora Core 34 Linux system, and got the following warnings from cmake:

-- Dire Wolf Version: 1.7.0-8913a85

Ok.. Just an aside, the Github shows the same Git hash for the last commit on Sept 30th, 2022 but on my system using the command line git tool, I see:

--
commit 8913a852fd805e62b5312c055645da624b85ba2c (HEAD -> dev, origin/dev)
Author: wb2osz <wb2osz@...><mailto:wb2osz@...>
Date:   Sat Oct 1 02:32:43 2022 +0100

    clean up
--


Seeing different date and git hashes on the command line vs. the web interface is rather strange to me but I'm no Git expert.  Anyway.. moving on.


-- Build type set to: Release
CMake system: Linux
-- Target architecture: x86_64
-- Use SSE2 SIMD instructions
-- Use SSSE3 SIMD instructions
-- Use SSE 4.1 SIMD instructions
-- Use SSE 4.2 SIMD instructions
CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (HAMLIB)
  does not match the name of the calling package (hamlib).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/modules/Findhamlib.cmake:55 (find_package_handle_standard_args)
  CMakeLists.txt:290 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (UDEV) does
  not match the name of the calling package (udev).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/modules/Findudev.cmake:68 (find_package_handle_standard_args)
  CMakeLists.txt:304 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (AVAHI) does
  not match the name of the calling package (Avahi).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/modules/FindAvahi.cmake:12 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:309 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

I see similar things BUT my u22.04 machine includes lines saying it successfully found the various libraries.  See the BOLDED text below.  It's strange your output DOESN'T show any of that.  Btw, I don't have any Avahi libaries installed as I always rip that stuff out of my Linux machines:

--
$ cmake ..
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.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
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.34.1")
-- Dire Wolf Version: 1.7.0-8913a85
-- Build type set to: Release
CMake system: Linux
-- Target architecture: x86_64
-- Use SSE SIMD instructions
-- Looking for strlcpy
-- Looking for strlcpy - not found
-- Looking for strlcat
-- Looking for strlcat - not found
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Checking for module 'libgps'
--   Found libgps, version 3.22
-- Found GPSD: /usr/lib/x86_64-linux-gnu/libgps.so
-- Checking for module 'hamlib'
--   Found hamlib, version 4.3.1
CMake Warning (dev) at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (HAMLIB)
  does not match the name of the calling package (hamlib).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/modules/Findhamlib.cmake:55 (find_package_handle_standard_args)
  CMakeLists.txt:290 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found HAMLIB: /usr/lib/x86_64-linux-gnu/libhamlib.so
-- Found ALSA: /usr/lib/x86_64-linux-gnu/libasound.so (found version "1.2.6.1")
-- Checking for module 'libudev'
--   Found libudev, version 249
CMake Warning (dev) at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (UDEV) does
  not match the name of the calling package (udev).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/modules/Findudev.cmake:68 (find_package_handle_standard_args)
  CMakeLists.txt:304 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found UDEV: /usr/lib/x86_64-linux-gnu/libudev.so
CMake Warning (dev) at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (AVAHI) does
  not match the name of the calling package (Avahi).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/modules/FindAvahi.cmake:12 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:309 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Could NOT find AVAHI (missing: AVAHI_COMMON_FOUND AVAHI_CLIENT_FOUND)
-- Configuring done
-- Generating done
--


What version of cmake is on your Fedora machine?  I'm using 3.22.1 here.

--David
KI6ZHD

On Thu, Nov 24, 2022 at 08:02 AM, Christopher Maness wrote:

Is it possibly robust packet?

?

I don't know about robust packet. Pretty sure Direwolf defaults to FX.25 protocol. Anyway, after I got packets through to an i-gate in WI from my QTH in UT earlier this morning, I haven't had anything else decoded, nor have I decoded anything. Pretty disappointing. I don't think the band conditions are THAT bad today.

I've had direwolf running for a long time and haven't received any packets over RF.
Is anyone operating on 10.1476 MHz?

On upper side band?

Our local reference in VK;


Seems to be consistent with;


73, Kim VK5FJ

Le 24 nov. 2022 à 14:25, David, K7DMJ <davdj0nsn@...> a écrit :

Yeah, 30m band (in US, at least) ends at 10.150 MHz, so 10.151 MHz is a non-starter.

I just want to know if 10.1476 is the right dial frequency and whether there is any activity at all (or even any i-gates) on 30m.

I'm occasionally seeing a tone come up on the waterfall within my 3kHz passband but nothing is getting decoded. Still not seeing my beacons on aprs.fi

On 23 Nov 2022, at 22:27, David, K7DMJ <davdj0nsn@...> wrote:

David KI6ZHD,

I think you are 100% right about my problem being RFI.

I am transmitting on 10.1476 MHz USB using a 10 watt radio (FX-4C) into an end-fed random wire antenna, using a ATU-100 tuner.

After reading your message, I installed a current choke just before the coax from the antenna connects to the ATU, and also wrapped three turns of the USB cable connecting the FX-4C to the Surface Go through a clip-on ferrite. After doing that, I had no problems keying up PTT with Direwolf.

Now I have another problem: although I am transmitting packets, I am not seeing them being picked up on RF by any i-gate when I look at aprs.fi (my callsign is K7DMJ-1). What I am seeing instead is the packet going straight through TCPIP. This is not what I want. I'm trying to test my system for off-grid, where I won't have any internet connection. If my packets were being picked up by an i-gate on 30m, I assume that I'd see that in aprs.fi right? I think this is not working. I'm disappointed. Band conditions are supposed to be "Good" tonight on 30m.

I'm using MODEM 300 1600:1800 and I have via=GATE in my PBEACON command

I've had direwolf running for a long time and haven't received any packets over RF. Is anyone operating on 10.1476 MHz?

On 24 Nov 2022, at 06:51, f1mhv <F1MHV@...> wrote:

Out of band VFO dial? LSB is useless…

On 24 Nov 2022, at 08:52, Steve/KB9PVH via groups.io <kb9pvh@...> wrote:

?try 10.151 LSB

73.. --steve.kb9pvh--



Get Outlook for AndroidFrom: [email protected] <[email protected]> on behalf of Christopher Maness <christopher.maness@...>
Sent: Wednesday, November 23, 2022 11:50:10 PM
To: [email protected] <[email protected]>
Subject: Re: [direwolf] HF APRS 30m 10.1476 MHz right dial frequency?
Following. I was trying to decode those things too. I do believe
they have to be pretty strong to decode -- not the best for HF.

-Chris KQ6UP

On Wed, Nov 23, 2022 at 9:20 PM David, K7DMJ <davdj0nsn@...> wrote:

I've been listening and transmitting position beacons on 10.1476 MHz USB this evening using my 10w radio into a end-fed random wire antenna with Direwolf operating a 300 baud modem. Didn't hear or decode any traffic and none of my beacons were apparently picked up by an i-gate. Is this the correct dial frequency? Is anyone still using APRS on 30m?

I know the radio is working. I could see my FT8 signals being received in the Midwest on PSKreporter on 40m. I has a RFI problem earlier but have apparently fixed it.

--
Thanks,
Chris Maness