Date   

locked Re: IC-7100 FT8 transmit timing problem.

Dave Garber
 

oops replied to wrong message
Dave Garber
VE3WEJ / VE3IE


On Sun, Oct 25, 2020 at 10:04 AM Dave Garber via groups.io <ve3wej=gmail.com@groups.io> wrote:
check topbe sure you are on ft8 as the selected mode...
Dave Garber
VE3WEJ / VE3IE


On Sun, Oct 25, 2020 at 7:58 AM Martin G0HDB <marting0hdb@...> wrote:
On Sat, Oct 24, 2020 at 08:04 PM, Bill Somerville wrote:

Hi Martin,

the audio click you are hearing when using CAT PTT is probably due to the PTT not being asserted until after the audio from WSJT-X has started. WSJT-X does try and avoid that but some rigs do not provide feedback that they have switched to SEND mode.

I would guess that the delayed PTT via CAT is something to do with your K9JM CI-V router. Have you tried eliminating that for a test, taking care to remove any sensitive/buggy devices from the CI-V bus, like a PW-1 PA.

73
Bill
G4WJS.

Morning Bill, thanks for the above.

Re: the audio clicks (or splats!) at the start and occasionally the end of a transmit period, I take your point about the PTT not being asserted (within the rig?) until after WSJT-X has started to generate and send the audio, but shouldn't the Tx delay setting in WSJT-X take care of that?  My understanding has always been that the Tx delay is between WSJT-X executing its command to enable PTT and the onset of the Tx audio generated by the s/ware, so increasing the Tx delay to say 0.5secs should give ample time for the rig to receive the PTT command via whatever option is selected and action the changeover from Rx to Tx before the audio arrives.  As I mentioned previously, increasing the Tx delay setting when I use the CAT PTT option doesn't seem to affect the presence of the audio splats, although I haven't tried using a delay setting of >0.5secs.

With regard to your second point, there's a slight misunderstanding - I experience the seemingly randomly-delayed start of transmission when I DON'T use the CAT PTT option, so the presence of the K9JM router in the CAT connection between PC and rig shouldn't have any bearing.  The rig's PTT is controlled entirely by the G4ZLP datamodes interface device which appears to WIndows as an external audio codec in the same way as a SignaLink-USB.  The PTT signal generated by a VOX-type circuit within the G4ZLP device is hard-wired to the rig's PTT input on the ACC1 socket, so as soon as the audio generated by WSJT-X begins to emerge as an analogue signal from the codec within the G4ZLP device the VOX circuit should toggle the PTT line - apparently the 'VOX delay' is only of the order of 10-20msecs.

73
--
Martin G0HDB






locked Re: IC-7100 FT8 transmit timing problem.

Dave Garber
 

check topbe sure you are on ft8 as the selected mode...
Dave Garber
VE3WEJ / VE3IE


On Sun, Oct 25, 2020 at 7:58 AM Martin G0HDB <marting0hdb@...> wrote:
On Sat, Oct 24, 2020 at 08:04 PM, Bill Somerville wrote:

Hi Martin,

the audio click you are hearing when using CAT PTT is probably due to the PTT not being asserted until after the audio from WSJT-X has started. WSJT-X does try and avoid that but some rigs do not provide feedback that they have switched to SEND mode.

I would guess that the delayed PTT via CAT is something to do with your K9JM CI-V router. Have you tried eliminating that for a test, taking care to remove any sensitive/buggy devices from the CI-V bus, like a PW-1 PA.

73
Bill
G4WJS.

Morning Bill, thanks for the above.

Re: the audio clicks (or splats!) at the start and occasionally the end of a transmit period, I take your point about the PTT not being asserted (within the rig?) until after WSJT-X has started to generate and send the audio, but shouldn't the Tx delay setting in WSJT-X take care of that?  My understanding has always been that the Tx delay is between WSJT-X executing its command to enable PTT and the onset of the Tx audio generated by the s/ware, so increasing the Tx delay to say 0.5secs should give ample time for the rig to receive the PTT command via whatever option is selected and action the changeover from Rx to Tx before the audio arrives.  As I mentioned previously, increasing the Tx delay setting when I use the CAT PTT option doesn't seem to affect the presence of the audio splats, although I haven't tried using a delay setting of >0.5secs.

With regard to your second point, there's a slight misunderstanding - I experience the seemingly randomly-delayed start of transmission when I DON'T use the CAT PTT option, so the presence of the K9JM router in the CAT connection between PC and rig shouldn't have any bearing.  The rig's PTT is controlled entirely by the G4ZLP datamodes interface device which appears to WIndows as an external audio codec in the same way as a SignaLink-USB.  The PTT signal generated by a VOX-type circuit within the G4ZLP device is hard-wired to the rig's PTT input on the ACC1 socket, so as soon as the audio generated by WSJT-X begins to emerge as an analogue signal from the codec within the G4ZLP device the VOX circuit should toggle the PTT line - apparently the 'VOX delay' is only of the order of 10-20msecs.

73
--
Martin G0HDB



locked Re: RX Window blank, Waterfall full and radio shows large activity

Komkit Listisard
 

If your signal is in the middle between the green lines then issue may be somewhere else like other have suggested.


locked Re: RX Window blank, Waterfall full and radio shows large activity

Mike Toole
 

Thank you all.  Have checked the items you recommended ( I use dimension 4 for clock sync) and am still having the issue.

73, KI5EGH Mike


locked Re: RX Window blank, Waterfall full and radio shows large activity

Reino Talarmo
 

Mike,

Have you selected Start new period decodes at top? If so there is a known issue that the display stops properly function after an ‘excessive’ amount of decodes. You need now and then erase the band activity window, right click on it and select Erase.

73, Reino OH3mA

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of KI5EGH via groups.io
Sent: 25. lokakuuta 2020 13:11
To: main@WSJTX.groups.io
Subject: [WSJTX] RX Window blank, Waterfall full and radio shows large activity

 

FT8 has been working fine then on occasion the RX screen would be blank and then start to populate.  Now it is blank all the time.  The waterfall in WSJTX shows heavy activity and I can hear it in the radio.  The decode button flashes but still nothing in the RX window.  I have downloaded the latest version, followed the YouTube videos for setup with the IC-7300 again and even checked all the security/firewall settings to ensure WSJTX is authorized through.

I am lost.  Any help out there?

Thank you,
Mike
KI5EGH


locked Re: RX Window blank, Waterfall full and radio shows large activity

Karza
 

Hi Mike,

On 25.10.2020 13.10, KI5EGH via groups.io wrote:
FT8 has been working fine then on occasion the RX screen would be blank and then start to populate.  Now it is blank all the time.  The waterfall in WSJTX shows heavy activity and I can hear it in the radio.  The decode button flashes but still nothing in the RX window.  I have downloaded the latest version, followed the YouTube videos for setup with the IC-7300 again and even checked all the security/firewall settings to ensure WSJTX is authorized through.

I am lost.  Any help out there?

You may have "Start new period decodes at top" selected in "File" => "Settings" "General" -tab.


Try disabling that.


73's de Kari, oh2gqc



locked Re: RX Window blank, Waterfall full and radio shows large activity

Komkit Listisard
 

Make sure you see the signals on waterfall line up with the green lines.  If not the signals are not in the middle between green line your timing is off. Check your clock.


locked RX Window blank, Waterfall full and radio shows large activity

Mike Toole
 

FT8 has been working fine then on occasion the RX screen would be blank and then start to populate.  Now it is blank all the time.  The waterfall in WSJTX shows heavy activity and I can hear it in the radio.  The decode button flashes but still nothing in the RX window.  I have downloaded the latest version, followed the YouTube videos for setup with the IC-7300 again and even checked all the security/firewall settings to ensure WSJTX is authorized through.

I am lost.  Any help out there?

Thank you,
Mike
KI5EGH


locked Re: IC-7100 FT8 transmit timing problem.

Martin G0HDB
 

On Sat, Oct 24, 2020 at 08:04 PM, Bill Somerville wrote:

Hi Martin,

the audio click you are hearing when using CAT PTT is probably due to the PTT not being asserted until after the audio from WSJT-X has started. WSJT-X does try and avoid that but some rigs do not provide feedback that they have switched to SEND mode.

I would guess that the delayed PTT via CAT is something to do with your K9JM CI-V router. Have you tried eliminating that for a test, taking care to remove any sensitive/buggy devices from the CI-V bus, like a PW-1 PA.

73
Bill
G4WJS.

Morning Bill, thanks for the above.

Re: the audio clicks (or splats!) at the start and occasionally the end of a transmit period, I take your point about the PTT not being asserted (within the rig?) until after WSJT-X has started to generate and send the audio, but shouldn't the Tx delay setting in WSJT-X take care of that?  My understanding has always been that the Tx delay is between WSJT-X executing its command to enable PTT and the onset of the Tx audio generated by the s/ware, so increasing the Tx delay to say 0.5secs should give ample time for the rig to receive the PTT command via whatever option is selected and action the changeover from Rx to Tx before the audio arrives.  As I mentioned previously, increasing the Tx delay setting when I use the CAT PTT option doesn't seem to affect the presence of the audio splats, although I haven't tried using a delay setting of >0.5secs.

With regard to your second point, there's a slight misunderstanding - I experience the seemingly randomly-delayed start of transmission when I DON'T use the CAT PTT option, so the presence of the K9JM router in the CAT connection between PC and rig shouldn't have any bearing.  The rig's PTT is controlled entirely by the G4ZLP datamodes interface device which appears to WIndows as an external audio codec in the same way as a SignaLink-USB.  The PTT signal generated by a VOX-type circuit within the G4ZLP device is hard-wired to the rig's PTT input on the ACC1 socket, so as soon as the audio generated by WSJT-X begins to emerge as an analogue signal from the codec within the G4ZLP device the VOX circuit should toggle the PTT line - apparently the 'VOX delay' is only of the order of 10-20msecs.

73
--
Martin G0HDB


locked Re: CFOM mode on higher EMEfrequencies with K3S

Bill Somerville
 

Hi Joe,

thanks for that. In which case selecting "Settings->Radio->Split Operating->Fake It" should allow EME Doppler tracking to work with the K3/K3S rigs.

73
Bill
G4WJS.

On 24/10/2020 23:41, Joe Subich, W4TV wrote:
Bill,

The K3/K3S specifically disallows the DT, FR and FT commands while in
transmit.  From the release notes for firmware version 5.56:
 > * DT, FR, and FT HOST COMMANDS DISALLOWED IN TX MODE: Previously,
these commands could be sent to the K3 during transmit from some
software applications. This could cause side effects such as muting
of transmit audio in DATA modes.

73,

   ... Joe, W4TV


On 2020-10-24 9:12 AM, Bill Somerville wrote:
On 24/10/2020 13:29, Jan Kappert wrote:
Hi Bill,
I guess so, the setup is not with me, but at my friends to prepare for 24Ghz.
During rx he reads 10.368.020, which is 020kHz on 3cm band.
And during the rx period the doppler is changing the last figures, which should be the case for tx as well.

Br. Jan, PAoPLY

Hi Jan,

the first thing to check, and any K3 or K3S user can do this, is if the basic CAT capability needed works. A simple test using a regular FT8 setup for HF can be used. Ensure "Settings->General->Allow Tx frequency changes while transmitting" is checked and that "Settings->Radio->Split Operating->Rig" is checked. Then with the "Pwr" slider reduced to minimum click "Tune" to go to Tx and then Ctrl+click on the waterfall more than 500 Hz away from the current Tx offset (red goal post marker) while observing the rig. The Tx VFO (VFOB) should change. Click "Tune" again to revert to Rx mode.

73
Bill
G4WJS.



locked Re: CFOM mode on higher EMEfrequencies with K3S

Joe Subich, W4TV
 

Bill,

The K3/K3S specifically disallows the DT, FR and FT commands while in
transmit. From the release notes for firmware version 5.56:
> * DT, FR, and FT HOST COMMANDS DISALLOWED IN TX MODE: Previously,
these commands could be sent to the K3 during transmit from some
software applications. This could cause side effects such as muting
of transmit audio in DATA modes.
73,

... Joe, W4TV


On 2020-10-24 9:12 AM, Bill Somerville wrote:
On 24/10/2020 13:29, Jan Kappert wrote:
Hi Bill,
I guess so, the setup is not with me, but at my friends to prepare for 24Ghz.
During rx he reads 10.368.020, which is 020kHz on 3cm band.
And during the rx period the doppler is changing the last figures, which should be the case for tx as well.

Br. Jan, PAoPLY
Hi Jan,
the first thing to check, and any K3 or K3S user can do this, is if the basic CAT capability needed works. A simple test using a regular FT8 setup for HF can be used. Ensure "Settings->General->Allow Tx frequency changes while transmitting" is checked and that "Settings->Radio->Split Operating->Rig" is checked. Then with the "Pwr" slider reduced to minimum click "Tune" to go to Tx and then Ctrl+click on the waterfall more than 500 Hz away from the current Tx offset (red goal post marker) while observing the rig. The Tx VFO (VFOB) should change. Click "Tune" again to revert to Rx mode.
73
Bill
G4WJS.


locked Re: CFOM mode on higher EMEfrequencies with K3S

Jan Kappert
 

Hi Bill,
Will check it this way.
Note: the K3S is currently controlled using the USB connection and WSJT-x.

Op za, okt. 24, 2020 om 15:13 schreef Bill Somerville
<g4wjs@...>:

Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#17653): https://WSJTX.groups.io/g/main/message/17653

Mute This Topic: https://groups.io/mt/77762285/1600284
-=-=-
WSJT-X      Weak Signal Communication  . ©2001-2020 by Joe Taylor, K1JT.    References : https://physics.princeton.edu/pulsar/K1JT/refs.html
Unsubscribe: WSJTX+unsubscribe@groups.io
-=-=-
Group Owner: main+owner@WSJTX.groups.io
Unsubscribe: https://WSJTX.groups.io/g/main/leave/defanged [pa0ply@...]
-=-=-=-=-=-=-=-=-=-=-=-


locked Re: FST4

David AD4TJ
 

In the US( and everywhere? ), 3.573 is the FT8 frequency.

Still looking for the answer to my question:

FST4 was quoted as being used on the 80 meter WSPR freq, but with 2000 hz being used. Does that or does it not interfere with WSPR stations at 1500( or whatever freq ) hz?

David AD4TJ

On Saturday, October 24, 2020, 3:12:46 PM EDT, Georgina Joyce <gena@...> wrote:


Hello,

Interesting. Here in the UK 3.573 is very busy come nightfall.

73


On 24 Oct 2020, at 18:58, Gary E. Kohtala via groups.io <gary.k7ek@...> wrote:

For Dave, AD4TJ: The 80m WSPR freq changed months and months ago. To keep abreast of current WSPR happenings, please see http://www.wsprnet.org. The current 80m WSPR freq is 3.5686. Occasionally I still see a station on the old 80m WSPR freq, however they find themselves all alone due to not staying informed.

Best regards,

Gary, K7EK

On Oct 23, 2020, at 09:45, "David AD4TJ via groups.io" <yahoo.com@groups.io target=_blank>ad4tj=yahoo.com@groups.io> wrote:
Bill, there was an email sent out last night that reported that FST4 was using WSPR frequencies on 40 meters, but that the audio frequency of 2000 hz was used, which should mean that it would not interfere with WSPR stations. Is that incorrect info?

David

On Friday, October 23, 2020, 9:36:19 AM EDT, Bill Somerville <g4wjs@...> wrote:


David,

a QSO mode like FST4 should not be used in WSPR sub-bands, the only exception to this might be on LF and MF bands where often transmitters have very limited bandwidths, or even fixed single frequency. Note here MF means 630m and LF means 2200m. Where transmitters and receivers can be readily tuned to different frequencies then please do not use WSPR sub-bands for other modes, the WSPR network is extensive and often using specialist hardware in unattended operation with quite low QRP or QRPP power levels, it provides an excellent propagation probing and research tool.

FST4 and FST4W are targeted at MF/LF bands where the path frequency stability is likely to be suitable for the close tone spacings used with the longer T/R periods, at HF frequencies Doppler spreading and transmitted stability is less likely to favour FST4 over modes like JT9 and similarly FST4W vs. WSPR.

Please experiment with these modes and report back how it goes, but QRM to other modes must be considered and avoided where possible.

73
Bill
G4WJS.

On 23/10/2020 14:22, David AD4TJ via groups.io wrote:
Wilfredo: I did a search for " WSPR Frequencies " and wrote them down. Apparently, FST4 is being done on WSPR frequencies, although I listened last night to 7.0386 MHz and only saw WSPR signals; no FST4 seen. Nor on the alternate freq of 7.04 MHz. Then I went to 80 meters, to WSPR frequency of 3.5926 MHz, then 3.594 MHz, and, again, saw no FST4 signals. So I am at a loss, also, as to where the activity is.

David AD4TJ

On Friday, October 23, 2020, 8:43:59 AM EDT, Wilfredo Martínez Consuegra (CO6WIL) <co6wil@...> wrote:


Greetings
As far as I could understand in the mail, I tried to do what I show in the image I send you, and I didn't get any results.
Is there anything else I should do?
co6wil
Wilfredo from Cuba











Georgina


Call: M0EBP
DMR ID: 2346259
Allstar: 52178
Locater: IO83PS





locked Re: FST4

Georgina Joyce
 

Hello,

Interesting. Here in the UK 3.573 is very busy come nightfall.

73


On 24 Oct 2020, at 18:58, Gary E. Kohtala via groups.io <gary.k7ek@...> wrote:

For Dave, AD4TJ: The 80m WSPR freq changed months and months ago. To keep abreast of current WSPR happenings, please see http://www.wsprnet.org. The current 80m WSPR freq is 3.5686. Occasionally I still see a station on the old 80m WSPR freq, however they find themselves all alone due to not staying informed.

Best regards,

Gary, K7EK

On Oct 23, 2020, at 09:45, "David AD4TJ via groups.io" <yahoo.com@groups.io target=_blank>ad4tj=yahoo.com@groups.io> wrote:
Bill, there was an email sent out last night that reported that FST4 was using WSPR frequencies on 40 meters, but that the audio frequency of 2000 hz was used, which should mean that it would not interfere with WSPR stations. Is that incorrect info?

David

On Friday, October 23, 2020, 9:36:19 AM EDT, Bill Somerville <g4wjs@...> wrote:


David,

a QSO mode like FST4 should not be used in WSPR sub-bands, the only exception to this might be on LF and MF bands where often transmitters have very limited bandwidths, or even fixed single frequency. Note here MF means 630m and LF means 2200m. Where transmitters and receivers can be readily tuned to different frequencies then please do not use WSPR sub-bands for other modes, the WSPR network is extensive and often using specialist hardware in unattended operation with quite low QRP or QRPP power levels, it provides an excellent propagation probing and research tool.

FST4 and FST4W are targeted at MF/LF bands where the path frequency stability is likely to be suitable for the close tone spacings used with the longer T/R periods, at HF frequencies Doppler spreading and transmitted stability is less likely to favour FST4 over modes like JT9 and similarly FST4W vs. WSPR.

Please experiment with these modes and report back how it goes, but QRM to other modes must be considered and avoided where possible.

73
Bill
G4WJS.

On 23/10/2020 14:22, David AD4TJ via groups.io wrote:
Wilfredo: I did a search for " WSPR Frequencies " and wrote them down. Apparently, FST4 is being done on WSPR frequencies, although I listened last night to 7.0386 MHz and only saw WSPR signals; no FST4 seen. Nor on the alternate freq of 7.04 MHz. Then I went to 80 meters, to WSPR frequency of 3.5926 MHz, then 3.594 MHz, and, again, saw no FST4 signals. So I am at a loss, also, as to where the activity is.

David AD4TJ

On Friday, October 23, 2020, 8:43:59 AM EDT, Wilfredo Martínez Consuegra (CO6WIL) <co6wil@...> wrote:


Greetings
As far as I could understand in the mail, I tried to do what I show in the image I send you, and I didn't get any results.
Is there anything else I should do?
co6wil
Wilfredo from Cuba











Georgina


Call: M0EBP
DMR ID: 2346259
Allstar: 52178
Locater: IO83PS



locked Re: IC-7100 FT8 transmit timing problem.

Bill Somerville
 

On 24/10/2020 19:55, Martin G0HDB wrote:
On Thu, Oct 22, 2020 at 03:16 PM, Bill Somerville wrote:

Do you mean the Tx starts 3 seconds late rather than the DT reported by
those receiving you being off by up to 3 seconds? If so then how is your
PC and rig connected for audio and PTT?
Hello Bill (and all), just to add my input to this thread...

I'm currently running v2.2.2 on a 32-bit Win 7 PC (a Dell OptiPlex780 with 4G of RAM); the rig is an IC-7610.  My PC-to-rig interface is a G4ZLP device, which is similar to a SignaLink-USB but better...  :-)  The connection from the G4ZLP device to the rig is via the rig's ACC1 socket.  [Note to people - please don't suggest that I use the IC-7610's inbuilt audio codec instead of the G4ZLP device and the analogue audio input and output on the ACC1 socket; I have my perfectly valid reasons for preferring the analogue interface.]

The rig is keyed by the wired PTT output from the G4ZLP device onto pin 3 on the ACC1 socket; in effect the PTT signal is generated by VOX within the G4ZLP device.  I've got the WSJT-X PTT setting set to VOX but the rig's VOX is off (I'm not sure if VOX operates on the data input to the ACC1 socket anyway, when the rig is in USB-D mode).

I've tried using CAT for the WSJT-X PTT option (the CAT interface from PC to rig is via a K9JM CI-V router to the rig's Remote port) and that seems to work (possibly more) reliably but for some reason when I use CAT for PTT there's a large audio 'splat' at the start of each transmission that's very visible on the 7610's bandscope - it's maybe approaching 2kHz wide in total spaced equally about the centre - and is also audible on the transmitted audio.  There's sometimes also a 'splat' when a transmission ends.  Changing the WSJT-X Tx Delay setting to a higher figure, eg. 0.5secs, doesn't eliminate the 'splats'.

I quite often find that the rig only goes into transmit a few (typically 2 or 3) seconds after the start of a 15sec FT8 period; the delay seems to be randomly variable and is very often almost non-existent or is at least imperceptible.  On a very few occasions the rig hasn't gone into transmit at all during a 15sec period and on other occasions the changeover from Rx to Tx has happened towards the end of the 15sec Tx period, eg. at the 10 or 11sec point.  There's also often a start-of-transmission delay when I operate FT4; there doesn't appear to be any particular set of circumstances that causes the delay in either FT8 or FT4.  I haven't been able to associate the delay with anything else that's happening on the PC - there's no apparent correlation with other apps.  I haven't checked all the other WSJT-X modes but from what I can recall there don't seem to be any delays when I operate MSK144.

I'm quite prepared to believe that the seemingly randomly-delayed start of transmission is caused by something in my system rather than a software issue - the PC isn't exactly the most up-to-date hardware(!), or perhaps there's something odd happening with the internally-generated VOX within the G4ZLP device that is causing its PTT output to be delayed.  I haven't yet tried to examine the hardware PTT signal and also the Tx audio signal going into the rig using a 'scope to see if the PTT is being asserted at the correct time at the start of a 15sec transmit period, or if it's appearing late, after the onset of the audio.

I'm in the process of setting up and configuring a new PC (a brand-new Dell OptiPlex 3070 with a 9th-gen i7 CPU at 3GHz, 16G RAM and an SSD, which should overcome any PC hardware issues!); it will be interested to see if upgrading the PC to modern hardware eliminates the start-of-transmission delays that I currently experience.  I'll keep you posted...!

73
--
Martin G0HDB

Hi Martin,

the audio click you are hearing when using CAT PTT is probably due to the PTT not being asserted until after the audio from WSJT-X has started. WSJT-X does try and avoid that but some rigs do not provide feedback that they have switched to SEND mode.

I would guess that the delayed PTT via CAT is something to do with your K9JM CI-V router. Have you tried eliminating that for a test, taking care to remove any sensitive/buggy devices from the CI-V bus, like a PW-1 PA.

73
Bill
G4WJS.


locked Re: IC-7100 FT8 transmit timing problem.

Martin G0HDB
 

On Thu, Oct 22, 2020 at 03:16 PM, Bill Somerville wrote:

Do you mean the Tx starts 3 seconds late rather than the DT reported by
those receiving you being off by up to 3 seconds? If so then how is your
PC and rig connected for audio and PTT?
Hello Bill (and all), just to add my input to this thread...

I'm currently running v2.2.2 on a 32-bit Win 7 PC (a Dell OptiPlex780 with 4G of RAM); the rig is an IC-7610.  My PC-to-rig interface is a G4ZLP device, which is similar to a SignaLink-USB but better...  :-)  The connection from the G4ZLP device to the rig is via the rig's ACC1 socket.  [Note to people - please don't suggest that I use the IC-7610's inbuilt audio codec instead of the G4ZLP device and the analogue audio input and output on the ACC1 socket; I have my perfectly valid reasons for preferring the analogue interface.]

The rig is keyed by the wired PTT output from the G4ZLP device onto pin 3 on the ACC1 socket; in effect the PTT signal is generated by VOX within the G4ZLP device.  I've got the WSJT-X PTT setting set to VOX but the rig's VOX is off (I'm not sure if VOX operates on the data input to the ACC1 socket anyway, when the rig is in USB-D mode).

I've tried using CAT for the WSJT-X PTT option (the CAT interface from PC to rig is via a K9JM CI-V router to the rig's Remote port) and that seems to work (possibly more) reliably but for some reason when I use CAT for PTT there's a large audio 'splat' at the start of each transmission that's very visible on the 7610's bandscope - it's maybe approaching 2kHz wide in total spaced equally about the centre - and is also audible on the transmitted audio.  There's sometimes also a 'splat' when a transmission ends.  Changing the WSJT-X Tx Delay setting to a higher figure, eg. 0.5secs, doesn't eliminate the 'splats'.

I quite often find that the rig only goes into transmit a few (typically 2 or 3) seconds after the start of a 15sec FT8 period; the delay seems to be randomly variable and is very often almost non-existent or is at least imperceptible.  On a very few occasions the rig hasn't gone into transmit at all during a 15sec period and on other occasions the changeover from Rx to Tx has happened towards the end of the 15sec Tx period, eg. at the 10 or 11sec point.  There's also often a start-of-transmission delay when I operate FT4; there doesn't appear to be any particular set of circumstances that causes the delay in either FT8 or FT4.  I haven't been able to associate the delay with anything else that's happening on the PC - there's no apparent correlation with other apps.  I haven't checked all the other WSJT-X modes but from what I can recall there don't seem to be any delays when I operate MSK144.

I'm quite prepared to believe that the seemingly randomly-delayed start of transmission is caused by something in my system rather than a software issue - the PC isn't exactly the most up-to-date hardware(!), or perhaps there's something odd happening with the internally-generated VOX within the G4ZLP device that is causing its PTT output to be delayed.  I haven't yet tried to examine the hardware PTT signal and also the Tx audio signal going into the rig using a 'scope to see if the PTT is being asserted at the correct time at the start of a 15sec transmit period, or if it's appearing late, after the onset of the audio.

I'm in the process of setting up and configuring a new PC (a brand-new Dell OptiPlex 3070 with a 9th-gen i7 CPU at 3GHz, 16G RAM and an SSD, which should overcome any PC hardware issues!); it will be interested to see if upgrading the PC to modern hardware eliminates the start-of-transmission delays that I currently experience.  I'll keep you posted...!

73
--
Martin G0HDB


locked Re: FST4

Gary - K7EK
 

For Dave, AD4TJ: The 80m WSPR freq changed months and months ago. To keep abreast of current WSPR happenings, please see http://www.wsprnet.org. The current 80m WSPR freq is 3.5686. Occasionally I still see a station on the old 80m WSPR freq, however they find themselves all alone due to not staying informed.

Best regards,

Gary, K7EK

On Oct 23, 2020, at 09:45, "David AD4TJ via groups.io" <yahoo.com@groups.io target=_blank>ad4tj=yahoo.com@groups.io> wrote:
Bill, there was an email sent out last night that reported that FST4 was using WSPR frequencies on 40 meters, but that the audio frequency of 2000 hz was used, which should mean that it would not interfere with WSPR stations. Is that incorrect info?

David

On Friday, October 23, 2020, 9:36:19 AM EDT, Bill Somerville <g4wjs@...> wrote:


David,

a QSO mode like FST4 should not be used in WSPR sub-bands, the only exception to this might be on LF and MF bands where often transmitters have very limited bandwidths, or even fixed single frequency. Note here MF means 630m and LF means 2200m. Where transmitters and receivers can be readily tuned to different frequencies then please do not use WSPR sub-bands for other modes, the WSPR network is extensive and often using specialist hardware in unattended operation with quite low QRP or QRPP power levels, it provides an excellent propagation probing and research tool.

FST4 and FST4W are targeted at MF/LF bands where the path frequency stability is likely to be suitable for the close tone spacings used with the longer T/R periods, at HF frequencies Doppler spreading and transmitted stability is less likely to favour FST4 over modes like JT9 and similarly FST4W vs. WSPR.

Please experiment with these modes and report back how it goes, but QRM to other modes must be considered and avoided where possible.

73
Bill
G4WJS.

On 23/10/2020 14:22, David AD4TJ via groups.io wrote:
Wilfredo: I did a search for " WSPR Frequencies " and wrote them down. Apparently, FST4 is being done on WSPR frequencies, although I listened last night to 7.0386 MHz and only saw WSPR signals; no FST4 seen. Nor on the alternate freq of 7.04 MHz. Then I went to 80 meters, to WSPR frequency of 3.5926 MHz, then 3.594 MHz, and, again, saw no FST4 signals. So I am at a loss, also, as to where the activity is.

David AD4TJ

On Friday, October 23, 2020, 8:43:59 AM EDT, Wilfredo Martínez Consuegra (CO6WIL) <co6wil@...> wrote:


Greetings
As far as I could understand in the mail, I tried to do what I show in the image I send you, and I didn't get any results.
Is there anything else I should do?
co6wil
Wilfredo from Cuba








locked Re: CFOM mode on higher EMEfrequencies with K3S

Bill Somerville
 

On 24/10/2020 13:29, Jan Kappert wrote:
Hi Bill,
I guess so, the setup is not with me, but at my friends to prepare for 24Ghz.
During rx he reads 10.368.020, which is 020kHz on 3cm band.
And during the rx period the doppler is changing the last figures, which should be the case for tx as well.

Br. Jan, PAoPLY

Hi Jan,

the first thing to check, and any K3 or K3S user can do this, is if the basic CAT capability needed works. A simple test using a regular FT8 setup for HF can be used. Ensure "Settings->General->Allow Tx frequency changes while transmitting" is checked and that "Settings->Radio->Split Operating->Rig" is checked. Then with the "Pwr" slider reduced to minimum click "Tune" to go to Tx and then Ctrl+click on the waterfall more than 500 Hz away from the current Tx offset (red goal post marker) while observing the rig. The Tx VFO (VFOB) should change. Click "Tune" again to revert to Rx mode.

73
Bill
G4WJS.


locked Re: CFOM mode on higher EMEfrequencies with K3S

jan kappert <2016pa0ply@...>
 

Hi Bill,
I guess so, the setup is not with me, but at my friends to prepare for 24Ghz.
During rx he reads 10.368.020, which is 020kHz on 3cm band.
And during the rx period the doppler is changing the last figures, which should be the case for tx as well.

Br. Jan, PAoPLY

Op za, okt. 24, 2020 om 0:02 schreef Bill Somerville
<g4wjs@...>:



locked Re: CFOM mode on higher EMEfrequencies with K3S

Bill Somerville
 

On 23/10/2020 22:52, Jan Kappert via groups.io wrote:
Hi Bill 
Yes, of course.
Also set for rig to use split
But only rx freq is following, the tx frequency is stable as a house.
Br. Jan, PAoPLY

Hi Jan,

sri, I had to ask just in case.

Do you have the VFO in FINE mode?

73
Bill
G4WJS.

19301 - 19320 of 36847