Hi Edouard,
It has been a long time since I thought about details of the RS(63,12)
code used in JT65. I do not specifically recall have remembered that it
is a systematic code; and indeed when I look at the 12 six-bit
user-information symbols and 63 six-bit channel symbols for a particular
JT65 message, it does not appear to be a systematic code.
Here is an example of executing the test program "jt65code":
C:\Users\joe\wsjt\wsjtx_install>jt65code "CQ K1JT FN20"
Message: CQ K1JT FN20
Packed message, 6-bit symbols: 62 32 32 49 39 55 3 29 53 53 39 14
Information-carrying channel symbols:
43 0 14 31 20 37 23 32 44 39 24 34 1 25 56 58 0 2 41 55 5
20 48 37 49 33 19 8 47 42 20 58 14 42 48 47 10 5 38 32 40 39
21 48 47 28 40 0 1 20 39 31 41 52 27 63 47 50 8 41 40 52 9
Decoded message: CQ K1JT FN20
Maybe I am forgetting something about the way I carried out the
encoding? Bit ordering, or something? Anyway, at first glance my
encoder does not seem to produce a systematic code.
-- Joe, K1JT
On 2/5/2014 12:39 PM, [email protected] wrote:
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
