Re: [time-nuts] New Member / Z3801

[Azelio Boriani]

Welcome,
you hit the usual GPS week rollover issue, see these:


No impact on the 10MHz/PPS accuracy.
No command can correct the rollover, I seem to remember that if you
set the date before the GPS has a fix (right after a power cycle),
then the date will be correct (until the next power cycle).
There is also this software:


On Sun, Jan 17, 2016 at 3:59 PM, Artek Manuals  wrote:
> Hi guys
>
> Dave at ArtekManuals.com here. Long time electronics enthusiast/tinkerer/
> ham radio op.
> Recently moved and am in the process of setting up my long dreamed of a
> planned electronics lab and radio shack (NR1DX).
>
> At the heart of the lab is a HP Z3801 GPSDO to provide  an external 10MHz
> frequency reference. I bought the unit about 15 years ago but it has been in
> environmentally controlled storage ever since. Serial prefix is 3517Ax
> and I am running this on a +54VDC supply. Upon firing the Z3801 up, the
> first conundrum I am running into is that the unit does not seem to support
> setting the date above 12/31/2007. Sometimes during the survey mode it will
> automatically set the correct 2016 date , other times during the survey the
> date stays stuck on 1996. The unit tracks the satellites and mostly settles
> in around 1 second PPS at +/- 20ns with a holdover of 4 to 8us. More about
> the "mostly" comment in a later post.
>
> On the surface the actual reported date is not a big deal for me. as long as
> the date is not critical to the GPSDO function? The engineer in me would
> like to be able to set the date correctly ..just because. When
> attempting to set the using GPS:INIT:DATE I get an E-222 error (data out of
> range).
>
> So here are my initial questions.
> 1) I assume that the date thing is a firmware issue? Is there updated
> firmware out there that allows dates above 2007, 12, 31?
> 2) If all I care about is 10MHz accuracy, do I need to care about the date?
> 3) Is there a different command string I should be using?
> 4)Software: I am running HP SATSTAT and Z38XX on a WIN-XP/32 laptop ...IS
> there something better (or different) I should be running in the way of FREE
> software? I looked at the GPSCon package and so far questions about support
> for the software and portability eventually to WIN-10 supported have gone
> unanswered (not a good sign)
>
> Finally I am sure that the above have been addressed on older posts, but I
> gave up searching in frustration.  Is there an easy way to search the ENTIRE
> list archive. It seems that the archives must be queried one month at time
> which is REALLY TEDIOUS
>
> Dave
> NR1DX
> ArtekManuals.com
>
> --
> Dave
> manu...@artekmanuals.com
> www.ArtekManuals.com
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] New Member / Z3801

[Bob Camp]

Hi

> On Jan 17, 2016, at 9:59 AM, Artek Manuals  wrote:
> 
> Hi guys
> 
> Dave at ArtekManuals.com here. Long time electronics enthusiast/tinkerer/ ham 
> radio op.
> Recently moved and am in the process of setting up my long dreamed of a 
> planned electronics lab and radio shack (NR1DX).
> 
> At the heart of the lab is a HP Z3801 GPSDO to provide  an external 10MHz 
> frequency reference. I bought the unit about 15 years ago but it has been in 
> environmentally controlled storage ever since. Serial prefix is 3517Ax 
> and I am running this on a +54VDC supply. Upon firing the Z3801 up, the first 
> conundrum I am running into is that the unit does not seem to support setting 
> the date above 12/31/2007. Sometimes during the survey mode it will 
> automatically set the correct 2016 date , other times during the survey the 
> date stays stuck on 1996. The unit tracks the satellites and mostly settles 
> in around 1 second PPS at +/- 20ns with a holdover of 4 to 8us. More about 
> the "mostly" comment in a later post.
> 
> On the surface the actual reported date is not a big deal for me. as long as 
> the date is not critical to the GPSDO function? The engineer in me would like 
> to be able to set the date correctly ..just because. When attempting to 
> set the using GPS:INIT:DATE I get an E-222 error (data out of range).
> 
> So here are my initial questions.
> 1) I assume that the date thing is a firmware issue? Is there updated 
> firmware out there that allows dates above 2007, 12, 31?

The firmware issue is in the GPS module inside the 3801. The “solution” is to 
swap out the GPS module. 

> 2) If all I care about is 10MHz accuracy, do I need to care about the date?

No, the date in no way impacts the 10 MHz accuracy.

> 3) Is there a different command string I should be using?

You may eventually get it to take for a while. Check “GPS rollover” in the 
archives. There is a lot of information there on what’s going on. 

> 4)Software: I am running HP SATSTAT and Z38XX on a WIN-XP/32 laptop ...IS 
> there something better (or different) I should be running in the way of FREE 
> software? I looked at the GPSCon package and so far questions about support 
> for the software and portability eventually to WIN-10 supported have gone 
> unanswered (not a good sign)

Again, check the archives. The Z38xx software is a good way to go. It was 
originally written for the 3801.

> 
> Finally I am sure that the above have been addressed on older posts, but I 
> gave up searching in frustration.  Is there an easy way to search the ENTIRE 
> list archive. It seems that the archives must be queried one month at time 
> which is REALLY TEDIOUS

Google will search them quite nicely. 

Bob

> 
> Dave
> NR1DX
> ArtekManuals.com
> 
> -- 
> Dave
> manu...@artekmanuals.com
> www.ArtekManuals.com
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] New Member / Z3801

[cfo]

On Sun, 17 Jan 2016 09:59:22 -0500, Artek Manuals wrote:
> Finally I am sure that the above have been addressed on older posts, but
> I gave up searching in frustration.  Is there an easy way to search the
> ENTIRE list archive. It seems that the archives must be queried one
> month at time which is REALLY TEDIOUS
> 
> Dave NR1DX ArtekManuals.com

I use this url for searching they mirror time-nuts : 
https://www.mail-archive.com/time-nuts@febo.com/info.html

I also have a Z3801 w. a 1996 date, and think i saw that you should 
manually set the date before it gets a GPS fix. Then it will remember it 
(until next reboot)

CFO

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] New Member / Z3801

[paul swed]

Dave
Welcome to the group and have always appreciated the help from Artek.
If only frequency no need to care about the date. I learned this from
fellow time nuts. Yes I also hate 1996. Now I think there are later
software releases. I haven't had my 3801 on for a bit as I discovered that
I actually have a jumping frequency issue. But If need be happy to copy the
software.
Also check KO4bbs website later eproms may be there.
I don't actually recall seeing eproms in the unit.
Up until recently my 3801 of 10-14 years just worked thats why I am unclear
about the internals.
Unfortunately seems I may be digging into it.
Regards
Paul.
WB8TSL

On Sun, Jan 17, 2016 at 9:59 AM, Artek Manuals 
wrote:

> Hi guys
>
> Dave at ArtekManuals.com here. Long time electronics enthusiast/tinkerer/
> ham radio op.
> Recently moved and am in the process of setting up my long dreamed of a
> planned electronics lab and radio shack (NR1DX).
>
> At the heart of the lab is a HP Z3801 GPSDO to provide  an external 10MHz
> frequency reference. I bought the unit about 15 years ago but it has been
> in environmentally controlled storage ever since. Serial prefix is
> 3517Ax and I am running this on a +54VDC supply. Upon firing the Z3801
> up, the first conundrum I am running into is that the unit does not seem to
> support setting the date above 12/31/2007. Sometimes during the survey mode
> it will automatically set the correct 2016 date , other times during the
> survey the date stays stuck on 1996. The unit tracks the satellites and
> mostly settles in around 1 second PPS at +/- 20ns with a holdover of 4 to
> 8us. More about the "mostly" comment in a later post.
>
> On the surface the actual reported date is not a big deal for me. as long
> as the date is not critical to the GPSDO function? The engineer in me would
> like to be able to set the date correctly ..just because. When
> attempting to set the using GPS:INIT:DATE I get an E-222 error (data out of
> range).
>
> So here are my initial questions.
> 1) I assume that the date thing is a firmware issue? Is there updated
> firmware out there that allows dates above 2007, 12, 31?
> 2) If all I care about is 10MHz accuracy, do I need to care about the date?
> 3) Is there a different command string I should be using?
> 4)Software: I am running HP SATSTAT and Z38XX on a WIN-XP/32 laptop ...IS
> there something better (or different) I should be running in the way of
> FREE software? I looked at the GPSCon package and so far questions about
> support for the software and portability eventually to WIN-10 supported
> have gone unanswered (not a good sign)
>
> Finally I am sure that the above have been addressed on older posts, but I
> gave up searching in frustration.  Is there an easy way to search the
> ENTIRE list archive. It seems that the archives must be queried one month
> at time which is REALLY TEDIOUS
>
> Dave
> NR1DX
> ArtekManuals.com
>
> --
> Dave
> manu...@artekmanuals.com
> www.ArtekManuals.com
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[John Miles]

> Therefore, talk-only mode is a big advantage in terms of decoupling
> on RS-232 and makes almost no difference on GPIB.

That's not the case when it comes to counters.  By timing issues, I wasn't 
referring to layer-1 handshaking, but rather the interplay between the GPIB 
software application, the network or bus connectivity between the app and GPIB 
controller, the controller itself and its firmware, and an addressable counter 
that returns each measurement only in response to a command from the app.  The 
difference in performance between a talk-only connection and a two-way 
conversation can be substantial.  Yes, everything runs in lockstep, but the sum 
of the delays and latencies in each of those stages can easily exceed 0.1 
second.  In Attila's case there are also VM crossings in both directions to 
worry about.

The counter, unlike any of the other participants in the conversation, is 
working on a deadline.  Everything in a counter tends to happen in the 
"foreground," so to speak.  If the counter takes too long to interpret and 
execute a GPIB command, it may fail to rearm itself in time for the next 
trigger.  That's never a problem in talk-only mode, at least not at rates we're 
concerned with here, because the counter never has to do anything but send out 
data.

-- john, KE5FX
Miles Design LLC


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Hal Murray]

mag...@rubidium.dyndns.org said:
> OK, you where thinking about the flow-control.
> You can have RS-232 wired up to do flow-control (hardware-flow-control),
> where as flow-control is a standard property of GPIB. On the other hand,
> flow-control in itself only assures the data-transfer but not that  triggers
> is not missed in the overall system. 

GPIB is half duplex.  You have to turn the line around to tell it 
give-me-the-next-sample.  Talk-only avoids that.

In some sense, it's similar to flow control, but it's more likely to be 
implemented in software or wait for software to tell it to send data or ...

With talk-only, the OS buffer can handle many lines in case the scheduler is 
not cooperating.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Chuck Harris]

Talk-only mode is by intention, an exclusive mode, where
there is one talker, and one listener on the bus.  There
can be exceptions where there are more than one listener,
but that tends to be unusual.

Addressed mode can have one or more instrument on the
bus.  Although addressed mode is fully orchestrated by
the controller, the controller can easily interleave
things in a way that can cause unintended latency in a
critical instrument.

-Chuck Harris

Magnus Danielson wrote:

Poul-Henning,

On 01/17/2016 12:52 PM, Poul-Henning Kamp wrote:


In message <569b61cf.3030...@rubidium.dyndns.org>, Magnus Danielson writes:


This is a common misunderstanding:  Talk-only does *not* protecting you
against timing issues on GPIB.

On RS-232, yes, but not on GPIB.


Agree, to some degree. It's not a guarantee.

I think you should develop that line of thought, to detail why it helps
on GPIB and why not on serial.


It's really very simple:  RS-232 sends blind, you don't even need to
know if there is a receiver or what it does.  If the receiver cannot
keep op, data is simply lost.

GPIB handshakes every byte, so the actions of the receiving end affects
the transmitting end - in particular if the receiver cannot keep up.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Magnus Danielson]

God morgon!

On 01/16/2016 08:48 PM, Attila Kinali wrote:

God kväll!

On Sat, 16 Jan 2016 06:00:54 +0100
Magnus Danielson  wrote:


The two SR620s are both connected to an FS725 Rb frequency standard
(mostly because we have them around and nobody else uses them :-)


It's being used, by you! ;-)


There is another one lying around, nobody uses... and a CNT 91 :-)


Make sure to put that CNT-91 to use. :)
I have found that it's graph view is handy, especially when you don't 
have TimeLab around.



Have you tried swapping "role" of the SR620?


Yes, I've done that. Both SR620's lose some samples, but only one of
them loses significantly more than the other.


OK. So, the dropping follows the counter rather than the role?


Have you tried grabbing data in the Linux environment?


Nope. I couldn't find any tool for linux that worked.
I also tried to run Timelabs in Wine, but that segfaults on start.
Do you have any recommendation for a tool?


You don't need anything fancy. A small program to talk to the serial 
port should do it. If you could use talk only, I would just pipe it to a 
file and compare them later.


I really wish TimeLab existed directly on Linux. Last time I tried 
running it under Wine, it worked but didn't draw things properly for me.



Consider that the virtual box thing might not have the cleverest method
to handle data from multiple serial devices.


Yes. But I have done similar things, even more demanding stuff in the past
and they all worked. If anything was amis, then it was usually the USB
stack of Windows itself that screwed up.


Would not surprise me.


Have you tried swapping the serial-to-USB adaptors?


Yes, but I only have one type of adaptor at my disposal
(but at least a dozen of them).


OK.


Have you tried grabbing data on two independent PCs, just to avoid
issues in the USB handling? (Yes, never mind it won't correlate, just
check that you get the same amount of data)


Not yet. I'll do that on monday.


OK.


Have you tried feeding timelab two streams generated on the linux side?


What do you mean by that?


If you generate data that looks like real data and then mock the serial 
ports to make TimeLab beleive it is real counters, you can now see if 
the dataflow themselves causes issues over the Linux/Windows border and 
into TimeLab.



Essentially, from the counters to TimeLab you have a weak link, and you
need to consider all parts of it to identify which of them that is the
weak link.


I am currently leaning onto some kind of ground loop problem with the PC
in between. Though I am not sure. What I see is, that if only one of the
SR620s is running/connected, then the excursions with the "1s" size samples
are gone. So, currently I'm running only one of the SR620s (the one that
loses less samples) and capture only one pair of nodes at a time.


I'm considering that somewhere in that chain, the existence of two live 
streams is the issue. It could even be the TimeLab/counter interaction 
as hinted by John.



Another curious thing I see that I couldn't make sense of is, that from
time to time, on both of the SR620s, I see time differences of 1s (yes,
one full second). Given that the FPGAs produce a pulse every 50us, this
shouldn't be possible, unless the crystal oscillator stops.

Any idea what I might have done wrong or what the cause is?


It's not a consequence of the TI +/--mode such that the stop trigger
gets in early and you get a negative value reported because it takes
(start-time) - (stop-time) but allowing the stop-time to be the first?
Check the raw data.


It should not be. The pulses from the different nodes are within 2ns.
Even if one wanders away momentarily, it won't be able to go farther
than <3ns (the VCXO that generates the clock on each nodes is an ASVTX-09
which cannot be de-tuned more than a couple ppm, combined with a cycle
length of 50us after which the node is corrected into the right direction).
The trigger pulse comes a full 20us before the measured pulses come, so
that should not be the problem. I have to check what the raw data says.


I was hinting at a possible raw-data issue which in the pre-processing 
turned out a bit different. I realize now that dropping samples could 
possibly have the pre-processing react similarly.



Due to the problems I had with the SR620s and what the group at the TU Vienna
experienced (I am currently using their equipment), we started to ponder
whether we should build our own, multi-input TICs. Especially considering
that we are about to design some ASICs which we expect to be synced up
better than 100ps (somewhere around 20-50ps, limited by the delay uncertainty
of the cables).


Well, building your own TIC would naturally be interesting, but adds 
another aspect in that you will have to verifiy them extensively. It 
will be another factor of uncertainty to consider.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com

Re: [time-nuts] Timelab, two SR620s and losing samples

[Magnus Danielson]

John,

On 01/16/2016 10:33 PM, John Miles wrote:

Agreed with Magnus that there are a lot of possible variables in your setup 
that need to be ruled out.

Are you using the SR620 driver in TimeLab, or did you find a way to get it to 
emit data continuously via the RS232 port for use with the talk-only driver?  
I've seen occasional instances where a counter has ignored every other trigger 
when used in addressable mode by TimeLab.  It's not always readily 
reproducible, but the counter drivers in the current beta at 
http://www.miles.io/timelab/beta.htm seem to be a bit less prone to that 
behavior.  If you aren't already using the beta, try that.

It's always safest to use counters in talk-only mode when possible, since that 
rules out any timing problems that might arise in a two-way GPIB or serial 
conversation where each individual reading is requested by the software as done 
by the 5313xA, Philips, DTS2070-series, and SR620 drivers.  Some of those 
counters can be used in both talk-only and addressable modes, but I don't 
believe that's true of the SR620, unfortunately.  All of the programming 
examples in the SR620 manual work by requesting each reading individually.


I think it is the AUTM command that should be used, as it lets you swap 
between automatically start a new measurement (AUTM1) or let it start 
after computer receives measurement (AUTM0).


I have not tried it, I just pulled the manual from the shelf.

Come to think of it, in principle I could duplicate this as I have two 
SR620 lying around, but I think I better grab that second RF section in 
the boot of my car, bring it in and put it into the rack which needs 
rebuilding.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Poul-Henning Kamp]

In message <569b3b7e.6090...@rubidium.dyndns.org>, Magnus Danielson writes:

>> It's always safest to use counters in talk-only mode when possible,
>>since that rules out any timing problems that might arise in a
>>two-way GPIB [...]

This is a common misunderstanding:  Talk-only does *not* protecting you
against timing issues on GPIB.

On RS-232, yes, but not on GPIB.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Magnus Danielson]

Dear Poul-Henning,

On 01/17/2016 10:08 AM, Poul-Henning Kamp wrote:


In message <569b3b7e.6090...@rubidium.dyndns.org>, Magnus Danielson writes:


It's always safest to use counters in talk-only mode when possible,
since that rules out any timing problems that might arise in a
two-way GPIB [...]


This is a common misunderstanding:  Talk-only does *not* protecting you
against timing issues on GPIB.

On RS-232, yes, but not on GPIB.



Agree, to some degree. It's not a guarantee.

I think you should develop that line of thought, to detail why it helps 
on GPIB and why not on serial.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Attila Kinali]

Moin John,

On Sat, 16 Jan 2016 13:33:54 -0800
"John Miles"  wrote:

> Agreed with Magnus that there are a lot of possible variables in your setup 
> that need to be ruled out.  

Yes, too many. And it isn't really helping that I hardly understand what
I am doing.


> Are you using the SR620 driver in TimeLab, or did you find a way to get
> it to emit data continuously via the RS232 port for use with the talk-only
> driver?

I am using TimeLab and start two acquisitions. That part seems to work
quite nicely.

> I've seen occasional instances where a counter has ignored every other
> trigger when used in addressable mode by TimeLab.  It's not always readily 
> reproducible, but the counter drivers in the current beta at 
> http://www.miles.io/timelab/beta.htm seem to be a bit less prone to that 
> behavior.  If you aren't already using the beta, try that.

Thanks! I'll try that tomorrow.

> 
> It's always safest to use counters in talk-only mode when possible, since 
> that rules out any timing problems that might arise in a two-way GPIB or 
> serial conversation where each individual reading is requested by the 
> software as done by the 5313xA, Philips, DTS2070-series, and SR620 drivers.  
> Some of those counters can be used in both talk-only and addressable modes, 
> but I don't believe that's true of the SR620, unfortunately.  All of the 
> programming examples in the SR620 manual work by requesting each reading 
> individually. 

Hmm.. I have set TimeLab to do samples every 0.1 seconds, and have an
external trigger with the same interval (SR620 setting ist Ext +/- Time).
Could it be that TimeLab just samples a little slower than the 0.1s,
so that it misses a measurement once in a while and has to wait until
the next trigger arrives?


Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Attila Kinali]

Guete Morge!

On Sun, 17 Jan 2016 07:24:32 +0100
Magnus Danielson  wrote:

> >> Have you tried swapping "role" of the SR620?
> >
> > Yes, I've done that. Both SR620's lose some samples, but only one of
> > them loses significantly more than the other.
> 
> OK. So, the dropping follows the counter rather than the role?

Yes.
 
> >> Have you tried grabbing data in the Linux environment?
> >
> > Nope. I couldn't find any tool for linux that worked.
> > I also tried to run Timelabs in Wine, but that segfaults on start.
> > Do you have any recommendation for a tool?
> 
> You don't need anything fancy. A small program to talk to the serial 
> port should do it. If you could use talk only, I would just pipe it to a 
> file and compare them later.

Hmm.. good idea.

> I really wish TimeLab existed directly on Linux. Last time I tried 
> running it under Wine, it worked but didn't draw things properly for me.

It's like Lady Heather, it needs to be ported to Qt ;-)
 
> >> Have you tried feeding timelab two streams generated on the linux side?
> >
> > What do you mean by that?
> 
> If you generate data that looks like real data and then mock the serial 
> ports to make TimeLab beleive it is real counters, you can now see if 
> the dataflow themselves causes issues over the Linux/Windows border and 
> into TimeLab.

Ah.. unfortunately this would need a bit more fiddling and tool building
than I have time for. I'm only here for another week and have to spend
most of the time learning how to do ASICs.
 
> > Due to the problems I had with the SR620s and what the group at the TU 
> > Vienna
> > experienced (I am currently using their equipment), we started to ponder
> > whether we should build our own, multi-input TICs. Especially considering
> > that we are about to design some ASICs which we expect to be synced up
> > better than 100ps (somewhere around 20-50ps, limited by the delay 
> > uncertainty
> > of the cables).
> 
> Well, building your own TIC would naturally be interesting, but adds 
> another aspect in that you will have to verifiy them extensively. It 
> will be another factor of uncertainty to consider.

Yes. It wouldn't be something that is done fast. I expect it to take
at least half a year with a couple of highly motivated people as a team.
A year would be probably more realistic. And after that, comes a whole
lot of verification and qualification. But that could probably be done
together with PTB or CERN.


Attila Kinali
-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Magnus Danielson]

Poul-Henning,

On 01/17/2016 01:45 PM, Poul-Henning Kamp wrote:


In message <569b8b2e.5070...@rubidium.dyndns.org>, Magnus Danielson writes:


I think you should develop that line of thought, to detail why it helps
on GPIB and why not on serial.


It's really very simple:  RS-232 sends blind, you don't even need to
know if there is a receiver or what it does.  If the receiver cannot
keep op, data is simply lost.

GPIB handshakes every byte, so the actions of the receiving end affects
the transmitting end - in particular if the receiver cannot keep up.


OK, you where thinking about the flow-control.

You can have RS-232 wired up to do flow-control (hardware-flow-control),


But the important point is you don't have to do that, all you need
is two wires:  GND-GND and TXD->RXD

With GPIB that option does not exist, sender and receiver are always
in lock-step.

Therefore, talk-only mode is a big advantage in terms of decoupling
on RS-232 and makes almost no difference on GPIB.



If we can assume the consumption is fast enough to keep track, yes.
If it's not, flow control for this situation helps the border case 
somewhat, but if you are too slow, you are screwed anyway.


In the case that Attila describes, the flow-control helps over the 
various borders, especially as scheduling plays tricks with us. Running 
virtual applications like that does not help to get a grip of control 
over how data is transfered and when. If it where only to get it 
straight into an app really talking to the serial ports, sure, but I do 
not trust the virtualization to handle it all to well.


Not that hardware flow-control would in itself help much, but anyway.

Regardless, if the TimeLab needs to send commands back to the counter 
over the virtualization border, then getting things scheduled properly 
in time isn't really guaranteed.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Magnus Danielson]

Poul-Henning,

On 01/17/2016 12:52 PM, Poul-Henning Kamp wrote:


In message <569b61cf.3030...@rubidium.dyndns.org>, Magnus Danielson writes:


This is a common misunderstanding:  Talk-only does *not* protecting you
against timing issues on GPIB.

On RS-232, yes, but not on GPIB.


Agree, to some degree. It's not a guarantee.

I think you should develop that line of thought, to detail why it helps
on GPIB and why not on serial.


It's really very simple:  RS-232 sends blind, you don't even need to
know if there is a receiver or what it does.  If the receiver cannot
keep op, data is simply lost.

GPIB handshakes every byte, so the actions of the receiving end affects
the transmitting end - in particular if the receiver cannot keep up.



OK, you where thinking about the flow-control.

You can have RS-232 wired up to do flow-control (hardware-flow-control), 
where as flow-control is a standard property of GPIB. On the other hand, 
flow-control in itself only assures the data-transfer but not that 
triggers is not missed in the overall system.


I just didn't want to mind-read you on this one.

So, I don't see how flow-control would severely break in GPIB doing 
addressed mode compared to talk-only mode, it's an orthogonal feature of 
both.


It is however to some degree easier to control the real-time flow from 
only one instrument in talk-only mode compared to addressed mode. 
However, it should be possible to achieve it also in addressed mode, but 
you then need to think through the signaling interaction. Also, as both 
counters is triggered, the trigger interaction needs to be analyzed and 
the dataflow understood in the system context.


The SR620 does not recommend the AUTM1 mode for serial interface, as the 
synchronization between program and data-readout does not become as 
easy. Similarly, the SR620 does not support the binary mode for serial 
interface, but for GPIB, giving almost a ten-fold increase in 
sample-rate (150 vs 1400 samples per second).


Anyway, flow-control to ensure integrity of byte-flow should always be 
used. That will help if we can trigger both counters at the same time 
and guarantee that they are idle before next arming pulse.


Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Phase Noise Comparisons

[Bob Bob]

For software I'm using PN3048 from k35fx's site together with an Aglient 82347b 
GPIB interface running thru Virtual Box. Other than not recognizing the 
instruments once and a while, its been pretty reliable. I've also gotten the 
original BASIC program to work under HT BASIC and surprisingly is more reliable 
in terms of communicating with the devices.
I  ran the test at 10mhz against the builtin oscillator that comes with the 
hp11848a. I also ran a test against a Fluke 6070a at 100mhz and got almost the 
exact same results from 1khz on out. Maybe I got lucky with my 8660c. It would 
be interesting to see measurements from a few other units.
David

> From: r...@nc0b.com
> To: time-nuts@febo.com
> Date: Sun, 17 Jan 2016 04:21:40 +
> Subject: Re: [time-nuts] Phase Noise Comparisons
> 
> Hi Dave,
> 
> Very good.  Interesting you data is better than any typical data I could find 
> on the web which was -105 to -107 dBc/Hz at 10 kHz. 
> 
> I need N0QO to get his 3048A up and running again so we can test some other 
> equipment.
> 
> What are you using for software?
> At what frequency was this plot made?
> 
> I tried to send a moderate size PDF, but it at least temporarily has been 
> blocked. 
> 
> Rob
> NC0B
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob Bob
> Sent: Saturday, January 16, 2016 8:37 PM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Phase Noise Comparisons
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Actually, I just acquired a HP3048a phase measurement system and I'm 
> measuring all of the my signal generators, one of which is an 8660c with the 
> 86603 plugin.  Attached (ignore the caption) is the result compared against 
> the 3048a internal 10mhz low noise reference. 
> 
> 
> David
> > From: r...@nc0b.com
> > To: time-nuts@febo.com
> > Date: Sat, 16 Jan 2016 20:05:18 +
> > Subject: [time-nuts] Phase Noise Comparisons
> > 
> > I did some interpolation to compare the specs for phase noise of the 8660 
> > the way it was done then to the present method. I think it is going to be 
> > something like -105 dBc/Hz to -110 dBc/Hz at 10 kHz offset at 14 MHz 
> > carrier frequency.
> > 
> > 
> > 
> > As a comparison, the 8662A is about -135 dBc/Hz and the 8642A is better 
> > than -150 dBc/Hz.
> > 
> > Actual measurements on multiple generators in my lab.  Unfortunately I have 
> > never used or measured an 8660.
> > 
> > 
> > 
> > 3335A -128 dBc/Hz
> > 
> > 3336C -120 dBc/Hz
> > 
> > 3325A -115 dBc/Hz (original version.  Later improved by 4 pr 5 dB 
> > after the 3336C came out.)
> > 
> > 
> > 
> > As a comparison a Rigol DG4162 is -115 dBc/Hz All at 10 kHz offset and on 
> > the 20 meter band.
> > 
> > 
> > 
> > It depends what you are trying to measure. Sensitivity or noise floor, 
> > anything will work within the range of specified output accuracy and 
> > leakage.  On the other hand, if you are trying to measure the dynamic range 
> > of a receiver, or its phase noise characteristics, you cannot do that with 
> > most generators.
> > 
> > 
> > 
> > Rob, NC0B
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to 
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
> 
> 
> 
> --
> If this email is spam, report it to
> https://support.onlymyemail.com/view/report_spam/ODExMjI6MTg0MzU3MjgwMDpyb2JAbmMwYi5jb206ZGVsaXZlcmVk
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
  
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Timelab, two SR620s and losing samples

[Poul-Henning Kamp]

In message <569b8b2e.5070...@rubidium.dyndns.org>, Magnus Danielson writes:

>>> I think you should develop that line of thought, to detail why it helps
>>> on GPIB and why not on serial.
>>
>> It's really very simple:  RS-232 sends blind, you don't even need to
>> know if there is a receiver or what it does.  If the receiver cannot
>> keep op, data is simply lost.
>>
>> GPIB handshakes every byte, so the actions of the receiving end affects
>> the transmitting end - in particular if the receiver cannot keep up.
>
>OK, you where thinking about the flow-control.
>
>You can have RS-232 wired up to do flow-control (hardware-flow-control), 

But the important point is you don't have to do that, all you need
is two wires:  GND-GND and TXD->RXD

With GPIB that option does not exist, sender and receiver are always
in lock-step.

Therefore, talk-only mode is a big advantage in terms of decoupling
on RS-232 and makes almost no difference on GPIB.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] New Member + Basic Questions

[jimlux]

On 1/16/16 4:29 PM, Nathan Johnson wrote:

Right now I'm mostly aligning IF stages of boat anchor rigs,


An inexpensive eval board with a synthesizer chip might work for this, 
like the Si570.  Aligning the IF doesn't require great phase noise 
performance. this is probably a <$50 solution.


Pair that with a good step attenuator and a decent power meter (which 
have other uses) and you're good to go.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] New Member / Z3801

[Artek Manuals]

Hi guys

Dave at ArtekManuals.com here. Long time electronics 
enthusiast/tinkerer/ ham radio op.
Recently moved and am in the process of setting up my long dreamed of a 
planned electronics lab and radio shack (NR1DX).


At the heart of the lab is a HP Z3801 GPSDO to provide  an external 
10MHz frequency reference. I bought the unit about 15 years ago but it 
has been in environmentally controlled storage ever since. Serial prefix 
is 3517Ax and I am running this on a +54VDC supply. Upon firing the 
Z3801 up, the first conundrum I am running into is that the unit does 
not seem to support setting the date above 12/31/2007. Sometimes during 
the survey mode it will automatically set the correct 2016 date , other 
times during the survey the date stays stuck on 1996. The unit tracks 
the satellites and mostly settles in around 1 second PPS at +/- 20ns 
with a holdover of 4 to 8us. More about the "mostly" comment in a later 
post.


On the surface the actual reported date is not a big deal for me. as 
long as the date is not critical to the GPSDO function? The engineer in 
me would like to be able to set the date correctly ..just because. 
When attempting to set the using GPS:INIT:DATE I get an E-222 error 
(data out of range).


So here are my initial questions.
1) I assume that the date thing is a firmware issue? Is there updated 
firmware out there that allows dates above 2007, 12, 31?

2) If all I care about is 10MHz accuracy, do I need to care about the date?
3) Is there a different command string I should be using?
4)Software: I am running HP SATSTAT and Z38XX on a WIN-XP/32 laptop 
...IS there something better (or different) I should be running in the 
way of FREE software? I looked at the GPSCon package and so far 
questions about support for the software and portability eventually to 
WIN-10 supported have gone unanswered (not a good sign)


Finally I am sure that the above have been addressed on older posts, but 
I gave up searching in frustration.  Is there an easy way to search the 
ENTIRE list archive. It seems that the archives must be queried one 
month at time which is REALLY TEDIOUS


Dave
NR1DX
ArtekManuals.com

--
Dave
manu...@artekmanuals.com
www.ArtekManuals.com


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] New Member + Basic Questions

[Bob Camp]

Hi



> On Jan 16, 2016, at 7:29 PM, Nathan Johnson  wrote:
> 
> Right now I'm mostly aligning IF stages of boat anchor rigs, not designing new
> stuff or trying to evaluate performance of newer rigs, so I think the 8660 
> will
> do the job until I can afford something better. I'm debating what to buy 
> later,
> but it appears most of the older rigs with better specs and that are 
> well-liked
> here start at $500(It "powers on") to $1000(Tested and calibrated) and can
> easily go as high as one wants to spend on newer gear. I'm sure I will wind up
> that far into the hobby... Just not yet! I appreciate all the information from
> the group, I'm learning a lot.
> Nathan KK4REY

Consider that what you have right now may be “good enough” for anything you
are likely to do with it. You only *need* to get a different gizmo when you 
have an
application that is beyond what you can deal with now. Yes, gear is cheaper if 
you 
shop for a year for that “bargain”. You can also wind up with a shed full of 
gear (or 
possibly three sheds …) going for each deal that comes along. 

Bob


> 
> Sent using CloudMagic Email
> [https://cloudmagic.com/k/d/mailapp?ct=pi=7.4.15=9.1=email_footer_2]
> On Sat, Jan 16, 2016 at 19:32, Discussion of precise time and frequency
> measurement  wrote:
> I did some interpolation to compare the specs for phase noise of the 8660 the
> way it was done then to the present method. I think it is going to be 
> something
> like -105 dBc/Hz to -110 dBc/Hz at 10 kHz offset at 14 MHz carrier frequency.
> 
> As a comparison, the 8662A is about -135 dBc/Hz and the 8642A is better than
> -150 dBc/Hz.
> Actual measurements on multiple generators in my lab. Unfortunately I have 
> never
> used or measured an 8660.
> 
> 3335A -128 dBc/Hz
> 3336C -120 dBc/Hz
> 3325A -115 dBc/Hz (original version. Later improved by 4 pr 5 dB after the 
> 3336C
> came out.)
> 
> As a comparison a Rigol DG4162 is -115 dBc/Hz
> All at 10 kHz offset and on the 20 meter band.
> 
> It depends what you are trying to measure. Sensitivity or noise floor, 
> anything
> will work within the range of specified output accuracy and leakage. On the
> other hand, if you are trying to measure the dynamic range of a receiver, or 
> its
> phase noise characteristics, you cannot do that with most generators.
> 
> Rob, NC0B
> 
> 
> 
> 
> Sent from my iPad
> 
> > On Jan 16, 2016, at 3:10 AM, "Richard (Rick) Karlquist"
>  wrote:
> >
> >
> >
> >
> >
> >> On 1/14/2016 12:35 PM, Nathan Johnson wrote:
> >> What does the group think of the HP 8660? Just scored a broken one too 
> >> cheap
> to
> >> pass up. I know it's not gonna be the last signal generator I buy, but for
> under
> >> $100 shipped it should be an interesting project.
> >> Nathan KK4REY
> >
> > When I worked at HP, I had the chance to discuss this product
> > with various engineers who were involved in its development.
> > It frankly wasn't one of the better products in the line.
> > It has a high broadband noise floor. The follow on
> > product, the 8662, is MUCH better. No comparison.
> >
> > Rick Karlquist N6RK
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to 
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
> >
> >
> >
> > --
> > If this email is spam, report it to
> >
> https://support.onlymyemail.com/view/report_spam/ODExMjI6MTg0MzQzODAwNjpyb2JAbmMwYi5jb206ZGVsaXZlcmVk
> >
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.