Re: [time-nuts] HP5335A GPIB questions.
The 5335A is fussy. FWIW I used the following init string: IN,FN1,WA1\n Important: I then wait for 125 ms; that being the total time for IN,FN1,WA1 to execute per the 5335A manual. Only then, do I try to read data from the instrument. Pay careful attention to the times that commands take and don't try to access the 5335A before that time... expect it to sulk otherwise. After reading the first result, then I loop reading results. I have an additional delay of 100ms before reading each result. The comment in my code is: "5335A seems to sulk if we read too soon". I was using a real Prologix Ethernet GPIB adapter when I wrote this code. The delays are extremely important. The 5335A can and will hang if you don't wait long enough. In keeping with that, *do not* set your adapter to do an automatic read after sending data over the GPIB. Another thing to note is that the 5335A likes some kind of termination on its commands. I used using the ++eos=1 command to the Prologix. The unescaped '\n' in my init string ends the string to be sent over GPIB and '\r' is appended by the Prologix adapter. There is no need to send EOI after a command and the 5335A does not send EOI after the last character it sends.You have to read up to '\n' instead. You also want to make sure you don't timeout any read from the adapter before the gate time that is set on the 5335A. I used a 3s timeout with a gate of about 2s. I think that covers the gotchas that I know of! Orin. On Sat, Mar 21, 2015 at 7:24 PM, Luke Mester wrote: > I recently bought a HP5335A counter and have some questions about operating > the instrument with GPIB. > > I expect that a lot of time nuts are using this instrument and may be able > to help. Please excuse me if this is a stupid question. This is my first > GPIB instrument. > > After each GPIB command that I send I've found that I then need to send an > RE (reset) command. If I Don't send RE the instrument takes no readings and > has a blank display. For example I send FN9 to select period and get no > readings until RE is sent. Is this normal? > > I'm currently talking to it with a USB to GPIB adapter and a terminal > program. > > Since I had no idea if the GPIB interface was functional I didn't want to > buy an expensive GPIB adapter. I build the cheapest GPIB adapter that I > could find on the internet. It's possible that this is causing problems. > > It emulates a Prologix adapter. Here is a link if you're interested. > HTTP://http://www.dalton.ax/gpib/ > I've found that this adapter does not properly report the serial control > line status. Because of this, Timelab won't detect the GPIB adapter. > > You can get Timelab to work if you choose the "Acquire from counter in talk > only mode" option. > > > > > > > > -- > Luke Mester > http://mesterhome.com/ > ___ > 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] HP5335A GPIB questions.
Luke, the HP5335A was introduced in around 1980 and has an early (pre-IEEE-488.2) HP implementation of IEEE-488 which requires a terminator character at the end of each string. According to the manual, this terminator can be a comma, semicolon, space, carriage return, or line feed character. Later products (after about 1987) usually required a terminator of CR (carriage return), LF (line feed), or the hardware EOI (end or identify) termination method. In addition to the terminator character, your GPIB interface needs to change the bus transfer direction by unaddresing the HP5335A as a listener and making it a talker. Early IEEE-488 implementations in the late 1970's (IEEE-488 was introduced in 1975) and early 1980's often required explicit computer commands to assert and release the talk and listen commands, but by about 1990 the software commands usually performed these low level details for you automatically. So I suggest looking at the documentation for your GPIB interface and making sure you use a terminator character (from the list above) instead of only the EOI method of terminating commands, since I think the HP5335A will ignore the EOI line. Most GPIB interfaces in the past 20 years can be set to send a LF (ASCII 10 hex) character along with the EOI line transition to indicate the end of a command, and that should work. These old GPIB devices use very simple short cryptic commands, but they don't follow the later IEEE-488.2 and SCPI conventions. I'm sure you will be able to get this to work with the right configuration of termination character and talk/listen turnaround. -- Bill Byrom N5BB On Sat, Mar 21, 2015, at 09:24 PM, Luke Mester wrote: > I recently bought a HP5335A counter and have some questions about > operating the instrument with GPIB. > > I expect that a lot of time nuts are using this instrument and may be > able to help. Please excuse me if this is a stupid question. This is > my first GPIB instrument. > > After each GPIB command that I send I've found that I then need to > send an RE (reset) command. If I Don't send RE the instrument takes no > readings and has a blank display. For example I send FN9 to select > period and get no readings until RE is sent. Is this normal? > > I'm currently talking to it with a USB to GPIB adapter and a terminal > program. > > Since I had no idea if the GPIB interface was functional I didn't want > to buy an expensive GPIB adapter. I build the cheapest GPIB adapter > that I could find on the internet. It's possible that this is causing > problems. > > It emulates a Prologix adapter. Here is a link if you're interested. > HTTP://http://www.dalton.ax/gpib/ I've found that this adapter does > not properly report the serial control line status. Because of this, > Timelab won't detect the GPIB adapter. > > You can get Timelab to work if you choose the "Acquire from counter in > talk only mode" option. > > > > > > > > -- > Luke Mester http://mesterhome.com/ > _ > 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] HP5335A GPIB questions.
I recently bought a HP5335A counter and have some questions about operating the instrument with GPIB. I expect that a lot of time nuts are using this instrument and may be able to help. Please excuse me if this is a stupid question. This is my first GPIB instrument. After each GPIB command that I send I've found that I then need to send an RE (reset) command. If I Don't send RE the instrument takes no readings and has a blank display. For example I send FN9 to select period and get no readings until RE is sent. Is this normal? I'm currently talking to it with a USB to GPIB adapter and a terminal program. Since I had no idea if the GPIB interface was functional I didn't want to buy an expensive GPIB adapter. I build the cheapest GPIB adapter that I could find on the internet. It's possible that this is causing problems. It emulates a Prologix adapter. Here is a link if you're interested. HTTP://http://www.dalton.ax/gpib/ I've found that this adapter does not properly report the serial control line status. Because of this, Timelab won't detect the GPIB adapter. You can get Timelab to work if you choose the "Acquire from counter in talk only mode" option. -- Luke Mester http://mesterhome.com/ ___ 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] ADEV noise floor vs counter gate time
Hi, James. I'm a Tektronix RF Application Engineer in Dallas and thought I would throw in a few points about your FCA3100 (if you haven't read up on these already): All Tektronix manuals and technical reference documents can be downloaded for no charge on our website (http://www.tek.com), but some items may require you to register and sign in. The detailed specification and performance verification document (document number 077-0495-01) has many details about the specifications, and is at: http://www.tek.com/frequency-counter-supplies/mca3027-manual/fca3000-and-fca3100-series-mca3000-series All downloadable files for this product can be found in the list at: http://www.tek.com/search/apachesolr_search/fca3000 If you have a used counter, be sure you check the firmware version and update it if needed. If your exact model is "FCA3000", you have a 300 MHz counter with 100 ps single-shot resolution. This counter has reciprocal counter features (based on a 10 ns main counter time resolution), but also uses 100 ps RMS jitter interpolation to determine edge location with an additional X100 resolution. When the initial edge of the signal you are measuring is detected, the interpolater resolves this edge with 100 ps resolution relative to the internal 10 ns clock. After the desired measurement interval, the final edge is also resolved with 100 ps resolution, and the number of signal edges and interpolated intitial-to-final time are used to determine the frequency (for example). The analog interpolation circuit uses a constant current charging a capacitor with a sampler and A/D converter. Counting a 100 MHz signal, this provides 12 digits of resolution per second of measurement interval. -- Bill Byrom N5BB On Wed, Mar 18, 2015, at 05:49 PM, James via time-nuts wrote: > Hi Dave, > > Thanks for another detailed response. > > I've now programmed a version of my code that attempts to recover the > raw data by trying different counts up and down from the nominal and > finding the one with the smallest rounding error. > > One problem is I need to restrain the amount it goes up or down > otherwise it finds erroneously small or large numbers of cycles (+/- 2 > is believable, more than that isn't). > > As an experiment I then changed the data to match the "raw data". This > doesn't change the shape of the curve but it lowers it so it starts > below 10^-15! This is suspiciously good so I think I'm smoothing out > changes that are really there. > > Now that my new fca3100 has arrived I'm hoping to find time to get > measurements with it which should be proper time-stamped ones and much > more accurate - then I can compare the two. > > To answer your question on ADEV aggregating values, and speaking as a > total newbee myself, the approach to different tau sizes is to > aggregate all measurements within a bin of size tau and average the > frequencies (or average the time differences and invert - for small > variations it makes very little difference as (1+delta)^-1 is 1-delta > ignoring delta*delta terms). Then each term in the Alan Variaton > summation is the square of the difference between the average > frequency in adjacent bins. > > So with 1 second values at a tau of 100 secs, 100 values in each cell > are averaged whilst the 100 sec gate value results just have a single > value for each bin. But given that the counter itself should be > averaging there should be good agreement between the two - hence my > puzzlement. > > The fca3100 calculates ADEV directly so I'll have a check on my code. > > James > > > > > > > > -Original Message- From: Dave Martindale > To: jpbridge > CC: Discussion of precise time and frequency measurement > Sent: Wed, 18 Mar 2015 15:22 Subject: Re: > [time-nuts] ADEV noise floor vs counter gate time > > > > The counter always has a 1 count uncertainty in the timebase > measurement, which is a 2e-8 error with a 1 second gate time. If the > value being displayed starts with the digit 9, and 8 digits are > displayed, then that translates to +- 2 counts in the last place. But > the measurements are synchronized to the input signal, so it always > measures an integer number of input cycles, and there should be no > comparable uncertainty in the input (other than some noise in deciding > exactly when the edge crosses the input threshold, which should be > tiny compared to the 20 ns timebase period). > > > > But that's comparing the counter reading to the real world. My table > was comparing the displayed output to the likely raw measurements, and > it seems to show that the counter's internal math is being performed > to the full 10 digits of precision in the USB data, even when the gate > time supports only 8 bits of accuracy. That's good news because it > allows you to know when you have correctly guessed the input counts. > > > > > When trying to calculate the raw data from the reading, you do need to > try an input count of 91 in addition to 90 and 92. 91 did show up in > the
Re: [time-nuts] Obscure HP T/F instruments in ebay.fr
Warning: Discussion of old pre-1980 technology follows ... The Computer History Museum in Mountain View, CA, is amazing. I wish I hadn't sold my original issue Commodore PET 2001, but you can find examples of this and a wide range of early computers from the 1940's/50's/60's/70's (such as SAGE and CDC6400/6600) at the museum: http://www.computerhistory.org/ They have an operational Babbage Difference Engine No. 2: http://www.computerhistory.org/babbage/ I have worked for Tektronix for 28 years. Many of you may be interested in the vintageTEK website: http://www.vintagetek.org/ For those of you who have read old Tektronix service manuals with schematics: http://www.reprise.com/host/tektronix/humor/ Only a few of us existing Tektronix employees have been with the company long enough to have been involved in selling and supporting analog CRT oscilloscopes, TM500/TM5000 modular equipment, and the Tek 4051/4052/4054 (first all-in-one graphic desktop computers). Some of these were obsolete years before I started Tek in 1987, but I was using them in the late 1970's. When I was a University of Texas Electrical Engineering student back in the mid-1970's I built a device to compare the 3.5795454 MHz color burst NTSC television signal (from a normal TV set color reference oscillator) to an ovenized 5 MHz crystal oscillator using a 315/88 ratio TTL divider in the PLL. I used my Tektronix government surplus RM45A + CA plugin oscilloscope for this project. I also experimented with WWV 5/10/15 MHz frequency comparisons, but in Austin Texas the propagation from Ft Collins CO made this difficult to much better than 1 part in 10^7. The color burst method let me make use of the major TV network's rubidium standards. Unfortunately, by the late 1970's the networks were reading the monthly time deviation reports from NBS (name of NIST before 1988), and they would often manually readjust their rubidium standard magnetic field to get the frequency error in the NBS comparison closer to zero. Of course, this made the reliability of the time dissemination (phase of the color burst signal) unreliable. If they had just let the rubidium standard alone in a stable environment with no temperature or magnetic field changes, the drift in the timing error could have been modeled and corrections to the received signal made before reading the NBS monthly error reports. In my first job (late 70's to early 80's) we used Tektronix 7000 series CRT scopes to compare the output of a Tracor rubidium standard with a WWVB receiver and reference clocks in test instruments we were calibrating. We were considering building a commercial product based on my color burst recovery technique, but the random frequency adjustments by the networks and the switching between network and local station color burst reference clocks during local programming insertion caused us to abandon this project. This was about 7 years before I started at Tektronix. -- Bill Byrom N5BB On Fri, Mar 20, 2015, at 12:02 PM, Robert LaJeunesse wrote: > While it may not be time-nut centric there is a great museum in > Michigan that has collections of both clocks and technology, along > with a couple Stradavarius violins and machinist tools used by Mr. > Daimler. The Henry Ford Museum in Dearborn, MI has been actively > enlarging their technology collection - having recently paid nearly $1 > million for an original Apple I built by Jobs & Wozniak. They also > have Robert Moog's prototype music synthesizer. Might be time to > interest them in adding precision time to their clock and technology > collections. > > Bob LaJeunesse > >> Sent: Friday, March 20, 2015 at 1:33 AM From: "Bill Hawkins" >> To: "'Tom Van Baak'" , >> "'Discussion of precise time and frequency measurement'" >> Subject: Re: [time-nuts] Obscure HP T/F >> instruments in ebay.fr >> >> There are worse things than breaking up a collection. >> >> The Baaken Museum of Electricity in Life, near Minneapolis had a >> wonderful series of devices that used electricity to examine or >> prolong life, or to extract money from suckers. About 20 years ago, >> someone felt that there wasn't enough traffic at the museum, so the >> interesting exhibits were removed and the museum dumbed down for >> children. A vampire might greet you at the door. >> >> It seems that modern business managers have no time for things that >> don't draw crowds or fly off the shelves. If a museum or business >> wants to serve a market niche, it must compete with the incessant >> blizzard of advertising from the companies that just have to grow. >> Combine that with such companies expectations of productivity, and no >> one has time to search for interesting museums, never mind go to >> national parks. >> >> I would have been fascinated by and supportive of the French HP >> museum, had I known about it. I did not even dream such a place >> existed, but it makes sense that it was in Europe. Amsterdam has a >> science museum that lifts children's interest
Re: [time-nuts] Harmonics suppression in ring oscillators
Am Thu, 19 Mar 2015 22:26:15 +0100 schrieb Attila Kinali : > Moin, > > On Thu, 19 Mar 2015 21:50:03 +0100 > Florian Teply wrote: > > > My guess would be slightly different: the fundamental mode of > > oscillation could be considered the lowest energy state of all > > oscillation modes. Assuming that the system wants to minimize > > energy, this would be the mode to choose if it can't get into a > > steady state. But here we are back in wild guess land, and I'm not > > even sure that the concept of minimum energy states has any meaning > > in this context. > > That argumentation would work if all oscillation modes would have > a single, global energy source with a rate(power) limit. > An example for this are, e.g. lasers. There, the one mode with > the highest gain will suck up all energy from the other modes. > And the pump source replenishes the energy at a fixed, limted rate. > But in a ring oscillator, the energy is provided for each element > seperately and replenished as needed. Ie there is no competition > for energy between the different modes (all switching edges walk > around with the same speed and there are never two edges at the > same gate). > Umm, it might be not as clear a situation for CMOS technologies compared to lasers, but still there are some analogies to that as well: The Power supplies on chip are to some degree a limiting factor here. Higher Frequencies mean switching more often, and with standard loads in CMOS being capacitive, that translates to charging and discharging capacitors more often (=more average current consumption), which locally can often have a significant effect on voltage as CMOS gates become slower when the supply voltage is reduced. Usually not to the extent though that makes higher oscillation modes totally impossible... > Hmm... maybe the assumption that all edges walk around at the > same speed is wrong? > Well, in general this assumption is wrong, as by definition the gate delay as used in the definition of the oscillation frequency of an RO is anything but constant. At least for common CMOS technologies, there are several pitfalls: The gate delay as measured by oscillation frequency is the average of the propagation delays for both rising and faling edges. I have yet to come across a single combination of CMOS process and Digital Core Library that actually has balanced propagation delays, that is, equal numbers for both rising and falling edge. Commonly, falling edges (on the output) are somewhat faster than rising edges as n-Channel MOS transistors tend to have higher saturation currents than p-Channel types, and Core Cell Libraries usually are riddled with design tradeoffs in that regard. And as mentioned above, higher switching frequencies translate to lower effective power supply voltage locally at the gate, also increasing propagation delays. Then there is power dissipation, which is roughly linear with frequency. Add in the dependency of transistor parameters on temperature and thermal time constants on chip and you're getting closer to the effects that play a role in the data-dependent jitter Hal Murray mentioned in his answer. And there's even more that plays a role. Think of global and local mismatch between devices, process variation (which does not need to be uniform for both n- and p-Channel devices, and only in very rare cases affects both types in the same way so as to keep the drive balance between both). Of course, all of this CAN be addressed analytically (that is, in circuit simulations before manufacturing) and fed back for optimization, but in the semiconductor industry this is not commonly done as it would need to take into account way too many variables which are unknown to the ASIC Design Engineer, and often can not be known a priori. Best regards, Florian ___ 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] Comparing the BeagleBone Black & Raspberry Pi as NTP servers
David: On the BBB, were you running the fully loaded release, or the minimum "console" version of the OS? Which specific version of the OS? Thanks, --- Graham == On Sat, Mar 21, 2015 at 11:23 AM, David J Taylor < david-tay...@blueyonder.co.uk> wrote: > Folks, > > I've just put up my first draft of a comparison of these two popular > devices as NTP servers: > > http://www.satsignal.eu/ntp/BBB-vs-RPi.html > > Comments welcomed - I know it's an imperfect test! > > Cheers, > David > -- > SatSignal Software - Quality software written to your requirements > Web: http://www.satsignal.eu > Email: david-tay...@blueyonder.co.uk > ___ > 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] Comparing the BeagleBone Black & Raspberry Pi as NTP servers
Folks, I've just put up my first draft of a comparison of these two popular devices as NTP servers: http://www.satsignal.eu/ntp/BBB-vs-RPi.html Comments welcomed - I know it's an imperfect test! Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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] Measuring on my Racal 9480 with OCXO & 40 10Mhz outputs - (8x 5 chan)
Guyzz , i just got my Racal 9480 with OCXO & 40 10Mhz outputs And decided to play around with my PM6680B and linux-gpib. I'm using gmane to post , so i can't do attachments. But i have uploaded the results here: Url on eevblog : http://tinyurl.com/pdcc9ey I'm doing 10 measurements w. 1 s gate. And have enabled stats on the 6680B, for each 10 reading blocks. I'm reading out & logging F-max,min,mean and sdev What else cold be fun ?? CFO -- E-mail:xne...@luna.dyndns.dk ___ 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] The HP 58503A
On Fri, 20 Mar 2015 15:27:22 +, R.Phillips wrote: > Gentlemen I have recently acquired an HP 58503A which is working > perfectly, Was it the UK one going quite cheap ? The seller didn't answer me if he would ship outside UK, so i had to let it go. Congrats w. a nice instrument CFO -- E-mail:xne...@luna.dyndns.dk ___ 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] Some observations of the BG7T BL GPSDO
See performance plots, data files, and summary at http://www.ke5fx.com/gpscomp.htm . Thanks to Bob, W7AVK for the loan of the unit for testing! Would be curious to know if anyone else has encountered a similar frequency error, or if the issue I saw was unique to this particular example. -- 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.
