Hi all,
I should have mentioned that (as of r5987) the code in .../trunk builds
WSJT10 so that JT65 decoding is done in sfrsd2, and kvasd[.exe] is no
longer required. If we no problems arise, we can probably leave it this
way and do away with all non-free code.
-- Joe
On 10/20/2015
Hi Joe,
When you all are ready, I'll look at what needs doing to update the
JTSDK builds and InnoSetup files to ommit the KVASD binary inclusions
for WSJT. Both changes should be fairly simple.
73's
Greg, KI7MT
On 10/20/2015 14:13, Joe Taylor wrote:
> Hi all,
>
> I should have mentioned
Hi Joe,
Yup, I was just looking at what all you've done.
For Windows, it looks like, all we need to do is update the CX_Freeze
files in Makefile.jtsdk2; remove kvasd.exe kvasd.dat
For Linux, the Makefile does not include KVASD so should be no trouble
there.
I looked through / verified the
Hi Joe,
No worries on the reply; I know you and Steve have been hard after this
new decoder stuff, which is far more important.
I've been playing with Python Scripts and such; creating tables, queries
and things for WSJT, but nothing with WSJT-X. I was toying with an Idea
of add a contest
Thanks, Greg. I think I've already made the changes necessary to make
JTSDK build using sfrsd2. I have *not* removed the kvasd stuff, however.
-- Joe
On 10/20/2015 4:36 PM, Greg Beam wrote:
> Hi Joe,
>
> When you all are ready, I'll look at what needs doing to update the
>
Hi Steve and all,
I will be traveling and mostly out of touch for the next three days, so
I want to bring you up-to-date on what I've been doing.
Directory .../trunk/rsdtest now has code for three programs that do
their Reed-Solomon decoding in sfrsd2.
rsdtest - reads s3() data from file
Hi Greg,
I intended to respond to this message of yours some weeks ago, but
apparently forgot to do so.
Basically, I think it's a good idea to look carefully at possible use of
SQLite for several tasks in WSJT-X: logging and a replacement for
CALL3.TXT are two good possibilities.
Have you
