Hello Joe and all, well the Sunny Riviera doesn't really deserve the term "sunny" these days but we have nothing like an ice storm (yet!).
I wanted to contact you earlier about this but moved to something else and the subject of linking with the RS decoder brought me back to the idea. I think the main and possibly only thing preventing from making WSJT work with my decoder is the fact that this decoder cannot work with systematic codes. i.e. where the original message itself is included in the RS codeword. I see that WSJT uses this type of coding and this has to be kept for compatibility with older or "third party" software. With (quite?) a bit of math works it may be possible to have my library work with systematic codes but I haven't made any research in this direction yet. I suppose there should be a way to convert a non-systematic code to a systematic one and vice versa. Indeed I am particularly interested in weak-signal communication and the investigations I have made with the possibility of using Gold Codes in a similar way as the GPS system does (my "WSGC" project) tends to prove that MFSK is still the way to go when dealing with disturbed radio paths. 73s! Edouard, F4EXB. Quoting Joe Taylor <[email protected]>: > Bonjour Edouard, > > Many thanks for your message, and for drawing my attention to your > well-documented work on Reed-Solomon soft-decision decoding and > weak-signal communication in general. I had no idea that another ham > was working on these things. I have look at your web site and done a > quick read of several of the papers there, bit I will need more time to > fully appreciate what you have done. > > I would definitely be interested in trying your open-source decoder for > the (63,12) code in place of the one I implemented in KVASD. If you are > interested in helping with this, I will be happy to describe for you the > I/O mechanism used to interface with our executable kvasd. > > Please note that things may be slow for me today, and possibly (I hope > not) for a few days. We have had a rather severe ice storm and are > without power at home. I'm now in my Princeton University office. > > -- 73, Joe, K1JT > > On 2/5/2014 9:28 AM, [email protected] wrote: > > 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 > _______________________________________________ Wsjt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/wsjt-devel
