Re: [wsjt-devel] choosing the best CRC for short data blocks

2018-01-25 Thread Nico Palermo
Hi Steve, As it turns out, the most likely number of incorrect bits in the 87-bit > message+CRC block contained within incorrect codewords is 20. After reading Don message I was just figuring out this number for the LDPC code used by FT8 :-) What Don probably misinterpreted is that Koopman's

Re: [wsjt-devel] choosing the best CRC for short data blocks

2018-01-25 Thread Nico Palermo
> They all reduce the number of incorrect decodes by about a factor of > 2^12=2048. Obviously, I have a problem with basic arithmetic. I should have said > 2^12=4096. > It looks almost the 1.6 factor Joe was speaking about :-) 73 Nico / IV3NWV

Re: [wsjt-devel] choosing the best CRC for short data blocks

2018-01-25 Thread Nico Palermo
> > the chance that the error pattern passes the CRC test, that's to say the > probability that an error goes undetected, is just inversely propoprtional > to 2^L where L is the CRC polynomial degree. That's why when a system uses an ECC what really matters to counterfeat > undetected errors is

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

2018-08-30 Thread Nico Palermo
Furthermore there is no need to improve a protocol just to cope with energy limits when a really variable medium, as the ionosphere is in the HFs, is the limit itself. Of course we could think to a new mode in which a 2-way QSO between two antipodal points on earth would require 50 mWatts instead

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

2018-08-31 Thread Nico Palermo
e JA5AEA > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > -- > *From:* Nico Palermo > *Sent:* Friday, August 31, 2018 7:04:31 AM > *To:* WSJT software development > *Subject:* Re: [wsjt-devel] WSJT-X 2.0

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

2018-08-31 Thread Nico Palermo
> > Probably we can add more flexibility if some information will be passed > over Internet, for instance free text messages and GRID, it will spare more > bits toward sensitivity on the radio interface. Ok, Igor, but then I would prefer to call the new modes "Weak Internet Communications". 73

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

2018-09-01 Thread Nico Palermo
> Most applications of diversity reception are on the MF and low HF bands. I > believe that most fading on these bands is selective fading, where signals > traveling slightly different paths, the low-frequency equivalent of > picket-fencing at VHF/UHF. It might be worth studying propagation on the

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

2018-09-05 Thread Nico Palermo
Take, we can indeed agree that transmitting an hash key could be better than to send a full call sign. Anyway when you transmit an hash key you miss the possibility for receivers to go back to the original information unless they decode a complete sequence of messages. With FT8 or with all the

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

2018-09-11 Thread Nico Palermo
Igor, I think that the Vojager probes communication links still work without any HLR/VLR database technique at a distance of more than 100 astronomical units and nobody makes complaints. Am I missing something I yet don't know? 73 Nico / IV3NWV ___

Re: [wsjt-devel] Another achievement for QRA64

2018-10-27 Thread Nico Palermo
Congratulations to you and Rex, Charlie. I guess that it has not been so easy to make such a remarkable EME, earth limb to earth limb, 19116 km QRB QSO on 10 GHz. Really pretty. 73 Nico / IV3NWV Il giorno sab 27 ott 2018 alle ore 12:25 < char...@sucklingfamily.free-online.co.uk> ha scritto: >

Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol

2018-09-02 Thread Nico Palermo
ed in classic textbooks. > > > > Finally, I enjoyed the conversation with you and thank you very much. > > > > 73 > > > > take > > > > de JA5AEA > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows

Re: [wsjt-devel] Bug in qra64.c

2019-01-08 Thread Nico Palermo
> > if ((x[9]&0x80)==1) > return; > warning: bitwise comparison always evaluates to false Nothing really important but I would have appreciated more a warning like this: warning: bitwise comparison always evaluates to false, therefore I will refuse to compile this source code until you

Re: [wsjt-devel] Bug in qra64.c

2019-01-09 Thread Nico Palermo
> We could enable -Werror by default :) > That would be great indeed, Richard. I must remind myself to do it always ;-) 73 Nico / IV3NWV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net

Re: [wsjt-devel] Call for information about PC systems being used for WSJT-X

2021-06-09 Thread Nico Palermo
Some things can be done more efficiently if they are "vectorized" but not all the algorithms can be easily vectorized with the current technology and maybe that chess games belong to this case, I'm not expert about them. For what concerns our case, there's a lot of things that we can do in order

Re: [wsjt-devel] Call for information about PC systems being used for WSJT-X

2021-06-11 Thread Nico Palermo
The same CPU I'm using here, Frank. Actually the cores are only 4. It's Intel Hyper Threading technology that makes them appear as 8. Anyway it's not bad. Exploiting the AVX instruction set and all of its cores, the computing power of an i7-4770 amounts to about 0.11 TeraFLOPS, that's to say

Re: [wsjt-devel] WSPR sync vector generator polynomial?

2021-05-16 Thread Nico Palermo
Hi Phil, I don't know what Joe used in WSPR but, for instance, he told me that he generated the sync sequence used in Q65 by means of direct optimization of its autocorrelation function, not in an algebraic way, so that its lateral peaks were minimum only in a limited time shift interval. I guess

Re: [wsjt-devel] WSPR sync vector generator polynomial?

2021-05-16 Thread Nico Palermo
/ IV3NWV ___ Il giorno dom 16 mag 2021 alle ore 23:36 Phil Karn ha scritto: > On 5/16/21 09:15, Nico Palermo wrote: > > Hi Phil, > > > > I don't know what Joe used in WSPR but, for instance, he told me that > > he generated the sync se