Re: [time-nuts] Synchronization

[Bob kb8tq]

Hi

On a traditional RPi, many things go over the USB. The ethernet interface 
connects via USB. On some, the WiFi also connects over USB. It all necks 
down into a very narrow “pipe”. 

Bob

> On Dec 5, 2019, at 3:21 PM, Anton Strydom  wrote:
> 
> HI Bob
> 
> I do not require timing on the USB at all
> 
> 
> On Thu, Dec 5, 2019 at 6:00 PM Bob kb8tq  wrote:
> 
>> Hi
>> 
>> One timing issue could be that USB is not that great for timing. Since it
>> is
>> packet based it introduces jitter in the link. Running NTP on a
>> “traditional”
>> RPi is unlikely to produce numbers below a milisecond.
>> 
>> Indeed I’m digging into that for what I’m working on …..
>> 
>> Bob
>> 
>>> On Dec 5, 2019, at 12:09 AM, Anton Strydom  wrote:
>>> 
>>> Good day Hal
>>> 
>>> Thank you for your contribution
>>> 
>>> The physical setup is as follows, each Rp1 has 2 or more cameras attached
>>> to it via a multiplexer or usb depending on the camera, there are a
>> number
>>> of V2 RPi and also a couple of USB cameras attached to some of the RPi's.
>>> All the equipment is powered by solar
>>> 
>>> I will be able to run cable but it is going to be difficult plus the
>>> possibility that the cables and equipment attached to it will be stolen
>> is
>>> 100% hence the WiFi
>>> 
>>> Yours sincerely
>>> 
>>> Anton
>>> 
>>> 
>>> 
>>> On Thu, Dec 5, 2019 at 3:01 AM Hal Murray 
>> wrote:
>>> 
 
 agstry...@gmail.com said:
> The cameras are pairs sitting on a multiplexer so the problem is not
>> the
> camera pair synchronization but the RPi synchronization
 
 I don't understand the physical setup.  Is it possible to run a cable to
 wherever you need good time?
 
 Even if that isn't practical in the long run, it might be useful for
 experimenting.
 
 
 --
 These are my opinions.  I hate spam.
 
 
 
 
 ___
 time-nuts mailing list -- time-nuts@lists.febo.com
 To unsubscribe, go to
 http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
 and follow the instructions there.
 
>>> ___
>>> time-nuts mailing list -- time-nuts@lists.febo.com
>>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>>> and follow the instructions there.
>> 
>> 
>> ___
>> time-nuts mailing list -- time-nuts@lists.febo.com
>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[Bob kb8tq]

Hi

If you are moving blocks of data ( = pictures / video ) out over the same basic
USB interface. I suspect you will get into blocking issues. That sort of thing 
will
make the basic “frame rate” stuff a bit less important. I have that same 
“gotcha” 
in what I’m doing. The network will be a bit busy while I’m also trying to sent 
time.

Bob

> On Dec 5, 2019, at 2:21 PM, jimlux  wrote:
> 
> On 12/5/19 5:16 AM, Bob kb8tq wrote:
>> Hi
>> One timing issue could be that USB is not that great for timing. Since it is
>> packet based it introduces jitter in the link. Running NTP on a “traditional”
>> RPi is unlikely to produce numbers below a milisecond.
> 
> 
> USB only guarantees 125 microsecond timing (8kHz) - that's the basic "frame 
> rate" for isochronous channels, and was designed years ago to make it 
> possible to do telephone quality audio in real time.
> 
> It might well be that USB 2 and USB 3 have shortened the timing windows as 
> well as increasing the speed, but I wouldn't be counting on it.  One might 
> also have specific USB implementations that are better, but you're depending 
> on a "feature" of the chip, not part of the spec.  I did see a mention on 
> wikipedia about some interrupt latency of about 1 microsecond in high speed 
> transfers, which is substantially better than the 125 microsecond frame 
> timing.
> 
> There are people who claim to have low uncertainty USB timing. Fierce 
> electronics was one I found using google, but they appear to use custom USB 
> hubs.
> 
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[Anton Strydom]

HI Bob

I do not require timing on the USB at all


On Thu, Dec 5, 2019 at 6:00 PM Bob kb8tq  wrote:

> Hi
>
> One timing issue could be that USB is not that great for timing. Since it
> is
> packet based it introduces jitter in the link. Running NTP on a
> “traditional”
> RPi is unlikely to produce numbers below a milisecond.
>
> Indeed I’m digging into that for what I’m working on …..
>
> Bob
>
> > On Dec 5, 2019, at 12:09 AM, Anton Strydom  wrote:
> >
> > Good day Hal
> >
> > Thank you for your contribution
> >
> > The physical setup is as follows, each Rp1 has 2 or more cameras attached
> > to it via a multiplexer or usb depending on the camera, there are a
> number
> > of V2 RPi and also a couple of USB cameras attached to some of the RPi's.
> > All the equipment is powered by solar
> >
> > I will be able to run cable but it is going to be difficult plus the
> > possibility that the cables and equipment attached to it will be stolen
> is
> > 100% hence the WiFi
> >
> > Yours sincerely
> >
> > Anton
> >
> >
> >
> > On Thu, Dec 5, 2019 at 3:01 AM Hal Murray 
> wrote:
> >
> >>
> >> agstry...@gmail.com said:
> >>> The cameras are pairs sitting on a multiplexer so the problem is not
> the
> >>> camera pair synchronization but the RPi synchronization
> >>
> >> I don't understand the physical setup.  Is it possible to run a cable to
> >> wherever you need good time?
> >>
> >> Even if that isn't practical in the long run, it might be useful for
> >> experimenting.
> >>
> >>
> >> --
> >> These are my opinions.  I hate spam.
> >>
> >>
> >>
> >>
> >> ___
> >> time-nuts mailing list -- time-nuts@lists.febo.com
> >> To unsubscribe, go to
> >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> >> and follow the instructions there.
> >>
> > ___
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[James C Cotton]

>I'd like to test with the Raspberry Pi 4B which avoids USB in its gigabit
>Ethernet port path.
>
>Cheers,
>David

As a network engineer at a university I can tell you that you are just trading 
one set of unknowns for a different and possibly larger set.

When you go from "n devices on the same switch" toward "other side of the 
state" the unknowns multiply.  With that said, hopefully the ethernet connection
will give you better numbers than the USB interfaces.

Best of luck.

Jim


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[jimlux]

On 12/5/19 5:16 AM, Bob kb8tq wrote:

Hi

One timing issue could be that USB is not that great for timing. Since it is
packet based it introduces jitter in the link. Running NTP on a “traditional”
RPi is unlikely to produce numbers below a milisecond.



USB only guarantees 125 microsecond timing (8kHz) - that's the basic 
"frame rate" for isochronous channels, and was designed years ago to 
make it possible to do telephone quality audio in real time.


It might well be that USB 2 and USB 3 have shortened the timing windows 
as well as increasing the speed, but I wouldn't be counting on it.  One 
might also have specific USB implementations that are better, but you're 
depending on a "feature" of the chip, not part of the spec.  I did see a 
mention on wikipedia about some interrupt latency of about 1 microsecond 
in high speed transfers, which is substantially better than the 125 
microsecond frame timing.


There are people who claim to have low uncertainty USB timing. Fierce 
electronics was one I found using google, but they appear to use custom 
USB hubs.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Quartz oscillator slow drift/aging

[Bob kb8tq]

Hi

Yikes 

That should read “expected on an OCXO” !!!

Sorry !!!

Bob

> On Dec 5, 2019, at 8:05 AM, Bob kb8tq  wrote:
> 
> Hi
> 
> That’s unexpected on an OCXO that may have been power off for a 
> decade or more. Let it run for a month and see how it’s doing then.
> 
> Bob
> 
>> On Dec 2, 2019, at 2:30 PM, AC0XU (Jim)  wrote:
>> 
>> Time Gurus-
>> 
>> I have a FPS 1150A quartz oscillator with the 1 PPS disciplining option. 
>> With the frequency control set to "manual" I can use the digital thumbwheel 
>> control to set 10 MHz correctly. However, for two weeks there has been a 
>> steady drift upwards of about 2E-10 per day. I have not seen this behavior 
>> in other similar oscillators - the magnitude of the drift seems greater than 
>> expected. Any ideas what could be happening?  I have no idea how long the 
>> unit was unpowered before I got it - it needed repairs - it may have been 
>> years. Is this normal? Should I  expect the drift to decrease over time? Etc?
>> 
>> Thanks!
>> 
>> Jim
>> 
>> 
>> ___
>> time-nuts mailing list -- time-nuts@lists.febo.com
>> To unsubscribe, go to 
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
> 


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Quartz oscillator slow drift/aging

[Majdi S. Abbas]

On Mon, Dec 02, 2019 at 12:30:44PM -0700, AC0XU (Jim) wrote:
> I have a FPS 1150A quartz oscillator with the 1 PPS disciplining 
> option. With the frequency control set to "manual" I can use the digital 
> thumbwheel control to set 10 MHz correctly. However, for two weeks there 
> has been a steady drift upwards of about 2E-10 per day. I have not seen 
> this behavior in other similar oscillators - the magnitude of the drift 
> seems greater than expected. Any ideas what could be happening?  I have no
> idea how long the unit was unpowered before I got it - it needed repairs - 
> it may have been years. Is this normal? Should I  expect the drift to 
> decrease over time? Etc?

Crystal oscillators will retrace their old aging curve pretty
quickly when switched back on.  Run it for a few more weeks and then
evaluate it.

4-6 weeks is a typical figure.

--msa

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[David J Taylor via time-nuts]

From: Bob kb8tq

Hi

One timing issue could be that USB is not that great for timing. Since it is
packet based it introduces jitter in the link. Running NTP on a 
“traditional”

RPi is unlikely to produce numbers below a milisecond.

Indeed I’m digging into that for what I’m working on …..

Bob


For those interested, some time ago I made some measurements:

 https://www.satsignal.eu/ntp/BBB-vs-RPi.html

I'd like to test with the Raspberry Pi 4B which avoids USB in its gigabit 
Ethernet port path.


Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 



___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[Bob kb8tq]

Hi

One timing issue could be that USB is not that great for timing. Since it is 
packet based it introduces jitter in the link. Running NTP on a “traditional”
RPi is unlikely to produce numbers below a milisecond. 

Indeed I’m digging into that for what I’m working on …..

Bob

> On Dec 5, 2019, at 12:09 AM, Anton Strydom  wrote:
> 
> Good day Hal
> 
> Thank you for your contribution
> 
> The physical setup is as follows, each Rp1 has 2 or more cameras attached
> to it via a multiplexer or usb depending on the camera, there are a number
> of V2 RPi and also a couple of USB cameras attached to some of the RPi's.
> All the equipment is powered by solar
> 
> I will be able to run cable but it is going to be difficult plus the
> possibility that the cables and equipment attached to it will be stolen is
> 100% hence the WiFi
> 
> Yours sincerely
> 
> Anton
> 
> 
> 
> On Thu, Dec 5, 2019 at 3:01 AM Hal Murray  wrote:
> 
>> 
>> agstry...@gmail.com said:
>>> The cameras are pairs sitting on a multiplexer so the problem is not the
>>> camera pair synchronization but the RPi synchronization
>> 
>> I don't understand the physical setup.  Is it possible to run a cable to
>> wherever you need good time?
>> 
>> Even if that isn't practical in the long run, it might be useful for
>> experimenting.
>> 
>> 
>> --
>> These are my opinions.  I hate spam.
>> 
>> 
>> 
>> 
>> ___
>> time-nuts mailing list -- time-nuts@lists.febo.com
>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] USB over optical fiber

[David Van Horn via time-nuts]

Ok, thanks for the info.  My unit should be arriving today or tomorrow.

--
David VanHorn
Lead Hardware Engineer

Backcountry Access, Inc.
2820 Wilderness Pl, Unit H
Boulder, CO  80301 USA
phone: 303-417-1345  x110
email: david.vanh...@backcountryaccess.com 

-Original Message-
From: Scott McGrath  
Sent: Wednesday, December 4, 2019 9:16 PM
To: Discussion of precise time and frequency measurement 

Cc: David Van Horn 
Subject: Re: [time-nuts] USB over optical fiber

You may still have a problem,  That said most of your noise power is going to 
come from your USB device itself and perhaps the power supply 

That said ive never really had a problem doing similar testing using small 
chambers from ETS-Lindgren and similar vendors using the Corning interface. 

That said i’d recommend you go a step up to the Newnex and similar devices they 
are 3x the price but the fiber interlink is just a standard fiber LC-LC patch 
cord.

With the low cost interface crimp its cable once accidentally you are buying a 
new one.

With the newnex you are buying a 20-30 dollar patch cord.

All that said performance is the same in the end but the newnex and similar 
have an advantage in an open lab.   For permanent installation in raceway the 
cost advantage is with the one piece units.

Content by Scott
Typos by Siri

> On Dec 4, 2019, at 10:07 PM, Davida  Van Horn via time-nuts 
>  wrote:
> 

I'm not too worried up there, my receivers are working at 457 kHz. 

-Original Message-
From: Scott McGrath 
Sent: Wednesday, December 4, 2019 12:14 AM
To: Discussion of precise time and frequency measurement 

Cc: David Van Horn 
Subject: Re: [time-nuts] USB over optical fiber

Its not so much the noise from the interface its the USB device itself i’d 
worry about as USB 3.0 generates RF signals up to 3 GHz.   And also has fairly 
strong signals in the 2.4 GHz ISM band.

Content by Scott
Typos by Siri

> On Dec 4, 2019, at 12:07 AM, David Van Horn via time-nuts 
>  wrote:
> 

I suppose this is vaguely time-nutty. 😊

I have an application where I need to take USB into an EMC faraday cage.
I see a number of optical fiber implementations available, and the prices 
($200-300) are acceptable, but I’m worried about noise that the downstream end 
may cause, since it will need to be inside the cage.

Does anyone have experience with these?  Ones to stay away from?



--
David VanHorn
Lead Hardware Engineer

Backcountry Access, Inc.
2820 Wilderness Pl, Unit H
Boulder, CO  80301 USA
phone: 303-417-1345  x110
email: 
david.vanh...@backcountryaccess.com

___
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Trimble Tbolt temperature

[Bob kb8tq]

Hi

Since the DAC / reference is the main source of error, placing the sensor
a bit away from the OCXO makes sense. You also don’t want to watch the 
OCXO heat the board. You want data on the outside temperature. 

Since it’s all buried away in a Khalman filter, even the people who designed
it were unable to be 100% sure of what exactly it was doing. ( I paid for 
lunch to find that out ….it was back in the late 1990’s so lunch was cheap) 

Bob

> On Dec 4, 2019, at 10:58 PM, Didier Juges  wrote:
> 
> Maybe the Khalman  filter does not want to know the crystal temperature and
> is more interested in the ambient temperature which is better acquired away
> from the internals, i.e. in the corner of the board. The oven regulates the
> crystal temperature so if it does its job, there should not be too much
> variation to measure and the drift of the DAC and reference which I assume
> are outside the oven would not be compensated.
> 
> On Wed, Dec 4, 2019, 9:23 PM Charles Steinmetz 
> wrote:
> 
>> Tom wrote:
>> 
>>> Section 5.1.2 (Kalman Filtering) on page 5-4 (PDF page 48) says:
>>> 
>>> Oscillator performance is subject to two basic effects. First, changes
>>> in environmental temperature can cause the oscillator to speed up to
>>> slow down. Second, the oscillator has a natural tendency to drift over
>>> time. This is called aging.
>>> 
>>> Both temperature and aging can be mathematically predicted. However, the
>>> characteristics vary from crystal to crystal. The Kalman filtering
>>> monitors the unique oscillator performance over time and temperature and
>>> records this behavior.
>> 
>> The DS1620, perched way over in the corner of the board, cannot provide
>> useful crystal temperature data, even by inference.  That would need to
>> come from within the oven at the very least, more likely from inside the
>> crystal envelope itself using, e.g., an IR thermometer.
>> 
>> Instead, Kalman filters in GPSDOs track the oscillator frequency
>> continuously and do their best to separate the drift effects from the
>> temperature effects using software algorithms (note "mathematically
>> predicted" in the paragraph above).  You can see a hint of this by
>> monitoring the statistics from one of the older HP units like a Z3801.
>> 
>> Best regards,
>> 
>> Charles
>> 
>> 
>> 
>> ___
>> time-nuts mailing list -- time-nuts@lists.febo.com
>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Quartz oscillator slow drift/aging

[Bob kb8tq]

Hi

That’s unexpected on an OCXO that may have been power off for a 
decade or more. Let it run for a month and see how it’s doing then.

Bob

> On Dec 2, 2019, at 2:30 PM, AC0XU (Jim)  wrote:
> 
> Time Gurus-
> 
> I have a FPS 1150A quartz oscillator with the 1 PPS disciplining option. With 
> the frequency control set to "manual" I can use the digital thumbwheel 
> control to set 10 MHz correctly. However, for two weeks there has been a 
> steady drift upwards of about 2E-10 per day. I have not seen this behavior in 
> other similar oscillators - the magnitude of the drift seems greater than 
> expected. Any ideas what could be happening?  I have no idea how long the 
> unit was unpowered before I got it - it needed repairs - it may have been 
> years. Is this normal? Should I  expect the drift to decrease over time? Etc?
> 
> Thanks!
> 
> Jim
> 
> 
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] measuring currents on USB powered devices

[Adrian Godwin]

A problem with inline measurement is that a suitable sense resistance for
measuring runtime current (perhaps at a few hundred mA) is not sensitive
enough for standby current (uA), and if chosen as a useful value for
standby current it drops far too much voltage during full power running.

An approach I've used is to bypass the higher resistance with a diode, then
use the measurements from that sense resistor only up to about 0.5V. If
above that value then the voltage over a smaller inline resistor is used
instead (perhaps via a second scope channel or voltmeter). Autoranging
voltmeters won't usually re-range fast enough to give useful measurements
of short on-periods and a scope, despite its low resolution, is often more
appropriate for such transient measurements.

The resulting 0.6 - 0.7V diode drop at higher currents is still too much
loss from a nominal 5V (unless subsequently regulated down to 3V3), but is
within the range that can be compensated by a bench supply's voltage sense
terminals, so a good quality 5V or less can be maintained while still
getting high speed measurements and a wide range of sensitivity, if the
current sense network is placed at the power supply output and the voltage
sense connected at the load.

I'm not sure why the raspberry pi is so intolerant of 5V variation given
that it does regulate down to 3v3 and lower onboard : presumably there is
some part of the system  (other than the USB ports) that requires the full
5V. Perhaps the ethernet controller ?


On Thu, Dec 5, 2019 at 3:23 AM Bob Albert via time-nuts <
time-nuts@lists.febo.com> wrote:

>  Bill, I have elected to do just that.  I ordered a few USB female
> connectors with tiny pcb and a male-to-male cable.  I will put a
> milliammeter in the dc line.  My total cost around two dollars and I use my
> own test equipment.
> Bob
> On Wednesday, December 4, 2019, 05:01:20 PM PST, WB6BNQ <
> wb6...@cox.net> wrote:
>
>  Hi Jim,
>
>
> Whatever you do DO NOT bother with the el cheapo USB measuring devices.
> I bought a couple and I got to tell you they are, at best, a very crude
> indicator.  The calibration SUCKS big time.
>
>
> You would be better off using some USB breakout devices and use your own
> measurement system.
>
>
> BillWB6BNQ
>
>
> On 12/4/2019 8:56 AM, jimlux wrote:
> > Any recommendations or brickbats for devices that measure the power
> > drawn by USB powered devices.  I've been using a modified cable that
> > breaks out the red wire to run to a meter, but it would be nice to
> > have something that has a ADC and some sort of interface (USB?) that
> > would make it possible to log the power draw.
> >
> > I've got a bunch of wireless Beagleboards with GPS receivers and
> > RTL-SDR pods (to do phased array measurements) and I'm trying to come
> > up with better power information.
> >
> > (the recent WiFi NTP low power discussion prompts this).
> >
> > What would be great is if there were some USB "thru" pod that measured
> > this and reported the data over a USB interface (recognizing all sorts
> > of isolation issues that are possible), so I could plug the USB power
> > "to" the beagle board and the USB power to the RTL-SDR, and log them
> > both.
> >
> >
> > ___
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe, go to
> > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Lowest Power NTP Server

[Hal Murray]

kb...@n1k.org said:
> However  if the “broadcast” NTP approach was the method of choice, then a
> wake up and do it would work. for. the server. 

One of the disadvantages of broadcast is that you don't know what the round 
trip time is so you can't use that to filter out quirky cases.

If you get to the point where having the server go to sleep becomes important, 
you could have the server send a broadcast after it wakes up and is ready.  
The idea is to kick the clients, then have them do the normal client-server 
pair.  I don't know of any off-the-shelf NTP software with a hook to do that 
when poked.  It wouldn't be hard to add - there is a HUP catcher already.

-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Synchronization

[Anton Strydom]

Good day Hal

Thank you for your contribution

The physical setup is as follows, each Rp1 has 2 or more cameras attached
to it via a multiplexer or usb depending on the camera, there are a number
of V2 RPi and also a couple of USB cameras attached to some of the RPi's.
All the equipment is powered by solar

I will be able to run cable but it is going to be difficult plus the
possibility that the cables and equipment attached to it will be stolen is
100% hence the WiFi

Yours sincerely

Anton



On Thu, Dec 5, 2019 at 3:01 AM Hal Murray  wrote:

>
> agstry...@gmail.com said:
> > The cameras are pairs sitting on a multiplexer so the problem is not the
> > camera pair synchronization but the RPi synchronization
>
> I don't understand the physical setup.  Is it possible to run a cable to
> wherever you need good time?
>
> Even if that isn't practical in the long run, it might be useful for
> experimenting.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.