Hello All, if this is of interest to any of you I have committed an open source library in C++ for Reed-Solomon soft decoding: https://code.google.com/p/rssoft/
It has been dormant for a while and I haven't investigated the possibility to replace kvasd executable with a clone of it using my library instead. I lack the knowledge of the I/O protocol to kvasd and didn't want to invest time in reverse engineering it. Also an important divergence is that my library cannot work with systematic codes. Yet I have tried to make a comparison with the kvasd engine by building a minimal clone of JT65 (as an offspring of another project also dormant) and using figures given by Joe in his paper. I have found that my library has a 0.5 dB disadvantage vs kvasd. But if this can be of some use... at least understanding what's behind the scene and possibly improving the basic algorithm I have tried to put in place that would be all the better. Please feel free to use and contribute! 73s! Edouard, F4EXB. Quoting Bill Somerville <[email protected]>: > On 04/02/2014 18:45, Joe Taylor wrote: > > Bill -- > > > >> Having said that it does appear to be portable! I suspect that the libc > >> dependencies from libgfortran were not pulled in because they weren't > >> referenced. > > > > Nearly all of kvasd is written in C -- there's just a fortran wrapper > > that calls the C code. There must be plenty of references to things > > in libc. > Obviously they have improved the granularity of libc since I last did > this sort of thing. > > There is another issue, in theory you may be breaking the terms of the > LGPL licence. If you static link LGPL code I believe you may need to > publish your object code (possibly source code). I believe the issue is > that you are distributing a "derivative work" rather than linking to > something that the end user can freely obtain from an official source > unmodified. Clearly a show stopper in this case if that is the case. > Having said that IANAL and this particular consequence of the LGPL > licence is often argued either way. > > > > -- Joe > 73 > Bill > G4WJS. > _______________________________________________ > Wsjt-devel mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/wsjt-devel > _______________________________________________ Wsjt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/wsjt-devel
