tlf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tlf-devel] TLF maintenance release 1.0.1


From: Andy Summers
Subject: Re: [Tlf-devel] TLF maintenance release 1.0.1
Date: Sun, 23 Jan 2011 21:05:45 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7

Hi Tom,

Thanks for that.

There's a bug in netkeyer.c since TLF-1.0.0 that I can't figure out.

Its symptoms are that when in SSB mode and you hit, say, F1 to send that recorded message, cwdaemon gets a PTT=1 command but gets another PTT=1 at the end of the message when it should get PTT=0. The effect is that the rig is permanently keyed after pressing the F-key.

I've had a look, but I'm confused because the correct string seems to be sent to the sendto() system call. Even more confusing is if I edit callinput.c so it sends PTT=0 at the beginning of the message, it still asserts PTT!

If I revert to netkeyer.c from TLF-0.9.31 PTT works OK again, but I don't see that much is changed in that file. Another weird thing is that if I go back to the new version, recompile, it stops working properly, then go back to the old version and it still doesn't work. If I then do 'touch netkeyer.h' and recompile it's fixed again. There's no difference between the two .h files.

My feeling is that sendto() is getting upset somehow, but I'm not good enough with C to work it out.

Has anyone else seen this, and/or does anyone have any ideas? For the time being, I'm using netkeyer.c from TLF-0.9.31.

73 Andy, G4KNO.

On 15/01/11 14:40, Thomas Beierlein wrote:
Please find a maintenance version TLF-1.0.1 at:

http://www.staff.hs-mittweida.de/~tb/tlf-1.0.1.tar.gz

Bug fixes:
----------
  * Fix logfile read error. Last QSO got read in twice.
  * Fix bug in cty.dat and in the routine which reads in the file
    Some prefixes from BY were not recognised.
  * Fix calculation of sun up and down time in MUF prediction window.
    It is now based on longitude from country description in cty.dat
    instead of the former timezone difference. That should be more
    accurate now.

73, de Tom DL1JBE





reply via email to

[Prev in Thread] Current Thread [Next in Thread]