Hi,
First: thank you all for a phenomenal tool !
I have a question/issue : I cannot make the split mode work with a ft-991a
interfaced to a Mac.
I’m using v1.7.0 r7405
I can make my radio move to another frequency on VFOa when in “fake it” mode.
I can also make my rig go into split mode with VF
On 31/03/2017 00:44, Josh Rovero wrote:
> If one of the WSJT-X instances "hangs" and leaves a lock file, other
> applications under AppData\Local, like Google Chrome, can't access
> their data. So if I bring up Chrome and it complains that it can't
> access profile data, I know that one of my W
Thank you - "Ctrl M" restored the widegraph parameters.
Colin mm5agm
From: CX8AT VERA [mailto:cx...@vera.com.uy]
Sent: 30 March 2017 18:26
To: WSJT software development
Subject: Re: [wsjt-devel] Development R7624 - widegraph parameters
Try "Ctrl M"
Al
CX8AT
On 30/03/2017 14:13, Colin99 Campbel
I run multiple instances of WSJT-X 1.7.1 simultaneously under Windows 10
64-bit. Normally 10 or 12 per computer. Each instance is started with
the --rig_name= parameter and writing to a different directory
under $APPDATA, such as:
C:\Users\\AppData\Local\WSJT-X - one
C:\Users\\AppData\Loc
Hi Bill and Mike,
I’d like to correct the following:
> The LDPC decoder will either produce a valid codeword, or nothing (an
> erasure). The CRC is being used to detect these invalid codewords.
to say, instead:
The LDPC decoder will either produce a codeword from the list of codewords
defined
I do see his note now at the bottom of the tables.
His "implicit + 1" is probably because you always want the low order bit set.
I see his hdlen utilty also expects implicit+1 for the poly argument.
de Mike W9MDB
From: Bill Somerville
To: Black Michael ; WSJT software development
Sent:
On 30/03/2017 18:13, Black Michael wrote:
Doesn't look to me as though 0x1e7 is a good choice as it doesn't even
cover HD=3 for 88 bits.
0x8f3 is much superior.
Hi Mike,
clearly I did not get my point across very well. There is a notation
issue here.
Koopman uses a self-admittedly quirky n
Try "Ctrl M"
Al
CX8AT
On 30/03/2017 14:13, Colin99 Campbell wrote:
Hi all,
I’ve just installed R7624 on a Windows 10 PC and there doesn’t appear
to be any parameter controls at the bottom of the widegraph,
Bins/Pixel for example.
Another, extremely trivial observation, is that if you sele
It's in the Help file under section 10.10 Miscellaneous. Maybe we need another
location to mention it?
CTRL-M works on all windows to hide/show controls (i.e. [M]inimize)
de Mike W9MDB
From: Colin99 Campbell
To: WSJT software development
Sent: Thursday, March 30, 2017 12:16 PM
Subjec
Hi all,
I've just installed R7624 on a Windows 10 PC and there doesn't appear to be any
parameter controls at the bottom of the widegraph, Bins/Pixel for example.
Another, extremely trivial observation, is that if you select "Hide menus and
labels" under the "View" menu it does indeed hide them
Doesn't look to me as though 0x1e7 is a good choice as it doesn't even cover
HD=3 for 88 bits.0x8f3 is much superior.
Poly=0x1e7 startHD=3 maxHD=9# 0x1e7 HD=3 len=15 Example: Len=16 {0} (0x100)
(Bits=2)# 0x1e7 HD=4 len=15 Example: Len=16 {0} (0x100) (Bits=2)# 0x1e7
HD=5 len=1 Example: L
On 30/03/2017 17:05, Bill Somerville wrote:
/x^12 + x^8 //+ //x^7 //+ x^6 //+ x^5 //+ x^2 + x + 1
/
I note that it doesn't have an even number of bits (yes that is
confusing too) so apparently cannot detect all errors with an odd
number of bits set according to this:
http://www.repairfaq.org
On 30/03/2017 16:44, Bill Somerville wrote:
that would be 0x0cf1 in the notation of Boost CRC as he uses a quirky
"implicit +1" notation.
Hi Mike & Steve,
Oh dear, my message is even more ambiguous than these polynomial
notations! Plus I inadvertently inverted it. Ouch!
What I meant was tha
I guess our BER is approximated by how many transmitted messages fail CRC since
it's real-life testing that really matters, right?
To achieve 1/10 and it looks like we're doing CRC on 11*8=88 bits, right?
So 10/88 = 1,136So, at most, only one out of every 1,136 messages would
fail CRC to
On 30/03/2017 16:36, Black Michael wrote:
0x80f gives slightly worse performance then either 0xc07 or 0x8f3
Hi Mike & Steve,
that would be 0x0cf1 in the notation of Boost CRC as he uses a quirky
"implicit +1" notation.
73
Bill
G4WJS.
Hi Mike and Bill -
The LDPC decoder will either produce a valid codeword, or nothing (an erasure).
The CRC is being used to detect these invalid codewords. If the code is any
good to begin with, an incorrect codeword will differ from the correct one in
quite a few bits, i.e. we should see only
0x80f gives slightly worse performance then either 0xc07 or 0x8f3
Poly=0x80f startHD=3 maxHD=7# 0x80f HD=3 len=2032 Example: Len=2033 {0}
(0x800) (Bits=2)# 0x80f HD=4 len=2032 Example: Len=2033 {0} (0x800)
(Bits=2)# 0x80f HD=5 len=1 Example: Len=2 {0} (0xc08) (Bits=4)# 0x80f HD=6
len=
On 30/03/2017 15:45, Bill Somerville wrote:
What I am not so sure of is if the Boost CRC library requires it to be
specified as 0x080f or as 0x180f.
Hi Steve & Mike,
I can confirm that the highest order coefficient of the CRC polynomial
never needs to be given so to use:
/x^12 + x^11 + x^3
I noticed Phillip has update his webiste since the 2004
publicationhttps://users.ece.cmu.edu/~koopman/crc/index.html
Now recommends 0x8f3 as the best 12-bit poly.
Testing 0xc06 gives this which shows 0xc06 cannot achieve HD=4
Poly=0xc06 startHD=3 maxHD=6# 0xc06 HD=3 len=79 Example: Len=80 {0
On 30/03/2017 16:02, Black Michael wrote:
> Don't we expect a much higher BER?
HI Mike,
in this case the CRC is checked after FEC using LDPC so the error rates
should be low.
73
Bill
G4WJS.
--
Check out the vibrant te
Actually, reading his website it's even less clear what should be used
He says these polynomials are only good for a low BER of 1/100,000.
Don't we expect a much higher BER?
de Mike W9MDB--
Check out the vibrant tech co
If we're wanting to save bits the table given in the reference is quite handy.
Also handy for determining the best poly to use.So if we're doing 72 bits you
can do a 8-bit CRC with 0x97 to give HD=4, but to get HD=5 you need a 14-bit
CRC. 12-bit solutions probably give better hamming distances
On 30/03/2017 15:25, Black Michael wrote:
Where'd you get 0x180d from?.
Hi Mike,
I took the polynomial that Steve used, 0x0c06, and applied his incorrect
assumption that the lowest order coefficient was truncated and assumed
to be 1:
0x0c06 x 2 + 1 = 0x180d = /x/^12 + /x/^11 + /x/^3 + /x/^
Where'd you get 0x180d from?.The reference on this uses a 48-bit data word and
poly 0xc07 and actually recommends 0x8f8 as it achieves HD=5 where 0xc07
achieves HD=4. 0x8f8 also has a lower hamming weight when you sum HD4 through
HD6.We want the highest detection of all possible corruptions, don
Hi Mike and Bill -
OK - I clearly need to work out some CRC’s by hand and make sure that I
understand what the routine is calculating.
In any case, I believe that what matters is the final undetected error rate
that we achieve by using the CRC to detect incorrect codewords identified by
the
On 30/03/2017 15:06, Bill Somerville wrote:
> That, I think, means that the polynomial should be specified as 0x180d
> for the intended CRC.
Having said that, 0x080f looks more promising.
73
Bill
G4WJS.
--
Check out th
On 30/03/2017 14:47, Black Michael wrote:
Don't they mean the high order bit and not the low order one?
Hi Mike & Steve,
I believe Mike is correct. When using 8-bit, 16-bit, 32-bit, 64-bit etc
sums the highest order bit will always require a register one bit wider
but that bit is also always
Don't they mean the high order bit and not the low order one?
The templates they give show the correct polynomials and changing to 0xc07 does
change the answer so the low order bit is not ignored.
typedef crc_optimal<16, 0x8005, 0, 0, true, true> crc_16_type;
typedef crc_optimal<16, 0x1021
> On Mar 30, 2017, at 8:15 AM, Bill Somerville wrote:
>
> On 30/03/2017 13:59, Black Michael wrote:
>> You may want to check your polynomial. I do believe 0xc06 should be 0xc07
>> -- you never want a zero x^0 term.
Hi Mike,
The polynomial argument provided to the Boost CRC library is a trun
On 30/03/2017 13:59, Black Michael wrote:
You may want to check your polynomial. I do believe 0xc06 should be
0xc07 -- you never want a zero x^0 term.
https://en.wikipedia.org/wiki/Polynomial_representations_of_cyclic_redundancy_checks
What's the logic behind using a 12-bit CRC? Is there a p
You may want to check your polynomial. I do believe 0xc06 should be 0xc07 --
you never want a zero x^0 term.
https://en.wikipedia.org/wiki/Polynomial_representations_of_cyclic_redundancy_checks
What's the logic behind using a 12-bit CRC? Is there a plan of some sort here?
de Mike W9MDB
F
31 matches
Mail list logo
