(similar to the ones below) to either confirm and/or help identify their isolated recordings. If you would prefer to see videos of the spectrograms playing as you listen to a recording we could arrange this option as well. I would have the students group recordings by a single habitat and location. If this interests you and you have the time to help, please email me directly at: laurie.doss@marvelwood.org These files, once confirmed, will be shared with the CT Bird Atlas Project and used in a Raven Exhibit based on the Macedonia Forest Block Important Bird Area that the kids are customizing. To learn more about what a Raven Exhibit is please follow this link: https://www.birds.cornell.edu/brp/raven-exhibit-2-0/ If these links do not work here, it might be because we have to share them to a single person which can be done if we have an individual's email. CERW_KLT_Skiff Mountain South Preserve June 2019 - Forest Gap https://drive.google.com/file/d/1npHrOLUKJppWzZki_3qZZ1ta87xGl4z5/view?usp=sharing AMCR and BWHA Skiff Mountain North Preserve June 2019 https://drive.google.com/file/d/1Qpq1tVn8vQ6m-5Ca4kLUciVxvenBVGkv/view?usp=sharing Unknown Softwoods (White Pine and Eastern Hemlock) May 2019 KLT Audrey and RobertTobin Preserve above Kent Falls https://drive.google.com/file/d/1__pkJl2t1kM0_QG5nQkKWC-ch_Jd471L/view?usp=sharing Thank you for your time and consideration. Sincerely, Laurie Doss -- Laurie Doss Science Department Chair The Marvelwood School 476 Skiff Mountain Road Kent, CT 06757 860-927-0047 860-927-1528 This message originates from The Marvelwood School. The information contained in this message may be privileged and confidential. If you are the intended recipient you must maintain this message in a secure and confidential manner. If you are not the intended recipient, please notify the sender immediately and destroy this message. Thank you. Important Notice: This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. https://www.facebook.com/marvelwood Like us on Facebook: https://www.facebook.com/marvelwood -- This message originates from The Marvelwood School. The information contained in this message may be privileged and confidential. If you are the intended recipient you must maintain this message in a secure and confidential manner. If you are not the intended recipient, please notify the sender immediately and destroy this message. Thank you.

p: 1) The timestamping facility is very obviously a "bolt-on" and as such the documentation was severely lacking. 2) The timestamping counter runs at the RX-clock rate. That means: a) You want something 10GE plugged into the port for max resolution. b) If you unplug it or it resets or reboots, your timescale jumps. c) You timescale is the Xtal at the /far/ end of the cable. This can probably all be mitigated with a loop-back, but then you cannot timestamp packets. 3) To timestamp packets, they have to look "sufficiently" like certain PTP packets. This was not documented then, could be now. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

erface is to drive a RS-232 port’s Carrier Detect pin (pin 1 on DB-9) > > with the 1PPS signal > > > > back in the day when that tied directly to an interrupt with consistent > latency, that works pretty well. > > > These days, though, there's often USB hosts in the way, or some other > intermediate interfaces that increases the uncertainty in timing of > "when software does something" in response to "external event" > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

ere's often USB hosts in the way, or some other intermediate interfaces that increases the uncertainty in timing of "when software does something" in response to "external event"

nt to do right now. > I have read Dan Drown's blog post on using the APU2 to achieve this, and > while it's more or less exactly what I want to replicate, for now, there > are a few gaps I need to fill in - and you may be able to help me do so. I > don't have a PC Engines APU2 board yet, but I suspect I'll order one once I > have the software side of things ironed out, because I really like their > form factor. I'm currently testing an APU6b4 unit and made a small adaptor PCB that gets clicked into the Mini-PCIE slot and touches to the main pcb via some pogo-pins: No soldering on the main apu board. If you are interested, I can send you the gerber-files and BOM. It should also fit the apu3-series (and possibly yours, too) and allows convenient SMA-access through the front panel to the SDP pins of two of the NICs. > What I'm using right now is a Portwell NANO-6050[1], and it has i210 and > i218 NICs. The SDP pins on the i210 aren't broken out into nice pads like > the APU2 has, but with some magnet wire and a steady hand I was able to > connect directly to one of the pins. Where I am struggling right now is > ironing out the software configuration side of things. I'm not interested > at all in PTP yet, right now the focus is purely on feeding the PPS into > chrony via the SDP pins. > The GNSS I'm using is a Sparkfun uBlox NEO-M9N > GNSS receiver in its default configuration, connected to the computer over > USB. PPS pin connected to the i210's SDP0. PPS pulse is 3v3 for 100ms. That should work fine. > I have tried using refclock strings from chrony's examples page[2] as a > jumping-off point, but it doesn't make much sense to me. To me it seems that chrony is just using the timestamps on the PHC of that network interface and not actually locking the PHC to the PPS input. As I wanted to verify that the lock is working, and maybe later use the PHC also for PTP, I also wanted the PHC to follow the external time, and running both chrony and phc2sys to make the phc follow system time ended in chaos. Therefore it seems that a two-step approach works better: First I make sure that using ts2phc the PHC is locked to the 100ms-1PPS input on SDP0: # ----------[contents of /etc/linuxptp/ts2phc.conf]------------------------- # run with ts2phc -c eth3 -s generic -l 7 -f /etc/linuxptp/ts2phc.conf -m -q [global] use_syslog 0 verbose 1 logging_level 6 ts2phc.pulsewidth 100000000 max_frequency 1000000 step_threshold 0.05 [eth3] ts2phc.channel 0 ts2phc.extts_polarity both ts2phc.pin_index 0 ts2phc.extts_correction -32 For this to start up properly, you need to make sure the clocks are roughly correct, i.e. you need to set your system time (e.g. with ntpdate, ntp, chrony) and then sync your PHC to system time by letting # Locking the PHC of eth3 (ptp3) to CLOCK_REALTIME phc2sys -c eth3 -s CLOCK_REALTIME -O +37 -m -q run for a few seconds. If you also output the PHC timer on SDP1 by testptp -d /dev/ptp3 -L1,2 -p 1000000000 you can see a falling edge right when SDP0 has a rising edge input with only a few nanoseconds jitter. (if anyone know how to invert the 1PPS output on i211 interfaces, let me know...) Sidenote: The interfaces /sys/class/ptp/* seem to be broken with my kernel. I can configure PPS output there, but every time I do that I get random frequencies for ~10 seconds before the output actually starts... When the PCH is locked to the 1PPS, I can have chrony use the PHC as clock input with this chrony.conf line: refclock PHC /dev/ptp3 tai refid PTP3 dpoll -4 poll -2 I do _not_ use the "extpps" option here, as ts2phc is already reading and consuming the time stamps. If there are two time-stamp readers, my chrony just hangs. > I have not been able to use the testptp tool on this system yet - building > it on another machine and running the copied-over executable fails, citing > too old a version of glibc, and when I try and build it locally it fails > for reasons that are unknown to me (I am very much not a C developer). Maybe try making a static library: gcc -static testptp.c -o testptp so that it has it's current glibc version linked in. > I am going to continue to fiddle with this - I think getting testptp working > such that I can verify that I'm actually getting a pulse on SDP0 is the > most important thing to confirm right now. The intel cards always give timestamp events on both pulse edges. The pulse-width and the roughly correct clock are necessary such that ts2phc can ignore the wrong pulse edge. From the source code it seems that ts2phc only considers edges falling within ±pulsewidth/2 around the expected time valid and discards the rest. So for a 100ms-1PPS pulse you should get the clock precise to 50ms before you start. As my pps is originally only µs long, I needed extra hardware to stretch it. The result: watch -n 0.5 'chronyc -m "sources -v" "sourcestats -v" "selectdata -v"' .-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current best, '+' = combined, '-' = not combined, | / 'x' = may be in error, '~' = too variable, '?' = unusable. || .- xxxx [ yyyy ] +/- zzzz || Reachability register (octal) -. | xxxx = adjusted offset, || Log2(Polling interval) --. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PTP3 0 -2 377 0 +2ns[ +2ns] +/- 195ns ^- sth1-ts.nts.netnod.se 1 8 377 83 -449us[ -450us] +/- 5331us ^- sth2-ts.nts.netnod.se 1 8 377 213 -461us[ -463us] +/- 5322us ^? ptbtime1.ptb.de 1 8 377 21 -46us[ -46us] +/- 5489us ^? ptbtime2.ptb.de 1 7 377 19 -60us[ -60us] +/- 5505us ^- polarx5tr.time.internal 1 8 377 147 -41us[ -43us] +/- 12ms .- Number of sample points in measurement set. / .- Number of residual runs with same sign. | / .- Length of measurement set (time). | | / .- Est. clock freq error (ppm). | | | / .- Est. error in freq. | | | | / .- Est. offset. | | | | | | On the -. | | | | | | samples. \ | | | | | | | Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== PTP3 9 7 2 +0.000 0.005 +0ns 2ns sth1-ts.nts.netnod.se 25 11 31m +0.060 0.044 -483us 28us sth2-ts.nts.netnod.se 22 10 29m +0.097 0.031 -419us 16us ptbtime1.ptb.de 25 12 32m +0.071 0.031 -43us 23us ptbtime2.ptb.de 21 5 23m +0.097 0.053 -5339ns 26us polarx5tr.time.internal 25 14 30m +0.038 0.153 -41us 104us .-- State: N - noselect, M - missing samples, d/D - large distance, / ~ - jittery, w/W - waits for others, T - not trusted, | x - falseticker, P - not preferred, U - waits for update, | S - stale, O - orphan, + - combined, * - best. | Effective options ------. (N - noselect, P - prefer | Configured options -. \ T - trust, R - require) | Auth. enabled (Y/N) -. \ \ Offset interval --. | | | | | S Name/IP Address Auth COpts EOpts Last Score Interval Leap ======================================================================= * PTP3 N ----- --TR- 0 1.0 -194ns +199ns N D sth1-ts.nts.netnod.se Y ----- --TR- 83 1.0 -5780us +4891us N D sth2-ts.nts.netnod.se Y ----- --TR- 213 1.0 -5769us +4888us N T ptbtime1.ptb.de N ----- ----- 20 1.0 -5515us +5458us N T ptbtime2.ptb.de N ----- ----- 19 1.0 -5564us +5448us N D polarx5tr.time.internal N --TR- --TR- 147 1.0 -12ms +11ms N Cheers, Jürgen

ad to some sort of logic level. The less time you have to do that, the happier > your driver IC (and regulator) are likely to be. > > One example of this would be the Trimble TBolt. It has a 10 us wide output pulse. Another > would be a uBlox LEA-6T (and the others in that lineup) with a default 10us wide output. > > > Bob Power dissipation, too. Fewer joules in a 10 microsecond pulse than in a 10 millisecond pulse.

at, the happier your driver IC (and regulator) are likely to be. One example of this would be the Trimble TBolt. It has a 10 us wide output pulse. Another would be a uBlox LEA-6T (and the others in that lineup) with a default 10us wide output. Bob > On Feb 1, 2023, at 5:02 PM, Matt Corallo via time-nuts wrote: > > > > On 2/1/23 10:38 AM, John Miller via time-nuts wrote: >> Hi Matt, > >> What I'm using right now is a Portwell NANO-6050[1], and it has i210 and i218 NICs. The SDP pins on the i210 aren't broken out into nice pads like the APU2 has, but with some magnet wire and a steady hand I was able to connect directly to one of the pins. Where I am struggling right now is ironing out the software configuration side of things. I'm not interested at all in PTP yet, right now the focus is purely on feeding the PPS into chrony via the SDP pins. The GNSS I'm using is a Sparkfun uBlox NEO-M9N GNSS receiver in its default configuration, connected to the computer over USB. PPS pin connected to the i210's SDP0. PPS pulse is 3v3 for 100ms. >> I have tried using refclock strings from chrony's examples page[2] as a jumping-off point, but it doesn't make much sense to me. > >> 16Hz PPS with a rate of 16 - why not use 1Hz with a default rate of 1? > > More samples can hide at least some of the noise. As Bob points out in his reply there's a limit, though, of course, the NEO-M9N datasheet says its time-pulse accuracy is 30ns RMS/60ns 99%. If your interrupt jitter is less than that, you're not gonna hide much :). > >> The Dan Drown blog post makes a little bit more sense, but I think something is missing from the 'relevant chrony.conf' example - notably, it includes a single refclock line with the "pps" option, which according to the chrony.conf docs[4]: "Another time source is needed to complete samples from the refclock." and that example isn't included. > > A PPS input is just a pulse. chrony has no idea what time that pulse was meant to indicate, only that it indicated a specific time. You have to somehow hook that pulse up to something else via the "lock" option. Probably you want to run gpsd and tell chrony about the gpsd input via a "refclock SHM...noselect" line. There should be examples of how to do this elsewhere > >> Furthermore, his "width" parameter is set to 0.7 milliseconds, which seems tremendously short to me. If the PPS pulses are 100ms (which I understand to be fairly standard) why wouldn't the width be configured as such? I may be misunderstanding this parameter. > > Yea, not sure, that does seem super small. If chrony knows the time (via the lock'ed refclock) with more accuracy than 0.7/2ms then its fine, but if you're locking to an NMEA input via gpsd you're gonna have way more variance than that. Ideally your pulse is half the width of your pulse rate, so 500ms if you're doing 1s PPS. > >> Either way, am not able to get chrony to lock up to a PHC refclock.[5] This is what my chrony.conf looks like: https://paste.millerjs.org/ajoxigiquc.txt >> I have not been able to use the testptp tool on this system yet - building it on another machine and running the copied-over executable fails, citing too old a version of glibc, and when I try and build it locally it fails for reasons that are unknown to me (I am very much not a C developer). I may have to install a newer OS in order to try this out. >> I am going to continue to fiddle with this - I think getting testptp working such that I can verify that I'm actually getting a pulse on SDP0 is the most important thing to confirm right now. I would greatly appreciate any help or feedback! > > chrony has been a bit...fidgety with me, the testptp utility will show at least whether your input is pulsing and being read or not. > > Matt > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com

es (in seconds). It is used to filter PPS samples when > the driver provides samples for both rising and falling edges. Note that it reduces the maximum > allowed error of the time source which completes the PPS samples. If the duty cycle is > configurable, 50% should be preferred in order to maximise the allowed error. which, maybe incorrectly, implied to me that there was no smarts for highly asymmetric pulse-to-not-pulsing time. Matt On 2/1/23 4:15 PM, Bob Camp wrote: > Hi > > A 10 or 100 microsecond wide 1 pps signal is more common than a 10 to 100 millisecond > wide pulse. > > Why? > > Back in the day, they coupled this stuff via a transformer. The frequency response issues > made a narrower pulse more appealing. These days it is not uncommon to try to drive a > 50 ohm load to some sort of logic level. The less time you have to do that, the happier > your driver IC (and regulator) are likely to be. > > One example of this would be the Trimble TBolt. It has a 10 us wide output pulse. Another > would be a uBlox LEA-6T (and the others in that lineup) with a default 10us wide output. > > > Bob > > >> On Feb 1, 2023, at 5:02 PM, Matt Corallo via time-nuts wrote: >> >> >> >> On 2/1/23 10:38 AM, John Miller via time-nuts wrote: >>> Hi Matt, >> >>> What I'm using right now is a Portwell NANO-6050[1], and it has i210 and i218 NICs. The SDP pins on the i210 aren't broken out into nice pads like the APU2 has, but with some magnet wire and a steady hand I was able to connect directly to one of the pins. Where I am struggling right now is ironing out the software configuration side of things. I'm not interested at all in PTP yet, right now the focus is purely on feeding the PPS into chrony via the SDP pins. The GNSS I'm using is a Sparkfun uBlox NEO-M9N GNSS receiver in its default configuration, connected to the computer over USB. PPS pin connected to the i210's SDP0. PPS pulse is 3v3 for 100ms. >>> I have tried using refclock strings from chrony's examples page[2] as a jumping-off point, but it doesn't make much sense to me. >> >>> 16Hz PPS with a rate of 16 - why not use 1Hz with a default rate of 1? >> >> More samples can hide at least some of the noise. As Bob points out in his reply there's a limit, though, of course, the NEO-M9N datasheet says its time-pulse accuracy is 30ns RMS/60ns 99%. If your interrupt jitter is less than that, you're not gonna hide much :). >> >>> The Dan Drown blog post makes a little bit more sense, but I think something is missing from the 'relevant chrony.conf' example - notably, it includes a single refclock line with the "pps" option, which according to the chrony.conf docs[4]: "Another time source is needed to complete samples from the refclock." and that example isn't included. >> >> A PPS input is just a pulse. chrony has no idea what time that pulse was meant to indicate, only that it indicated a specific time. You have to somehow hook that pulse up to something else via the "lock" option. Probably you want to run gpsd and tell chrony about the gpsd input via a "refclock SHM...noselect" line. There should be examples of how to do this elsewhere >> >>> Furthermore, his "width" parameter is set to 0.7 milliseconds, which seems tremendously short to me. If the PPS pulses are 100ms (which I understand to be fairly standard) why wouldn't the width be configured as such? I may be misunderstanding this parameter. >> >> Yea, not sure, that does seem super small. If chrony knows the time (via the lock'ed refclock) with more accuracy than 0.7/2ms then its fine, but if you're locking to an NMEA input via gpsd you're gonna have way more variance than that. Ideally your pulse is half the width of your pulse rate, so 500ms if you're doing 1s PPS. >> >>> Either way, am not able to get chrony to lock up to a PHC refclock.[5] This is what my chrony.conf looks like: https://paste.millerjs.org/ajoxigiquc.txt >>> I have not been able to use the testptp tool on this system yet - building it on another machine and running the copied-over executable fails, citing too old a version of glibc, and when I try and build it locally it fails for reasons that are unknown to me (I am very much not a C developer). I may have to install a newer OS in order to try this out. >>> I am going to continue to fiddle with this - I think getting testptp working such that I can verify that I'm actually getting a pulse on SDP0 is the most important thing to confirm right now. I would greatly appreciate any help or feedback! >> >> chrony has been a bit...fidgety with me, the testptp utility will show at least whether your input is pulsing and being read or not. >> >> Matt >> _______________________________________________ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe send an email to time-nuts-leave@lists.febo.com >

read a 64 bit register from a device. Extra > credit if you have PPS inputs that capture a time stamp etc. > > Anybody know how long it takes to read a device register? > I tried interfacing a cheap FPGA board (QMTECH XC6SLX16) with the LPC bus, accessible via the TPM header on some motherboards. Reading 1 byte takes around 1.5 us, and then you can read the rest of the counter. The rest of this project has an OCXO, a PPS timestamping counter at slightly less than 1 GHz using the Spartan 6 ISERDES, and a Linux PTP hardware clock (PHC) driver (just the clock without the networking parts). Instead of directly using the PHC, chrony can tightly sync the system clock (TSC) from the PPS timestamped by the PHC (the PHC itself may be free running). I may revisit this project and provide details/measurements if anyone is interested.