Steve

Thanks for your thoughts there. I just did a few experiments.

I started up WSJT-X fresh.
1) At 15:45:45 I clicked Enable Tx and Tx Next. - contrary to my earlier experience, it transmitted at 14:46:00
2) At 15:46:15 without TX Next enabled, I clicked Enable Tx and it immediately started transmitting!
3) At 15:51:50 (so 5 seconds before end of cycle) I clicked Enable transmit and Tx Next and it transmitted at 15:52:00

So it is now acting differently from before... and it was also a fresh instance of WSJT-X previously

Maybe we'll experiment with WSPR-2 in JTDX - no idea if they've modified anything on the WSPR front there

Thanks

Alan - a good point.
I guess as you would expect Tx Next to actually cause a transmission on the next cycle on the even minute, and as you would expect 100% transmission probability to do the same, it was simply overkill!
...and even overkill didn't work...!
73
Mike

Mike

I have noticed something similar - In the example you gave, I would expect clicking on TX next at 9:01:15 would indeed not transmit until 9:04:00. However if you clicked TX next at 9:00:15 then it will transmit at 9:02 as you expect.

I presume that there is a time period where it will work as expected and that is somewhere before the first minute ends. I have never tried to work out exactly where the cutoff is.

It may be linked to redundant data in the WSPR transmission as I notice that you can get a full decode even if you only listen for the first half of the transmission (I noticed this when I knocked it off frequency and it still decoded).

--
Steve M0NMA

On 28/02/2022 08:59, Mike M0AGP wrote:

A friend and I were trying to take turns alternating sending WSPR every other period and we both have found it is impossible to force WSPR to transmit, even if you set the % figure to 100% and tick the box "transmit next".

Mike

I do not have a definitive answer, but why use 100%?

From the relatively few times I want to initiate a TX cycle I just use TX next, do nothing else. As you have said, stopping, starting gives seemingly odd results.

Try 1%, use TX next, see what happens, the occasional 1% TX should not worry you too much.

73 Alan G4ZFQ

Thanks for your help Reino - maybe someone who knows the code can advise further?
73
Mike M0AGP

Hi Mike

Thanks for further description of the problem.

In our case you would be in the middle of a cycle and with the percentage set to 100%, click "Tx Next" and when the next even minute comes up it doesn't transmit.

I tried to test that and could not repeat it. But when I switched Monitor off, then Tx never started transmission. When I activated Monitor, it took the ongoing timeslot and the next full reception timeslot before transmitter went on. Looks like "Listen before transmitting" advice!

Doesn't "Tx Next" refer to the start of the very next cycle beginning on the even minute mark? So say it is 09:01:15 and we click enable transmit and Tx next: our expectation was that at 09:02:00 transmission would begin. But it begins at 09:04:00 instead with a needless receive cycle inserted.

I also think so, but was your Monitor active all time before that?

Usually it would transmit after a full cycle of receiving, though I think there were times when it waited out two full 2 minute cycles before it would transmit, despite the 100% setting and Tx Next.

I did not hit that in my short testing.

I guess we thought that the parameter which says which percentage of the time you want to transmit (e.g., normally 20% for example), when set to 100%, would affect the "random" calculation.

So for example if you said 50%, you would expect that each time, something like this was happening: "if random() < 0.5 then transmit" (where random() returns a floating point number between 0 and 1) And for higher percentage figures, you would expect that the probability increases that you would transmit. So if we set the percentage to 100%, then it would logically always transmit, beginning on the very next even minute.

Well, looks reasonable, but there could be some other rule as well. In my test using 50% I noted up to three continuous transmit or reception periods not more, but it was only a sort observation time!

And what's funny is that it seems like once it gets started it will keep transmitting forever - but it's getting it started that seems to be impossible to control.

Could be the "Listen before transmit" rule.

How does the actual logic work in the code pls?

Sri, my programming knowledge is so limited that I have no idea.

We may end up having to create our own version of the software to make it actually transmit on the start of the next even minute - but would really prefer not to have to do that :-)

Unfortunately that may be the most potential solution.

73, Reino OH3mA

Hi Reino

Thanks for your reply.

Yes I am aware that WSPR transmissions start on the even minute :-)

In our case you would be in the middle of a cycle and with the percentage set to 100%, click "Tx Next" and when the next even minute comes up it doesn't transmit.

Doesn't "Tx Next" refer to the start of the very next cycle beginning on the even minute mark? So say it is 09:01:15 and we click enable transmit and Tx next: our expectation was that at 09:02:00 transmission would begin. But it begins at 09:04:00 instead with a needless receive cycle inserted.

Usually it would transmit after a full cycle of receiving, though I think there were times when it waited out two full 2 minute cycles before it would transmit, despite the 100% setting and Tx Next.

I guess we thought that the parameter which says which percentage of the time you want to transmit (e.g., normally 20% for example), when set to 100%, would affect the "random" calculation.
So for example if you said 50%, you would expect that each time, something like this was happening: "if random() < 0.5 then transmit" (where random() returns a floating point number between 0 and 1)
And for higher percentage figures, you would expect that the probability increases that you would transmit. So if we set the percentage to 100%, then it would logically always transmit, beginning on the very next even minute.

And what's funny is that it seems like once it gets started it will keep transmitting forever - but it's getting it started that seems to be impossible to control.

How does the actual logic work in the code pls?

We may end up having to create our own version of the software to make it actually transmit on the start of the next even minute - but would really prefer not to have to do that :-)

Thanks
Mike

Hi Mike,

I may have silly question. When you activate the Tx Next, the next transmission will start at the next even minute not immediately. May I assume that you have noted that?

The next issue about 50% transmission synchronized with you friend at alternating 2 min timeslots may not be possible with the standard WSJT-X as the User Guide states in 9. WSPR Mode in the one but last bullet point:
"Transmitting periods are also 2 minutes duration, and will occur randomly in time to reduce the chance of clashing with other stations you may be monitoring."

At least in my short test it:
transmitted at 10:14
received at 10:16
transmitted at 10:18
transmitted at 10:20
received at 10:22
transmitted at 10:24
received at 10:26
transmitted at 10:28
received at 10:30
transmitted at 10:32
transmitted at 10:34
received at 10:36
received at 10:38
transmitted at 10:40
transmitted at 10:42
received at 10:44
as random as possible, I think.

73, Reino OH3mA

A friend and I were trying to take turns alternating sending WSPR every other period and we both have found it is impossible to force WSPR to transmit, even if you set the % figure to 100% and tick the box "transmit next". Despite these settings it often just decides not to transmit for some reason...
What is the smart way to make it transmit with certainty please?
Tnx
Mike M0AGP