Date   

Re: Tail ending my signal #FT8

Jon Ermels
 


SSB is different? If you ever chase rare DX they always want to be answered on a different frequency. There in gives you a hint there might be a problem piling on where he are calling. If any idiot piles on is frequency they will receive a hornets nest of "split" instructions.
73 de NØIGU Jon


On Friday, January 29, 2021, 01:05:57 AM CST, mchenryproj via groups.io <mchenryproj@...> wrote:


Personally I see this as cutting the available bandwidth in half. It’s similar to telling everyone to run split. Takes 2 frequencies to make a QSO that way.  As I figure it, if someone is calling CQ, you double tap to answer and move to his frequency that’s normal in every other mode. If you are the station responding to someone’s call, at the end of the conversation, move off and find your own open spot OR, go find others to respond to.  The bad manners in the situation is taking over someone else’s spot if you are responding to someone’s call.  Not occupying 2 spots on the crowded bands to make a QSO.

 

This is different than wandering around the dial looking for people calling CQ to respond to in SSB or CW modes, mostly.  In other modes you wander around, find a station looking for a contact and park there and respond. When you are done you move off.  If you want to call CQ, find an empty spot and start calling.  Now – the notable bug in that ointment is that you can effectively “hear” multiple people calling and answering calls all at the same time in these digital modes where as in SSB or even CW, that’s not the case.  Yet, if you use an SDR with a spectrum display, you can still essentially “see” other conversations going on and don’t actually need to drive the dial to them.

 

I guess what I am saying is I don’t see why these digital modes should operate all that much differently from SSB and CW.  If you’re the guy calling, it’s your frequency.  If you responded to a call, don’t start calling stations before you move your transmit frequency off the other guys spot.  It should be that easy.

 

When I see folks QRZ page stating they won’t answer on their own frequency, I don’t bother with them as I see those folks as wasting bandwidth.   But hey, what do I know, right?

 

My 2 cents (not adjusted for inflation)

 

KB8JNE

 





Re: Tail ending my signal #FT8

Williams, G (af8c) <af8c@...>
 

Hi Reino,
I said yesterday I would experiment.   Three times in a row this morning I called someone who called CQ.  Then I immediately changed my TX frequency by a few hundred Hz. The QSOs completed without any problem.

--73, Glenn, AF8C

On 1/29/2021 3:08 AM, Reino Talarmo via groups.io wrote:

>Personally I see this as cutting the available bandwidth in half. It’s similar to telling everyone to run split. Takes 2 frequencies to make a QSO that way

 

Hi,

Personally I am a selfish person and prefer to select whom I answer, but that is not the issue. Let me explain how FT8 is different to many other digital modes. The biggest difference is multi decoding that covers the whole waterfall and even overlapping signals. You still got a RX frequency where the first decoding is tried. RX frequency need not to be same as your TX frequency for successful QSOs. You receive and try to decode all stations over whole waterfall bandwidth.
Now let’s see what happens, when I call CQ. If all stations answers at my TX frequency they will QRM each other and none may not be decoded or only some close by station I am not currently interested in. On the other hand, when answering stations are spread over waterfall range, my receiver will decode most of those and I have nice opportunity to select one.
By the way I totally disagree any statement about cutting available bandwidth in half. Bandwidth is *used* only, when you or anybody is transmitting. When you receive, you don’t *use* any bandwidth. There is another essential difference to most other modes. All transmissions happen in timeslots either even or odd. In effect band is divided timewise into two independent “bands”. QSO uses alternating those “bands” and using a single frequency on each. On the usage point of view it is totally irrelevant, whether those frequencies are same or not. They cannot QRM each other due the time division.

So use split, please. It is more efficient at QSO setup time and after that there is no difference at all.

73, Reino OH3Ma                      








Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



Re: Tail ending my signal #FT8

Jim Shorney
 

Time division multiplexing. Not a new idea. Kids these days just don't understand technology. :D

73

-Jim
NU0C

On Fri, 29 Jan 2021 08:15:50 +0000
"Philip Rose via groups.io" <gm3zza=btinternet.com@groups.io> wrote:

Well said, Reino.

What I have highlighted below is the significant factor, that some people seem not able to get their heads around. People transmitting on the same frequency as you but in the other timeslot will NOT interfere with your signal, and you will still receive on all the frequencies in your filter bandwidth.

73 Phil GM3ZZA

Sent from Mail for Windows 10

From: Reino Talarmo
Sent: 29 January 2021 08:08
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Tail ending my signal

Personally I see this as cutting the available bandwidth in half. It’s similar to telling everyone to run split. Takes 2 frequencies to make a QSO that way
Hi,
Personally I am a selfish person and prefer to select whom I answer, but that is not the issue. Let me explain how FT8 is different to many other digital modes. The biggest difference is multi decoding that covers the whole waterfall and even overlapping signals. You still got a RX frequency where the first decoding is tried. RX frequency need not to be same as your TX frequency for successful QSOs. You receive and try to decode all stations over whole waterfall bandwidth.
Now let’s see what happens, when I call CQ. If all stations answers at my TX frequency they will QRM each other and none may not be decoded or only some close by station I am not currently interested in. On the other hand, when answering stations are spread over waterfall range, my receiver will decode most of those and I have nice opportunity to select one.
By the way I totally disagree any statement about cutting available bandwidth in half. Bandwidth is *used* only, when you or anybody is transmitting. When you receive, you don’t *use* any bandwidth. There is another essential difference to most other modes. All transmissions happen in timeslots either even or odd. In effect band is divided timewise into two independent “bands”. QSO uses alternating those “bands” and using a single frequency on each. On the usage point of view it is totally irrelevant, whether those frequencies are same or not. They cannot QRM each other due the time division.
So use split, please. It is more efficient at QSO setup time and after that there is no difference at all.
73, Reino OH3Ma                      


Re: Big Sur Progress Bar #macOS

Bill Somerville
 

On 28/01/2021 06:29, James Bennett / K7TXA via groups.io wrote:
I recently installed the -RC4 version of the program on my M1 Mac Mini. Glad to see that the wonky operation of the PWR slider has been fixed. :-)

One other issue that still persists is the loss of seeing the progress bar when WSJT-X looses focus. Is this something that can be fixed or has Apple stuck it to us for good on this issue?

Jim / K7TXA
Hi Jim,

someone has raised the issue with the Qt development team already, hopefully one of the developers will be addressing it soon. I have added a vote to the issue.

https://bugreports.qt.io/browse/QTBUG-89816

73
Bill
G4WJS.


Re: #Mac Pwr Slider #macOS

Bill Somerville
 

On 29/01/2021 02:23, James Bennett / K7TXA via groups.io wrote:
Bill, you stated that it was resolved in RC3. I installed RC4 yesterday and it is still broken.

Jim / K7TXA
Hi Jim,

it is working for me and others have reported the issue is resolved. Are you certain you are running the latest WSJT-X v2.3.0 RC4 version?

73
Bill
G4WJS.


Re: #Cat_RigControl #Cat_RigControl

Dave Garber
 

have you also checked with the manufacturer
Dave Garber
VE3WEJ / VE3IE


On Thu, Jan 28, 2021 at 11:12 PM Bill Murrell <bmurrell55@...> wrote:
Trying to hook up WMR DxPro to IC706MKIIG.  CAT control will not work.  Anybody have the majic settings?



Re: Tail ending my signal #FT8

 

Well said, Reino.

 

What I have highlighted below is the significant factor, that some people seem not able to get their heads around. People transmitting on the same frequency as you but in the other timeslot will NOT interfere with your signal, and you will still receive on all the frequencies in your filter bandwidth.

 

73 Phil GM3ZZA

 

Sent from Mail for Windows 10

 

From: Reino Talarmo
Sent: 29 January 2021 08:08
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Tail ending my signal

 

>Personally I see this as cutting the available bandwidth in half. It’s similar to telling everyone to run split. Takes 2 frequencies to make a QSO that way

 

Hi,

Personally I am a selfish person and prefer to select whom I answer, but that is not the issue. Let me explain how FT8 is different to many other digital modes. The biggest difference is multi decoding that covers the whole waterfall and even overlapping signals. You still got a RX frequency where the first decoding is tried. RX frequency need not to be same as your TX frequency for successful QSOs. You receive and try to decode all stations over whole waterfall bandwidth.
Now let’s see what happens, when I call CQ. If all stations answers at my TX frequency they will QRM each other and none may not be decoded or only some close by station I am not currently interested in. On the other hand, when answering stations are spread over waterfall range, my receiver will decode most of those and I have nice opportunity to select one.
By the way I totally disagree any statement about cutting available bandwidth in half. Bandwidth is *used* only, when you or anybody is transmitting. When you receive, you don’t *use* any bandwidth.
There is another essential difference to most other modes. All transmissions happen in timeslots either even or odd. In effect band is divided timewise into two independent “bands”. QSO uses alternating those “bands” and using a single frequency on each. On the usage point of view it is totally irrelevant, whether those frequencies are same or not. They cannot QRM each other due the time division.

So use split, please. It is more efficient at QSO setup time and after that there is no difference at all.

73, Reino OH3Ma                      

 


--
73 Phil GM3ZZA


Re: Tail ending my signal #FT8

Reino Talarmo
 

>Personally I see this as cutting the available bandwidth in half. It’s similar to telling everyone to run split. Takes 2 frequencies to make a QSO that way

 

Hi,

Personally I am a selfish person and prefer to select whom I answer, but that is not the issue. Let me explain how FT8 is different to many other digital modes. The biggest difference is multi decoding that covers the whole waterfall and even overlapping signals. You still got a RX frequency where the first decoding is tried. RX frequency need not to be same as your TX frequency for successful QSOs. You receive and try to decode all stations over whole waterfall bandwidth.
Now let’s see what happens, when I call CQ. If all stations answers at my TX frequency they will QRM each other and none may not be decoded or only some close by station I am not currently interested in. On the other hand, when answering stations are spread over waterfall range, my receiver will decode most of those and I have nice opportunity to select one.
By the way I totally disagree any statement about cutting available bandwidth in half. Bandwidth is *used* only, when you or anybody is transmitting. When you receive, you don’t *use* any bandwidth. There is another essential difference to most other modes. All transmissions happen in timeslots either even or odd. In effect band is divided timewise into two independent “bands”. QSO uses alternating those “bands” and using a single frequency on each. On the usage point of view it is totally irrelevant, whether those frequencies are same or not. They cannot QRM each other due the time division.

So use split, please. It is more efficient at QSO setup time and after that there is no difference at all.

73, Reino OH3Ma                      


Re: Tail ending my signal #FT8

mchenryproj <mchenryproj@...>
 

Personally I see this as cutting the available bandwidth in half. It’s similar to telling everyone to run split. Takes 2 frequencies to make a QSO that way.  As I figure it, if someone is calling CQ, you double tap to answer and move to his frequency that’s normal in every other mode. If you are the station responding to someone’s call, at the end of the conversation, move off and find your own open spot OR, go find others to respond to.  The bad manners in the situation is taking over someone else’s spot if you are responding to someone’s call.  Not occupying 2 spots on the crowded bands to make a QSO.

 

This is different than wandering around the dial looking for people calling CQ to respond to in SSB or CW modes, mostly.  In other modes you wander around, find a station looking for a contact and park there and respond. When you are done you move off.  If you want to call CQ, find an empty spot and start calling.  Now – the notable bug in that ointment is that you can effectively “hear” multiple people calling and answering calls all at the same time in these digital modes where as in SSB or even CW, that’s not the case.  Yet, if you use an SDR with a spectrum display, you can still essentially “see” other conversations going on and don’t actually need to drive the dial to them.

 

I guess what I am saying is I don’t see why these digital modes should operate all that much differently from SSB and CW.  If you’re the guy calling, it’s your frequency.  If you responded to a call, don’t start calling stations before you move your transmit frequency off the other guys spot.  It should be that easy.

 

When I see folks QRZ page stating they won’t answer on their own frequency, I don’t bother with them as I see those folks as wasting bandwidth.   But hey, what do I know, right?

 

My 2 cents (not adjusted for inflation)

 

KB8JNE

 


Re: Tail ending my signal #FT8

Jim Brown
 

On 1/28/2021 10:49 AM, Bobby Chandler wrote:
It also happens to me at times if I'm calling CQ and my QSO partner calls another station on my Freq.
Exactly why it is very bad manners to call someone on their frequency.

Best practice is to find a clear frequency on the waterfall, Shift-Click on it, and check the box for Hold TX Freq. Do this BEFORE you are ready to call someone. I do this every time I sit down to operate.

73, Jim K9YC


#Cat_RigControl #Cat_RigControl

Bill Murrell
 

Trying to hook up WMR DxPro to IC706MKIIG.  CAT control will not work.  Anybody have the majic settings?


Re: Tail ending my signal #FT8

Williams, G (af8c) <af8c@...>
 

Hi Reino,

1. I didn't imply that fake-it would change my TX frequency.  I meant "I"  change my TX frequency.

2. I would not normally move my TX frequency like I wrote. But what I am writing about is what I believe might happen if I keep jumping my TX frequency, which is that in a new 15 second cycle the other guy's QSO in progress will find where I jumped to because in his next decode of me and my cycle-buddies that the "sort" will find me again.  Unless someone in the know either confirms or denies my theory, I am going to test it.  Like I said, I would not normally do that.

--73, Glenn, AF8C

On 1/28/2021 3:54 PM, Reino Talarmo via groups.io wrote:

>Now it's time for clearing up another possible point of confusion.  Here is what I thought happens in FT8 with TX and RX disregarding use of fake-it and F&H.   I put my TX in a clear spot so as not to stomp on someone. Then I work several signals around the whole sub-band.  What I assume is that after a decode in the "other guys" computer, his computer knows where my signal was, and he
can send his replies wherever he wants.  And that in the middle of a QSO, while one of us is not transmitting, we can move our TX frequency before we transmit again. Then during the next each decode cycle me/their own computer reads all the RX signals and re-locates where the other guy's  in-QSO signal is at, after EACH 15-second cycle, to continue the QSO, so the signals can move around but only not while transmitting.  I will even test if this is true next time I am on.

If I am wrong, well, it's not as bad as a toothache.
--73, Glenn, AF8

Hi Glenn,
1. I agree with F&H, but what do you mean by fake-it? If you refer to Split Fake it, then that is not an exception as it does *not* change you transmission frequency.
2. Nothing as such prevents you to send each 15 s timeslot at different frequency. *But* why you should do that in first place. On a “full” band there is a bigger possibility that you will transmit on top of somebody seen at the other end than when you keep the frequency where he copied it in first place. His RX is sitting on the frequency he received you in your previous transmission and the first decoding attempt will be done on that frequency giving a higher decoding probability.
Of course there are exception to that general rule due to changing QRM situation.

73, Reino OH3mA





Virus-free. www.avast.com


Re: Tail ending my signal #FT8

Jim Shorney
 

I don't move. Ops calling split will reach me. Ops calling on "my" frequency may or may not. IMO that's not a reason to move. The perceived problem will just follow you.

73

-Jim
NU0C


On Thu, 28 Jan 2021 18:12:27 -0700
"Gary - AG0N" <mcduffie@ag0n.net> wrote:

On Jan 28, 2021, at 12:43, Philip Rose via groups.io <gm3zza=btinternet.com@groups.io> wrote:

I don’t mind if they call me on my frequency, why do you?
Because then I have to move before making the next contact if they don’t.

Gary - AG0N


Re: #Mac Pwr Slider #macOS

 

Bill, you stated that it was resolved in RC3. I installed RC4 yesterday and it is still broken. 

Jim / K7TXA


Re: Tail ending my signal #FT8

Robert Lorenzini
 

And you may have any unknown number of stations calling on your freq. some of
them don't stop calling even after you have made a contact. More repeats, more
interference. We have been over this numerous times and it always comes out
as poor form.

dod

On 1/28/2021 5:12 PM, Gary - AG0N wrote:

On Jan 28, 2021, at 12:43, Philip Rose via groups.io <gm3zza@...> wrote:

I don’t mind if they call me on my frequency, why do you?
Because then I have to move before making the next contact if they don’t.

Gary - AG0N





Re: Tail ending my signal #FT8

Gary - AG0N
 

On Jan 28, 2021, at 12:43, Philip Rose via groups.io <gm3zza=btinternet.com@groups.io> wrote:

I don’t mind if they call me on my frequency, why do you?
Because then I have to move before making the next contact if they don’t.

Gary - AG0N


Re: #AudioIssues #AudioIssues

Ron / W4MMP
 

Any luck?

73,
Ron / W4MMP
On 1/25/2021 23:50, Ron / W4MMP via groups.io wrote:

Hi Steve,

Hum,  a mystery to be solved.   Here are a few suggestions.   1) is to tap the audio output of the rig that is feeding your computer.   Do you have a scope?  If so monitor the audio with your scope.   When the audio stops take a look at the scope to see if your rig is still feeding audio to the computer.  If you don't have a scope, jury rig something so that you can monitor the audio with a head set or something along that line.  

Another thing you can do is monitor the volume meter:  Monitor the vertical volume LED bar.   It should always be showing some level of activity.

Yet another thing you can do monitor the audio with your computer speaker (or whatever audio output device plays the computer sounds).  Click "Listen to this device"  The audio that is sent to your WSJT-X audio device will also be sent to your computer speaker device.   


The point of this is to determine if the computer is hosing up, or your rig.

73,
Ron / W4MMP
On 1/25/2021 22:57, Steven Rutledge wrote:
Ron, I made all these changes.  Some of them I'd already done.  Others I had not.  I still have the problem.  Interestingly, I have found that when I lose audio, if I transmit, (tune), it recovers the audio chain.  So, I'm wondering if now it isn't something in the radio?????  Again, WSJT-X is only program running.  I am not transmitting, simply receiving and decoding.  Sometimes it will run for five minutes and stop.  Other times up to several hours.  Usually about an hour or so though before it stops receiving.  No RF involved in the shack. 

I'm totally confused.

Steve, N4JQQ


Re: West Mountain Radio RIGblaster Blue #IssueReport #bluetooth

Bill Somerville
 

On 28/01/2021 21:49, Sholto Fisher wrote:
Bill,

Audio is the problem actually. The symptoms are few decodes and it looks like sometimes the program's decode is happening at odd times. The RIGblaster uses the HSP and HFP Bluetooth® profiles. Sample rate conversion doesn't seem to be a problem in any other digital mode software and I'm not convinced it's the problem here, it may be more related to latency perhaps, or how WSJT-X opens/closes sound channels in the RX/TX period. I've tried the Microsoft Bluetooth® stack in Windows 10 but also the software stack provided with one of the Bluetooth® 4.0 dongles I have here to test with similar results. Also tried this in Ubuntu with the same dongles and same issue. I've tried CSR and Broadcom dongles.

73
Sholto
K7TMG
Hi Sholto,

latency greater than 400 mS will impact decoding.

WSJT-X only closes and re-opens the Rx audio stream when the device is changed in settings. The Tx audio stream is opened and closed around each transmission.

We Qt for access to audio streams, there are environment variables in the latest WSJT-X v2.3.0 RC4 to adjust buffer sizes which may help.

WSJT_(R|T)X_AUDIO_BUFFER_FRAMES

Default values should be OK but you can try different values. Zero means use default. Other than buffers sizes we have no real control on how Qt manages the streams.

73
Bill
G4WJS.


Re: West Mountain Radio RIGblaster Blue #IssueReport #bluetooth

Sholto Fisher
 

Bill,

Audio is the problem actually. The symptoms are few decodes and it looks like sometimes the program's decode is happening at odd times. The RIGblaster uses the HSP and HFP Bluetooth® profiles. Sample rate conversion doesn't seem to be a problem in any other digital mode software and I'm not convinced it's the problem here, it may be more related to latency perhaps, or how WSJT-X opens/closes sound channels in the RX/TX period. I've tried the Microsoft Bluetooth® stack in Windows 10 but also the software stack provided with one of the Bluetooth® 4.0 dongles I have here to test with similar results. Also tried this in Ubuntu with the same dongles and same issue. I've tried CSR and Broadcom dongles.

73
Sholto
K7TMG


Re: West Mountain Radio RIGblaster Blue #IssueReport #bluetooth

Bill Somerville
 

On 28/01/2021 20:25, Sholto Fisher wrote:

Hello to all. I’m not sure this is the right forum for my question so apologies if sent to the wrong place.

 

I work for West Mountain Radio and our Bluetooth audio RIGblaster doesn’t appear to work properly with WSJT-X although it did with previous versions and still does with other popular digital mode software.

 

I’m hoping I can speak with a WSJT-X developer and offer a RIGblaster Blue interface for debugging/testing.

 

Can anyone suggest a contact?

 

73

Sholto

K7TMG

Hi Sholto,

I assume the audio interface is not the problem. If your interface provides transparent CAT protocol pass through there should be no issue with CAT either. What are the symptoms?

73
Bill
G4WJS.

7661 - 7680 of 28804