Date   

locked Re: FT8 via running satellite #macOS #FT8

W0DHB
 

Karl

A group of us here in the U.S. have had great success using FT4.
It does require that you set your tracking software to update Doppler tuning at greater than 2 times per second .
SatPC32 and FlexSATPC software and I'm certain others can be set up to do this.

There was an article in the Amsat North America Journal Summer 2020 about satellite FT4 operations.

73's Dave W0DHB 


locked Re: Full duplex mode for Satellite operations #EnhancementReqest

W0DHB
 

Thanks for your response Bill.

I agree that development effort of that magnitude would not be justified, especially when running a second instance of WSJT-X is quite sufficient.

Dave W0DHB


locked Re: #IssueReport #WSPR #IssueReport #WSPR

Hasan Schiers N0AN
 

Also RC6 here, although downloaded a few days ago. I think there was a hamlib fix since then, but have not downloaded since very early RC6.

73, N0AN
Hasan


On Wed, Sep 8, 2021 at 11:21 AM Bill Somerville <g4wjs@...> wrote:
Hi Hasan,

Steve, K9AN, and I are running WSPR band-hopping with a variety of bands set for Tune and Rx only. Neither of us are seeing this issue so far. I am using the latest 2.5.0 RC6 version.

73
Bill
G4WJS.

On 08/09/2021 15:00, Hasan Schiers N0AN wrote:
No, no errors at all, see an occasional audio stream error, nothing else

Hasan


On Wed, Sep 8, 2021 at 8:20 AM Bill Somerville <g4wjs@...> wrote:
Hi Hasan,

are there any Hamlib error messages in the WJST-X wsjtx_syslog.log file that correlate with the time of the issue?

73
Bill
G4WJS.

On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the correlation I was looking for. 

If I tell WSPR Schedule to use the TUNE function (to make the autotuner adjust the antenna SWR on each band prior to transmitting), the ENABLE Tx light goes out in short order (next transmission or so).

If I uncheck the boxes on each band for Tune, and let the transmit signal itself actuate the auto-tuner, everything works normally.  

In reality, the TUNE function in the Scheduler is redundant, because the autotuner itself will auto-tune when RF is sent to it anyway, there is no need to 'pre-tune' things.

However, what I am reporting is undesirable and probably should be fixed, if it's a real malfunction.

73, N0AN
Hasan


On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville <g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
 
Issue:
 
When in Band Hopping Mode, with a proper schedule, the Enable Transmit button randomly goes dark and never lights up again.
 
This results in hours and hours of listening overnight with no transmitting. 
 
Is there an order effect or something that would cause this in terms of setup? It used to work perfectly with identical settings many versions ago.
 
Anyone else seen this?
 
TIA, 73, N0AN
Hasan

Hi Hasan,

that behaviour may be caused by a CAT error. Have a look in the wsjtx_syslog.log file (in the WSJT-X log files directory) for any Hamlib error messages around the time that the "Enable Tx" button resets.

73
Bill
G4WJS.






locked Re: #IssueReport #WSPR #IssueReport #WSPR

Hasan Schiers N0AN
 

Here is a recent sample of the error log, Bill:

[SYSLOG][2021-09-08 11:29:54.060941][12:29:07.539049][warning] Detected dropped audio source samples: 912 (0.019 S)
[SYSLOG][2021-09-08 11:40:28.319469][12:39:41.807077][info] shmem size: 48275456
[RIGCTRL][2021-09-08 11:40:28.341453][12:39:41.828568][info] Hamlib version: Hamlib 4.4~git Wed Sep 01 17:45:29 2021 +0000 SHA=6de458
[SYSLOG][2021-09-08 12:24:01.924582][13:23:15.439149][info] shmem size: 48275456
[RIGCTRL][2021-09-08 12:24:01.949567][13:23:15.464064][info] Hamlib version: Hamlib 4.4~git Wed Sep 01 17:45:29 2021 +0000 SHA=6de458
[SYSLOG][2021-09-08 12:24:57.648924][13:24:11.165287][warning] Detected dropped audio source samples: 720 (0.015 S)
[SYSLOG][2021-09-08 12:27:57.670814][13:27:11.187554][warning] Detected dropped audio source samples: 960 (0.02 S)
[SYSLOG][2021-09-08 12:31:57.652399][13:31:11.170195][warning] Detected dropped audio source samples: 864 (0.018 S)
[SYSLOG][2021-09-08 13:31:57.679875][14:31:11.243958][warning] Detected dropped audio source samples: 1728 (0.036 S)
[SYSLOG][2021-09-08 13:54:57.670548][14:54:11.249594][warning] Detected dropped audio source samples: 624 (0.013 S)
[SYSLOG][2021-09-08 14:04:27.682899][15:03:41.268923][warning] Detected dropped audio source samples: 1728 (0.036 S)
[SYSLOG][2021-09-08 14:06:27.680240][15:05:41.269116][warning] Detected dropped audio source samples: 768 (0.016 S)
[SYSLOG][2021-09-08 14:10:33.025069][15:09:46.616088][info] shmem size: 48275456
[RIGCTRL][2021-09-08 14:10:33.046057][15:09:46.637030][info] Hamlib version: Hamlib 4.4~git Wed Sep 01 17:45:29 2021 +0000 SHA=6de458

I assume it is local time , so 2:10:33 p.m.? 

73, N0AN
Hasan


On Wed, Sep 8, 2021 at 11:22 AM Bill Somerville <g4wjs@...> wrote:
Hi Hasan,

what are the audio stream errors?

73
Bill
G4WJS.

On 08/09/2021 15:00, Hasan Schiers N0AN wrote:
No, no errors at all, see an occasional audio stream error, nothing else

Hasan


On Wed, Sep 8, 2021 at 8:20 AM Bill Somerville <g4wjs@...> wrote:
Hi Hasan,

are there any Hamlib error messages in the WJST-X wsjtx_syslog.log file that correlate with the time of the issue?

73
Bill
G4WJS.

On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the correlation I was looking for. 

If I tell WSPR Schedule to use the TUNE function (to make the autotuner adjust the antenna SWR on each band prior to transmitting), the ENABLE Tx light goes out in short order (next transmission or so).

If I uncheck the boxes on each band for Tune, and let the transmit signal itself actuate the auto-tuner, everything works normally.  

In reality, the TUNE function in the Scheduler is redundant, because the autotuner itself will auto-tune when RF is sent to it anyway, there is no need to 'pre-tune' things.

However, what I am reporting is undesirable and probably should be fixed, if it's a real malfunction.

73, N0AN
Hasan


On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville <g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
 
Issue:
 
When in Band Hopping Mode, with a proper schedule, the Enable Transmit button randomly goes dark and never lights up again.
 
This results in hours and hours of listening overnight with no transmitting. 
 
Is there an order effect or something that would cause this in terms of setup? It used to work perfectly with identical settings many versions ago.
 
Anyone else seen this?
 
TIA, 73, N0AN
Hasan

Hi Hasan,

that behaviour may be caused by a CAT error. Have a look in the wsjtx_syslog.log file (in the WSJT-X log files directory) for any Hamlib error messages around the time that the "Enable Tx" button resets.

73
Bill
G4WJS.






locked Re: FT8 via running satellite #macOS #FT8

Carlos
 

Hi Bill, NO4ON,
Big gun antenna ... Congratulation !

My antenna (4el 2m + 5el 70cm) was always enough for the common running satellites....
No elevation, only azimuth.

Back to FT8:
In my expirience the doppler shift is very strong (fast). And the gpredict calculated frequency correction goes only in big steps. Depending on the CAT polling.
So cw was hard enough to listen, because of the frequency steps (jumps).
And so my opinion is, that FT8 is not easy possible.

What do others say about that ??

Any guess ???

I (we) appriciate all answers !!!!

Please Bill, keep me in touch with your satellite expiriences.

See U, 73, Karl OE3JAG


Am 08.09.2021 um 15:09 schrieb Bill - NO4ON:

Carlos,
Enclosed is my antenna.  I am just finishing it and it is in my front yard.  It will live on my roof when finally installed.  I run MacDoppler software to control the antenna and the 9700.  When it is on a bird it stays on the bird for the entire pass, which is sometimes up to 10 to 15 minutes.  What I said is that I want to explore FT8 and FT4 once the antenna is installed on my roof. It is a goal and one of the things that will make it happen, I believe is running a second instance of WSJT-X.



Bill,
Can I use Mac Automator to automate the commands without having to go into a terminal window?

NO4On - Bill





locked Re: #IssueReport #WSPR #IssueReport #WSPR

Michael Black
 

What rig?

Mike W9MDB




On Wednesday, September 8, 2021, 11:21:24 AM CDT, Bill Somerville <g4wjs@...> wrote:


Hi Hasan,

Steve, K9AN, and I are running WSPR band-hopping with a variety of bands set for Tune and Rx only. Neither of us are seeing this issue so far. I am using the latest 2.5.0 RC6 version.

73
Bill
G4WJS.

On 08/09/2021 15:00, Hasan Schiers N0AN wrote:
No, no errors at all, see an occasional audio stream error, nothing else

Hasan


On Wed, Sep 8, 2021 at 8:20 AM Bill Somerville <g4wjs@...> wrote:
Hi Hasan,

are there any Hamlib error messages in the WJST-X wsjtx_syslog.log file that correlate with the time of the issue?

73
Bill
G4WJS.

On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the correlation I was looking for. 

If I tell WSPR Schedule to use the TUNE function (to make the autotuner adjust the antenna SWR on each band prior to transmitting), the ENABLE Tx light goes out in short order (next transmission or so).

If I uncheck the boxes on each band for Tune, and let the transmit signal itself actuate the auto-tuner, everything works normally.  

In reality, the TUNE function in the Scheduler is redundant, because the autotuner itself will auto-tune when RF is sent to it anyway, there is no need to 'pre-tune' things.

However, what I am reporting is undesirable and probably should be fixed, if it's a real malfunction.

73, N0AN
Hasan


On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville <g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
 
Issue:
 
When in Band Hopping Mode, with a proper schedule, the Enable Transmit button randomly goes dark and never lights up again.
 
This results in hours and hours of listening overnight with no transmitting. 
 
Is there an order effect or something that would cause this in terms of setup? It used to work perfectly with identical settings many versions ago.
 
Anyone else seen this?
 
TIA, 73, N0AN
Hasan

Hi Hasan,

that behaviour may be caused by a CAT error. Have a look in the wsjtx_syslog.log file (in the WSJT-X log files directory) for any Hamlib error messages around the time that the "Enable Tx" button resets.

73
Bill
G4WJS.






locked Re: #IssueReport #WSPR #IssueReport #WSPR

Bill Somerville
 

Hi Hasan,

what are the audio stream errors?

73
Bill
G4WJS.

On 08/09/2021 15:00, Hasan Schiers N0AN wrote:
No, no errors at all, see an occasional audio stream error, nothing else

Hasan


On Wed, Sep 8, 2021 at 8:20 AM Bill Somerville <g4wjs@...> wrote:
Hi Hasan,

are there any Hamlib error messages in the WJST-X wsjtx_syslog.log file that correlate with the time of the issue?

73
Bill
G4WJS.

On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the correlation I was looking for. 

If I tell WSPR Schedule to use the TUNE function (to make the autotuner adjust the antenna SWR on each band prior to transmitting), the ENABLE Tx light goes out in short order (next transmission or so).

If I uncheck the boxes on each band for Tune, and let the transmit signal itself actuate the auto-tuner, everything works normally.  

In reality, the TUNE function in the Scheduler is redundant, because the autotuner itself will auto-tune when RF is sent to it anyway, there is no need to 'pre-tune' things.

However, what I am reporting is undesirable and probably should be fixed, if it's a real malfunction.

73, N0AN
Hasan


On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville <g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
 
Issue:
 
When in Band Hopping Mode, with a proper schedule, the Enable Transmit button randomly goes dark and never lights up again.
 
This results in hours and hours of listening overnight with no transmitting. 
 
Is there an order effect or something that would cause this in terms of setup? It used to work perfectly with identical settings many versions ago.
 
Anyone else seen this?
 
TIA, 73, N0AN
Hasan

Hi Hasan,

that behaviour may be caused by a CAT error. Have a look in the wsjtx_syslog.log file (in the WSJT-X log files directory) for any Hamlib error messages around the time that the "Enable Tx" button resets.

73
Bill
G4WJS.



locked Re: #IssueReport #WSPR #IssueReport #WSPR

Bill Somerville
 

Hi Hasan,

Steve, K9AN, and I are running WSPR band-hopping with a variety of bands set for Tune and Rx only. Neither of us are seeing this issue so far. I am using the latest 2.5.0 RC6 version.

73
Bill
G4WJS.

On 08/09/2021 15:00, Hasan Schiers N0AN wrote:
No, no errors at all, see an occasional audio stream error, nothing else

Hasan


On Wed, Sep 8, 2021 at 8:20 AM Bill Somerville <g4wjs@...> wrote:
Hi Hasan,

are there any Hamlib error messages in the WJST-X wsjtx_syslog.log file that correlate with the time of the issue?

73
Bill
G4WJS.

On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the correlation I was looking for. 

If I tell WSPR Schedule to use the TUNE function (to make the autotuner adjust the antenna SWR on each band prior to transmitting), the ENABLE Tx light goes out in short order (next transmission or so).

If I uncheck the boxes on each band for Tune, and let the transmit signal itself actuate the auto-tuner, everything works normally.  

In reality, the TUNE function in the Scheduler is redundant, because the autotuner itself will auto-tune when RF is sent to it anyway, there is no need to 'pre-tune' things.

However, what I am reporting is undesirable and probably should be fixed, if it's a real malfunction.

73, N0AN
Hasan


On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville <g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
 
Issue:
 
When in Band Hopping Mode, with a proper schedule, the Enable Transmit button randomly goes dark and never lights up again.
 
This results in hours and hours of listening overnight with no transmitting. 
 
Is there an order effect or something that would cause this in terms of setup? It used to work perfectly with identical settings many versions ago.
 
Anyone else seen this?
 
TIA, 73, N0AN
Hasan

Hi Hasan,

that behaviour may be caused by a CAT error. Have a look in the wsjtx_syslog.log file (in the WSJT-X log files directory) for any Hamlib error messages around the time that the "Enable Tx" button resets.

73
Bill
G4WJS.



locked Re: 2 instances of WSJTX on Mac Big Sur #macOS

Chuck Moore <wd4hxg@...>
 

Very nice!

On Sep 8, 2021, at 9:18 AM, Bill Somerville <g4wjs@...> wrote:

On 08/09/2021 14:09, Bill - NO4ON wrote:
Bill,
Can I use Mac Automator to automate the commands without having to go into a terminal window?

NO4On - Bill
Hi Bill,

I don't see why not. I would try using a shell script action in Automator.

73
Bill
G4WJS.




locked Re: #IssueReport #WSPR #IssueReport #WSPR

Hasan Schiers N0AN
 

If I were to make a WAG, I would think it is a logic problem that crept in, cuz it used to work last year without dropping out (with Tune selected in the BandHop Sked)

Hasan


On Wed, Sep 8, 2021 at 8:20 AM Bill Somerville <g4wjs@...> wrote:
Hi Hasan,

are there any Hamlib error messages in the WJST-X wsjtx_syslog.log file that correlate with the time of the issue?

73
Bill
G4WJS.

On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the correlation I was looking for. 

If I tell WSPR Schedule to use the TUNE function (to make the autotuner adjust the antenna SWR on each band prior to transmitting), the ENABLE Tx light goes out in short order (next transmission or so).

If I uncheck the boxes on each band for Tune, and let the transmit signal itself actuate the auto-tuner, everything works normally.  

In reality, the TUNE function in the Scheduler is redundant, because the autotuner itself will auto-tune when RF is sent to it anyway, there is no need to 'pre-tune' things.

However, what I am reporting is undesirable and probably should be fixed, if it's a real malfunction.

73, N0AN
Hasan


On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville <g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
 
Issue:
 
When in Band Hopping Mode, with a proper schedule, the Enable Transmit button randomly goes dark and never lights up again.
 
This results in hours and hours of listening overnight with no transmitting. 
 
Is there an order effect or something that would cause this in terms of setup? It used to work perfectly with identical settings many versions ago.
 
Anyone else seen this?
 
TIA, 73, N0AN
Hasan

Hi Hasan,

that behaviour may be caused by a CAT error. Have a look in the wsjtx_syslog.log file (in the WSJT-X log files directory) for any Hamlib error messages around the time that the "Enable Tx" button resets.

73
Bill
G4WJS.






locked Re: #IssueReport #WSPR #IssueReport #WSPR

Hasan Schiers N0AN
 

No, no errors at all, see an occasional audio stream error, nothing else

Hasan


On Wed, Sep 8, 2021 at 8:20 AM Bill Somerville <g4wjs@...> wrote:
Hi Hasan,

are there any Hamlib error messages in the WJST-X wsjtx_syslog.log file that correlate with the time of the issue?

73
Bill
G4WJS.

On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the correlation I was looking for. 

If I tell WSPR Schedule to use the TUNE function (to make the autotuner adjust the antenna SWR on each band prior to transmitting), the ENABLE Tx light goes out in short order (next transmission or so).

If I uncheck the boxes on each band for Tune, and let the transmit signal itself actuate the auto-tuner, everything works normally.  

In reality, the TUNE function in the Scheduler is redundant, because the autotuner itself will auto-tune when RF is sent to it anyway, there is no need to 'pre-tune' things.

However, what I am reporting is undesirable and probably should be fixed, if it's a real malfunction.

73, N0AN
Hasan


On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville <g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
 
Issue:
 
When in Band Hopping Mode, with a proper schedule, the Enable Transmit button randomly goes dark and never lights up again.
 
This results in hours and hours of listening overnight with no transmitting. 
 
Is there an order effect or something that would cause this in terms of setup? It used to work perfectly with identical settings many versions ago.
 
Anyone else seen this?
 
TIA, 73, N0AN
Hasan

Hi Hasan,

that behaviour may be caused by a CAT error. Have a look in the wsjtx_syslog.log file (in the WSJT-X log files directory) for any Hamlib error messages around the time that the "Enable Tx" button resets.

73
Bill
G4WJS.






locked Re: #IssueReport #WSPR #IssueReport #WSPR

Bill Somerville
 

Hi Hasan,

are there any Hamlib error messages in the WJST-X wsjtx_syslog.log file that correlate with the time of the issue?

73
Bill
G4WJS.

On 08/09/2021 01:09, Hasan Schiers N0AN wrote:
Bill,
I found the correlation I was looking for. 

If I tell WSPR Schedule to use the TUNE function (to make the autotuner adjust the antenna SWR on each band prior to transmitting), the ENABLE Tx light goes out in short order (next transmission or so).

If I uncheck the boxes on each band for Tune, and let the transmit signal itself actuate the auto-tuner, everything works normally.  

In reality, the TUNE function in the Scheduler is redundant, because the autotuner itself will auto-tune when RF is sent to it anyway, there is no need to 'pre-tune' things.

However, what I am reporting is undesirable and probably should be fixed, if it's a real malfunction.

73, N0AN
Hasan


On Sat, Sep 4, 2021 at 12:21 PM Bill Somerville <g4wjs@...> wrote:
On 04/09/2021 13:34, Hasan Schiers N0AN wrote:
WSJT-X 2.5.0 RC5
Mode WSPR
 
Issue:
 
When in Band Hopping Mode, with a proper schedule, the Enable Transmit button randomly goes dark and never lights up again.
 
This results in hours and hours of listening overnight with no transmitting. 
 
Is there an order effect or something that would cause this in terms of setup? It used to work perfectly with identical settings many versions ago.
 
Anyone else seen this?
 
TIA, 73, N0AN
Hasan

Hi Hasan,

that behaviour may be caused by a CAT error. Have a look in the wsjtx_syslog.log file (in the WSJT-X log files directory) for any Hamlib error messages around the time that the "Enable Tx" button resets.

73
Bill
G4WJS.



locked Re: 2 instances of WSJTX on Mac Big Sur #macOS

Bill Somerville
 

On 08/09/2021 14:09, Bill - NO4ON wrote:
Bill,
Can I use Mac Automator to automate the commands without having to go into a terminal window?

NO4On - Bill
Hi Bill,

I don't see why not. I would try using a shell script action in Automator.

73
Bill
G4WJS.


locked Re: 2 instances of WSJTX on Mac Big Sur #macOS

Bill - NO4ON
 

Carlos,
Enclosed is my antenna.  I am just finishing it and it is in my front yard.  It will live on my roof when finally installed.  I run MacDoppler software to control the antenna and the 9700.  When it is on a bird it stays on the bird for the entire pass, which is sometimes up to 10 to 15 minutes.  What I said is that I want to explore FT8 and FT4 once the antenna is installed on my roof. It is a goal and one of the things that will make it happen, I believe is running a second instance of WSJT-X.



Bill,
Can I use Mac Automator to automate the commands without having to go into a terminal window?

NO4On - Bill


locked Re: Compensating for audio lag from SDR? #AudioIssues

Bill Somerville
 

On 08/09/2021 12:01, Alan G4ZFQ wrote:
1.5 S audio latency is very high!

Bill,

I can beat that!
I have a local Kiwi which interfaces with a web browser. When I feed audio from that the DT  is about 4. WSJT-X still decodes more WSPR spots on busy bands than the native Kiwi multi-band software.

Some sort of RX adjustment would be useful but I'm sure only to a tiny proportion of WSJT-X users. And that number will probably decrease as SDRs evolve.

73 Alan G4ZFQ

Hi Alan,

IIRC WSPR has about -6 second tolerance, although I'm not certain that the last symbol or two gets passed to the decoder in such an extreme case.

73
Bill
G4WJS.


locked Re: Compensating for audio lag from SDR? #AudioIssues

Alan G4ZFQ
 

1.5 S audio latency is very high!
Bill,

I can beat that!
I have a local Kiwi which interfaces with a web browser. When I feed audio from that the DT is about 4. WSJT-X still decodes more WSPR spots on busy bands than the native Kiwi multi-band software.

Some sort of RX adjustment would be useful but I'm sure only to a tiny proportion of WSJT-X users. And that number will probably decrease as SDRs evolve.

73 Alan G4ZFQ


locked Re: Compensating for audio lag from SDR? #AudioIssues

Bill Somerville
 

On 08/09/2021 11:06, Bruce KX4AZ wrote:
One of my SDRs outputs audio with about 1.5 second lag time.  WSJT-x seems to decode FT8 OK, but any station sending with a "real" lag time might be missed.  And I don't like sending inaccurate time values to pskreporter.  Other than manually readjusting the PC clock to compensate for the delay (which would mess up time stamps generated by other apps), is there a setting in WSJT-x which can be adjusted?
Hi Bruce,

1.5 S audio latency is very high! Compensating is not really practical, and for a station that also transmits probably impractical. Adjusting the local machine time will definitely cause Tx signals to have an equivalent delay, so that doesn't work.

Time offsets are not posted to PSK Reporter.

73
Bill
G4WJS.


locked Compensating for audio lag from SDR? #AudioIssues

Bruce KX4AZ
 

One of my SDRs outputs audio with about 1.5 second lag time.  WSJT-x seems to decode FT8 OK, but any station sending with a "real" lag time might be missed.  And I don't like sending inaccurate time values to pskreporter.  Other than manually readjusting the PC clock to compensate for the delay (which would mess up time stamps generated by other apps), is there a setting in WSJT-x which can be adjusted?


locked Re: Here's a positive story . . #WSPR #linux

Heikki Pisilä
 

Huomenta Reino,

I have been using the Yaesu FT-2000D whose software I updated about 3 years ago, so wsjt-x v2.3.0 should work with most of today's transceivers and the configuration I have told you.

All transceivers today have the same base logic software as there are no big differences compared to my Yaesu, I mean by this only transceiver control with WSJT-X software.

73

Heikki/oh8gkp


Reino Talarmo kirjoitti 8.9.2021 klo 8:23:

Huomenta Heikki,

Nice to hear good news. Just for interest which rig you are using?

73, Reino OH3mA

 

Hi guys, I have been working and tested from the user's point of view for 3 weeks 24/7 ACER Chromebook 314 with WSJT-X v2.3.0 installed and it works really well, no port problems or audio problems, I use "audio dongle" and PulseAudio / Pavucontrol. The device has 2 USB ports, I installed a USB HUB with which I can connect a keyboard and mouse to the device as well as CAT. Band jumping works just as it should and timings, including all mode. WSJT-X runs in a so-called "virtual linux" environment where I installed "Debian v.11.0" where WSJT-X works really well. The device decodes quickly as well. The battery takes about 10 hours to work continuously in wspr mode so it is good enough if you use it as a portable device. On the plus side, the Chromebook in question is small in size and very affordable to buy, plus it has almost all the features of a PC. I highly recommend this device. A little something positive for this forum too ;)

73
Heikki/oh8gkp





locked Re: Here's a positive story . . #WSPR #linux

Reino Talarmo
 

Huomenta Heikki,

Nice to hear good news. Just for interest which rig you are using?

73, Reino OH3mA

 

Hi guys, I have been working and tested from the user's point of view for 3 weeks 24/7 ACER Chromebook 314 with WSJT-X v2.3.0 installed and it works really well, no port problems or audio problems, I use "audio dongle" and PulseAudio / Pavucontrol. The device has 2 USB ports, I installed a USB HUB with which I can connect a keyboard and mouse to the device as well as CAT. Band jumping works just as it should and timings, including all mode. WSJT-X runs in a so-called "virtual linux" environment where I installed "Debian v.11.0" where WSJT-X works really well. The device decodes quickly as well. The battery takes about 10 hours to work continuously in wspr mode so it is good enough if you use it as a portable device. On the plus side, the Chromebook in question is small in size and very affordable to buy, plus it has almost all the features of a PC. I highly recommend this device. A little something positive for this forum too ;)

73
Heikki/oh8gkp

9621 - 9640 of 37978