01:22 <set_> Okay, where were we? GenTooMan: Sorry for being curt earlier.

01:22 <set_> I have some things to 'accomplish.'

01:22 <set_> Forget it. This is too complicated to describe for now.

01:28 <set_> Anyway. I should try again soon.

01:30 <set_> It is probably that BB-UART2-00A0.dtbo.

01:30 <set_> W/out that darn blob file, I would be held renderless.

18:46 <CCFL_Man> it looks like there are a few pulse per second gpio implementations

18:47 <CCFL_Man> and quite a bit more uarts

20:18 <zmatt> CCFL_Man: ?

20:19 <zmatt> CCFL_Man: using gpios to implement anything timing-sensitive (with any sort of reliability) is pretty much impossible under linux, though PRU can do it if necessary... generally speaking using hardware peripherals would be preferred to using gpios

20:20 <zmatt> unless you meant something different from what you said

20:21 <zmatt> also when you say "pulse per second" you mean like a capture input? or pulse frequency measurement?

20:30 <CCFL_Man> oh, ok. what i mean is a pulse per second signal from a GNSS receiver. the pps_gpio driver creates a pps device file for ntpd to use

20:31 <CCFL_Man> to discipline ntpd

20:31 <zmatt> the AM335x has hardware peripherals that can timestamp signal edges with 10ns resolution

20:32 <CCFL_Man> oh wow, that's pretty good

20:32 <zmatt> gpio, in comparison, will be shit

20:32 <CCFL_Man> how can i feed the signal into it?

20:33 <zmatt> a better question is whether there's any driver for it

20:33 <CCFL_Man> that's true

20:35 <zmatt> pins that can be used as such a capture input are P9.42 (eCAP 0) and P9.28 (eCAP 2)

20:37 <zmatt> there are also four lower-resolution (24 MHz) capture inputs on P8.07-P8.10 (three of which have alternative mux options on P9.19, P9.20, P9.41)

20:40 <CCFL_Man> i wonder if the pps driver supports this

20:41 <zmatt> I've also written a driver that allows an eCAP timer to be used as system clock source for linux (instead of the default 24 MHz timer), I did that because we were noticing a continuous drift between the raw monotonic system time and the hardware timestamps on Precision Time Protocol network packets, caused by linux approximating 1GHz/24MHz as a fixed-point number

20:44 <zmatt> (and we're also doing some timestamping stuff in PRUSS, so having linux use the PRU eCAP as clocksource for the raw monotonic time makes it easy to convert raw eCAP timestamps from PRU to linux's raw monotonic timebase)

20:45 <CCFL_Man> i've never used PTP. what was your frequency source?

20:45 <zmatt> we just cared about synchronizing devices with each other, not with an absolute frequency reference

20:50 <zmatt> specifically we use it to tightly synchronize audio outputs on different devices; we use PRU to create audio timestamps (since the ALSA timestamps were too shit to be usable) expressed in the PRU eCAP timebase which can be converted to linux raw monotonic timebase (thanks to the eCAP driver I wrote), which is also used as the PTP packet timestamping timebase (which also required some patches to get ...

20:50 <zmatt> ...working properly), which allows these timestamps to be converted to the PTP timebase shared between devices

20:52 <zmatt> and this combined with an asynchronous samplerate converter allows different devices to play audio synchronized to within a fraction of a sample

21:03 <CCFL_Man> wow, were you logging data?

21:04 <zmatt> ?

21:04 <CCFL_Man> what audio signals were they?

21:04 <zmatt> just... audio. we're a speaker company

21:16 <CCFL_Man> oh, ok

22:02 <CCFL_Man> the software i use is called vlfrx-tools. it's a vlf SDR software suite that uses the soundcard as data acquisition. the program called vtcard reads data from the alsa/oss device as a specified sample rate and timestamps according to the system clock. vttime adjusts the timestamps according to a gps pps on the left or right channel. it uses a few methods to "find" the pulse

22:02 <CCFL_Man> http://abelian.org/vlfrx-tools/notes.html

22:02 <CCFL_Man> see vtcard and vttime sections

22:05 <zmatt> using an extra audio channel for pps sounds like a clever way of being able to very accurately timestamp the captured audio

22:06 <zmatt> (assuming you have an accurate source for a pps signal)

22:09 <CCFL_Man> it really is clever! you can achieve 50ns of UT with his software and a good GNSS receiver

22:09 <CCFL_Man> that's why i'm working on the "soundcard"

22:13 <zmatt> synchronizing the system time to pps would definitely be much harder, and like I said the audio timestamps from alsa are also crap (on the AM335x at least)

22:13 <zmatt> iirc dozens of _micro_seconds of jitter

22:14 <zmatt> probably with outliers that are even larger, I don't remember the exact numbers

22:14 <CCFL_Man> yeah, that's why vttime works so well. it even works on really crappy soundcards too

22:18 <CCFL_Man> with vlf receivers at distant locations, you can correlate events very accurately

22:18 <zmatt> yep, makes sense

22:55 <CCFL_Man> from what i've researched, the TI ADC seems to have the best performance

22:55 <CCFL_Man> between cirrus logic and akm

23:00 <CCFL_Man> so i'll be using the second channel for the gps pps