Re: [time-nuts] Some observations of the BG7T BL GPSDO
Fashinating error. Any details anywhere about how these are built? A quick search came up with nothing. Some of them have been sold on eBay (e.g., item 251802969291) and at http://bg7tbl.taobao.com . Is this a FLL design? There seems to be a somewhat caotic beat pattern in there, look how the phase has relatively flat parts where it seems to be on-track, which naturally is when it has it's high frequency periods near the 0 mark. Links to the build? Unfortunately this is all I know about the unit, as it was loaned to me. There seems to be a subtle 4-6 hour periodicity present, if you load the file and look at the frequency difference plot with a 10K-second averaging time. If it's real, perhaps it corresponds to interaction between the disciplining time constant and HVAC behavior but the effect is so broad that it barely appears as a ripple in the ADEV trace. Considering the price, the unit seems to offer a good GPS receiver and a very stable DOCXO, assuming the seller is hand-picking their MV89As to reject the bad ones that have been seen on the surplus market. (That may not be the case, as Bob told me he had to exchange his first unit because it arrived with a bad oscillator.) It could probably achieve extremely high performance with some optimization and/or bug fixes. One of those cases where you'd really like to be able to tweak the source code. -- 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] Some observations of the BG7T BL GPSDO
Curious, but I'm wondering whether there are any artefacts that might have been caused by the weak GPS signal? I would feel more comfortable if the unit had its planned strong GPS signal throughout the test. I know it's meant to cope with that, but it might have thrown up an obscure software bug. Exactly how that might have nudged the frequency off I can't figure. I will say that when the Thunderbolt went into holdover, the BG7TBL unit barely twitched (see http://www.ke5fx.com/gpscomp/holdover.png ). In fact, this was the only time its frequency error went positive for a significant period. It's likely that many/most newer GPSDOs have better receivers than the Thunderbolt. If the BG7TBL unit had been less consistently off-frequency, I'd be more inclined to agree that test wasn't fair due to the weak signal. Another area of concern is that I don't know how the unit manages its self-survey process. If it still thinks it's in China, then it obviously isn't going to perform at its best. Ideally it would recognize that it's been moved since the last powerup, but I can't be sure about that, not having any software or documentation for its serial port... -- 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] Comparing the BeagleBone Black Raspberry Pi asNTP servers
David: On this page: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29 they list an alternative console only image: https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz It might be easier starting with that if you don't intend to use graphics. Mike On 3/22/2015 03:46, David J Taylor wrote: 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 = Graham, The download was: bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz (547,024,548 bytes) which was from the Recommended Debian Images from: http://beagleboard.org/latest-images. Perhaps there are some services or background tasks I can disable to reduce the CPU steady load from its present 16% average level? 73, David GM8ARV ___ 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
On Sat, 21 Mar 2015 16:23:30 - David J Taylor david-tay...@blueyonder.co.uk wrote: 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! Something is wrong here. I would expect the BBB to perform at least as well as the rpi (after all, the BBB has an ethernet MAC with IEEE1588 support, while the rpi is basically a glorified USB controller with attached graphics card). You are most likely running services on the BBB (network services, local services, cron jobs,...) that cause the high, and spikey cpu load, which in turn destroys your ntp performance. Also, compare your results to [1], where Dan Drown uses the capture/compare unit of the AM3359 to timestamp the PPS and use this for ntp. In [2] he tries to measure the temperature dependence of the BBB oscillator (not be best way, but...). Attila Kinali [1] http://blog.dan.drown.org/beaglebone-black-timer-capture-driver/ [2] http://blog.dan.drown.org/tcxo-beaglebone-black/ -- _av500_ phd is easy _av500_ getting dsl is hard ___ 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 Bill, Thanks for the pointers. I should say that my results reported so far have been with my older TTi TF930 reciprocal counter, not with my FCA3100 which I have only just got (it arrived a few days ago) and I'm in the process of writing software to talk to it via the USB. I did discover the website, in fact I'd downloaded the manual before buying the counter, and it is fortunate I did because the website for me didn't work - I'm currently talking to Tek support about it. The problem is that to download software you must have your details registered. Every time I register my details and press the save button the site wipes all my details and returns to a blank form. When I try to down load the software it then stops me and tells me to update my details. I update my details and it blanks the form and so on... slightly frustrating. I've tried both Firefox and IE. The other thing is that the manuals don't show on the European site (I'm in the UK), you click on them but the download screen just shows a blank line. I got round this by going to the international site and just closing the screen asking me for my area rather than responding to it - I had to do this several times. I have now downloaded NI-VISA and have managed to do a bit of talking to the instrument over USB though I've not yet had time to do this properly. So in summary - I'm pleased with my counter but the Tek website for Europe at least has some serious bugs which hopefully will be fixed soon. The Tek support person I spoke to on the phone was helpful but she wasn't in a position to fix the web site issues directly so has forwarded my case to Tek IT. I intend repeating my TTi TF930 experiment with my FCA3100 when I've got everything working ok and am looking forward to seeing the results. James -Original Message- From: Bill Byrom t...@radio.sent.com To: time-nuts time-nuts@febo.com Sent: Sun, 22 Mar 2015 2:27 Subject: 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
Re: [time-nuts] Some observations of the BG7T BL GPSDO
Hi John, On 03/21/2015 08:14 AM, John Miles wrote: 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. Fashinating error. Any details anywhere about how these are built? A quick search came up with nothing. Is this a FLL design? There seems to be a somewhat caotic beat pattern in there, look how the phase has relatively flat parts where it seems to be on-track, which naturally is when it has it's high frequency periods near the 0 mark. Links to the build? 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] Comparing the BeagleBone Black Raspberry Pi asNTP 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 = Graham, The download was: bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz (547,024,548 bytes) which was from the Recommended Debian Images from: http://beagleboard.org/latest-images. Perhaps there are some services or background tasks I can disable to reduce the CPU steady load from its present 16% average level? 73, David GM8ARV -- 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.
Re: [time-nuts] AVAR - S_Y conversion
Hello time-nuts community, thanks to your feedback and that of others, I could make additional progress on my journey to understand powerlaw noise :) I would like to reiterate what I have learned so far. Please comment on anything that you think is done wrong. --- 0) Conventions: --- My main goal is to simulate powerlaw noise and analyze it as described in IEEE1139 [1]. I will use the following conventions: f_s sampling frequency of the simulated noise tau_0 time interval between two samples (directly related as 1/f_s) y(t)Fractional frequency deviation at time t S_y(f) one-sided PSD of y, has a shape of as h_alpha * f^alpha alpha has one of the following values: 2 White PM noise 1 Flicker PM noise 0 White FM noise -1 Flicker FM noise -2 Random Walk noise --- 1) Using the formulas in IEEE 1139: --- As I said, I mainly use the formulas given in IEEE1139, especially those in Table B.2, which define the relationship between Allan Variance and the S_y. I have attached a screenshot of those formulas to this mail. I'm not sure what f_h should be in the calculation of the terms D and E. IEEE 1139 defines it as the high-frequency cutoff of an infinitely sharp low-pass filter. I don't sample my noise from a real device, but simulate it. Am I right that I can use f_h = f_s/2 (Nyquist theorem)? I haven't found a publication that explicitly states this, but in my experiments this assumptions works well. --- 2) Noise generation, calculation of h_alpha: --- I generate powerlaw noise according to the publication by Kasdin and Walter [2]. As you might have noticed in my initial mail, I estimated h_alpha from an Allan Variance plot. This is not how it should be done. The better way would be to estimate it from my noise configuration. The reason why I went the other way is that I had trouble to estimate h_alpha from my noise configuration. The approach described in [2] generates white noise, and filters it to get the required PSD shape. The relationship between the standard variance Qd of the white input noise and the scaling factor h_alpha of the powerlaw noise is given in [2] as follows (equ 39): Qd = h_alpha / (2 * (2*pi)^alpha * tau_0^(alpha-1)) However, this definition never worked for me to predict the relationship between h_alpha and Qd. I think the formula should be modified as Qd = h_alpha / (2 * (2*pi)^alpha * tau_0^(alpha+1)) I changed the sign of the 1 in the exponent of tau_0. Using this change, the formula now works for calculating h_alpha and Qd from each other, and the results match if I do a counter-check and estimage h_alpha from the AVAR or the PSD. This change also makes the formula more consistent (e.g. the AVAR is defined so that the standard variance of White FM noise should match the AVAR for tau_0, this holds with the modified formula). --- 3) PSD estimation --- I tried to implement the PSD estimation as a mixture of the information found in [3] and [4]. However, I'm a novice when it comes to PSDs, and my approach had some error (I still don't know exactly what was wrong). As I know now, the 3dB difference that I saw for RW noise in my initial mail is a bug in my clumsy implementation. I tried to learn more about PSDs, and [5] proved to be very useful. I know now that the PSD estimation approach that I tried to use is known as the 'Welch's method' and supported in Matlab as 'pwelch'. -- Using this tool the PSD estimate converges to the expected value for all 5 types of noise! :) As PSD estimation configuration I use non-overlapping segments with a Hann window. There is no deeper reason for this choice (as I said, I'm new to these topics, so I would'nt know any better), it's just what is used in the example in [5] and it provides a PSD estimate as I would expect it. --- 4) All summed up --- With the assumptions and concepts of 1-3 I have finally been able to generate powerlaw noise in a way that the results match what I had configured :) I tried once more to generate the 5 noise types, and compare them with my expectations. I have included the resulting plots in a PDF file, which is available here: https://www.dropbox.com/s/lrdbpxrghkca0y8/Relationship_PSD_AVAR.pdf?dl=0 However, I also found new things that confuse me :P When I try to estimate the PSD with the 'pwelch' function in Matlab, I can select the number of non-overlapping segments my raw data should be divided into. Using a larger number of segments leads to a nicer plot, which converges to clean lines at some point. However, I also see that the lower part
Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi as NTP servers
On Sun, 22 Mar 2015 14:14:01 - David J Taylor david-tay...@blueyonder.co.uk wrote: Yes, my posting was at least in part for help with resolving the much higher CPU load seen on a default BBB installation than on an RPi setup. If you could provide a list of services and cron jobs to be disabled, and a brief guide to doing so (as I'm a beginner with Linux) that would be appreciated. Sorry, I cannot. I don't have a BBB to test the image and tell you what it runs. But i can at least guide you trough the steps to figure out what's going on. If you run `ps aux` you will get a list of what processes are active. This is the low level view. The high level view is aquired using `systemctl list-units` You can stop the units you don't need using `systemctl stop name` You can find more information on how to deal with systemd on https://wiki.archlinux.org/index.php/systemd Do not get confused by this being an Arch Linux wiki, it applies to Debian as well. BTW: As Graham wrote Debian is in kind of a transition, though nobody has really decided where it will be going (there are too many people who opose the systemd switch). But unlike what he wrote, there is no mix of init systems. It's either systemd, or it isn't. You cannot have both at the same time. The default image of BBB runs systemd. The second place where to look at are your cron jobs. They can be found in: /etc/crontab /etc/cron.d /etc/cron.hourly /var/spool/cron/crontabs/ The first one (/etc/crontab) is the system wide, old school table that contains all jobs. On a regular debian system, you should have only 4 entries, the monthly, weekly, daily and hourly job scripts. If you have only these, don't touch it. They are necessary. The second one (/etc/cron.d/) is a directory that contains files of the same format as /etc/crontab for specific installed packages. Edit them as you whish (but know what you are doing ;-). The third (/etc/cron.hourly) contains shell scripts that are run once per hour. They are most likely necessary, but might not be. If you don't want/need them, it's best to uninstall the package that they came with. The last one is one (/var/spool/cron/crontabs/) is one you shouldn't touch by hand. These are the files stored by the crontab command, for the respective user. If you need to disable/edit those, use the crontab command. BTW: i reccomend you getting a book on linux. Dealing with embedded devices you will need a good understanding of the inner workings of linux to effectively deal with them. I have heard good things about linux for dummies but i have never read it myself. I had looked at [1] but I'm not using his special timer setup, just GPIO pins. Unfortunately he doesn't quote any of the usual NTP parameters with which to compare. Yes. But it gives an idea how stable the oscillator is. You have large deviations of over 10us, which contradict the number Dan Drown is getting. HTH Attila Kinali -- _av500_ phd is easy _av500_ getting dsl is hard ___ 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] Some observations of the BG7T BL GPSDO
Hi, 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. Curious, but I'm wondering whether there are any artefacts that might have been caused by the weak GPS signal? I would feel more comfortable if the unit had its planned strong GPS signal throughout the test. I know it's meant to cope with that, but it might have thrown up an obscure software bug. Exactly how that might have nudged the frequency off I can't figure. Alan ___ 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] AVAR - S_Y conversion
Hello Magnus, I'm sorry, but I can't follow you here. I know that time deviation values and fractional frequency values are related via integration, so I think I understand the third line. But I don't know what is meant especially with the first one: What is d(t)? What is D? Is this the frequency drift? - Wolfgang On 03/14/2015 11:12 AM, Magnus Danielson wrote: Wolfgang, Remember to scale the double-integral right: d(t) = D y(t) = integrate(d(t),t) = y_0 + Dt x(t) = integrate(y(t),t) = x_0 + y_0*t + D/2*t^2 Did you miss the 1/2 factor somewhere? That would make sense for the Random Walk phase noise. Cheers, Magnus On 03/09/2015 04:57 PM, Wolfgang Wallner wrote: On 03/06/2015 10:29 PM, Magnus Danielson wrote: I have checked several sources, and they match up with the IEEE 1139 in this regard. I have also evaluated the equation for Allan variance for the random walk noise, and it matches up with the references and what I put here: https://en.wikipedia.org/wiki/Allan_variance#Power-law_noise Thanks a lot for your effort! So, the A formula you have matches up. You will need to find another source of the mismatch. I will take a step back and describe the overall picture of what I'm doing. Maybe someone can help me spot where I do something wrong. (As stated later, the part where I'm quite unsure what I'm doing is the PSD estimation part.) My main goal is to simulate powerlaw noise. I then analyze the generated noise to check if my simulation is reasonable. So the basic workflow would be the following: 1) Generate noise 2) Analyze the noise in the time and frequency domain 3) See that everything agrees and be happy :) Step 1: Noise generation --- I generate powerlaw noise with the method described by Kasdin and Walter in [1]. So basically I generate white noise and apply a filter as described in [1] to get a PSD shape corresponding to the different values of alpha. The part of the PSD that will have the correct shape depends on the filter length and the simulated sampling frequency. Basically: the length of a simulation I would like to carry out specifies a lower bound on the filter length to get correct results. For WPM, WFM and RW noise I can use a shortcut: for these types of noise the filter coefficients are basically a discrete derivative, an identity filter and a cumulative sum. This is expected, as it agrees with [2], which states that integration of powerlaw noise decreases alpha by 2 (chapter 3.4 in [2]). Thus for even values of alpha I can even skip the expensive convolution to apply the filter and implement the filters directly. As input white noise I use a Gaussian distribution, mainly because that is what is used in the original paper. (I have also found another implementation [3] that optionally provides a uniform distribution). I'm quite confident that the noise generation part works as expected. However, even if I do something wrong here, it should not influence the analyzing part. Step 2: Analyzing noise --- 2.1 Time domain To analyze powerlaw noise in the time domain, I use a Matlab script called 'allan' [4], which calculates the Allan Deviation. I also found another Matlab tool called 'Stability Analyzer' [5], which can also calculate ADEV values. These two tools are developed by different authors and expect different input formats, but their results agree for any noise example I have tried so far. Thus I would say both of them can be trusted to work as expected. 2.2 Frequency domain IEEE 1139[6] defines S_y as: frequency spectrum Sy(f): One-sided spectral density of the normalized frequency fluctuations, as defined in normalized frequency fluctuations y(t). However, I'm not sure how to calculate this measure for a given noise sample. Anything I describe below is just based on 'I think this might work'. If anyone knows a better way of calculating S_y, or tools that can be used for this task, I would be glad to hear about it :) As already stated in the earlier mail I use the method described in [7] to estimate the one-sided PSD of my noise data in FFD format. These plots are quite noisy, and to improve the graphical presentation I use the averaging method described in [8]. I split the noise vector in parts of equal length, calculate the individual PSDs and average over them. Using this averaging method, the PSD plots converge to lines on a log-log plot with the expected slopes. I have an example figure attached to the mail that shows the effect of the averaging (PSD_Average.png). Step 3: Comparing time and frequency domain results --- At this point I have plots for both the Allan Deviation and the FFD-PSD, and would like to compare them. As first step I estimate h_alpha from the Allan Deviation plot
Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers
David: On this page: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29 they list an alternative console only image: https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz It might be easier starting with that if you don't intend to use graphics. Mike Thanks for that, Mike. It takes quite some time to set up the BBB so if possible I would prefer to disable unnecessary programs and services. 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.
Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers
On Sun, 22 Mar 2015 09:29:56 -0400 Mike George mgeo...@tuffmail.us wrote: On this page: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29 they list an alternative console only image: https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz It might be easier starting with that if you don't intend to use graphics. Alternatively, use an embedded buildsystem (e.g. buildroot[1]) so that the image contains only what is really required, and nothing else. There are also several, preconfigured buildroot forks for the BBB (e.g. [2]). If you need help with that, send me an email off-list. Attila Kinali [1] http://buildroot.net [2] https://github.com/fhunleth/buildroot-bbb -- _av500_ phd is easy _av500_ getting dsl is hard ___ 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] Harmonics suppression in ring oscillators
On Fri, 20 Mar 2015 21:26:44 -0700 Hal Murray hmur...@megapathdsl.net wrote: dmend...@gmail.com said: You mean in a coaxial cable in a loop? It would be very fun... more points if you use a directional coupler to put the pulse in the loop. Anyhow I doubt it would settle to 1 :) I was thinking of an amplifier in there someplace so the pulse wouldn't decay simply due to the cable loss. This is the description of how a delay line oscillator works. While it is similar to a ring oscillator, there are certain things that do not work exactly the same way. Rubiolas book[1, chapter 5] contains a nice description of delay line oscillators and their performance. Attila Kinali [1] Phase Noise and Frequency Stability in Oscillators, by Enrico Rubiola, 2008 -- _av500_ phd is easy _av500_ getting dsl is hard ___ 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
From: Attila Kinali Something is wrong here. I would expect the BBB to perform at least as well as the rpi (after all, the BBB has an ethernet MAC with IEEE1588 support, while the rpi is basically a glorified USB controller with attached graphics card). You are most likely running services on the BBB (network services, local services, cron jobs,...) that cause the high, and spikey cpu load, which in turn destroys your ntp performance. Also, compare your results to [1], where Dan Drown uses the capture/compare unit of the AM3359 to timestamp the PPS and use this for ntp. In [2] he tries to measure the temperature dependence of the BBB oscillator (not be best way, but...). Attila Kinali [1] http://blog.dan.drown.org/beaglebone-black-timer-capture-driver/ [2] http://blog.dan.drown.org/tcxo-beaglebone-black/ Attila, Yes, my posting was at least in part for help with resolving the much higher CPU load seen on a default BBB installation than on an RPi setup. If you could provide a list of services and cron jobs to be disabled, and a brief guide to doing so (as I'm a beginner with Linux) that would be appreciated. I had looked at [1] but I'm not using his special timer setup, just GPIO pins. Unfortunately he doesn't quote any of the usual NTP parameters with which to compare. I'm also measuring thing differently, in that I'm measuring from a remote rather than a local system, as that is what would happen when using the device as an NTP server. Thanks, 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.
Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi as NTP servers
I'm surprised you did not kill off those other tasks. Looks like you might be running a web server, building an index or something. Were the /etc/ntp.conf files the same on Pi and BBB? Test is not valid unless both computers are running the same things. On Sat, Mar 21, 2015 at 12:38 PM, Graham / KE9H ke9h.gra...@gmail.com wrote: 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. -- Chris Albertson Redondo Beach, California ___ 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
Was the website problem this past week? The main Tek US website was acting up for a while one day this week, but seems to be fine now. I have no insights on European access. -- Bill Byrom N5BB On Sun, Mar 22, 2015, at 07:10 AM, James via time-nuts wrote: Hi Bill, Thanks for the pointers. I should say that my results reported so far have been with my older TTi TF930 reciprocal counter, not with my FCA3100 which I have only just got (it arrived a few days ago) and I'm in the process of writing software to talk to it via the USB. I did discover the website, in fact I'd downloaded the manual before buying the counter, and it is fortunate I did because the website for me didn't work - I'm currently talking to Tek support about it. The problem is that to download software you must have your details registered. Every time I register my details and press the save button the site wipes all my details and returns to a blank form. When I try to down load the software it then stops me and tells me to update my details. I update my details and it blanks the form and so on... slightly frustrating. I've tried both Firefox and IE. The other thing is that the manuals don't show on the European site (I'm in the UK), you click on them but the download screen just shows a blank line. I got round this by going to the international site and just closing the screen asking me for my area rather than responding to it - I had to do this several times. I have now downloaded NI-VISA and have managed to do a bit of talking to the instrument over USB though I've not yet had time to do this properly. So in summary - I'm pleased with my counter but the Tek website for Europe at least has some serious bugs which hopefully will be fixed soon. The Tek support person I spoke to on the phone was helpful but she wasn't in a position to fix the web site issues directly so has forwarded my case to Tek IT. I intend repeating my TTi TF930 experiment with my FCA3100 when I've got everything working ok and am looking forward to seeing the results. James -Original Message- From: Bill Byrom t...@radio.sent.com To: time-nuts time-nuts@febo.com Sent: Sun, 22 Mar 2015 2:27 Subject: 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
Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers
I can confirm similar issues with each of my BBBs. They just can't seem to get the jitter down. I've tried a variety of combinations of Debian and Ubuntu, and even replaced the clock on one with an Si5338. On Sun, Mar 22, 2015 at 6:29 AM, Mike George mgeo...@tuffmail.us wrote: David: On this page: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW. 2FBBB_.28All_Revs.29 they list an alternative console only image: https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/ console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz It might be easier starting with that if you don't intend to use graphics. Mike On 3/22/2015 03:46, David J Taylor wrote: 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 = Graham, The download was: bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz (547,024,548 bytes) which was from the Recommended Debian Images from: http://beagleboard.org/latest-images. Perhaps there are some services or background tasks I can disable to reduce the CPU steady load from its present 16% average level? 73, David GM8ARV ___ 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] Comparing the BeagleBone Black Raspberry Pi as NTP servers
One of those services is likely the full blown web server that runs on the BBB to allow you to view the help pages. -Chuck Harris Attila Kinali wrote: On Sat, 21 Mar 2015 16:23:30 - David J Taylor david-tay...@blueyonder.co.uk wrote: 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! Something is wrong here. I would expect the BBB to perform at least as well as the rpi (after all, the BBB has an ethernet MAC with IEEE1588 support, while the rpi is basically a glorified USB controller with attached graphics card). You are most likely running services on the BBB (network services, local services, cron jobs,...) that cause the high, and spikey cpu load, which in turn destroys your ntp performance. Also, compare your results to [1], where Dan Drown uses the capture/compare unit of the AM3359 to timestamp the PPS and use this for ntp. In [2] he tries to measure the temperature dependence of the BBB oscillator (not be best way, but...). Attila Kinali [1] http://blog.dan.drown.org/beaglebone-black-timer-capture-driver/ [2] http://blog.dan.drown.org/tcxo-beaglebone-black/ ___ 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 asNTP servers
David: If you are running headless, that is, not using the on board video-graphics system, all interaction with the unit is via the console, local or SSH. In this case, I would use the console version as described above. It is about one tenth the size of the version you are using. You will need to install ntp, and disable whatever time system is already present. As well as any time and logging services that you do not use, that you can find. Debian is in transition from using a services management system called init to a new system called systemd or system daemon. Debian 7.8 you are using is a mixture of both. By Debian 8 (jessie) the transition will be complete and is an almost pure systemd environment that will give you a centralized location and command set to view and turn on/off all services, including the recurring time-based ones. Jessie is in test currently, and should be released in the next few months. It is the OS for the new Beaglebone X-15 due out mid-year. They have not yet released a console version, but it real close. The other thing that will help is getting rid of the cape-manager system you are using, that is file i/o based. There is a lot of file scanning going on that is not useful in time critical applications. --- Graham == On Sun, Mar 22, 2015 at 8:29 AM, Mike George mgeo...@tuffmail.us wrote: David: On this page: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW. 2FBBB_.28All_Revs.29 they list an alternative console only image: https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/ console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz It might be easier starting with that if you don't intend to use graphics. Mike On 3/22/2015 03:46, David J Taylor wrote: 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 = Graham, The download was: bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz (547,024,548 bytes) which was from the Recommended Debian Images from: http://beagleboard.org/latest-images. Perhaps there are some services or background tasks I can disable to reduce the CPU steady load from its present 16% average level? 73, David GM8ARV ___ 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] Comparing the BeagleBone Black Raspberry Pi asNTP servers
David: On this page: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29 they list an alternative console only image: https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/console/bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz It might be easier starting with that if you don't intend to use graphics. Mike On reflection, Mike Attila, even though it may be more effort, I will give that a try. 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.
Re: [time-nuts] Harmonics suppression in ring oscillators
On Tue, 17 Mar 2015 11:28:59 +0100 Attila Kinali att...@kinali.ch wrote: So, how do people keep ring oscillators from oscillating at higher modes? So far, my google skills have failed me to turn up any answer. Ok, sofar i've dug up two papers (and a comment on one) that explicitly deal with harmonics generation in ring oscillators. One is by Sasaki [1] and quite old the other is current enough that it seems applicable today. Sasaki[1] argues, that process variations between transistors will prevent harmonics in small rings (see also comments in [2]), but cannot be prevented reliably in large rings. Bushan and Ketchen[3] on the other hand say nothing about harmonics in long or short rings, but say that the proper startup sequence will inject only a single edge into the ring. Attila Kinali [1] Higher Harmonic Generation in CMOS/SOS Ring Oscillators, by Nobuo Sasaki, 1982 http://dx.doi.org/10.1109/T-ED.1982.20696 [2] Comments on 'Higher harmonic generation in CMOS/SOS ring oscillators', by T.W. Huston, 1983 http://dx.doi.org/10.1109/T-ED.1983.21244 [3] Generation, Elimination and Utilization of Harmonics in Ring Oscillators, by Manjul Bushan, Mark B. Ketchen, 2010 http://dx.doi.org/10.1109/ICMTS.2010.5466847 -- _av500_ phd is easy _av500_ getting dsl is hard ___ 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] Measuring on my Racal 9480 with OCXO 40 10Mhz outputs - (8x 5 chan)
Hi, On 03/21/2015 10:22 AM, cfo wrote: 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 ?? Grab data using TimeLab, running time-inteval mode. Use either a PPS or a 10 MHz with PPS trigger from a GPSDO as reference. Start of with a 1 hour measurement. When that works, go for a few days. 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] 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.
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 CR 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 lmeste...@gmail.com 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] Comparing the BeagleBone Black Raspberry Pi asNTP servers
What kernel do you use? And what scheduling configuration? As it is a timing application, and sensible to jitter, I would suggest to use a real-time kernel (e.g. Preempt RT) [1]. Usually one can find pre-built kernels with PreempRT-support for boards like the RPi etc. on the internet. If you use a real-time kernel, and have it configured that your application of choice (in this case ntp) has real-time priority, the 16% cpu usage won't be a problem any more. Other workloads like IRQs or task scheduling may have much worse effects on application jitter (even on real-time systems). Interestingly, more CPU usage can even be better for jitter-sensitive applications: low cpu usage might enable power-saving functions, which in turn might lead to longer reaction times once an application needs to be handled. regards, Wolfgang [1] https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html On 03/22/2015 08:46 AM, David J Taylor wrote: 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 = Graham, The download was: bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz (547,024,548 bytes) which was from the Recommended Debian Images from: http://beagleboard.org/latest-images. Perhaps there are some services or background tasks I can disable to reduce the CPU steady load from its present 16% average level? 73, David GM8ARV ___ 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
On Sat, Mar 21, 2015 at 12:23 PM, David J Taylor
david-tay...@blueyonder.co.uk wrote:
I've just put up my first draft of a comparison of these two popular
devices as NTP servers:
Comments welcomed - I know it's an imperfect test!
...
Perhaps there are some services or background tasks I can disable to reduce
the CPU steady load from its present 16% average level?
There's not enough background to offer good advice but here's some okay
points:
1) Did you start out using the attached patch antenna? D Drown implies
successfully using the patch on the Adafruit until it was soldered in
place. He fixed that by switching to an external antenna. I've never had
any success with attached patch antennas but my receivers are inside.
2) I've attached the output of pstree for my NTP BBB. That machine is
typically 97% idle (load average 0 to .005) unless I run the PPS blinker
which is written in Python. It is running the heartbeat blinker that
sleeps almost all the time.
3) I run R. C. Nelson's builds of Ubuntu (Server) which do start Apache by
default but it's easy to turn off.
4) I don't understand the section labelled The view from afar. You say
you're measuring two machines but there are many lines of output. Perhaps
you could discard the data that's not related to the machines under test.
Compared to my primary clock via peerstats:
BBB mean offset 7.8e-6, mean jitter 7.0e-6
RPi mean offset 7.1e-5, mean jitter 5.3e-5
init-+-acpid
|-avahi-daemon---avahi-daemon
|-cron
|-dbus-daemon
|-dhclient
|-7*[getty]
|-hb.py
|-ntpd-428p1
|-rpc.idmapd
|-rpc.statd
|-rpcbind
|-rsyslogd---3*[{rsyslogd}]
|-sshd-+-sshd---bash
| `-sshd---bash---pstree
|-systemd-logind
|-systemd-udevd---6*[systemd-udevd]
|-udhcpd
|-upstart-file-br
|-upstart-socket-
`-upstart-udev-br
___
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] Some observations of the BG7T BL GPSDO
Hi John, Doesn't that have a NEO-6M in it rather than a timing receiver? Bob From: John Miles j...@miles.io To: 'Discussion of precise time and frequency measurement' time-nuts@febo.com Sent: Sunday, March 22, 2015 5:49 PM Subject: Re: [time-nuts] Some observations of the BG7T BL GPSDO Curious, but I'm wondering whether there are any artefacts that might have been caused by the weak GPS signal? I would feel more comfortable if the unit had its planned strong GPS signal throughout the test. I know it's meant to cope with that, but it might have thrown up an obscure software bug. Exactly how that might have nudged the frequency off I can't figure. I will say that when the Thunderbolt went into holdover, the BG7TBL unit barely twitched (see http://www.ke5fx.com/gpscomp/holdover.png ). In fact, this was the only time its frequency error went positive for a significant period. It's likely that many/most newer GPSDOs have better receivers than the Thunderbolt. If the BG7TBL unit had been less consistently off-frequency, I'd be more inclined to agree that test wasn't fair due to the weak signal. Another area of concern is that I don't know how the unit manages its self-survey process. If it still thinks it's in China, then it obviously isn't going to perform at its best. Ideally it would recognize that it's been moved since the last powerup, but I can't be sure about that, not having any software or documentation for its serial port... -- 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. ___ 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.
