[Linrad] Re: New release of MAP65-IQ

[Joe Taylor <Princeton.EDU; joe@xxxxxxxxxxxxxxxx>]

Hi Gabriel,

Something is wrong if your system clock needs adjustment by 
1 second after just 3 minutes.

For what it's worth: I have seen what may possibly be 
related behavior when running Linrad and MAP65-IQ on the 
same Windows computer.  Not every Windows, computer -- just 
one, of three that I tried.  One Win/XP machine showed the 
problem; another with Win/XP did not, nor did a third 
running Win/2000.

The symptom only showed up when both Linrad and MAP65-IQ 
were running.  Leif and I discussed it at some length, but 
we did not solve the problem.  Here are a few excepts from 
our emails:

############################################################
K1JT:
-----------------------------------------------------------
Strangest of all: with Linrad running in this mode (i.e., 
reading and processing a raw file) the Windows XP clock runs 
about 20% fast!!!  So far I have verified this on only one 
computer; but this is definitely a cause that would prevent 
MAP65-IQ from decoding signals.  So far I have no idea what 
is happening, or why.

K1JT, later:
-----------------------------------------------------------
I still have no explanation for the strange behavior of the 
Windows/XP system clock, which I described this morning. 
But I have now confirmed that it does not occur on another 
Win/XP machine -- the dual-core machine in my shack.  There, 
the raw data file can be played back, through Linrad, and 
MAP65-IQ happily decodes JT65 signals, just as it is 
supposed to do.

SM5BSZ:
-----------------------------------------------------------
I do not understand how that could happen. Data is stored 
sequentially and samples were taken at the correct time 
originally.  I assume map65 simply fills the data into an 
array and computes fft. Timing errors should cancel...

K1JT:
------------------------------------------------------------
The problem is that something was incrementing the Windows 
system clock so that it's reading increased by about 12 
seconds for every 10 seconds measured by my watch.  Hard to 
believe, but it was very reproducible. It happened only if 
Linrad was running.  The result was failure to decode, 
because MAP65 insists on having received a full buffer of Rx 
data within the allotted time; if the buffer is not full, it 
is dumped and another Rx period begins at the start of the 
next UTC minute.

I've never seen such behavior before, and I am amazed that 
any user program can affect the Windows clock in this way.

Yes, it was the system clock itself that was affected.  Even 
Windows own clock-calendar-setting utility showed the 
fast-moving clock.  Weird.

###############################################################

As you can see from this exchange, I noticed the problem 
when Linrad was processing raw data recorded on disk, rather 
than real-time data from the SDR-IQ.  However, it *may* be 
related to the problem you are seeing.

For what it's worth: the computer that showed this problem 
seemed to behave properly when Linrad was processing 
real-time data from the SDR-IQ.

Has anyone else seen problems with the Windows clock when 
running linrad and MAP65-IQ?

	-- 73, Joe, K1JT

Gabriel - EA6VQ wrote:
> I'm still having some trouble with the new release of MAP65-IQ.  In general
> it decodes fine, nearly at the same level than WSJT, but sometimes I notice
> two problems:
> 
> First, the program skips some decoding period from time to time, apparently
> not even trying to decode. It even shows nothing of that period in the
> waterfall display.
> 
> Second, some good signals (even as good as -15 dB) are not decoded at all,
> although they appear fine in the waterfall.
> 
> After having made some tests I think that the reason of the first problem
> could be related to the time synchronization. My PC has a very bad clock and
> I have to synchronize the time via Internet every 3 minutes (clock drift can
> be of about 1 second in that period..hi).  If I do it every 10 minutes (for
> instance) the problem apparently happens less often.  I wonder if might be
> the decoding algorithm gets fooled if the PC time changes sometime during
> the reception or decoding periods.
> 
> I also wonder if the second problem could also be caused by the same matter.
> 
> Anyone else has noticed this behaviour?
> 
> Joe, please, what do you think about this possibility?
> 
> 73. Gabriel - EA6VQ
> _________________________________________________________
> Web-Site: HTTP://www.vhfdx.net <HTTP://www.vhfdx.net>
> VQLog 3.1 (build 58): HTTP://www.vqlog.com <HTTP://www.vqlog.com>
> Real-Time Propagation maps: HTTP://www.vhfdx.net/spots/map.php
> <http://www.vhfdx.net/spots/map.php>
> _________________________________________________________
> 
> 
> > 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Linrad" group.
To post to this group, send email to linrad@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to linrad+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/linrad?hl=en
-~----------~----~----~----~------~----~------~--~---


LINRADDARNIL