[wsjt-devel] ft8sim.exe

[Claudio IW1QLH]

Dear developers,
is it possible to download a compiled version of ft8sim for Windows ?

73 & DX

Claudio - IW1QLH
HRDLOG.net 
Diploma Radio 
Hamradio Cluster 
WikiHamRadio 
E-Associazione 
IW1QLH 
--
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

[wsjt-devel] FT8 - Beacon bit

[Claudio IW1QLH]

Dear developers,
has it been considered to reserve a bit in subroutine packcall for beacon
stations?
As well as FT8, similar bit could be useful also in WSPR and other modes.


73 & DX

Claudio - IW1QLH
HRDLOG.net 
Diploma Radio 
Hamradio Cluster 
WikiHamRadio 
E-Associazione 
IW1QLH 
--
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] choosing the best CRC for short data blocks

[Paul Black via wsjt-devel]

 Thanks Mike,

And when I can hear it, see it on the waterfall display and it doesn't decode, 
It would be good to have the option of knowing why. I would like a display 
showing the data received from the packet and an indication of how far it got 
through the error correction, decompression and decoding process. 
I wonder if anyone else would be interested in this level of detail?

Cheers.  Paul


On Friday, 26 January 2018, 4:10:00 pm AEDT, Black Michael via wsjt-devel 
 wrote:  
 
 If you can hear it can't you also see it on the waterfall?  The waterfall is 
the raw display.

de Mike W9MDB


On Thursday, January 25, 2018, 5:52:24 PM CST, Paul Black via wsjt-devel 
 wrote:  
 
  I am a long term WSPR user and more recently FT8. I am also a bit of a detail 
obsessive (I'm doing a PhD in malware analysis). While it is great to see that 
I have a new WSPR detection or FT8 connection, I find myself being deeply 
curious about cases why I hear the signal on my radio but do not get a 
detection or connection. I would be interested in a details window or logging 
for WSJT which would show incoming raw received data. I could then start to 
think about local QRM, my antennas, propagation effects and so on. Has this 
been discussed previously?
Cheers.  Paul, VK3TXR

On Friday, 26 January 2018, 7:30:18 am AEDT, Joe Taylor 
 wrote:  
 
 Don --

One other matter...

> Is there a more detailed description of the various modes available to 
> members of this list?  I am a new ham, but did waveform design and 
> optimal detection for many years until I retired last May.   I may be 
> able to help in some manner.

For detailed descriptions of the various modes, I recommend starting 
with Section 17 of the WJT-X User Guide:

http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html#PROTOCOLS

You could then progress to the list of papers posted here:

http://physics.princeton.edu/pulsar/k1jt/refs.html

... especially items number 4, 16, 25, 26, 28, 29, and 30.

    -- 73, Joe, K1JT

--
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
  --
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] choosing the best CRC for short data blocks

[Black Michael via wsjt-devel]

If you can hear it can't you also see it on the waterfall?  The waterfall is 
the raw display.

de Mike W9MDB


On Thursday, January 25, 2018, 5:52:24 PM CST, Paul Black via wsjt-devel 
 wrote:  
 
  I am a long term WSPR user and more recently FT8. I am also a bit of a detail 
obsessive (I'm doing a PhD in malware analysis). While it is great to see that 
I have a new WSPR detection or FT8 connection, I find myself being deeply 
curious about cases why I hear the signal on my radio but do not get a 
detection or connection. I would be interested in a details window or logging 
for WSJT which would show incoming raw received data. I could then start to 
think about local QRM, my antennas, propagation effects and so on. Has this 
been discussed previously?
Cheers.  Paul, VK3TXR

On Friday, 26 January 2018, 7:30:18 am AEDT, Joe Taylor 
 wrote:  
 
 Don --

One other matter...

> Is there a more detailed description of the various modes available to 
> members of this list?  I am a new ham, but did waveform design and 
> optimal detection for many years until I retired last May.   I may be 
> able to help in some manner.

For detailed descriptions of the various modes, I recommend starting 
with Section 17 of the WJT-X User Guide:

http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html#PROTOCOLS

You could then progress to the list of papers posted here:

http://physics.princeton.edu/pulsar/k1jt/refs.html

... especially items number 4, 16, 25, 26, 28, 29, and 30.

    -- 73, Joe, K1JT

--
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] tx audio equalisation, just a thought.

[Black Michael via wsjt-devel]

You run either rig split or fakeit.  That keeps all your audio in the 1500-2000 
range.
de Mike W9MDB



On Thursday, January 25, 2018, 7:02:45 PM CST, Peter Sumner 
 wrote:  
 
 Hello, first off, sorry if this subject has already been discussed and 
resolved but could not see anything on my searches.
As the owner of an older Icom VHF SSB rig, I have a seemingly common problem 
that my TX pass band is not flat, in fact using QRA64-D earlier today with Rex, 
VK7MO revealed a significant ripple across the tones (about 3db) seen on the 
Bird output power meter.As I am unsure how much control there is over the level 
of the tones generated by WSJT-X but I wondered if there is a way to build in a 
simple level control for TX tones across the passband?In my head I had thought 
an adjuster for 500-750 750-1000 1000-1250 and so on and be able to change the 
nominal value from 0db (flat) to be -1db or +1db for each segment of the 
decided passband...
Maybe others have a better way of managing this that is not part of WSJTX?
Regards,Peter, 
vk5pj--
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

[wsjt-devel] tx audio equalisation, just a thought.

[Peter Sumner]

Hello,
 first off, sorry if this subject has already been discussed and resolved
but could not see anything on my searches.

As the owner of an older Icom VHF SSB rig, I have a seemingly common
problem that my TX pass band is not flat, in fact using QRA64-D earlier
today with Rex, VK7MO revealed a significant ripple across the tones (about
3db) seen on the Bird output power meter.
As I am unsure how much control there is over the level of the tones
generated by WSJT-X but I wondered if there is a way to build in a simple
level control for TX tones across the passband?
In my head I had thought an adjuster for 500-750 750-1000 1000-1250 and so
on and be able to change the nominal value from 0db (flat) to be -1db or
+1db for each segment of the decided passband...

Maybe others have a better way of managing this that is not part of WSJTX?

Regards,
Peter, vk5pj
--
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] choosing the best CRC for short data blocks

[Paul Black via wsjt-devel]

 I am a long term WSPR user and more recently FT8. I am also a bit of a detail 
obsessive (I'm doing a PhD in malware analysis). While it is great to see that 
I have a new WSPR detection or FT8 connection, I find myself being deeply 
curious about cases why I hear the signal on my radio but do not get a 
detection or connection. I would be interested in a details window or logging 
for WSJT which would show incoming raw received data. I could then start to 
think about local QRM, my antennas, propagation effects and so on. Has this 
been discussed previously?
Cheers.  Paul, VK3TXR

On Friday, 26 January 2018, 7:30:18 am AEDT, Joe Taylor 
 wrote:  
 
 Don --

One other matter...

> Is there a more detailed description of the various modes available to 
> members of this list?  I am a new ham, but did waveform design and 
> optimal detection for many years until I retired last May.   I may be 
> able to help in some manner.

For detailed descriptions of the various modes, I recommend starting 
with Section 17 of the WJT-X User Guide:

http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html#PROTOCOLS

You could then progress to the list of papers posted here:

http://physics.princeton.edu/pulsar/k1jt/refs.html

... especially items number 4, 16, 25, 26, 28, 29, and 30.

    -- 73, Joe, K1JT

--
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] choosing the best CRC for short data blocks

[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 the CRC polynomial degree, not the polynomial
> coefficents unless their are choosen in a very bad way of course.


As an heuristic proof consider that whatever the information message length
M is when you add L CRC bits to the information message there are just 2^M
codewords out of all the possible 2^(M+L) combinations of (M+L) ouput bits.
Therefore, imagined as a point in a binary (M+L) dimensional space, each
codeword is surrounded on average by (2^L)-1 points for which the CRC
doesn't match and the error pattern is detected.

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

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

[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






Mail
priva di virus. www.avast.com

<#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 list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

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

[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 table assume that
messages are uncoded, which is indeed true for most embedded networking
applications but is not the case when a message undergoes some further,
block oriented forward error correction coding process, as in example it
happens for ALL of the protocols used by WSJT-X (or by NASA deep-space
applications).

@Don: if you protect some information with a CRC and then you *code* the
result using an ECC (error correction code) what you get after decoding the
ECC is something which may have a very large hamming distance from the
original information+crc packet. In these cases the HD of the CRC
polynomial is usually much less than the average error pattern weight and,
on average, 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 the CRC polynomial degree, not the polynomial coefficents unless their
are choosen in a very bad way of course.

73
Nico / IV3NWV




Mail
priva di virus. www.avast.com

<#m_2711666899474482065_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2018-01-25 23:13 GMT+01:00 Steven Franke :

> Hi Don,
>
> To add to what Joe and Bill have already said, I’d like to point out that
> Koopman’s tables are not particularly relevant for our application. The FT8
> decoder always produces a valid 174-bit codeword that satisfies all parity
> checks. In other words, the decoder always return a codeword from the
> codebook defined by our (174,87) LDPC code. The purpose of the CRC is to
> help us determine when the decoder has returned the wrong codeword. As it
> turns out, the most likely number of incorrect bits in the 87-bit
> message+CRC block contained within incorrect codewords is 20. This is "off
> the charts” as far as Koopman’s tables go. I have not found any reason to
> believe that selecting a polynomial that is optimum for a Hamming distance
> (HD) of 4, say, has any bearing on how it would perform with typical
> incorrect codewords having HD=20. This is why we have resorted to long
> simulations to evaluate the performance that is available from different
> CRC polynomials. In fact, our simulations showed very little difference in
> the performance of various 12-bit CRCs from Koopman’s table. They all
> reduce the number of incorrect decodes by about a factor of 2^12=2048.
>
> 73,
> Steve k9an
>
> > On Jan 25, 2018, at 2:21 PM, Joe Taylor  wrote:
> >
> > Hi Don,
> >
> > Thanks for your message and your interest in FT8, etc.
> >
> > We're well aware of the tables of "good CRC polynomials" published by
> Koopman, though admittedly we have not always used them to best advantage.
> >
> > Steve Franke, K9AN, did an extensive series of tests with different CRC
> generators when used with the 75-bit information block in FT8.  The CRC12
> used in FT8 is slightly sub-optimal, but the resulting increase in
> undetected error rate is only a factor of 1.6.  Since the error rate is
> already very low, the consequences are not serious.
> >
> >   -- Joe, K1JT
> >
> > On 1/25/2018 2:23 PM, Don Goldston wrote:
> >> Sirs,
> >> I have not delved into your software, and being old and retired I may
> not do so.  From the superficial descriptions of FT8 I have found, your
> group seems to know very well what they are doing.
> >> https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_
> crc_poly_embedded.pdf
> >> Here is a link to a paper on CRCs that you should consider for future
> design work.  The paper gives the best CRC of a given length for a data
> block of a given length.  You can potentially have equal or better
> corruption detection with a smaller CRC, Examine table 3 carefully.  I
> believe you could use an 8 bit CRC (0x97) for data blocks of up to length
> 119 bits and achieve a hamming distance of 4,  which is equal to or better
> than the performance achievable with the optimal 12 bit CRC at data block
> lengths above 53 bits in length.
> >> It may be too late to impact FT8, but the principles outlined in the
> paper can save you a few bits in future development.
> >> As a general caution, be aware that previous published "standard" and
> "good" CRCs, may not be the best even at long block lengths.
> >> If you were already aware of this paper, please forgive me for wasting
> your time.
> >> Is there a more detailed description of the 

Re: [wsjt-devel] Remove me from the mailing list.

[Joe Taylor]

If you receive this email, the list believes you are a member.  You must 
remove yourself: click on the link at the bottom every message from this 
reflector.


On 1/25/2018 5:33 PM, iz6gvc--- via wsjt-devel wrote:

Please, remove this email from your mailing list, I'm not member.

Thanks and 73s
___
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] Remove me from the mailing list.

[Steven Franke]

Iz6gvc

You can remove yourself. Follow the link at the end of every message:

> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> 
Then follow the link under “Unsubscribe & Settings”.

Steve k9an

> On Jan 25, 2018, at 10:33 PM, iz6gvc--- via wsjt-devel 
>  wrote:
> 
> Please, remove this email from your mailing list, I'm not member.
> 
> 
> 
> Thanks and 73s
> 
> --
> 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] choosing the best CRC for short data blocks

[Steven Franke]

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

Steve k9an



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

[wsjt-devel] Remove me from the mailing list.

[iz6gvc--- via wsjt-devel]

Please, remove this email from your mailing list, I'm not member.


Thanks and 73s
--
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] choosing the best CRC for short data blocks

[Don Goldston]

Thanks, all, for the information.  I had not run into a situation where the
"wrong code-word" distance was so high, but it absolutely makes sense, as
does the 1/2048 ratio.  I appreciate y'all taking the time to educate me.
I'm old, but not too old to learn - yet!

73,
Don AE0AG

On Thu, Jan 25, 2018 at 3:13 PM, Steven Franke 
wrote:

> Hi Don,
>
> To add to what Joe and Bill have already said, I’d like to point out that
> Koopman’s tables are not particularly relevant for our application. The FT8
> decoder always produces a valid 174-bit codeword that satisfies all parity
> checks. In other words, the decoder always return a codeword from the
> codebook defined by our (174,87) LDPC code. The purpose of the CRC is to
> help us determine when the decoder has returned the wrong codeword. As it
> turns out, the most likely number of incorrect bits in the 87-bit
> message+CRC block contained within incorrect codewords is 20. This is "off
> the charts” as far as Koopman’s tables go. I have not found any reason to
> believe that selecting a polynomial that is optimum for a Hamming distance
> (HD) of 4, say, has any bearing on how it would perform with typical
> incorrect codewords having HD=20. This is why we have resorted to long
> simulations to evaluate the performance that is available from different
> CRC polynomials. In fact, our simulations showed very little difference in
> the performance of various 12-bit CRCs from Koopman’s table. They all
> reduce the number of incorrect decodes by about a factor of 2^12=2048.
>
> 73,
> Steve k9an
>
> > On Jan 25, 2018, at 2:21 PM, Joe Taylor  wrote:
> >
> > Hi Don,
> >
> > Thanks for your message and your interest in FT8, etc.
> >
> > We're well aware of the tables of "good CRC polynomials" published by
> Koopman, though admittedly we have not always used them to best advantage.
> >
> > Steve Franke, K9AN, did an extensive series of tests with different CRC
> generators when used with the 75-bit information block in FT8.  The CRC12
> used in FT8 is slightly sub-optimal, but the resulting increase in
> undetected error rate is only a factor of 1.6.  Since the error rate is
> already very low, the consequences are not serious.
> >
> >   -- Joe, K1JT
> >
> > On 1/25/2018 2:23 PM, Don Goldston wrote:
> >> Sirs,
> >> I have not delved into your software, and being old and retired I may
> not do so.  From the superficial descriptions of FT8 I have found, your
> group seems to know very well what they are doing.
> >> https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_
> crc_poly_embedded.pdf
> >> Here is a link to a paper on CRCs that you should consider for future
> design work.  The paper gives the best CRC of a given length for a data
> block of a given length.  You can potentially have equal or better
> corruption detection with a smaller CRC, Examine table 3 carefully.  I
> believe you could use an 8 bit CRC (0x97) for data blocks of up to length
> 119 bits and achieve a hamming distance of 4,  which is equal to or better
> than the performance achievable with the optimal 12 bit CRC at data block
> lengths above 53 bits in length.
> >> It may be too late to impact FT8, but the principles outlined in the
> paper can save you a few bits in future development.
> >> As a general caution, be aware that previous published "standard" and
> "good" CRCs, may not be the best even at long block lengths.
> >> If you were already aware of this paper, please forgive me for wasting
> your time.
> >> Is there a more detailed description of the various modes available to
> members of this list?  I am a new ham, but did waveform design and optimal
> detection for many years until I retired last May.   I may be able to help
> in some manner.
> >> 73,
> >> Don Goldston, AE0AG
> >
> > 
> --
> > 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] choosing the best CRC for short data blocks

[Steven Franke]

Hi Don,

To add to what Joe and Bill have already said, I’d like to point out that 
Koopman’s tables are not particularly relevant for our application. The FT8 
decoder always produces a valid 174-bit codeword that satisfies all parity 
checks. In other words, the decoder always return a codeword from the codebook 
defined by our (174,87) LDPC code. The purpose of the CRC is to help us 
determine when the decoder has returned the wrong codeword. As it turns out, 
the most likely number of incorrect bits in the 87-bit message+CRC block 
contained within incorrect codewords is 20. This is "off the charts” as far as 
Koopman’s tables go. I have not found any reason to believe that selecting a 
polynomial that is optimum for a Hamming distance (HD) of 4, say, has any 
bearing on how it would perform with typical incorrect codewords having HD=20. 
This is why we have resorted to long simulations to evaluate the performance 
that is available from different CRC polynomials. In fact, our simulations 
showed very little difference in the performance of various 12-bit CRCs from 
Koopman’s table. They all reduce the number of incorrect decodes by about a 
factor of 2^12=2048.

73,
Steve k9an

> On Jan 25, 2018, at 2:21 PM, Joe Taylor  wrote:
> 
> Hi Don,
> 
> Thanks for your message and your interest in FT8, etc.
> 
> We're well aware of the tables of "good CRC polynomials" published by 
> Koopman, though admittedly we have not always used them to best advantage.
> 
> Steve Franke, K9AN, did an extensive series of tests with different CRC 
> generators when used with the 75-bit information block in FT8.  The CRC12 
> used in FT8 is slightly sub-optimal, but the resulting increase in undetected 
> error rate is only a factor of 1.6.  Since the error rate is already very 
> low, the consequences are not serious.
> 
>   -- Joe, K1JT
> 
> On 1/25/2018 2:23 PM, Don Goldston wrote:
>> Sirs,
>> I have not delved into your software, and being old and retired I may not do 
>> so.  From the superficial descriptions of FT8 I have found, your group seems 
>> to know very well what they are doing.
>> https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf
>> Here is a link to a paper on CRCs that you should consider for future design 
>> work.  The paper gives the best CRC of a given length for a data block of a 
>> given length.  You can potentially have equal or better corruption detection 
>> with a smaller CRC, Examine table 3 carefully.  I believe you could use an 8 
>> bit CRC (0x97) for data blocks of up to length 119 bits and achieve a 
>> hamming distance of 4,  which is equal to or better than the performance 
>> achievable with the optimal 12 bit CRC at data block lengths above 53 bits 
>> in length.
>> It may be too late to impact FT8, but the principles outlined in the paper 
>> can save you a few bits in future development.
>> As a general caution, be aware that previous published "standard" and "good" 
>> CRCs, may not be the best even at long block lengths.
>> If you were already aware of this paper, please forgive me for wasting your 
>> time.
>> Is there a more detailed description of the various modes available to 
>> members of this list?  I am a new ham, but did waveform design and optimal 
>> detection for many years until I retired last May.   I may be able to help 
>> in some manner.
>> 73,
>> Don Goldston, AE0AG
> 
> --
> 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] Fwd: Save Directory

[Joe Taylor]

Hi Mike,

As has been described here on a number of occasions before, all incoming 
audio is saved to a *.wavfile.  If you have *Save | None* checked, these 
files will be deleted about 3/4 of the way through the next T/R 
sequence.  Thus, these files should not be accumulating unless you 
checked *Save Decoded* or *Save All*.


If you save all files when Monitoring all day in FT8 you should have 
5760 files.  You'd get over 300 thousand files in a couple of 24/7 months.


As far as I know all items on the *Save* menu work as intended.  If you 
believe it's not working for you, please send me a copy of your 
configuration file WSJT-X.ini.  It's in  the same directory as your log 
files, accessible from the File menu.


File names have the format YYMMDD_HHMMSS.wav.  Names beginning with 
1801...  were recorded in January 2018, etc.


-- 73, Joe, K1JT

On 1/25/2018 4:06 PM, MICHAEL FAGER wrote:

THIS IS AN UPDATE TO MY POSTING OF YESTERDAY

I am running version 1.8.0 of wsjt-x. I use it often. I recently noticed
that I had about 29GB of room left on a 500 GB hard drive. I knew of no
reason why this would be the case. This computer is only a "radio" computer.

I went looking for all of this used space, and after quite a bit of time
I found that I have 365 GB used to store 379,476 files in the
\appdata\local\wsjt-x\save directory. A quick look tells me that these
are mostly, if not all, wav files.

When I look at the wsjt-x manual I don't find detailed instructions on
how to not store all of this info. I checked the "Save" tab on the main
menu, and "None" was already checked.


If None is already checked you should not be saving


I have deleted the 379,476 files and will see what happens now.

Thanks

Mike, K7SR

ps All of the file names started with 180 which makes me suspect that
the problem started after upgrading to 1.8.0
mcf

--
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] Fwd: Save Directory

[Bill Somerville]

On 25/01/2018 21:06, MICHAEL FAGER wrote:

THIS IS AN UPDATE TO MY POSTING OF YESTERDAY

I am running version 1.8.0 of wsjt-x. I use it often. I recently noticed
that I had about 29GB of room left on a 500 GB hard drive. I knew of no
reason why this would be the case. This computer is only a "radio" computer.

I went looking for all of this used space, and after quite a bit of time
I found that I have 365 GB used to store 379,476 files in the
\appdata\local\wsjt-x\save directory. A quick look tells me that these
are mostly, if not all, wav files.

When I look at the wsjt-x manual I don't find detailed instructions on
how to not store all of this info. I checked the "Save" tab on the main
menu, and "None" was already checked.

I have deleted the 379,476 files and will see what happens now.

Thanks

Mike, K7SR

ps All of the file names started with 180 which makes me suspect that
the problem started after upgrading to 1.8.0
mcf


Hi Mike,

which band and mode are you using?

73
Bill
G4WJS.


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

[wsjt-devel] Fwd: Save Directory

[MICHAEL FAGER]

THIS IS AN UPDATE TO MY POSTING OF YESTERDAY

I am running version 1.8.0 of wsjt-x. I use it often. I recently noticed 
that I had about 29GB of room left on a 500 GB hard drive. I knew of no 
reason why this would be the case. This computer is only a "radio" computer.

I went looking for all of this used space, and after quite a bit of time 
I found that I have 365 GB used to store 379,476 files in the 
\appdata\local\wsjt-x\save directory. A quick look tells me that these 
are mostly, if not all, wav files.

When I look at the wsjt-x manual I don't find detailed instructions on 
how to not store all of this info. I checked the "Save" tab on the main 
menu, and "None" was already checked.

I have deleted the 379,476 files and will see what happens now.

Thanks

Mike, K7SR

ps All of the file names started with 180 which makes me suspect that 
the problem started after upgrading to 1.8.0
mcf

--
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] choosing the best CRC for short data blocks

[Joe Taylor]

Don --

One other matter...

Is there a more detailed description of the various modes available to 
members of this list?  I am a new ham, but did waveform design and 
optimal detection for many years until I retired last May.   I may be 
able to help in some manner.


For detailed descriptions of the various modes, I recommend starting 
with Section 17 of the WJT-X User Guide:


http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html#PROTOCOLS

You could then progress to the list of papers posted here:

http://physics.princeton.edu/pulsar/k1jt/refs.html

... especially items number 4, 16, 25, 26, 28, 29, and 30.

-- 73, Joe, K1JT

--
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] choosing the best CRC for short data blocks

[Joe Taylor]

Hi Don,

Thanks for your message and your interest in FT8, etc.

We're well aware of the tables of "good CRC polynomials" published by 
Koopman, though admittedly we have not always used them to best advantage.


Steve Franke, K9AN, did an extensive series of tests with different CRC 
generators when used with the 75-bit information block in FT8.  The 
CRC12 used in FT8 is slightly sub-optimal, but the resulting increase in 
undetected error rate is only a factor of 1.6.  Since the error rate is 
already very low, the consequences are not serious.


-- Joe, K1JT

On 1/25/2018 2:23 PM, Don Goldston wrote:

Sirs,

I have not delved into your software, and being old and retired I may 
not do so.  From the superficial descriptions of FT8 I have found, your 
group seems to know very well what they are doing.


https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf


Here is a link to a paper on CRCs that you should consider for future 
design work.  The paper gives the best CRC of a given length for a data 
block of a given length.  You can potentially have equal or better 
corruption detection with a smaller CRC, Examine table 3 carefully.  I 
believe you could use an 8 bit CRC (0x97) for data blocks of up to 
length 119 bits and achieve a hamming distance of 4,  which is equal to 
or better than the performance achievable with the optimal 12 bit CRC at 
data block lengths above 53 bits in length.


It may be too late to impact FT8, but the principles outlined in the 
paper can save you a few bits in future development.


As a general caution, be aware that previous published "standard" and 
"good" CRCs, may not be the best even at long block lengths.


If you were already aware of this paper, please forgive me for wasting 
your time.


Is there a more detailed description of the various modes available to 
members of this list?  I am a new ham, but did waveform design and 
optimal detection for many years until I retired last May.   I may be 
able to help in some manner.


73,

Don Goldston, AE0AG


--
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] choosing the best CRC for short data blocks

[Bill Somerville]

On 25/01/2018 19:23, Don Goldston wrote:

Sirs,

I have not delved into your software, and being old and retired I may 
not do so.  From the superficial descriptions of FT8 I have found, 
your group seems to know very well what they are doing.


https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf 




Here is a link to a paper on CRCs that you should consider for future 
design work.  The paper gives the best CRC of a given length for a 
data block of a given length.  You can potentially have equal or 
better corruption detection with a smaller CRC, Examine table 3 
carefully.  I believe you could use an 8 bit CRC (0x97) for data 
blocks of up to length 119 bits and achieve a hamming distance of 4,  
which is equal to or better than the performance achievable with the 
optimal 12 bit CRC at data block lengths above 53 bits in length.


It may be too late to impact FT8, but the principles outlined in the 
paper can save you a few bits in future development.


As a general caution, be aware that previous published "standard" and 
"good" CRCs, may not be the best even at long block lengths.


If you were already aware of this paper, please forgive me for wasting 
your time.


Is there a more detailed description of the various modes available to 
members of this list?  I am a new ham, but did waveform design and 
optimal detection for many years until I retired last May.   I may be 
able to help in some manner.


73,

Don Goldston, AE0AG


Hi Don,

we are indeed aware of that paper and web site, in fact it is a current 
topic of discussion amongst the development team for a few reasons. We 
are also aware that a 12-bit CRC is probably more that is necessary, in 
fact our CRC polynomial is not the one we intended due to a small 
development  misunderstanding and is only effectively an 11-bit CRC and 
not optimal to boot. Simulations do show it is effective and in theory 
substituting a proper optimal 12-bit CRC should improve the already 
excellent decoding error rate by a dB or two. It may get changed or we 
may re-purpose the "wasted" bit. Clearly a change in the CRC length or 
polynomial would obsolete the current protocol so there has to be a 
really good reason to make such a disruptive change given the number of 
active stations.


73
Bill
G4WJS.

--
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] PSK Reporter ANTENNA

[Gary McDuffie]

> On Jan 25, 2018, at 6:45 AM, Black Michael via wsjt-devel 
>  wrote:
> 
> Yes they do.

Thanks, Mike.  Learn something every day.  :)  Hadn’t noticed that before.

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

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

[Don Goldston]

Sirs,

I have not delved into your software, and being old and retired I may not
do so.  From the superficial descriptions of FT8 I have found, your group
seems to know very well what they are doing.

https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf


Here is a link to a paper on CRCs that you should consider for future
design work.  The paper gives the best CRC of a given length for a data
block of a given length.  You can potentially have equal or better
corruption detection with a smaller CRC, Examine table 3 carefully.  I
believe you could use an 8 bit CRC (0x97) for data blocks of up to length
119 bits and achieve a hamming distance of 4,  which is equal to or better
than the performance achievable with the optimal 12 bit CRC at data block
lengths above 53 bits in length.

It may be too late to impact FT8, but the principles outlined in the paper
can save you a few bits in future development.

As a general caution, be aware that previous published "standard" and
"good" CRCs, may not be the best even at long block lengths.

If you were already aware of this paper, please forgive me for wasting your
time.

Is there a more detailed description of the various modes available to
members of this list?  I am a new ham, but did waveform design and optimal
detection for many years until I retired last May.   I may be able to help
in some manner.

73,

Don Goldston, AE0AG
--
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] PSK Reporter ANTENNA

[David Tiller]

Interestingly there's an article in the Feb QST about this very subject written 
by Steve Ford, WB8IMY. The article's title? "Antenna Reporting with WSJT-X".


If you're a member you can access the article online.



From: Gary McDuffie 
Sent: Thursday, January 25, 2018 8:02 AM
To: sv1...@yahoo.com; WSJT software development
Subject: Re: [wsjt-devel] PSK Reporter ANTENNA



> On Jan 25, 2018, at 1:03 AM, Dennis Drakopoulos via wsjt-devel 
>  wrote:
>
> I believe it would be beneficial for all if WSJT software development team 
> could add as a feature, to allow the user to provision antenna information 
> field on the spots being uploaded to PSK REPORTER project.

I’ve never seen antenna information given by pskreporter.  Do they even have 
that provision?

Gary - AG0N
--
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] question and/or feature request

[Jim Record]

When you changed the time zone, OSX updated your clock. This probably got
you working. No reason to use anything but your local time zone.

Jim
AD0YO

On Thu, Jan 25, 2018 at 12:20 AM Georg  wrote:

> David,
>
> It does not matter what time zone you are in.  My Mac is set to UTC +1. As
> long as the seconds are OK you are fine.
>
> 73s
>
> Georg
> DJ6GI, NZ1C
>
> Am 25.01.2018 um 08:06 schrieb David Jaffe :
>
> Dear Developers,
>
> I am a new user of WSJT-X.   When I first tried the program (on MacOSX),
> nothing decoded. After scratching my head for a while, I tried setting my
> time zone to UTC and suddenly it worked. This was surprising to me, as I
> would have thought that simply having the minutes/seconds accurate would
> have been sufficient.  Is there some way to set the time zone offset so
> that I can keep my computer clock set to local time, but still have WSJT-X
> know the correct UTC?  If not, having such a value in Preferences would be
> a handy feature.
>
> Thanks, and sorry if this is a naive question.
>
> 73,
> David
> K6DAJ
>
>
>
>
>
> --
> 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
>
-- 
Jim Record
*Firgenholt Joyner*
(Old English (sort of) for Mountain Wood Joiner)
--
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] PSK Reporter ANTENNA

[Joe Taylor]

On 1/25/2018 8:45 AM, Black Michael via wsjt-devel wrote:
Yes they do.  But the main problem for this is all the different 
antennas one may have make it a band-specific value in a lot of cases.  
Not so useful in that case.  


This is not correct.  WSJT-X reports Antenna Description information to 
PSR Reporter on a band-specific basis.  See the screen shot included 
here in the User Guide for a few examples:


http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.8.0.html#BAND_SETTINGS

... and the associated text:

"Station Information: You can save Band, Offset and Antenna Description 
information for your station. The antenna information will be included 
in reception reports sent to PSK Reporter."


See also the short piece by WB8IMY on p 63 of the February, 2018 QST.

-- 73, Joe, K1JT

--
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] PSK Reporter ANTENNA

[Dennis Drakopoulos via wsjt-devel]

TKS everyone!Apologies but missed this in new WSJT-X suite. Yeap it is there 
available and I have just provisioned it.
Rationale behind is for a ham using PSK REPORTER spots to be able to assess 
their reception by different spotters.When I discussed abt it with Philip, 
owner of PSK REPORTER, he did mention that if that field was not provided, it 
would be filled with data from other spots. That is what happened to me. So I 
ended up reporting that I have a Dipole at 20meters height on 3.5MHz when I 
merely use a simple PA0RDT mini whip ant!

73 de SV1CDN, Dennis! 
 
  On Thu, Jan 25, 2018 at 15:48, Black Michael via 
wsjt-devel wrote:   
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot  
--
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] PSK Reporter ANTENNA

[Black Michael via wsjt-devel]

Yes they do.  But the main problem for this is all the different antennas one 
may have make it a band-specific value in a lot of cases.  Not so useful in 
that case.  Notably more coding required to allow for that.  And it's a 
minimally useful thing.




 de Mike W9MDB

On Thursday, January 25, 2018, 7:22:50 AM CST, Gary McDuffie 
 wrote:  
 
 

> On Jan 25, 2018, at 1:03 AM, Dennis Drakopoulos via wsjt-devel 
>  wrote:
> 
> I believe it would be beneficial for all if WSJT software development team 
> could add as a feature, to allow the user to provision antenna information 
> field on the spots being uploaded to PSK REPORTER project.

I’ve never seen antenna information given by pskreporter.  Do they even have 
that provision?

Gary - AG0N
--
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] PSK Reporter ANTENNA

[Gary McDuffie]

> On Jan 25, 2018, at 1:03 AM, Dennis Drakopoulos via wsjt-devel 
>  wrote:
> 
> I believe it would be beneficial for all if WSJT software development team 
> could add as a feature, to allow the user to provision antenna information 
> field on the spots being uploaded to PSK REPORTER project.

I’ve never seen antenna information given by pskreporter.  Do they even have 
that provision?

Gary - AG0N
--
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] PSK Reporter ANTENNA

[signalhz signalhz]

I think it’s available in most programs that report to the psk reporter. Fill 
in your info about your antenna system

 73 Eddy N7AED

Sent from my iPhone

On Jan 25, 2018, at 1:13 AM, Libor Holouš 
> wrote:

Hello Dennis.

This is available in WSJT-X. Hope the picture helps you..

73 Libor
- Original Message -
From: Dennis Drakopoulos via wsjt-devel
To: wsjt-devel@lists.sourceforge.net
Cc: Dennis Drakopoulos
Sent: Thursday, January 25, 2018 9:03 AM
Subject: [wsjt-devel] PSK Reporter ANTENNA


Hello from Athens!
I believe it would be beneficial for all if WSJT software development team 
could add as a feature, to allow the user to provision antenna information 
field on the spots being uploaded to PSK REPORTER project.


73 de SV1CDN, Dennis!



--
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] PSK Reporter ANTENNA

[Libor Holouš]

Hello Dennis.

This is available in WSJT-X. Hope the picture helps you..

73 Libor
  - Original Message - 
  From: Dennis Drakopoulos via wsjt-devel 
  To: wsjt-devel@lists.sourceforge.net 
  Cc: Dennis Drakopoulos 
  Sent: Thursday, January 25, 2018 9:03 AM
  Subject: [wsjt-devel] PSK Reporter ANTENNA




  Hello from Athens!
  I believe it would be beneficial for all if WSJT software development team 
could add as a feature, to allow the user to provision antenna information 
field on the spots being uploaded to PSK REPORTER project.




  73 de SV1CDN, Dennis!


--


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

[wsjt-devel] PSK Reporter ANTENNA

[Dennis Drakopoulos via wsjt-devel]

Hello from Athens!I believe it would be beneficial for all if WSJT software 
development team could add as a feature, to allow the user to provision antenna 
information field on the spots being uploaded to PSK REPORTER project.


73 de SV1CDN, Dennis!--
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