And also the NINO-TNC.? Much less expensive than the DRAWS hat if you don't need all the features...

And the NEXUS DR-X which still requires a sound card and direwolf, but will control 2 rigs seperately

Get

On Jan 17, 2022, at 13:15, John D Hays - K7VE <john@...> wrote:

There are also purpose built HATs like that don't have the audio transformer issues (especially when you want to move beyond 1200 baud).

On Mon, Jan 17, 2022 at 12:24 PM Don Rolph < don.rolph@...> wrote:

A signallink?will work, but is pricey and uses an onboard VOX approach.? There are cheaper interfaces which use the CM108 PTT control which is supported in Dire wolf and provides programmatic?control of PTT through?the 6 piin mini-din interface.

--

John D. Hays
Kingston, WA

K7VE / WRJT-215

?

A signallink?will work, but is pricey and uses an onboard VOX approach.? There are cheaper interfaces which use the CM108 PTT control which is supported in Dire wolf and provides programmatic?control of PTT through?the 6 piin mini-din interface.

A SignaLink works fine. You'll need to read the docs to find out how to setup the device name.

Mark

KD0QYN?

On Mon, Jan 17, 2022 at 1:35 PM, Don Rolph

<don.rolph@...> wrote:

An interesting question.

Some assumptions:

- you appear to be focused on Dire Wolf

- it seems you are focused on?Raspberry PIs

We can state up front that the internal sound capability of th Raspberry PI is inadequate: ?you will?need an add on sound system.

You are also left with the challenge of how?to handle?PTT: ?use hand held VOX or wire to PTT circuit in the handheld?speaker/mic connection.? The former is easy but clunky. ?the latter is hard to implement but effective.? The following may work:

-?

to provide the hardware PTT capability against the standard 6 pin mini-din connector.

Examples of Raspberry?PI packet interfaces can be found at:

-?

which discuss interfaces from?Raspberry PI ((Dire Wolf) to radios through?the 6 pin? mini-din.

I discuss?in:

-?

experiments with the IOS application using a Baofeng UV-5A and a Wouxun KG-UV6D.? Both gave quite acceptable?packet reception performance with packet reception on a par with my D72A.? Volume needed to be set to about 50%.

Packet send levels seem to be well controlled by the internal ALC circuitry.

The testing suggests that any handheld with the Kenwood?Speaker/mic connection will probably work reasonably well for packet IF you can obtain the needed the PTT behavior.

On Mon, Jan 17, 2022 at 1:33 PM Jon Adams <n7uv.jon@...> wrote:

I occasionally build porta-digis that need to fit in things like ammo cans and can run on a SLA battery and 10-20 W solar power for indefinite periods of time. This means no mobile radios as their rx modes always burn way to much power.

I've used up all my old Yaesu/Vertex hand-held 2m radios. A few years ago I interfaced a Baofeng UV5 to a KPC3+, got that to work but the receive performance was pretty poor (seemed to be receiver distortion). I also got another Baofeng (not the UV5 model, but quite similar) to work with a custom-built PTT/audio interface to a Direwolf instance on an RPi, but again what I was finding was the receiver distortion was pretty significant and receive performance was poor.

Given that there's now several more hand-held radios that are available and a heck of a lot more experience tinkering with them, I was wondering if there is any general consensus on "good-enough" performing hand-held radios for APRS 1200 baud?

Cheers and 73 - Jon N7UV

--

73,

AB1PH

Don Rolph

I occasionally build porta-digis that need to fit in things like ammo cans and can run on a SLA battery and 10-20 W solar power for indefinite periods of time. This means no mobile radios as their rx modes always burn way to much power.

I've used up all my old Yaesu/Vertex hand-held 2m radios. A few years ago I interfaced a Baofeng UV5 to a KPC3+, got that to work but the receive performance was pretty poor (seemed to be receiver distortion). I also got another Baofeng (not the UV5 model, but quite similar) to work with a custom-built PTT/audio interface to a Direwolf instance on an RPi, but again what I was finding was the receiver distortion was pretty significant and receive performance was poor.

Given that there's now several more hand-held radios that are available and a heck of a lot more experience tinkering with them, I was wondering if there is any general consensus on "good-enough" performing hand-held radios for APRS 1200 baud?

Cheers and 73 - Jon N7UV

In my shack, I have an RPi with a hardware RTC, running weewx and direwolf, and using a serial GPS with 1pps output connected to the RPi serial port, then gpsd and ntp. Keeps excellent time (microsecond stable) and also serves as the NTP server for the house. The biggest deal was making sure shell was disabled on the serial port.

Cheers and 73 - Jon N7UV

Charles -

There are two different time synch services available in the Debian distribution used as a base for the Rpi.

One is the service you've asked about , known to the system as "systemd-timesyncd.service".
The other is the service that is being used to sync time, known to the system as "ntp.service".

The command "timedatectl" with no arguments examines the system clock in the context of "systemd-timesyncd.service", and is equivalent to "timedatectl status".
Typing "timedatectl show", on the other hand, shows different output.

Examining the current state of the services managed by the system (a.k.a "daemons" or "demons") is done by the command systemctl.

To examine both of the services mentioned above, type the following command in a console (terminal):
systemctl list-units --all ntp.service systemd-timesyncd.service

On my Rpi 4B, using the 1.5 HamPi distribution, here is the leading few lines of output
UNIT????????????????????????????????? LOAD?? ACTIVE?? SUB?????? DESCRIPTION??????????????? ?
ntp.service????????????????????????? loaded??? active??????? running? Network Time Service?????? ?
systemd-timesyncd.service loaded?? inactive???? dead?????? Network Time Synchronization

This shows that the "ntp.service" is up and running, doing it's task of syncing the clock, as specified by /etc/ntp.conf .
To obtain more details about the status of ntp.service, the command "ntpq" can be used, but the various options assume wizard-status on the distributed time service implementation and function.

A useful command is "ntpq -n -c lpeers" , where the output is in dotted-quad IP addresses. The leading asterisk indicates the current time source, the plus indicates "candidate" to become a source, and the minus indicates "outlier" status.

Hope this helps clear up any confusion. Post any follow-up questions in this thread, and I'll attempt to answer.

Walt
W1ALT
(Unix/linux nerd for most of my working life)

I have a Pi 4, and am using the mid December version of Hampi.? (ie the
one before new years update.

the time takes a few moments to set itself, but then deems to drift.

if I type timedatectl
? in a console, I find that systemd-timesyncd.service active: is
indicating that the service is NOT running.

searching on the internet I get all sorts of anwers, most suggesting
installing ntpd invariably followed by another post saying No that is
not the way to do it.

I don't think I have changed any settings from the way hampi was
packaged.? I just made a new sd card of the system about a week before
the new years update, and I noticed that some folks were having problems
with the latest version using wsjt-x so I am hesitant to start fresh
with hampi 2.0.

I am sure that their is a simple thing that I have missed.? the pi is
plugged into my local network, (which then is connected to the net via
DSL)? and the kubuntu pcs on that network seem to manage to stay in sync.

ideas?


--
Charles MacDonald? VA3CPY? ? ? ? ? ? ? ?Stittsville Ontario
cmacd@...? ? ? ? ? ? ? Just Beyond the Fringe
No Microsoft Products were used in sending this e-mail.