Re: [Tlf-devel] TLF run mode problem

[Drew Arnett]

Thanks for digging in, Ervin.

I will look at that pull request.  Another difference in my case is
that I'm using my pywinkeyerdaemon with a K1EL (www.hamcrafters.com)
'WinKeyer USB'.  https://github.com/drewarnett/pywinkeyerdaemon  (One
diff though, as I need to update it for the later python-serial lib;
timeout is now set by attribute, not method.  I also need to publish a
python3 version!)  Interrupting auto_cq to respond would involve
sending a message to NETKEYER/cwdaemon.  Maybe my implementation has a
subtle, problem causing difference?  I'll either examine my code
versus what cwdaemon does or just install the standard cwdaemon and
see if there is any difference.

I've also finished the experiment where I installed buster on the hard
disk and tlf and my config files.  The problem still exists.  So,
maybe that confirms that it is not the same problem pull 84 fixed.

I will pursue my idea regarding NETKEYER/cwdaemon/pywinkeyerdaemon
both by experiment and by reviewing cwdaemon and pywinkeyerdaemon
source.  I would be interested in hypothesis or suggestions for what I
may try.

Thanks and best regards,

Drew
kb9fko


On Thu, Aug 1, 2019 at 6:38 AM Ervin Hegedüs <address@hidden> wrote:
>
> Hi Drew,
>
> On Thu, Aug 01, 2019 at 02:17:13AM +0000, Drew Arnett wrote:
> > I just tried a fairly new desktop hard disk (less than a year old)
> > with an older USB 2.0 to SATA adapter.  I put my local working
> > directory there (logcfg.dat, rules, cty, partials, log), and the same
> > bad behavior persists.  Will install buster to hard disk (not via USB
> > adapter) and see how that behaves.
> >
> meanwhile I searched our discussion with Thomas, it was in
> January of 2018.
>
> The problem was not in the mode switching, but in the
> backgroud_process() - the cleanup() function called faster than
> the netkeyer sent the message to keyer.
>
> And that bug was fixed:
>
> https://github.com/Tlf/tlf/pull/84
>
>
> After read this mail from you, I'm sure in this case the problem
> is totally different, but currently I don't have any idea.
>
> Reflect to your apt-cache outputs: looks like this package is
> what I pushed to Debian (compared the hashes), not the another
> build. And the source of package is equals with the upstream reelase.
>
>
> To any other users: could someone check this version?
>
>
>
> Let's keep in touch,
>
>
> 73, Ervin
>