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

2018-08-09 Thread Neil Zampella 

I'd just leave it to the WSJT-X team, and only the WSJT-X team.

Neil, KN3ILZ


On 8/9/2018 4:08 PM, Andras Bato wrote:

George is quite right!
Leave it to the dev team -and to Igor!
It well worth to test what does JTDX dev team do.
gl de ha6nn
Andras

On Wed, Aug 8, 2018 at 1:10 PM, George J Molnar > wrote:


I think he is lamenting the “loss of sensitivity” with FT8
compared to JT65 now that the former has come to dominate. Not
sure his math works out, so will leave that to the dev team.
Imagine they are keenly interested in performance, too.

George J Molnar
Virginia, USA


> On Aug 8, 2018, at 8:04 AM, Neil Zampella mailto:ne...@techie.com>> wrote:
>
> Frankly,  I don't see where you're getting the idea that JT65
sensitivity is missing?
>
> It is still much more sensitive than FT8, and will be for the
foreseeable future, as are the other WSJT-X modes.    JT9A is at
-27, JT65A is at -25, and QRA64A is at -26.   FT8 is -21 .. all
this is based on a average noise floor.
>
> I don't see what your 'new mode' is going to accomplish.
>
> Neil, KN3ILZ
>
>
>> On 8/8/2018 2:29 AM, Игорь Ч wrote:
>> Hello Joe and all,
>> .
>> We all have been missing JT65 mode sensitivity and proposed
WSJT-X 2.0 new FT8 approach with 0.2 dB sensitivity penalty can
make things even worse.
>> .
>> I would like to ask you to consider a new protocol where
callsign hash would be used instead of the real callsign in all
messages but CQ and incoming call, this way we can get back to
-25..26dB SNR sensitivity although will get more limited with the
free message length.
>> .
>> CQ message: 28 bit callsign1  + i5bit + 12 bit CRC = 45 bit
>> incoming call: 10 bit call1 hash + 28 bit callsign2 + i5bit +
12bit CRC = 55 bit
>> report message: 10 bit call2 hash + 10 bit call1 hash + i5bit +
(10 bit call3 hash for DXpedition) + 6 bit report + 12 bit CRC =
43(53) bit
>> roger+report message: 10 bit call1 hash +  10 bit call2 hash +
6 bit report+ i5bit + 12bit CRC = 43 bit
>> 73 message: 10 bit call2 hash + 10 bit call1 hash  + 15 bit
GRID + i5bit + 12bit CRC = 55 bit
>> RR73 message: 10 bit call1 hash + 10 bit call2 hash + 15 bit
GRID + i5bit  + 12bit CRC= 52 bit
>> .
>> Spare bits can be used for nonstandard(special) callsign
transmission in CQ message. call1 hash could be omitted in the
incoming call message if this message is originated by the
nonstandard(special) callsign.
>> .
>> Probably we can optimize protocol even better while a main idea
is to transmit a full callsign only once per each QSO and to
transmit not more than one full callsign in the message.
>> .
>> 73 Igor UA3DJY
>
>
>

--
> 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





--
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

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

2018-08-09 Thread Andras Bato 
George is quite right!
Leave it to the dev team -and to Igor!
It well worth to test what does JTDX dev team do.
gl de ha6nn
Andras

On Wed, Aug 8, 2018 at 1:10 PM, George J Molnar  wrote:

> I think he is lamenting the “loss of sensitivity” with FT8 compared to
> JT65 now that the former has come to dominate. Not sure his math works out,
> so will leave that to the dev team. Imagine they are keenly interested in
> performance, too.
>
> George J Molnar
> Virginia, USA
>
>
> > On Aug 8, 2018, at 8:04 AM, Neil Zampella  wrote:
> >
> > Frankly,  I don't see where you're getting the idea that JT65
> sensitivity is missing?
> >
> > It is still much more sensitive than FT8, and will be for the
> foreseeable future, as are the other WSJT-X modes.JT9A is at -27, JT65A
> is at -25, and QRA64A  is at -26.   FT8 is -21 .. all this is based on a
> average noise floor.
> >
> > I don't see what your 'new mode' is going to accomplish.
> >
> > Neil, KN3ILZ
> >
> >
> >> On 8/8/2018 2:29 AM, Игорь Ч wrote:
> >> Hello Joe and all,
> >> .
> >> We all have been missing JT65 mode sensitivity and proposed WSJT-X 2.0
> new FT8 approach with 0.2 dB sensitivity penalty can make things even worse.
> >> .
> >> I would like to ask you to consider a new protocol where callsign hash
> would be used instead of the real callsign in all messages but CQ and
> incoming call, this way we can get back to -25..26dB SNR sensitivity
> although will get more limited with the free message length.
> >> .
> >> CQ message: 28 bit callsign1  + i5bit + 12 bit CRC = 45 bit
> >> incoming call: 10 bit call1 hash + 28 bit callsign2 + i5bit + 12bit CRC
> = 55 bit
> >> report message: 10 bit call2 hash + 10 bit call1 hash + i5bit + (10 bit
> call3 hash for DXpedition) + 6 bit report + 12 bit CRC = 43(53) bit
> >> roger+report message: 10 bit call1 hash +  10 bit call2 hash + 6 bit
> report+ i5bit + 12bit CRC = 43 bit
> >> 73 message: 10 bit call2 hash + 10 bit call1 hash  + 15 bit GRID +
> i5bit + 12bit CRC = 55 bit
> >> RR73 message: 10 bit call1 hash + 10 bit call2 hash + 15 bit GRID +
> i5bit  + 12bit CRC= 52 bit
> >> .
> >> Spare bits can be used for nonstandard(special) callsign transmission
> in CQ message. call1 hash could be omitted in the incoming call message if
> this message is originated by the nonstandard(special) callsign.
> >> .
> >> Probably we can optimize protocol even better while a main idea is to
> transmit a full callsign only once per each QSO and to transmit not more
> than one full callsign in the message.
> >> .
> >> 73 Igor UA3DJY
> >
> >
> > 
> --
> > 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
>
--
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

Re: [wsjt-devel] wsjt-devel Digest, Vol 54, Issue 34

2018-08-09 Thread Al Pawlowski 
FWIW, my experience (in ~3yrs of use): lowest JT65 decode about -28, JT9 about 
-26, FT8 about -20.

I have gotten a few low level JT9 QSO’s at times when I could not get them on 
JT65 - I suspect due to band activity.

My WSJT-X is set for 2-pass, 6 erasure and 10 aggression.


Al Pawlowski, K6AVP
Los Osos, CA USA



> Date: Wed, 8 Aug 2018 11:20:56 -0600
> From: Gary McDuffie mailto:mcduf...@ag0n.net>>
> To: WSJT software development  >
> Subject: Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol
> 
> 
>> On Aug 8, 2018, at 9:03 AM, Wolfgang > > wrote:
>> 
>> So, we have -21 db in FT8 and in JT65 of around -27db 
>> (92% decoded at -27db, 58% at -28db and 17% at -29db)  
> 
> FYI, several times in the last two or three weeks, I have decoded very weak 
> ones at -24………..

--
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

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

2018-08-09 Thread Neil Zampella 


FT8 was never supposed to have the same sensitivity as JT65 .. you can't 
not with only 13 or 14 seconds of Tx time.    As was pointed out, 
you can have -24 reports on FT8 but its more a result of the noise floor 
in your location or the receiving station's location.


Not to mention that the suggestion leaves out provisions for the various 
contests that the updated protocol will cover.


Neil, KN3ILZ


On 8/8/2018 11:03 AM, Wolfgang wrote:
Re: [wsjt-devel] WSJT-X 2.0 possible new mode/protocol Neil, you have 
to read before you snap back!


Igor wrote, that we miss the sensivity of JT65 in FT8 !

So, we have -21 db in FT8 and in JT65 of around -27db
(92% decoded at -27db, 58% at -28db and 17% at -29db)

And the new proposed FT 2.0 will be another 0.2db (in math) less in
sensivity to the existing FT8. Igor suggested a FT8 protocoll that
could be at around -25 to -26db in sensivity - so again near to the
one of JT65.

Wolfgang, OE1MWW



Wednesday, August 8, 2018, 3:04:19 PM, you wrote:

*> Frankly,  I don't see where you're getting the idea that JT65
> sensitivity is missing?

> It is still much more sensitive than FT8, and will be for the
> foreseeable future, as are the other WSJT-X modes.  JT9A is at -27,
> JT65A is at -25, and QRA64A  is at -26.   FT8 is -21 .. all this is
> based on a average noise floor.

> I don't see what your 'new mode' is going to accomplish.

> Neil, KN3ILZ


> On 8/8/2018 2:29 AM, Игорь Ч wrote:
>> Hello Joe and all,
>> .
>> We all have been missing JT65 mode sensitivity and proposed WSJT-X 2.0
>> new FT8 approach with 0.2 dB sensitivity penalty can make things even
>> worse.
>> .
>> I would like to ask you to consider a new protocol where callsign hash
>> would be used instead of the real callsign in all messages but CQ and
>> incoming call, this way we can get back to -25..26dB SNR sensitivity
>> although will get more limited with the free message length.
>> .
>> CQ message: 28 bit callsign1  + i5bit + 12 bit CRC = 45 bit
>> incoming call: 10 bit call1 hash + 28 bit callsign2 + i5bit + 12bit
>> CRC = 55 bit
>> report message: 10 bit call2 hash + 10 bit call1 hash + i5bit + (10
>> bit call3 hash for DXpedition) + 6 bit report + 12 bit CRC = 43(53) 
bit

>> roger+report message: 10 bit call1 hash +  10 bit call2 hash + 6 bit
>> report+ i5bit + 12bit CRC = 43 bit
>> 73 message: 10 bit call2 hash + 10 bit call1 hash  + 15 bit GRID +
>> i5bit + 12bit CRC = 55 bit
>> RR73 message: 10 bit call1 hash + 10 bit call2 hash + 15 bit GRID +
>> i5bit  + 12bit CRC= 52 bit
>> .
>> Spare bits can be used for nonstandard(special) callsign transmission
>> in CQ message. call1 hash could be omitted in the incoming call
>> message if this message is originated by the nonstandard(special)
>> callsign.
>> .
>> Probably we can optimize protocol even better while a main idea is to
>> transmit a full callsign only once per each QSO and to transmit not
>> more than one full callsign in the message.
>> .
>> 73 Igor UA3DJY


> 
-- 


> 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 




73 de Wolfgang
OE1MWW

--
Amateur radio is the most expensive type of free-of-charge communication!
Amateurfunk ist die teuerste Art der kostenlosen Kommunikation! 


--
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

Re: [wsjt-devel] no decode

2018-08-09 Thread John C. Westmoreland, P.E. 
To All,

My rig did the same thing - checked timing with WWV - was exact, and still
no decode.

I'm using VAC's with my current rig - reset those - and wham!  Works.

So, the ONLY reason this may not work IS NOT timing.   Even if your timing
is off a bit you'll still see some decodes usually on 40m provided it's busy
and it usually is.

Check VAC's.  Everything looks ok - but I tore down and then remade my VACs
and everything worked again.  I agree it's a little strange.
(Note for those that could be wondering, I've retired my venerable Vista-64
motherboard.)

73's,
John
AJ6BC


On Tue, Aug 7, 2018 at 11:21 AM, John L. Broughton <2silverhon...@gmail.com>
wrote:

> Dimension 4 works just fine with Windows 10. I've been on Windows 10 for
> quite some time and have no problem with Dimension 4. I'm running version
> 5.31.331.0.
>
> John, WB9VGJ
>
> John L. Broughtonwww.wb9vgj.uswb9vgj@arrl.net2silverhon...@gmail.com
>
> On 8/7/2018 7:52 AM, harold deitz via wsjt-devel wrote:
>
> Chris,
>
> I have been using "Dimension 4" for time sync.  Recently upgraded my OS to
> Windows 10.  Found out that Dimension 4 won't work with Windows 10.  How do
> I get Meinberg?
>
> Hal W5GHZ
>
>
>
> Sent from Yahoo Mail. Get the app 
>
>
> On ‎Tuesday‎, ‎August‎ ‎7‎, ‎2018‎ ‎01‎:‎53‎:‎46‎ ‎PM‎ ‎GMT, Chris Getman
>   wrote:
>
>
> I had a very similar problem.
>
>
>
> The time looked OK, but when I did a manual Time Sync everything started
> working
>
>
>
> Michael had me switch time sync programs to Meinberg and I haven’t had an
> issue since.
>
>
>
> It’s worth a try and might fix your issue also.
>
>
>
> Chris  -  N3PLM
>
>
>
> *From:* Black Michael via wsjt-devel [mailto:wsjt-devel@lists.
> sourceforge.net ]
> *Sent:* Tuesday, August 7, 2018 9:38 AM
> *To:* wsjt-devel@lists.sourceforge.net
> *Cc:* Black Michael  
> *Subject:* Re: [wsjt-devel] no decode
>
>
>
> Hmmm hamspots.net doesn't show any transmissions from you for the last 16
> hours so you may not be transmitting as you think.
>
>
>
> You say your time is good but what does http://time.is tell you?
>
>
>
> de Mike W9MDB
>
>
>
>
>
>
>
>
>
> On Tuesday, August 7, 2018, 8:21:08 AM CDT, seaka...@juno.com <
> seaka...@juno.com> wrote:
>
>
>
>
>
> I've been using this software flawlessly for a while.  I'm using it on a
> Mac machine with Signalink and ICOM 735.  This morning when I turned on the
> computer and ran the program it was not decoding.  The waterfall shows lots
> of very strong signals.  Time is exact between software and computer.  When
> I look at the mac sound settings all is normal.  The software DOES
> transmit.  Just no decoding of signals.   I was using it yesterday before I
> shut the computer down perfectly.  No indication of trouble.  I also
> deleted the program and re installed a new download.  All perimeters stayed
> the same upon re install.  Again it does transmit.  Just no decode..
>
> Any ideas???
>
>
>
> Mike M
>
> AC1DV
>
>
>
>
>
>
>
>
> "All good things are wild and free."
>
> ~ Henry David Thoreau
>
>
>
> 
> *How To Remove Eye Bags & Lip Lines Fast (Watch)*
> Fit Mom Daily
> 
> http://thirdpartyoffers.juno.com/TGL3132/5b699b793d36a1b7944b9st02vuc
> [image: SponsoredBy Content.Ad]
>
> 
> --
> 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
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_-4362295290346306729_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> --
> 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 
> listwsjt-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites,