The error came on a older x86_64 KUbuntu desktp homebrew computer, with the motherboard sound card, and no PTT setting (VOX).? Direwolf has "no clue' how the PTT is being handled.
In fact, the testing was originally started with no radio connected at all.? How can the PTT be on for too long when thd non-connected radio has no connection to Direwolf to be measured (timed)?
On Fri, Jul 9, 2021 at 18:40, David Ranch
<direwolf-groupsio@...> wrote:
Hello Rob,
If you google the following term:
?? direwolf "Transmit timing error: PTT is on" "mSec
too long"
You'll see a few hits and one one of these talks about the issue
being known on non-Raspberry Pi 4 and newer hardware with it's
older USB stack.? What hardware are you using with your setup?? If
you are using older Raspberry Pi hardware, there is a workaround
you can try:
??
--David
KI6ZHD
On 07/09/2021 07:19 AM, Rob Giuliano
via groups.io wrote:
I used the config file you
proposed and it appears to be behaving now.
I am getting an error 1.7-dev-A that is
????? Transmit
timing error: PTT is on 104 mSec too long.?
I am using VOX (no PTT
settings), so not sure where this is coming from.
The times vary from about
100 mSec too long to maybe 250 mSec too long
This seems to be shorter
('too long time') and less often with the updated config.c
file.
With the original config.c,
they were as long as 500 mSec.
They only seem happen on TX
from an attached client (either [0L] or [1L], but not both),
or for PBEACON on the [1L] stream
On Thursday, July 8, 2021, 3:36:49 PM EDT, Brent WG0A
<bjpetit@...> wrote:
I bumped into this when trying to run two separate
instances of direwolf. One for VHF and one for HF. In
that case I would see a collision on port 8001. After
digging around a bit I found that the way to turn off
the 8001 default is to set KISSPORT 0 before any other
KISSPORT settings in the config.?
I also proposed a code change to the KISSPORT default
behavior here.
