Hello Take,
I hope some coordination function will be established to sort out for the
> priority list.
Well, I think that as long as the boss is reliable (and Joe is reliable),
it his up to him to sort out the priorities and decide.
A couple of years ago, when we worked hand-in-hand to implement what
contained in the QRA64 modes, we were both much interested in what could
have came out of the couple of ideas we had and this was really amazing, I
think for both of us, almost independently of any comment we received. We
were just working on something each of us already knew in some detail (i.e.
Joe the Costas synchronization patterns and me some simple LDPC code) and
we just wanted to put things together in the attempt to provide something
better than, not just different from, what already done.
Making long discussions about what new could be implemented and what could
not does not help a developer very much. Usually the developer has already
clear in his mind what he wants to implement; he of course needs the help
and the appreciation of the other developers in the team otherwise things
get more difficult to do. I.e. I just barely knew where to put my hands in
the WSJT-X code and got helped by the team.
I think that Joe's ears are always open and careful to new ideas. Anyway
not all the new ideas are really meaningful. Again, as WSJT-X carries his
first names, I think that any final decision should belong only to him.
There are many things that we can suggest him but such suggestions should
already contain some significant and proved advantages and/or results
otherwise they would make him spend time to verify what others should have
already done before.
Developing means to do many simulations of what one would like to
implement, not just write down some C source code in the hope that it does
magic things just because it looks that it should.
In few words, there's a lot of work to do behind the fifth. Therefore
simple suggestions help less than true cooperation.
For what concern hashing I have already an idea in my mind. I would not
call it hasing but simply source encoding. We insist to encode messages in
a way which is much less efficent than the way we would employ if we
exploited the fact that a 2-way QSO: 1) is a sequence of messages and 2)
the messages in this sequence can be always split in two parts, where the
first part is ALWAYS and ALREADY known and shared by both of the stations
partecipating to the 2-way QSO.
With this in mind, each 2-way QSO with reports/maidenhead locators and
final acknowledgments could be implemented as a sequence of six messages
each carring only *28* bit per message (even less if one would like to
optimize the protocol further, something more if we would like to use
cyclic redundancy checks).
I should have mentioned this to Joe some months ago but we had some
problems to communicate as my email server was randomly blacklisted by his
server.
Anyway, to be implemented the idea requires a good set of codes which I'm
still working to and that's why I'm not yet suggesting it :-)
Finally, I enjoyed the conversation with you and thank you very much.
Me too, thanks!
73
Nico / IV3NWV
2018-09-02 4:54 GMT+02:00 Tsutsumi Takehiko <ja5...@outlook.com>:
> Hi, I will make another noise from the floor as Iztok wrote as follows,
> “Commenting
> contribution by Take, Igor etc:”
>
> Two topics, hashing and diversity technologies has been repeatedly on the
> topics from the readers of this mailing list in the past and are willing to
> adopt by the development team by similar reason. On the other hand, I did
> not have my memory that “ WSJT-X2.0” and “Dxpedition mode” to be fairly
> discussed and adopted among readers of this mailing list. Therefore, I
> sense there is the perception gap about the priority of the development
> task between the development team and the readers. As I belong to the group
> the readers, I naturally have my impression that the development team is
> hearing Devil’s whisper too much. I know I am totally wrong but I can not
> totally deny this nightmare as I live JA, where a thousand miles away from
> the development team. I hope some coordination function will be established
> to sort out for the priority list.
>
>
>
> Nico, you may discover new diversity merits at HF propagation at Shannon’s
> limit region just like you and Steve noticed in M-ary FSK BER vs. Eb/N0
> curve which did not much been addressed 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 10
>
>
> ------------------------------
> *From:* Nico Palermo <nico...@microtelecom.it>
> *Sent:* Sunday, September 2, 2018 9:19:43 AM
> *To:* k...@arrl.net; WSJT software development
> *Subject:* Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
>
>
> 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
>> MF/HF bands before assuming that the two receivers can be added. I could be
>> wrong, but I strongly suspect that signals at the two receivers will be
>> displaced in time, and that the displacement can be a variable by virtue of
>> the variability of those paths.
>>
>
> Jim,
> symbol transmitted by FT8, JT65 and so on are long hundreds milliseconds.
> On HFs, such time interval is usually 1) shorter than the channel
> coherence time (which is seconds) and 2) still much longer than the channel
> delay spread (which is milliseconds).
> Therefore, for signals few Hertzs wide, the channel appears as a
> slow-varying frequency-flat medium whether you use diversity or you don't.
>
> In these cases space diversity helps only because the probability that two
> uncorrelated signals exhibit a given amount of fade at the same time is
> much smaller than the probability that a single copy fades out.
> Frequency selectivity can be almost safely neglected. You don't need
> OFDM systems to cope with selective fading if you are transmitting at few
> bits per second in the HFs.
>
> 73
> Nico / IV3NWV
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
