Re: [wsjt-devel] Audio input from RTP stream?

[Phil Karn]

On 3/6/18 08:05, Bill Somerville wrote:

> 
> Our experience of users using the Elecraft remote kit using IP streaming
> is that latency and delay are a problem, this being because of our
> dependence on external wall clock synchronization. Can RTP provide
> absolute time-stamp information that we can leverage to capture UTC time
> sync relative to the source? Is there a recovery mechanism to "unbuffer"
> when delays accumulate?

Bill,

I'm finally reading through the RTCP spec (have only implemented RTP so
far) and I see it already solves your exact problem. Every participant
in a multicast group periodically multicasts reports to the group. Every
RTCP sender report includes a 32-bit RTP timestamp and a corresponding
NTP (Network Time Protocol) timestamp. This lets every receiver derive
absolute clock time (to the sender's accuracy) for any received sample
in the RTP stream.

The 64-bit NTP timestamp is divided into two 32-bit parts: an integer
count of seconds since January 1, 1900 (at 00:00:00 UT, presumably) and
a 32-bit count of fractional seconds.

As much as I dislike NTP's use of universal time, which introduces the
many headaches of leap seconds, and the fact that this timestamp will
roll over in 2036, I will probably switch to using it to timestamp my
I/Q samples to avoid inflicting yet another "standard" on the world.

Phil

--
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] DXpedition Mode Test Results

[gary]

Some of the participants may have been deliberately breaking the rules as part 
of the test.  

It wasn't made clear, in advance, whether we should simply pretend the fox was 
real to simulate a genuine deep DX pileup, or do weird stuff to check how 
resilient the whole thing is.

I guess the team already has the wherewithal to generate WAVs simulating 
conventional pileups of arbitrary depth, perhaps even test setups with banks of 
hound-simulators calling and making simulated QSOs with the fox ... but 
replicating all the weirdness and antisocial goings-on that happen in real HF 
pileups, along with the propagation and path anomalies (such as polar flutter 
and multipath DX sigs) is a tough ask.  So, I guess some of the participants 
went intentionally weird.

I wondered about the XE station on 20, for instance: he could easily have been 
a deliberate part of the test, perhaps primed by Joe to call CQ or mess around. 
 Likewise with those participants who didn't read or heed the instructions: 
some may have knowinly avoided using DXpedition mode to see what happened.

Something to think about for the next test maybe?  Maybe not.  Spontaneous and 
accidental weirdness may be testing enough!

73
Gary  ZL2iFB

-Original Message-
From: Alex, VE3NEA  
Sent: Thursday, 8 March 2018 10:11 a.m.
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] DXpedition Mode Test Results


> - Of course, some Hounds did not operate as intended.  Several kept trying to 
> raise Fox by calling below 1000 Hz.  

Perhaps the software should block attempts to send Tx1 below 1000 Hz if Hound 
mode is enabled, and show a popup message explaining why transmission did not 
start.

73 Alex VE3NEA

--
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] Something for the wish list ... offset for TX only

[Glenn VE9GJ]

Hi
Been having lots of fun with WSJT-X.  I recently became active on 630m 
using my Kenwood TS-590SG and a Transmit transverter 80m in, 630m out 
(3.2mhz offset).


http://njdtechnologies.net/the-mf-solutions-630-meter-transmit-downconverter

If I add an offset to the Frequencies Setting for 630m it is applied to 
both the RX and TX frequency. At the moment I run with no offset in 
WSJT-X and manually set the 80m freq on VFO B and put the Kenwood in 
split and it seems to work OK.  It would be great if an offset could be 
specified for just TX.


Keep up the great work!

73
Glenn VE9GJ

--
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] UDP list command

[José Aparecido Pereira]

Hello friends I am developing an integration software with WSJT-X that is
working very well, but I still lack one last thing send a request to
connect to another station via UDP port Can anyone please tell me how to
list the UDP communication command with WSJT-x? thank you so much
PY5JAP
JOSE



Livre
de vírus. 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] DXpedition Mode Test Results

[Gary McDuffie]

> On Mar 7, 2018, at 1:27 PM, Joe Taylor  wrote:
> 
> I'm sure there is more to be said, but that will do for now.  Depending on 
> programming progress and on my own travel schedule, we may schedule another 
> public test within a few weeks.

Thanks for the great job, Joe.  It’s clear that lots of work went into this and 
I look forward to more tests.  I just hope I can be available to do a better 
job of it.  

I like the idea of randomizing for the fox, and maybe even for the hounds, but 
I wonder if that eliminates the ability for the hound to manually bounce around 
dodging other signals.

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] Macro Expansion

[Tom Melvin]

Hi Mike

Just throwing it out there - ‘FD’ while may be common on cw etc for some 
contests the CQ xx characters are generally taken as State / Providence / 
Region - while FD is not a US State - it could well apply to another country.  
Hardcoding it into one app does cause more confusion.  

The X? may work (Assuming no country) - but did I not see issues with a station 
XE  in recent fox/hound test - If some authority somewhere decides they will 
use XD as call there will be a mad rush to release patches assuming developers 
are around.

I would hate for some (no offence intended)  cock and bull method that  is not 
fully thought out - where would sota ref go, what about IOTA and all the other 
niche events. No doubt the one ‘’ macro that is not added/supported will be 
the one that causes most moans and complaints. 

Yes there should be a solution to that along with 6 character grids and a way 
of passing a ‘reference’ - SOTA ref/Contest Number/IOTA code - what it is I 
can’t help with but shoe horning a solution for xx% of users is not it.

Again no offence - just my personal view.

Regards

Tom
GM8MJV


On 7 Mar 2018, at 17:34, Black Michael via wsjt-devel 
 wrote:

> What other applications?  Is anybody interpreting the directed calls for any 
> purpose besides JTAlert giving it a "#" ??
> 
> To me it's a tradeoff between "confusion" where non-macro users would see the 
> 2-letter code and wonder what it's for and possibly ask questionsand the 
> ability to have "CQ FOX..." show up in Dxpedition mode and other such special 
> calls to let people know what's going on.
> 
> This has been asked numerous times for field day, SOTA, and such with no 
> other solution that I've seen.
> 
> 
> --- 
> Michael D. Black
> 
> 
> On Wednesday, March 7, 2018, 11:27:40 AM CST, Bill Somerville 
>  wrote:
> 
> 
> On 07/03/2018 17:19, Black Michael via wsjt-devel wrote:
> > Is there a downside to doing a macro expansion like this?
> >
> Hi Mike,
> 
> the obvious one is other applications not following suit. Changing the 
> interpretation of messages unilaterally is a recipe for confusion. At 
> least with the "E9aa" mapping to "CQ aa" the effect is relatively 
> transparent and if an application doesn't translate i.e. WSJT, then 
> users soon get the picture that E9EU means CQ EU and so on, whereas your 
> proposed mappings are rather more opaque.
> 
> 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
> --
> 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] DXPedition test results

[David Fisher]

Joe and everyone:

Thanks for the summary of what worked and didn’t last night.  The bug in the 
RR73 logic explains a lot.

Here are a few things I noticed:

Apart from our friend in Mexico, who simply made a mistake, I noticed a few 
other instances of people transmitting on top of the Fox’s transmissions.  I 
suggest that we should assume this will happen, accidentally or otherwise.  
Perhaps some method can be found to mitigate the effects.  Perhaps it is 
already there.

I had some trouble with the goalposts.  In Hound mode, I suggest we might be 
better off if moving the TX goalpost into a location where it probably 
shouldn’t be resulted in a nag box warning.  I know I fumbled this a few times. 
 I keep in mind that when working a rare DX, it is easy to get excited and make 
stupid mistakes.

What is the purpose of the Green goalpost in Hound mode?  It can direct decodes 
into the right window, but I didn’t pay much attention to that window.  I was 
interested in seeing what messages the Fox was sending, as a group.  Would it 
make more sense to simply turn the green goalpost off in Hound mode?

It hit a nasty bug by accident.  The instructions suggest double clicking on 
the Fox’s callsign to set the program’s parameters.  It also says you can type 
the information into the boxes.  I used both methods at one time or another.  
At one point I restarted the program and needed to reinit the Fox callsign, 
etc.  Deep into the fray, the Fox’s messages don’t have his callsign in them 
very often (ever?). Carelessly, I double clicked his callsign in a “ 
 ” message that appeared in the left window.  Bad things happened. 
 The  callsign was put into the callsign box, the messages were 
re-written to address the .  These effects are understandable, and 
reversible.  But most significantly, the transmit phase was reversed.  I found 
myself transmitting when Fox was transmitting.  Since the “phase” control is 
dimmed in this mode, I wasn’t able to correct it.  I had to stop the program 
and restart.  If I understand it correctly, Foxes and Hounds are assigned fixed 
transmit slots.  If that is the case, then double-clicking shouldn’t be able to 
change that assignment.

I hope this helps.

Dave / NX6D



--
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] DXpedition Mode Test Results

[Alex, VE3NEA]

- Of course, some Hounds did not operate as intended.  Several kept trying to raise Fox by calling below 1000 Hz.  


Perhaps the software should block attempts to send Tx1 below 1000 Hz if Hound mode is enabled, and show a popup message 
explaining why transmission did not start.


73 Alex VE3NEA

--
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] DXpedition Mode Test Results

[John Zantek]

Magnificent summary.  Bravo!

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Wednesday, March 7, 2018 12:28 PM
To: WSJT software development 
Subject: [wsjt-devel] DXpedition Mode Test Results

Hi all,

Here are a few highlights of results from last night's public test of
FT8 DXpedition Mode:

  - The overwhelming majority of participating Hounds operated as intended,
and according to instructions.  I copied 190 unique Hound callsigns during
the 2300 hour (when I was acting as Fox on 20m) and 330 unique callsigns
during the whole four hours.  I suppose that we had at least 400-500
participants, maybe more.

- Fox's multi-signal capability worked very well at the tested values,
NSlots = 3, 4, and 5.  This feature is surely a "keeper", and I see no
reason not to use NSlots = 5 -- especially if Fox is running power.

  - In the four test hours the number of "QSOs" logged by Foxes on 20, 30,
40, and 80m was 320, 189, 454, and 351.  However, a regrettable program bug
was preventing deletion of Hound callsigns from Fox's "QSO-in-Progress" list
after a QSO had been logged.  As a result, many repeated "RR73" messages
were sent, many dupe QSOs were logged, and the QSO-in-Progress list kept
growing.  As another consequence, some QSOs took up to ~20 min to complete,
and a number of Hounds who had been sent a report never received their
QSO-confirming "RR73".

- AA7A actually worked 120 unique calls in the 40m hour, and the other Foxes
worked comparable slightly lower numbers.  When this program bug is
corrected, hourly QSO in the 300-400 range should certainly be achievable.

- Of course, some Hounds did not operate as intended.  Several kept trying
to raise Fox by calling below 1000 Hz.  (Most of these that I noticed were
from non-English speaking countries.  We will probably need translations of
the FT8 DXpedition Mode User Guide.)  A few would-be Hounds were not
obviously not using v1.9.0-rc2, and were calling Fox "blind" in 1st
sequence.  A few Hounds tried using compound callsigns, which is not
supported -- and which needs to be made more clear in the instructions.

- Nearly everybody noticed the XE1GK calling CQ on the low-end Fox frequency
and working people these.  Please don't be too hard on
Ignacio: he obviously misunderstood what was supposed to be happening, and
how to operate in the test run.  He sent me an abject apology. 
Anyway, his signal helped us to evaluate how well we can cope with QRM and
DQRM.

Two operating hints that should be used as needed, but in general were not:

  - Hounds should manually reset their Tx frequency as needed to evade QRM.

  - Fox may decide to use the randomizing feature to vary his own Tx
frequency.


I list here some relatively minor bugs and other things that came to 
light during the test run:

  - Spurious "Callsign mismatch" warning messages were displayed to the 
Fox operator.

  - Fox's log window should automatically scroll to the bottom.  Or 
maybe it should simply show the most recent ~10 QSOs logged.

  - I'm not sure that Fox's "Max Calls" parameter worked as designed.

  - Sometimes Fox sent RR73 to the same station in more that one slot, 
in the same transmission.

  - The dreaded "Blue Decode" button was seen by some.

  - Hounds sometimes send a spuriously low signal report to Fox, even 
when Fox is loud.

  - If Hound hits "Enter" with the DX Call box empty, a blank message 
can be transmitted.

  - It a random station (not Fox) calls a Hound, it can trigger a Hound 
transmission just as if Fox had called.

  - Previously decoded Hound calls can sometimes reappear in Fox's left 
window, when they should not.


Finally, let me outline a few new features we may decide to implement.

  - At least for debugging, and possibly as an option, offer a display 
window that shows the Fox operator the contents of all active queues.

  - Limit the number of QSOs in progress to no more than NSlots.

  - Option to suppress display of the waterfall timestamp.

  - Have Fox call CQ in one slot at least once every few (1 or 2?) minutes.

  - Should Hound's Tx3 frequency be re-randomized for each repeat try?

I'm sure there is more to be said, but that will do for now.  Depending 
on programming progress and on my own travel schedule, we may schedule 
another public test within a few weeks.

-- 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] DXpedition Mode Test Results

[Joe Taylor]

Hi all,

Here are a few highlights of results from last night's public test of 
FT8 DXpedition Mode:


 - The overwhelming majority of participating Hounds operated as 
intended, and according to instructions.  I copied 190 unique Hound 
callsigns during the 2300 hour (when I was acting as Fox on 20m) and 330 
unique callsigns during the whole four hours.  I suppose that we had at 
least 400-500 participants, maybe more.


- Fox's multi-signal capability worked very well at the tested values, 
NSlots = 3, 4, and 5.  This feature is surely a "keeper", and I see no 
reason not to use NSlots = 5 -- especially if Fox is running power.


 - In the four test hours the number of "QSOs" logged by Foxes on 20, 
30, 40, and 80m was 320, 189, 454, and 351.  However, a regrettable 
program bug was preventing deletion of Hound callsigns from Fox's 
"QSO-in-Progress" list after a QSO had been logged.  As a result, many 
repeated "RR73" messages were sent, many dupe QSOs were logged, and the 
QSO-in-Progress list kept growing.  As another consequence, some QSOs 
took up to ~20 min to complete, and a number of Hounds who had been sent 
a report never received their QSO-confirming "RR73".


- AA7A actually worked 120 unique calls in the 40m hour, and the other 
Foxes worked comparable slightly lower numbers.  When this program bug 
is corrected, hourly QSO in the 300-400 range should certainly be 
achievable.


- Of course, some Hounds did not operate as intended.  Several kept 
trying to raise Fox by calling below 1000 Hz.  (Most of these that I 
noticed were from non-English speaking countries.  We will probably need 
translations of the FT8 DXpedition Mode User Guide.)  A few would-be 
Hounds were not obviously not using v1.9.0-rc2, and were calling Fox 
"blind" in 1st sequence.  A few Hounds tried using compound callsigns, 
which is not supported -- and which needs to be made more clear in the 
instructions.


- Nearly everybody noticed the XE1GK calling CQ on the low-end Fox 
frequency and working people these.  Please don't be too hard on 
Ignacio: he obviously misunderstood what was supposed to be happening, 
and how to operate in the test run.  He sent me an abject apology. 
Anyway, his signal helped us to evaluate how well we can cope with QRM 
and DQRM.


Two operating hints that should be used as needed, but in general were not:

 - Hounds should manually reset their Tx frequency as needed to evade QRM.

 - Fox may decide to use the randomizing feature to vary his own Tx 
frequency.



I list here some relatively minor bugs and other things that came to 
light during the test run:


 - Spurious "Callsign mismatch" warning messages were displayed to the 
Fox operator.


 - Fox's log window should automatically scroll to the bottom.  Or 
maybe it should simply show the most recent ~10 QSOs logged.


 - I'm not sure that Fox's "Max Calls" parameter worked as designed.

 - Sometimes Fox sent RR73 to the same station in more that one slot, 
in the same transmission.


 - The dreaded "Blue Decode" button was seen by some.

 - Hounds sometimes send a spuriously low signal report to Fox, even 
when Fox is loud.


 - If Hound hits "Enter" with the DX Call box empty, a blank message 
can be transmitted.


 - It a random station (not Fox) calls a Hound, it can trigger a Hound 
transmission just as if Fox had called.


 - Previously decoded Hound calls can sometimes reappear in Fox's left 
window, when they should not.



Finally, let me outline a few new features we may decide to implement.

 - At least for debugging, and possibly as an option, offer a display 
window that shows the Fox operator the contents of all active queues.


 - Limit the number of QSOs in progress to no more than NSlots.

 - Option to suppress display of the waterfall timestamp.

 - Have Fox call CQ in one slot at least once every few (1 or 2?) minutes.

 - Should Hound's Tx3 frequency be re-randomized for each repeat try?

I'm sure there is more to be said, but that will do for now.  Depending 
on programming progress and on my own travel schedule, we may schedule 
another public test within a few weeks.


-- 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] Sourceforge status?

[Black Michael via wsjt-devel]

I just got notified that from sourceforge that this problem has been fixed now.
de Mike W9MDB
--
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] DXpedition Mode Test Numbers

[John Zantek]

Thank you, Bill.  I agree…reaching 120 Qph will put a serious dent in the armor 
of those who argue that the FT8 rate isn’t worth the effort vs SSB or CW.  I 
know there were some DXpedition vets in the foray last night, and I hope it was 
an eye-opener for them.

 

N0AN’s comment exactly echoes my experience during both the 30M and the 40M 
test.  “After I had been "moved" to the lower freq tier by the Fox, it put me 
in a mess of others. So I watched the rx window for a while and when I saw a  
hole develop, I moved my TX there (still in the lower freq tier area where the 
Fox had put me, but in a clearer spot). Immediately on my next transmission, 
the qso finished out.”  Right on, Hasan!

 

I wonder what the learning curve timeline will be for the ever-expanding FT8 
user community who never reads the docs.  Some brave, real Fox in the near 
future (sooner than Baker?) will have their hands full with non-Hounds braying 
after them.  :)

 

Regardless, it was a magnificent test.  Ready for the next one, with 4 
callsigns (mine, XYL, & 2 clubs) in the local arsenal to enhance the loading!

 

73 John KE7B

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Wednesday, March 7, 2018 10:10 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] DXpedition Mode Test Numbers

 

On 07/03/2018 17:42, John Zantek wrote:

The OTA tests were a hoot, even with the hound-on-hound nonsense and the 
unfortunate DQRM from XE.

 

Did anyone collect and mention the final numbers for the foxes?  I thought N1DG 
said ~190 for 30M, but I sense the total 40M QSO’s may have been quite 
significant, since my screen was REALLY scrolling during AA7A’s hour.

 

73 John KE7B

Hi John,

the total Fox QSO counts mentioned on PJR included many dupes, this is because 
the Fox mode logs a dupe when a repeated confirmation is received from a Hound. 
This would be ok but a defect lead to signoff messages not always being sent 
again by the Fox so the dupe counts were very high. I don't have exact figures 
but something of the order of 1/5 of the maximum possible unique QSOs for the 
number of Tx slots being used by the Fox. With the defect found and fixed so 
that Hounds that have to repeat their confirmation are very likely to get a 
prompt RR73 response, the throughput should increase significantly.

I would expect that with a suitable sized pileup and reasonably good behaviour, 
a slick Fox operator may be able to get quite close to optimal rates i.e. 
 x 120 QSOs per hour. There are a few tools in the Foxes bag for 
pileup management that were not used such as randomized Tx frequencies (helps 
with DQRM), directional calls (needs thought as currently the Fox has to stop 
and call CQ to ask), working weak callers first, working furthest distances 
first, etc..

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] WSJT-X 1.9.0 rc2 Waterfall

[Libor Holouš]

Hi Gary..

Not for decoding but find and fit into most free space.
BTW, I have it smooth too now, no changes, just upgraded.. I liked it more 
like before it was..

Now I feel like glasses needed..

But somebody maybe like it or don't want to wear glasses and that way it is 
more comfortable? :-)


My WF settings: N Avg 1, Palete Green1

73 Libor OK2ZO

- Original Message - 
From: "Gary McDuffie" 

To: "WSJT software development" 
Sent: Wednesday, March 07, 2018 8:28 PM
Subject: Re: [wsjt-devel] WSJT-X 1.9.0 rc2 Waterfall






On Mar 7, 2018, at 9:59 AM, Lawrence Lopez  wrote:

I found the really liked the new format of the waterfall.
It was much less critical to adjust in order to get data.


The waterfall has no bearing on the ability to decode.  It isn’t even 
needed.


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] WSJT-X 1.9.0 rc2 Waterfall

[rjai...@gmail.com]

Smeared is going to get some people angry emails about power, even though
they aren’t running power. Hope it works out

Ria
N2RJ
On Wed, Mar 7, 2018 at 2:30 PM Gary McDuffie  wrote:

>
>
> > On Mar 7, 2018, at 9:59 AM, Lawrence Lopez  wrote:
> >
> > I found the really liked the new format of the waterfall.
> > It was much less critical to adjust in order to get data.
>
> The waterfall has no bearing on the ability to decode.  It isn’t even
> needed.
>
> 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] WSJT-X 1.9.0 rc2 Waterfall

[Gary McDuffie]

> On Mar 7, 2018, at 9:59 AM, Lawrence Lopez  wrote:
> 
> I found the really liked the new format of the waterfall.
> It was much less critical to adjust in order to get data.

The waterfall has no bearing on the ability to decode.  It isn’t even needed.

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] Audio input from RTP stream?

[Phil Karn]

On 3/7/18 01:33, Игорь Ч via wsjt-devel wrote:

> Playing out silence in place of the lost packets is not a good idea:
> it will distrurb sychronization and will bring wrong Delta Time values 
> to the weak signals at demodulation. I would suggest usage of some 
> averaging instead of the silence.
> .
> 73 Igor UA3DJY

Igor, the whole point of playing out silence is to maintain
synchronization. If, for example, the sampling rate is 48 kHz and your
RTP packets each contain 240 samples (5 milliseconds), then I would
replace a single missing packet with 240 samples of binary zeroes. Your
signal blanks for 5 ms, but synchronization is maintained when it
reappears. Most of the slower JT schemes wouldn't even notice.

My experience is that local wired Ethernet networks are extremely
reliable unless overloaded. Lost packets are very rare and reordered or
corrupted packets are almost unheard of unless something is *very* broken.

WiFi 802.11 is a different and somewhat complex story. Delays are much
more variable due to contention and other physical layer problems.
Packet loss depends on whether they're sent as physical multicasts or
unicasts. Physical unicasts are acknowledged at the physical layer so
they can might arrive late (i.e., with a lot of delay variance) but are
usually not dropped.

Multicast is different. A physical layer 802.11 multicast is sent at a
very low "base rate" to maximize reception probability at every user
station. They're not acknowledged. Not only can that lose packets, the
low base rate can make the channel almost unusable if there's a lot of
multicast traffic (like one of my I/Q streams).

Some access points (like my Engenius 600) have a "multicast to unicast
conversion" feature so that a multicast frame arriving on the Ethernet
is sent as a series of unicast frames, one for each mobile station that
has subscribed to the multicast group. Then each unicast can be sent at
whatever speed that link can bear, and they're individually acknowledged
for reliability. This is almost always vastly faster than a physical
multicast.

Phil

--
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] Public test of FT8 DXpedition mode March 6-7

[Pino Zollo]

Hi,

I made the QSO (TU Joe K1JT), but after it the DECODER went stuck no more 
decoding even if the band was full of stations.


I had to close the program and started it again ...

After a while the problem appeared again; this time the button DECODE did 
remain blue fixed. ...I was changing my call from ZP4KFX to ZP4KFX/6 ...and I 
did enter manually the call K1JT into DX Call 

It looks like there is a problem with decoder when overstressed.

 73

Pino ZP4KFX

P.S.
Linux Mint 18.3 64b with MATE



--
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] Add ft8d and ft8sim to makefile?

[Steven Franke]

Hi Rockwell,

The development routine ft8d is not what you want for a stand-alone 
command-line decoder. It is not kept up-to-date. Every now and then, when we 
are testing a new feature or debugging a particular issue, we’ll bring it up to 
date for that purpose. But at any given instant in time, it may not be 
functional. I believe that this is one of those instants. At present, it is not 
even being compiled.

For command-line decoding of saved wav files, jt9 with the -8 command-line 
option should do want you want.

For simulation, the ft8sim executable should be found in your build directory, 
assuming that you are building the development versions yourself.

73, Steve k9an

> On Mar 6, 2018, at 8:13 PM, Rockwell Schrock  wrote:
> 
> Hi folks,
> 
> I am interested in integrating some software with FT8 by passing audio files 
> into and out of the FT8 modem as provided by WSJT-X. I'm no FORTRAN 
> developer, but it appears that I could utilize the `ft8d` command-line 
> utility to decode WAV files, and `ft8sim` to generate them. Is that a 
> reasonable approach?
> 
> If so, could we get `ft8d` and `ft8sim` executables added to the WSJT-X 
> outputs, alongside jt9, jt65code, etc.?
> 
> Thanks,
> 
> Rockwell WW1X
> --
> 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] Public Test of FT8 DXpedition mode-received signal report

[Glenn via wsjt-devel]

I could copy all 4 stations fairly well.  I was able to get a signal 
report from the fox on all bands, but only completed the contact on 40 
meters.  On the other bands I got stuck sending my signal report.  It 
appeared as though the fox was initiating new QSO's and not finishing 
previous contacts. On 40 meters I got in just as the fox started.  The 
only other anomaly I noted was that my signal report was always R-15 on 
all four bands .  May have been a coincidence.


The test was exciting to watch and participate. Thanks to all.

73,

Glenn WA3LAB

--
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] Sourceforge status?

[Black Michael via wsjt-devel]

Looks like you are building on Linux with JTSDK?
You need to edit /usr/local/bin/jtsdk and change the http: entries to 
https:Also edit the jtsdk-wsjtx file to do the same

de Mike W9MDB
 

On Wednesday, March 7, 2018, 12:08:44 PM CST, Wolfgang  
wrote:  
 
 Hello Mike,

(JTSDK-QT 5.5 ) C:\JTSDK)svn relocate 
http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx 
https://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
svn: E155024: Invalid source URL prefix: 
'http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx' (does not overlap target's 
URL 'https://svn.code.sf.net/p/jtsdk/jtsdk/jtsdk-win/tags/jtsdk-win-2.0.6')

any solution on this please?

73's de OE1MWW
Wolfgang

Wednesday, March 7, 2018, 6:26:25 PM, you wrote:


Yup...that works

svn relocate http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx 
https://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx


They must've shutdown non-https access.

de Mike W9MDB



--
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] Sourceforge status?

[Bill Somerville]

On 07/03/2018 18:08, Wolfgang wrote:

(JTSDK-QT 5.5 ) C:\JTSDK)svn 
relocatehttp://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx  
https://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
svn: E155024: Invalid source URL prefix: 
'http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx' (does not overlap target's 
URL'https://svn.code.sf.net/p/jtsdk/jtsdk/jtsdk-win/tags/jtsdk-win-2.0.6')

any solution on this please?


HI Wolfgang,

you are trying to relocate the wrong workspace, you need to change your 
working directory to the one with the WSJT sources in first. Use "svn 
info" to conform you are in the right place before re-running that 
relocate command.


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] DXpedition Mode Test Numbers

[Bill Somerville]

On 07/03/2018 17:42, John Zantek wrote:


The OTA tests were a hoot, even with the hound-on-hound nonsense and 
the unfortunate DQRM from XE.


Did anyone collect and mention the final numbers for the foxes?  I 
thought N1DG said ~190 for 30M, but I sense the total 40M QSO’s may 
have been quite significant, since my screen was /REALLY/ scrolling 
during AA7A’s hour.


73 John KE7B


Hi John,

the total Fox QSO counts mentioned on PJR included many dupes, this is 
because the Fox mode logs a dupe when a repeated confirmation is 
received from a Hound. This would be ok but a defect lead to signoff 
messages not always being sent again by the Fox so the dupe counts were 
very high. I don't have exact figures but something of the order of 1/5 
of the maximum possible unique QSOs for the number of Tx slots being 
used by the Fox. With the defect found and fixed so that Hounds that 
have to repeat their confirmation are very likely to get a prompt RR73 
response, the throughput should increase significantly.


I would expect that with a suitable sized pileup and reasonably good 
behaviour, a slick Fox operator may be able to get quite close to 
optimal rates i.e.  x 120 QSOs per hour. There are a few 
tools in the Foxes bag for pileup management that were not used such as 
randomized Tx frequencies (helps with DQRM), directional calls (needs 
thought as currently the Fox has to stop and call CQ to ask), working 
weak callers first, working furthest distances first, etc..


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] Sourceforge status?

[Wolfgang]

Hello Mike,

(JTSDK-QT 5.5 ) C:\JTSDK)svn relocate 
http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx 
https://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
svn: E155024: Invalid source URL prefix: 
'http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx' (does not overlap target's 
URL 'https://svn.code.sf.net/p/jtsdk/jtsdk/jtsdk-win/tags/jtsdk-win-2.0.6')

any solution on this please?

73's de OE1MWW
Wolfgang

Wednesday, March 7, 2018, 6:26:25 PM, you wrote:


Yup...that works

svn relocate http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx 
https://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx


They must've shutdown non-https access.

de Mike W9MDB



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

[Hasan al-Basri]

All four stations were strong. K1JT started out at +15 on 20 meters, but
within 20 minutes had dropped to -23  (late afternoon band change). 30 dB
change in about 20 minutes...talk about catching the band moving!

Completed with all 4 stations, but one completion was aided by a trick on
my end. After I had been "moved" to the lower freq tier by the Fox, it put
me in a mess of others. So I watched the rx window for a while and when I
saw a  hole develop, I moved my TX there (still in the lower freq tier area
where the Fox had put me, but in a clearer spot). Immediately on my next
transmission, the qso finished out.

The attached image shows a  nice trace of the N=5 Fox ...very cool!

It was a fun test, noticed same anomalies as others. Had two lockups on Rx.
Killed and restarted program and all was fine.

Deliberate qrm was significant in amount, but  ineffective. I saw it all,
but it cause me no problems with the Fox, nor completing contacts.

I look look forward to the next test. This was MOST enjoyable. Congrats to
the team!

73, N0AN



Hasan

On Wed, Mar 7, 2018 at 10:09 AM, Joe Taylor  wrote:

> Jim --
>
> I don't think you had to scramble.  If Fox calls you, your Tx3 message
> will be sent (somewhere in 300-900 Hz), even if Tx Enable is not engaged.
> -- Joe
>
>
> On 3/7/2018 11:05 AM, James Shaver wrote:
>
>> Yep, twice the timer had expired on me right as the “Fox” called me and I
>> had to scramble.
>>
>> Jim S.
>> N2ADV
>>
>> *From:*Bill Turner via wsjt-devel [mailto:wsjt-devel@lists.sourc
>> eforge.net]
>> *Sent:* Wednesday, March 7, 2018 11:03 AM
>> *To:* WSJT Software Development
>> *Cc:* Bill Turner
>> *Subject:* [wsjt-devel] Timer
>>
>> Great job with the test last night.  I did find the 2 minute timer to be
>> a real pain, however. I understand you do not want a robot operation, but a
>> 5 or 10 minute timer would be less frustrating.
>>
>> When the software shuts off the Enable TX, how do we know that we are
>> still on the correct sequence when we click on Enable TX?  I noticed some
>> comments about folks calling on the wrong sequence last night.
>>
>> Again, thanks for the effort in the test.
>>
>> Bill Turner, W4WNT
>>
>>
>>
>> 
>> --
>> 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

[wsjt-devel] DXpedition Mode Test Numbers

[John Zantek]

The OTA tests were a hoot, even with the hound-on-hound nonsense and the 
unfortunate DQRM from XE.

 

Did anyone collect and mention the final numbers for the foxes?  I thought N1DG 
said ~190 for 30M, but I sense the total 40M QSO’s may have been quite 
significant, since my screen was REALLY scrolling during AA7A’s hour.

 

73 John KE7B

 

--
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] Macro Expansion

[Black Michael via wsjt-devel]

What other applications?  Is anybody interpreting the directed calls for any 
purpose besides JTAlert giving it a "#" ??

To me it's a tradeoff between "confusion" where non-macro users would see the 
2-letter code and wonder what it's for and possibly ask questionsand the 
ability to have "CQ FOX..." show up in Dxpedition mode and other such special 
calls to let people know what's going on.
This has been asked numerous times for field day, SOTA, and such with no other 
solution that I've seen.

--- 
Michael D. Black 

On Wednesday, March 7, 2018, 11:27:40 AM CST, Bill Somerville 
 wrote:  
 
 On 07/03/2018 17:19, Black Michael via wsjt-devel wrote:
> Is there a downside to doing a macro expansion like this?
>
Hi Mike,

the obvious one is other applications not following suit. Changing the 
interpretation of messages unilaterally is a recipe for confusion. At 
least with the "E9aa" mapping to "CQ aa" the effect is relatively 
transparent and if an application doesn't translate i.e. WSJT, then 
users soon get the picture that E9EU means CQ EU and so on, whereas your 
proposed mappings are rather more opaque.

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
  --
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] Sourceforge status?

[Black Michael via wsjt-devel]

Yup...that works
svn relocate http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx 
https://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx


They must've shutdown non-https access.
de Mike W9MDB
 

On Wednesday, March 7, 2018, 11:15:49 AM CST, Bill Somerville 
 wrote:  
 
 On 07/03/2018 17:03, Black Michael via wsjt-devel wrote:
> What does your "svn info" show?
>
Hi Mike,

I use git-svn and I use svn+ssh access as I have write access but here 
is the equivalent:

$ git svn info
Path: .
URL: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
Repository Root: svn+ssh://svn.code.sf.net/p/wsjt/wsjt
Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Revision: 8544
Node Kind: directory
Schedule: normal
Last Changed Author: k1jt
Last Changed Rev: 8544
Last Changed Date: 2018-03-07 16:20:40 + (Wed, 07 Mar 2018)

But that is local only, "svn info" does not do a server round trip.

Here's a transaction using pure svn:

$ svn info
Path: .
Working Copy Root Path: C:\Users\bill\src\wsjt-svn
URL: svn+ssh://bsome...@svn.code.sf.net/p/wsjt/wsjt/tags/wsjtx-1.9.0-rc2
Relative URL: ^/tags/wsjtx-1.9.0-rc2
Repository Root: svn+ssh://bsome...@svn.code.sf.net/p/wsjt/wsjt
Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Revision: 8533
Node Kind: directory
Schedule: normal
Last Changed Author: bsomervi
Last Changed Rev: 8533
Last Changed Date: 2018-02-25 00:59:36 + (Sun, 25 Feb 2018)


bill@BILLS_LENOVO ~/src/wsjt-svn
$ svn up
Updating '.':
At revision 8544.

Maybe it is only http svn access that is having problems. Do they even 
support http these days? Can you switch to https?

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
  --
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] Macro Expansion

[Bill Somerville]

On 07/03/2018 17:19, Black Michael via wsjt-devel wrote:

Is there a downside to doing a macro expansion like this?


Hi Mike,

the obvious one is other applications not following suit. Changing the 
interpretation of messages unilaterally is a recipe for confusion. At 
least with the "E9aa" mapping to "CQ aa" the effect is relatively 
transparent and if an application doesn't translate i.e. WSJT, then 
users soon get the picture that E9EU means CQ EU and so on, whereas your 
proposed mappings are rather more opaque.


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] Macro Expansion

[Black Michael via wsjt-devel]

Is there a downside to doing a macro expansion like this?
I've got this working and it only affects the display and not what's 
transmitted.  Takes advantage of unused country codes which I suppose someday 
might be used..though X countries are fairly rare and calling for them even 
more rare.  Q would be another choice but X sounds like "Xpansion" so is a 
touch more intuitive.  On the other hand QA is the only Q country code and 
probably less chance of collision.

CQ XH K1JT FN20  CQ FOX K1JT FN20CQ XG K1JT +05 >> CQ SPLIT K1JT +5KHZCQ XG 
K1JT -01 >> CQ SPLIT K1JT -1KHZ

+void MainWindow::macroExpansion(QString& msg)
+{
+  // Let's avoid certain country codes for now
+  // See https://www.ng3k.com/Dxcc/dxcc.html
+  // These are good for now
+  // XA XB XC XD XG XH XI XJ XK XL XM XN XO XP XQ XR XS
+  msg.replace(" FD "," FIELDDAY ");
+  msg.replace(" XA "," TEST ");
+  msg.replace(" XB "," BEACON ");
+  msg.replace(" XC "," CONTEST ");
+  msg.replace(" XD "," DXPEDITION ");
+  if (msg.contains(" XG ")) {
+    msg.replace(" XG "," SPLIT ");
+    QString khz = msg.mid(0,msg.length()-1);
+    if (msg.mid(msg.length()-3)=="-") {
+    khz = "-" + khz;
+    }
+    else {
+    khz = "+" + khz;
+    }
+    msg.chop(3);
+    msg += khz + "KHZ";
+  }+  msg.replace(" XH "," FOX ");
+  msg.replace(" XM "," EMAILME ");
+  msg.replace(" XO "," 1010 ");
+  msg.replace(" XP "," QSOPARTY ");
+  msg.replace(" XS "," SOTA ");
+}


de Mike W9MDB
--
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] Sourceforge status?

[Alessandro Gorobey via wsjt-devel]

Hi All,

seems as http is no a good protocol today.

(JTSDK-QT 5.5 ) C:\JTSDK)svn list http://svn.code.sf.net/p/wsjt/wsjt/tags
svn: E175013: Unable to connect to a repository at URL 
'http://svn.code.sf.net/p/wsjt/wsjt/tags'

svn: E175013: Access to '/p/wsjt/wsjt/tags' forbidden

But
svn list https://svn.code.sf.net/p/wsjt/wsjt/tags
or
svn list svn://svn.code.sf.net/p/wsjt/wsjt/tags
work OK

--
73
Sandro
IW3RAB

--
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] Sourceforge status?

[Bill Somerville]

On 07/03/2018 17:03, Black Michael via wsjt-devel wrote:

What does your "svn info" show?


Hi Mike,

I use git-svn and I use svn+ssh access as I have write access but here 
is the equivalent:


$ git svn info
Path: .
URL: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
Repository Root: svn+ssh://svn.code.sf.net/p/wsjt/wsjt
Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Revision: 8544
Node Kind: directory
Schedule: normal
Last Changed Author: k1jt
Last Changed Rev: 8544
Last Changed Date: 2018-03-07 16:20:40 + (Wed, 07 Mar 2018)

But that is local only, "svn info" does not do a server round trip.

Here's a transaction using pure svn:

$ svn info
Path: .
Working Copy Root Path: C:\Users\bill\src\wsjt-svn
URL: svn+ssh://bsome...@svn.code.sf.net/p/wsjt/wsjt/tags/wsjtx-1.9.0-rc2
Relative URL: ^/tags/wsjtx-1.9.0-rc2
Repository Root: svn+ssh://bsome...@svn.code.sf.net/p/wsjt/wsjt
Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Revision: 8533
Node Kind: directory
Schedule: normal
Last Changed Author: bsomervi
Last Changed Rev: 8533
Last Changed Date: 2018-02-25 00:59:36 + (Sun, 25 Feb 2018)


bill@BILLS_LENOVO ~/src/wsjt-svn
$ svn up
Updating '.':
At revision 8544.

Maybe it is only http svn access that is having problems. Do they even 
support http these days? Can you switch to https?


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] WSJT-X 1.9.0 rc2 Waterfall

[James Shaver]

It took me a few days to get it the way I wanted it but I like it way better.  

Jim S. 
N2ADV

-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Wednesday, March 7, 2018 11:27 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X 1.9.0 rc2 Waterfall

On 07/03/2018 16:21, Ron Schwartz wrote:
> The 1.9.0 rc2 waterfall now appears ‘smeared’ and weak traces are not 
> as visible as earlier versions (see attached).  Is this an intentional 
> change?

Hi Ron,

it has been changed, the intent was to improve the visibility of weak signals. 
Please try adjusting the sliders to your liking. Once you get what appears to 
be a good trace try playing back the recorded .WAV file in version v1.8.0 with 
your old settings and compare. If you still think the new waterfall is worse 
please send us the .WAV file.

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


--
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] Sourceforge status?

[Black Michael via wsjt-devel]

Been that way for a day and others are having problems too
What does your "svn info" show?
Path: .
Working Copy Root Path: C:\JTSDK\src\wsjtx
URL: http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
Relative URL: ^/branches/wsjtx
Repository Root: http://svn.code.sf.net/p/wsjt/wsjt
Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Revision: 8543
Node Kind: directory
Schedule: normal
Last Changed Author: bsomervi
Last Changed Rev: 8543
Last Changed Date: 2018-03-06 15:45:35 -0600 (Tue, 06 Mar 2018)


de Mike W9MDB 
 

On Wednesday, March 7, 2018, 10:25:35 AM CST, Bill Somerville 
 wrote:  
 
 On 07/03/2018 16:18, Black Michael via wsjt-devel wrote:
> Is this a problem with sourceforge?  If so, has anybody reported the 
> problem?
>
> Updating '.':
> svn: E175013: Unable to connect to a repository at URL 
> 'http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx'
> svn: E175013: Access to '/p/wsjt/wsjt/branches/wsjtx' forbidden
>
> de Mike W9MDB

Hi Mike,

there was briefly, seems ok now.

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
  --
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 1.9.0 rc2 Waterfall

[Lawrence Lopez]

I found the really liked the new format of the waterfall.
It was much less critical to adjust in order to get data.
True the contrast was lower but could see much more information
was available.

The previous version 1.8.0 did note seem to able to show weak signals.


On Wed, Mar 7, 2018 at 11:26 AM, Bill Somerville 
wrote:

> On 07/03/2018 16:21, Ron Schwartz wrote:
>
>> The 1.9.0 rc2 waterfall now appears ‘smeared’ and weak traces are not as
>> visible as earlier versions (see attached).  Is this an intentional change?
>>
>
> Hi Ron,
>
> it has been changed, the intent was to improve the visibility of weak
> signals. Please try adjusting the sliders to your liking. Once you get what
> appears to be a good trace try playing back the recorded .WAV file in
> version v1.8.0 with your old settings and compare. If you still think the
> new waterfall is worse please send us the .WAV file.
>
> 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
>
--
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 1.9.0 rc2 Waterfall

[Bill Somerville]

On 07/03/2018 16:21, Ron Schwartz wrote:
The 1.9.0 rc2 waterfall now appears ‘smeared’ and weak traces are not 
as visible as earlier versions (see attached).  Is this an intentional 
change? 


Hi Ron,

it has been changed, the intent was to improve the visibility of weak 
signals. Please try adjusting the sliders to your liking. Once you get 
what appears to be a good trace try playing back the recorded .WAV file 
in version v1.8.0 with your old settings and compare. If you still think 
the new waterfall is worse please send us the .WAV file.


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] Sourceforge status?

[Bill Somerville]

On 07/03/2018 16:18, Black Michael via wsjt-devel wrote:
Is this a problem with sourceforge?  If so, has anybody reported the 
problem?


Updating '.':
svn: E175013: Unable to connect to a repository at URL 
'http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx'

svn: E175013: Access to '/p/wsjt/wsjt/branches/wsjtx' forbidden

de Mike W9MDB


Hi Mike,

there was briefly, seems ok now.

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] Sourceforge status?

[Black Michael via wsjt-devel]

Is this a problem with sourceforge?  If so, has anybody reported the problem?

Updating '.':
svn: E175013: Unable to connect to a repository at URL 
'http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx'
svn: E175013: Access to '/p/wsjt/wsjt/branches/wsjtx' forbidden

de Mike W9MDB
--
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] Timer

[James Shaver]

Thanks, Steve and Joe both - my sleep-deprived brain completely failed to 
register that part.  

Jim S. 

-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: Wednesday, March 7, 2018 11:13 AM
To: WSJT software development
Subject: Re: [wsjt-devel] Timer

Hi Jim, 

Check out item 12 in the Hound instructions:

“12. After you receive a signal report from Fox, WSJT-X will automatically send 
your next transmission as message Tx 3 (“R+rpt”) at a randomly chosen frequency 
between 300 and 900 Hz. Note that WSJT-X will send this message even if Enable 
Tx is disabled, and even if you have not called Fox for several Tx sequences. 
If you have stopped calling Fox because you will be leaving the rig unattended, 
you should quit WSJT-X or disable Hound mode in order to avoid the possibility 
of unwanted transmissions."

It is important to understand this behavior. It means that, in most cases, you 
should not just leave your rig on and monitoring the DX after you have stopped 
paying attention, as you could be in for a surprise when your rig springs to 
life and starts TXing.

Steve K9AN

> On Mar 7, 2018, at 10:05 AM, James Shaver  wrote:
> 
> Yep, twice the timer had expired on me right as the “Fox” called me and I had 
> to scramble. 
>  
> Jim S. 
> N2ADV
>  
> From: Bill Turner via wsjt-devel 
> [mailto:wsjt-devel@lists.sourceforge.net]
> Sent: Wednesday, March 7, 2018 11:03 AM
> To: WSJT Software Development
> Cc: Bill Turner
> Subject: [wsjt-devel] Timer
>  
> Great job with the test last night.  I did find the 2 minute timer to be a 
> real pain, however. I understand you do not want a robot operation, but a 5 
> or 10 minute timer would be less frustrating.
>  
> When the software shuts off the Enable TX, how do we know that we are still 
> on the correct sequence when we click on Enable TX?  I noticed some comments 
> about folks calling on the wrong sequence last night.
>  
> Again, thanks for the effort in the test.
>  
> Bill Turner, W4WNT
> --
>  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] Timer

[Hasan al-Basri]

Bill,

TX timeout timer is about right. Prevents non-stop (when not being heard)
QRM from Hounds. Also, when it times out, you have time to let a couple
cycles go by and see where in the band it might be best to call (look for
hole).

I did this multiple times (let it expire), watched the pileup, found a
hole, then simply hit Enable Tx...off it went. No settings needed to be
changed.

Sequence is automatic, no intervention needed. If people were off sequence
it was either caused by 1) Incompetence, 2) a bug , 3) Deliberate
interference, of which  there was a bunch.

As far as the Hounds are concerned, there is no sequence...it is all
controlled by the Fox. If you double click on the Fox, after setting your
Tx freq > 1000, then the only intervention required is if you aren't
getting heard, and then just Enable Tx again.

73, N0AN



Hasan

On Wed, Mar 7, 2018 at 10:02 AM, Bill Turner via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Great job with the test last night.  I did find the 2 minute timer to be a
> real pain, however. I understand you do not want a robot operation, but a 5
> or 10 minute timer would be less frustrating.
>
> When the software shuts off the Enable TX, how do we know that we are
> still on the correct sequence when we click on Enable TX?  I noticed some
> comments about folks calling on the wrong sequence last night.
>
> Again, thanks for the effort in the test.
>
> Bill Turner, W4WNT
>
> 
> --
> 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] Timer

[Steven Franke]

Hi Jim, 

Check out item 12 in the Hound instructions:

“12. After you receive a signal report from Fox, WSJT-X will automatically send 
your next transmission as message Tx 3 (“R+rpt”) at a randomly chosen frequency 
between 300 and 900 Hz. Note that WSJT-X will send this message even if Enable 
Tx is disabled, and even if you have not called Fox for several Tx sequences. 
If you have stopped calling Fox because you will be leaving the rig unattended, 
you should quit WSJT-X or disable Hound mode in order to avoid the possibility 
of unwanted transmissions."

It is important to understand this behavior. It means that, in most cases, you 
should not just leave your rig on and monitoring the DX after you have stopped 
paying attention, as you could be in for a surprise when your rig springs to 
life and starts TXing.

Steve K9AN

> On Mar 7, 2018, at 10:05 AM, James Shaver  wrote:
> 
> Yep, twice the timer had expired on me right as the “Fox” called me and I had 
> to scramble. 
>  
> Jim S. 
> N2ADV
>  
> From: Bill Turner via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
> Sent: Wednesday, March 7, 2018 11:03 AM
> To: WSJT Software Development
> Cc: Bill Turner
> Subject: [wsjt-devel] Timer
>  
> Great job with the test last night.  I did find the 2 minute timer to be a 
> real pain, however. I understand you do not want a robot operation, but a 5 
> or 10 minute timer would be less frustrating.
>  
> When the software shuts off the Enable TX, how do we know that we are still 
> on the correct sequence when we click on Enable TX?  I noticed some comments 
> about folks calling on the wrong sequence last night.
>  
> Again, thanks for the effort in the test.
>  
> Bill Turner, W4WNT
> --
> 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] Timer

[James Shaver]

I missed that in the documentation - thanks for that, Joe!  My cat was very put 
out when I made a mad dash for the mouse ;)

I'll apologize to her later. 

Jim S. 
N2ADV

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Wednesday, March 7, 2018 11:09 AM
To: WSJT software development
Subject: Re: [wsjt-devel] Timer

Jim --

I don't think you had to scramble.  If Fox calls you, your Tx3 message will be 
sent (somewhere in 300-900 Hz), even if Tx Enable is not engaged.
-- Joe


On 3/7/2018 11:05 AM, James Shaver wrote:
> Yep, twice the timer had expired on me right as the “Fox” called me and 
> I had to scramble.
> 
> Jim S.
> N2ADV
> 
> *From:*Bill Turner via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> *Sent:* Wednesday, March 7, 2018 11:03 AM
> *To:* WSJT Software Development
> *Cc:* Bill Turner
> *Subject:* [wsjt-devel] Timer
> 
> Great job with the test last night.  I did find the 2 minute timer to be 
> a real pain, however. I understand you do not want a robot operation, 
> but a 5 or 10 minute timer would be less frustrating.
> 
> When the software shuts off the Enable TX, how do we know that we are 
> still on the correct sequence when we click on Enable TX?  I noticed 
> some comments about folks calling on the wrong sequence last night.
> 
> Again, thanks for the effort in the test.
> 
> Bill Turner, W4WNT
> 
> 
> 
> --
> 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] Timer

[Joe Taylor]

Jim --

I don't think you had to scramble.  If Fox calls you, your Tx3 message 
will be sent (somewhere in 300-900 Hz), even if Tx Enable is not engaged.

-- Joe


On 3/7/2018 11:05 AM, James Shaver wrote:
Yep, twice the timer had expired on me right as the “Fox” called me and 
I had to scramble.


Jim S.
N2ADV

*From:*Bill Turner via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
*Sent:* Wednesday, March 7, 2018 11:03 AM
*To:* WSJT Software Development
*Cc:* Bill Turner
*Subject:* [wsjt-devel] Timer

Great job with the test last night.  I did find the 2 minute timer to be 
a real pain, however. I understand you do not want a robot operation, 
but a 5 or 10 minute timer would be less frustrating.


When the software shuts off the Enable TX, how do we know that we are 
still on the correct sequence when we click on Enable TX?  I noticed 
some comments about folks calling on the wrong sequence last night.


Again, thanks for the effort in the test.

Bill Turner, W4WNT



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

[James Shaver]

Yep, twice the timer had expired on me right as the “Fox” called me and I had 
to scramble. 

 

Jim S. 
N2ADV

 

From: Bill Turner via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Wednesday, March 7, 2018 11:03 AM
To: WSJT Software Development
Cc: Bill Turner
Subject: [wsjt-devel] Timer

 

Great job with the test last night.  I did find the 2 minute timer to be a real 
pain, however. I understand you do not want a robot operation, but a 5 or 10 
minute timer would be less frustrating.

 

When the software shuts off the Enable TX, how do we know that we are still on 
the correct sequence when we click on Enable TX?  I noticed some comments about 
folks calling on the wrong sequence last night.

 

Again, thanks for the effort in the test.

 

Bill Turner, W4WNT

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

[Bill Turner via wsjt-devel]

Great job with the test last night.  I did find the 2 minute timer to be a real 
pain, however. I understand you do not want a robot operation, but a 5 or 10 
minute timer would be less frustrating.
When the software shuts off the Enable TX, how do we know that we are still on 
the correct sequence when we click on Enable TX?  I noticed some comments about 
folks calling on the wrong sequence last night.
Again, thanks for the effort in the test.
Bill Turner, W4WNT
--
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] Public test of FT8 DXpedition mode March 6-7

[Rich - K1HTV]

While on 20M FT8 a few days ago I saw 5B4AIF and called him. It appeared that 
he was using the DXpedition mode (N=1). While sending a RR73 message to one 
station, it was followed by a semicolon and my call and report. I had called 
the 5B4, hundreds of Hertz higher in frequency. When he answered my call, I 
received an alert message about having to be in the DXpedition mode. I did NOT 
enter the Fox/Hound mode, nor did I manually move lower in frequency, as the 
mode would do automatically. I continued calling the 5B4, but he never 
responded. I wonder If I had manually moved my frequency closer to him if the 
QSO would continue. Probably not, because the magic "byte" was not set, right?


See you all Tuesday EST for the FT8 DXpedition mode test pileups. I'm sure that 
they will be big!


73,

Rich - K1HTV 


= = =

To  WSJT software development https://connect.xfinity.com/appsuite/#  
* Delete
* Actions https://connect.xfinity.com/appsuite/#

I’m curious to know what will happen when someone wanders into these tests, 
without RC2, and tries to send one of the messages not used in these 
abbreviated sequences.  Will those callers be ignored?

Dave / NX6D--
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] Fox mode suggestion

[George J Molnar]

Perhaps one of the Fox channels can include a randomized ID (even like CQ PH0X 
FM29), not to exceed 9 minutes? Might help pileup management.

George J Molnar
Washington, DC
@GJMolnar | KF2T 
> 
--
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] Public test of FT8 DXpedition mode March 6-7

[Gary Rogers]

Morning all, I was only able to participate in the last 20 minutes of the 20m 
test and most of the 30m test. Due to propagation, l was not able to decode the 
fox on either band although I saw many hounds calling and providing their 
signal reports. 

I had set up wsjtx the night before in hound mode so it would be ready once I 
got on the air for the test. Once I started it up last night, I noticed a 
couple of weird things:

The program locked up when ran my auto tuner. Resolved by closing and 
restarting. Never happened before. 

The program got “stuck” in the decode phase several times requiring close and 
restart. 

The program would not pass CQs (I.e. the Mexican station) to JT bridge.  
Usually passes CQs without fail. 

Frustrated, I changed back to non DXpedition mode and closed the program. 
Restarted in regular FT8 mode then switched back to hound and everything worked 
perfectly. 

So I’m not sure whether this is the way the software is supposed to work or not 
but if it is, a stronger admonition in the user manual about not starting the 
program in fox or hound mode may be warranted. 

For the record, I’m running the OSX version on a MacBook Pro with JTBridge and 
Rumlog.

Hope this useful. Gary KO3F 

Sent from my iPad

> On Mar 7, 2018, at 6:40 AM, Jay Hainline  wrote:
> 
> My observations.
> 
> I was only able to participate during the first 20 minutes of the 20 meter
> test at 2300z. Joe was decoding around -18 during the time and I was calling
> using barefoot power. According to pskreporter, Joe heard me but I was never
> called.
> 
> So my question is why I was never called? Does my callsign get pushed down
> the list when new calls are decoded? What sort order was Joe using at the
> time? Is there a "first come, first serve" sort order to the queue of hounds
> to be called?
> 
> Judging by comments I have seen, the lack of RR73 message being sent causing
> hounds to send R-report over and over, there is still work to be done before
> it is dxpedition ready. I hope there are more tests and I will be able to
> participate fully.
> 
> Thank you to the developers for putting this all together. It is very
> interesting!
> 
> 73 Jay KA9CFD
> 
> -Original Message-
> From: Joe Taylor  
> Sent: March 4, 2018 23:44
> To: WSJT software development 
> Subject: [wsjt-devel] Public test of FT8 DXpedition mode March 6-7
> 
> Hi all,
> 
> I write to remind you of the public test of *FT8 DXpedition Mode* scheduled
> for March 6-7.  The more participants, the better!
> The main goal is to simulate pileups in which many "Hounds" call and attempt
> to work a desirable rare DX station, the  "Fox", and to maximize the
> resulting QSO rate.  We hope you can be there and work each of our Foxes on
> each band.
> 
> All participating stations must use program version WSJT-X v1.9.0-rc2. 
> If you don't yet have it, download links are available here:
> https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
> 
> Detailed instructions for Fox and Hound stations are posted here:
> http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
> It's important to read and follow these instructions carefully!  Don't just
> try to wing it.
> 
> Each hour during the test has a designated frequency and Fox callsign,
> "Fox_A" in the following table.
> 
> Date   UTCFreq  Fox_AFox_B   NSlots
> ---
> Mar 6 2300  14.080  K1JT W7/KH7Z3
> Mar 7   10.141  W1/KH7Z  K9AN   5
> Mar 7 0100   7.080  W7/KH7Z  K1JT   4
> Mar 7 0200   3.585  K9AN W1/KH7Z3
> 
> As you will know after reading the FT8 DXpedition Mode User Guide, Fox can
> conduct up to "NSlots" QSOs simultaneously.  W7/KH7Z will be operated by
> AA7A, and W1/KH7Z by N1DG.
> 
> Fox_A will operate for the full hour if plenty of Hounds keep calling. 
> Fox_B is on standby reserve.  If the QSO rate for Fox_A approaches zero at
> the half-hour mark, Fox_A will stop transmitting and Fox_B will call CQ.
> 
> If you (as a Hound) can legitimately use more than one callsign -- your
> spouse's call, club call, etc. -- please try to work each Fox multiple
> times.  No dupe QSOs with the same call and same band, though.
> 
> Real-time liaison will be available via the "Ping Jockey Relief" chat page
> (PJB), https://www.pingjockey.net/cgi-bin/pingtalkB .  Everyone should
> monitor this page for possible announcements of frequency changes or
> switch-overs from Fox_A to Fox_B.  To ensure that announcements from Fox
> stations are easily visible, Hounds should monitor PJB but not post messages
> there during the test.
> 
> The deepest pileups will help us to tune the final-release software version
> for optimum performance on both Fox and Hound sides.  After the test, please
> post any comments you feel will be helpful to one of our two email forums,
> wsjtgr...@yahoogroups.com or wsjt-devel@lists.sourceforge.net .  You will
> need 

Re: [wsjt-devel] Public test of FT8 DXpedition mode March 6-7

[Jay Hainline]

My observations.

I was only able to participate during the first 20 minutes of the 20 meter
test at 2300z. Joe was decoding around -18 during the time and I was calling
using barefoot power. According to pskreporter, Joe heard me but I was never
called.

So my question is why I was never called? Does my callsign get pushed down
the list when new calls are decoded? What sort order was Joe using at the
time? Is there a "first come, first serve" sort order to the queue of hounds
to be called?

Judging by comments I have seen, the lack of RR73 message being sent causing
hounds to send R-report over and over, there is still work to be done before
it is dxpedition ready. I hope there are more tests and I will be able to
participate fully.

Thank you to the developers for putting this all together. It is very
interesting!

73 Jay KA9CFD

-Original Message-
From: Joe Taylor  
Sent: March 4, 2018 23:44
To: WSJT software development 
Subject: [wsjt-devel] Public test of FT8 DXpedition mode March 6-7

Hi all,

I write to remind you of the public test of *FT8 DXpedition Mode* scheduled
for March 6-7.  The more participants, the better!
The main goal is to simulate pileups in which many "Hounds" call and attempt
to work a desirable rare DX station, the  "Fox", and to maximize the
resulting QSO rate.  We hope you can be there and work each of our Foxes on
each band.

All participating stations must use program version WSJT-X v1.9.0-rc2. 
If you don't yet have it, download links are available here:
https://physics.princeton.edu/pulsar/k1jt/wsjtx.html

Detailed instructions for Fox and Hound stations are posted here:
http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
It's important to read and follow these instructions carefully!  Don't just
try to wing it.

Each hour during the test has a designated frequency and Fox callsign,
"Fox_A" in the following table.

Date   UTCFreq  Fox_AFox_B   NSlots
---
Mar 6 2300  14.080  K1JT W7/KH7Z3
Mar 7   10.141  W1/KH7Z  K9AN   5
Mar 7 0100   7.080  W7/KH7Z  K1JT   4
Mar 7 0200   3.585  K9AN W1/KH7Z3

As you will know after reading the FT8 DXpedition Mode User Guide, Fox can
conduct up to "NSlots" QSOs simultaneously.  W7/KH7Z will be operated by
AA7A, and W1/KH7Z by N1DG.

Fox_A will operate for the full hour if plenty of Hounds keep calling. 
Fox_B is on standby reserve.  If the QSO rate for Fox_A approaches zero at
the half-hour mark, Fox_A will stop transmitting and Fox_B will call CQ.

If you (as a Hound) can legitimately use more than one callsign -- your
spouse's call, club call, etc. -- please try to work each Fox multiple
times.  No dupe QSOs with the same call and same band, though.

Real-time liaison will be available via the "Ping Jockey Relief" chat page
(PJB), https://www.pingjockey.net/cgi-bin/pingtalkB .  Everyone should
monitor this page for possible announcements of frequency changes or
switch-overs from Fox_A to Fox_B.  To ensure that announcements from Fox
stations are easily visible, Hounds should monitor PJB but not post messages
there during the test.

The deepest pileups will help us to tune the final-release software version
for optimum performance on both Fox and Hound sides.  After the test, please
post any comments you feel will be helpful to one of our two email forums,
wsjtgr...@yahoogroups.com or wsjt-devel@lists.sourceforge.net .  You will
need to be subscribed to the list in order to post there.

We sincerely hope you can join us for this test, working each Fox on each
band!

 -- 73, Joe, K1JT (for the WSJT Development Group)


--
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] FT8 with YAESU FT920

[Bill Somerville]

On 07/03/2018 09:39, Hans Piehler wrote:


Now all stations are in the above range more than 2000.

I think this is not the normal range to compare with the FT817.

If I change the mode from DIG to USB, I have all stations in the 
normal range but


no modulation comes to the backside connector.


Hi Hans,

Yaesu rigs usually have two menu settings that set the VFO display 
offset and shift for their USB-DATA modes (DIG), these need adjusting so 
that the dial frequency and passband are correctly aligned. Often zero 
for both is correct as that equates to a voice SSB passband with the 
dial frequency at the suppressed carrier frequency and the audio 
passband between 0Hz and ~4000 Hz and maximum width. Yaesu are not 
consistent with these parameters with the shift on some rigs allowing 
movement between LSB and USB, those need a positive shift of roughly 
half the maximum width to centre the IF passband on the USB side.


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] FT8 with YAESU FT920

[Claude Frantz]

On 03/07/2018 10:39 AM, Hans Piehler wrote:

Hi Hans,

> I started FT8 with a small equipment FT817. In this configuration I made
> some QSO.
> 
> The picture FT817 show the settings and the screen. It seems to work right.
> 
> Than I changed to my home station FT920. There ist the picture FT920
> with the settings
> 
> and screen.

I confess that I'm a little bit surprised while looking at the waterfall
on these pictures. On the FT817 picture, I'm observing regularly spaced
signals over all the range. This is not usual. Perhaps an overdrive on
the audio channel ? On the FT920 picture, I can see a non flat channel
response on a frequency usually not used with FT8.

> Now all stations are in the above range more than 2000.
> 
> I think this is not the normal range to compare with the FT817.

I suggest to verify that CAT is really well configured and operational
on both rigs.

> If I change the mode from DIG to USB, I have all stations in the normal
> range but
> 
> no modulation comes to the backside connector.

Please note that switching the mode from DIG to USB can change also the
sockets on your XCVR on which ones the signals appear.

Best whishes,
Claude (DJ0OT)

--
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] Audio input from RTP stream?

[Игорь Ч via wsjt-devel]

Hello Phil,
>I implemented RTP in about a page of C code, not counting all of the
>UNIX/Linux system calls needed to set up multicast sockets. That's
>actually the only hard part. With RTP I just check that the next packet
>is in sequence, drop any old duplicates, and play out silence in place
>of lost packets to maintain timing, which is much more important for
>digital demodulators than for human speech.
.
Playing out silence in place of the lost packets is not a good idea:
it will distrurb sychronization and will bring wrong Delta Time values 
to the weak signals at demodulation. I would suggest usage of some 
averaging instead of the silence.
.
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

[wsjt-devel] FT8 with YAESU FT920

[Hans Piehler]

Hello dear OM's,

 

I started with FT8 and a small equipment FT817. In this configuration I made
some QSO.

The picture FT817 show the settings and the screen. It seems to work right.

Than I changed to my home station FT920. There ist the picture FT920 with
the settings

and screen.

Now all stations are in the above range more than 2000.

I think this is not the normal range to compare with the FT817.

If I change the mode from DIG tu USB, I have all stations in the normal
range but 

no modulation comes to the backside connector.

 

What shell I do to get a good working condition? Can you help me?

 

Mni tks es 73 de Hans, DL8ARJ 

 

--
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] Audio input from RTP stream?

[Phil Karn]

To Bill (and Joe),

It just occurred to me that I could multicast my receiver output to you
in the frequency domain. UDP already provides the necessary framing. We
just define that as a new RTP "codec type".

I use fast convolution with overlap-and-save for filtering, so as long
as I tell you the parameters (i.e, FFT block size and the overlap
amount) I could just give you the frequency domain signal before I'd
ordinarily perform the IFFT. This would save me the IFFT (though I'd
probably do it anyway just so I could listen). With the right blocksize,
it might also save you an FFT.

To be honest, at that point there wouldn't be much left for my receiver
to do. Or you could just read my raw SDR I/Q streams directly...

We could also reduce the bandwidth by just truncating the frequency
information, though I'd have to apply a low pass decimation filter to
avoid aliasing. I use Kaiser windowing for pretty much everything; I
really like its tuning knob to trade transition sharpness against
stopband sidelobes. (I also worked with Jim Kaiser at Bellcore way back
in the 1980s.)

Phil


--
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] Audio input from RTP stream?

[Phil Karn]

On 3/6/18 08:05, Bill Somerville wrote:

> not very hard at all. The audio in WSJT-X is via a Qt I/O Device
> abstraction and making a UDP server that joins a multicast group to
> receive and send audio would only require a thin layer to manage
> datagram reception and transmission converting into/out of a stream
> in/out of respective QIODevice sub-classes is about the whole
> requirement. The Modulator and Detector classes in WSJT-X are pretty
> much agnostic about which QIODevice derivative they talk to for PCM
> sample streams.

This is great news!

> Can you point me to somewhere I can get information about gathering RTP
> datagrams and combining as a continuous stream? Do I need to work with
> RTCP as well?

RTP is really very simple. It's documented in RFC-3550 ("A Transport
Protocol for Real-Time Applications"). It also defines RTCP

I implemented RTP in about a page of C code, not counting all of the
UNIX/Linux system calls needed to set up multicast sockets. That's
actually the only hard part. With RTP I just check that the next packet
is in sequence, drop any old duplicates, and play out silence in place
of lost packets to maintain timing, which is much more important for
digital demodulators than for human speech.

Where RTP can get tricky is in managing timing jitter. This isn't a
problem on most LANs unless they're severely overloaded. Over a longer
path the problem is always picking the right size for the playout
buffer, trading off latency against the risk of dropping packets that
arrive just a little too late. This is only a problem for interactive
voice; it's a non-problem for a program like WSJT that processes signals
in large chunks. For example, with WSPR your "playout buffer" could be
the entire two minutes long; just drop each RTP packet into the right
place in the buffer when it arrives and start the decoder on the even
minute as usual.

I haven't implemented RTCP yet but I will soon. The receiver statistics
aren't very useful on a LAN, but RTCP looks like the best way for a
multicast sender to tell who's listening so it can not bother sending
when there isn't anybody. With IGMP snooping the multicast streams don't
really go anywhere when nobody is listening, but the sending computer
could still save some CPU cycles.

> Our experience of users using the Elecraft remote kit using IP streaming
> is that latency and delay are a problem, this being because of our
> dependence on external wall clock synchronization. Can RTP provide
> absolute time-stamp information that we can leverage to capture UTC time
> sync relative to the source? Is there a recovery mechanism to "unbuffer"
> when delays accumulate?

RTP also provides a 32-bit relative timestamp. Its exact meaning depends
on the codec; in general it's supposed to count audio samples at the
encoder input or decoder output (or frames for video). For 48 kHz PCM
(any number of channels and any number of bits per sample) the timestamp
increments every 1/48000 sec of real time. So if a PCM packet contains
960 samples (20 ms @ 48 kHz) the RTP timestamp increases 960 with each
packet. It's the same even with compressed signals; for example, if you
use Opus with 20 ms frames the RTP timestamp still increases by 960 for
each packet even though the actual number of (compressed) bytes in the
packet varies (and is considerably less than 960).

This is a *relative* timestamp unrelated to clock time. I've thought a
lot about the absolute timestamp problem as I also have it with the
AFSK/FM demod, HDLC receiver and APRS data extractor I wrote to process
my receiver output so our satellite antennas can automatically track the
high altitude balloons we fly at the high school ham club.

For I/Q streams I insert my own metadata header between RTP and the data
that carries the receiver LO frequency, sample rate and analog gain
settings. I just recently added absolute clock time represented as a
64-bit integer count of nanoseconds since the GPS epoch of 6 January
1980 00:00:00 UTC (don't get me started about leap seconds).

But doing that on receiver audio output would be incompatible with audio
players like VLC that can play multicast 16-bit linear PCM. Listening
directly to a raw I/Q stream doesn't seem very interesting, so there I
don't mind the incompatibility.

So the clock time problem is currently unsolved on the receiver output,
but I'm thinking of periodically sending the clock time in a separate
metadata packet. It would give the wall clock time (or the original wall
clock time for an I/Q playback) that corresponds to a particular RTP
timestamp. The sample rate ought to be accurate enough to interpolate
between those metadata updates. Remember I already fill in any missing
I/Q frames with zeroes to maintain synchronization.

IMHO, many network audio streaming schemes have huge latency because
they use TCP, which was never designed for real-time traffic. That's
what RTP/UDP is for.

I work to keep the delays in my own SDR as small as possible.