On 23/07/2017 12:53, David Tiller wrote:
Perhaps for the very tightly time-constrained modes a simple
computation comparing the received delta-T's of all received signals
could be made. If everyone else's clocks seem consistently wrong,
maybe it's you!
An indication of that made by turning the
many still call on ssb when station returns to other station so no change
there hi
On 23 July 2017 at 16:51, Gary McDuffie wrote:
>
> > On Jul 23, 2017, at 9:28 AM, Alex, VE3NEA wrote:
> >
> > I am trying WSJT-X r7934 using FT8, calling DX stations with Auto Seq
> enabled. I have noticed that t
> On Jul 23, 2017, at 9:28 AM, Alex, VE3NEA wrote:
>
> I am trying WSJT-X r7934 using FT8, calling DX stations with Auto Seq
> enabled. I have noticed that the program keeps sending my call even after DX
> has answered another station, as in the transcript below:
>
> 030130 -14 0.9 1909 ~ C
On 23/07/2017 16:28, Alex, VE3NEA wrote:
I am trying WSJT-X r7934 using FT8, calling DX stations with Auto Seq
enabled. I have noticed that the program keeps sending my call even
after DX has answered another station, as in the transcript below:
030130 -14 0.9 1909 ~ CQ CP6CL FH82 !Bolivia
0
I am trying WSJT-X r7934 using FT8, calling DX stations with Auto Seq enabled. I have noticed that the program keeps sending my
call even after DX has answered another station, as in the transcript below:
030130 -14 0.9 1909 ~ CQ CP6CL FH82 !Bolivia
030146 Tx 1909 ~ CP6CL VE3NEA FN03
03
I was pondering this very subject this morning.
Perhaps for the very tightly time-constrained modes a simple computation
comparing the received delta-T's of all received signals could be made. If
everyone else's clocks seem consistently wrong, maybe it's you!
An indication of that made by turnin
On 23/07/2017 07:48, Mark Turner via wsjt-devel wrote:
± 1.5s shouldn't present a problem to anyone, even, just about, for
people (e.g. some dxp) that rely on crude GPS NMEA serial data time
synchronisation.
In the (unlikely?) event that an even shorter DT window is ever
considered, I'd like
+/- 1.5s shouldn't present a problem to anyone, even, just about, for
people (e.g. some dxp) that rely on crude GPS NMEA serial data time
synchronisation.
In the (unlikely?) event that an even shorter DT window is ever
considered, I'd like to request that a small range of DT adjustment be
mad
Hi Bill:
Usually I try to look into code changes. Will be more aware of monitoring
code changes comments.
Thanks!
Edfel
KP4AJ
On Sat, Jul 22, 2017 at 6:20 PM, Bill Somerville
wrote:
> On 22/07/2017 20:47, Edfel Rivera wrote:
>
>> Thank you Mike! After fixing PC time, decoding properly now.
On 22/07/2017 20:47, Edfel Rivera wrote:
Thank you Mike! After fixing PC time, decoding properly now.
Hi Edfel,
Steve, K0AN, has tightened the time synchronization requirements for the
FT8 decoder. The change seemed sensible given the shorter T/R period,
higher proportion of the T/R period t
r DT.
>
> Sanity check time at http://time.is
>
> For Windows I can recommend Meinberg NTP.
>
> de Mike W9MDB
>
>
> --
> *From:* Edfel Rivera
> *To:* WSJT software development
> *Sent:* Saturday, July 22, 2017 2:24 PM
> *Subje
[wsjt-devel] Devel Build 7934 - Problems decoding
Hi:
Somehow decoding is affected at least in build 7934. I am aware this is
development code that is unstable just sharing behavior. This particularly
true for 6m, in 20m did test and there is decoding. But behavior not seems
normal.
At D
12 matches
Mail list logo
