**** BEGIN LOGGING AT Thu Aug 25 02:59:58 2016 Aug 25 03:20:59 Hi Aug 25 03:21:04 Newbie here Aug 25 03:21:42 Could you provide the beagleboard X15 schematic to me? Aug 25 03:39:42 https://github.com/beagleboard/beagleboard-x15 Aug 25 03:39:47 you could also just have used google :P Aug 25 03:43:57 it was kind of you to not give him a LMGTFY link :) Aug 25 03:51:35 I considered it Aug 25 03:52:52 tonights task… putting ubuntu on my BBG Aug 25 04:01:29 ew, why would you do that Aug 25 04:02:55 to make installing ROS easier Aug 25 04:07:44 that and i am far more comfortable in ubuntu Aug 25 04:15:49 must say cloud9 was nice. wonder if i can install it on ubuntu to get it back Aug 25 10:12:23 hello Aug 25 10:12:29 The whole Law is fulfilled in one statement: ‘You’ll love your neighbour as much as yourself’ - Galatians 5:14 Aug 25 10:12:30 God bless you all and have fun asking! Aug 25 10:12:59 what does this message mean 'omap_uart 481a8000.serial: could not find pctldev for node /ocp/interrupt-controller@48200000, deferring probe' Aug 25 10:13:20 i patched yocto's kernel and add overlay support, everything works Aug 25 10:13:26 added* Aug 25 10:15:39 do i need BB-UART04 dtbo ? Aug 25 10:52:30 iskander_work: that remark is an extremely poor error messages that generally results for trying to load an overlay compiled without symbols Aug 25 10:54:28 basically it means the kernel tried to follow the reference from the uart node to its associated pinmux node, yet somehow managed to end up at the interrupt controller Aug 25 11:35:11 hmm Aug 25 11:36:13 thanks, i'll check my dts files Aug 25 13:10:17 hey Aug 25 21:46:12 ddrown, is this the bbb's main oscillator at Y2 - https://www.febo.com/pipermail/time-nuts/attachments/20141114/7a51017f/attachment-0003.jpg Aug 25 21:46:38 Strykar: that looks right Aug 25 21:46:59 well shit, he makes it look easy Aug 25 21:47:07 heh Aug 25 21:49:02 ddrown, as zmatt explained yesterday, if we were going to replace the main osc, do we choose the highest from all the supported frequencies ( 19.2 MHz, 24 MHz, 25 MHz, or 26 MHz) for better precision? Aug 25 21:50:20 higher frequency does not equal better precision Aug 25 21:50:28 only better precision equals better precision Aug 25 21:50:41 Strykar: there isn't that big of a difference between those - 38ns - 52ns Aug 25 21:50:54 zmatt, thanks for clearing that up, I was going by how ddrown used higher Mhz for the GPS Aug 25 21:52:01 precision could mean frequency accuracy, which you're right about Aug 25 21:52:08 26 MHz also has some caveats, iirc it makes setting the adc clock divider to 1 illegal (since its max clock is 25 MHz) Aug 25 21:52:19 what's the context here, what are you trying to do? Aug 25 21:52:29 I mean, nearly all uses of the main osc go through a PLL anyway Aug 25 21:52:40 (adc being one exception) Aug 25 21:53:19 well, going by Simon Marsh's results to the time-nuts list, he's achieved what can only be described as close to picosecond accuracy - "I'd intended to provide some nice graphs from NTP, but in practice the NTP jitter flatlined at 4us and the offset all night was practically flat as well, showing only occasional variation with maximums of +- 2us. This was great from a performance view, suggesting performance is better than NTP can report, Aug 25 21:53:20 but does make for some dull graphs." Aug 25 21:53:47 that isn't skirting time-nuts territory, thats serious time-nuts ground Aug 25 21:53:49 us = microsecond, 10^-6 Aug 25 21:54:07 oh snap, misread it Aug 25 21:55:05 wait, he couldn't do better replacing the main osc? ddrown did so much better than microsecond without replacing the main osc Aug 25 21:55:17 unless you're stepping something in units of a system clock cycle, its frequency is irrelevant Aug 25 21:55:37 Strykar: interrupt latency and jitter is easily in the 10us range Aug 25 21:55:53 zmatt, so changing the main osc isn't going to improve clock drift/ntp performance? Aug 25 21:56:16 I don't know, what's the cause of the drift? Aug 25 21:56:25 https://blog.dan.drown.org/beaglebone-black-timer-capture-driver/ Aug 25 21:56:39 ^ more detail on interrupt jitter Aug 25 21:56:44 ddrown, ok, so anything better is probably going to require something that has a dedicated interrupt or along those lines Aug 25 21:56:50 interrupt jitter should be irrelevant, packets are timestamped in hardware Aug 25 21:56:59 zmatt: this is NTP and PPS Aug 25 21:57:04 ok Aug 25 21:57:16 but for PTP you'd be right Aug 25 21:57:54 Strykar: BBB has a hardware timestamp for PPS, which is what my driver hooks into Aug 25 21:58:10 so interrupt latency/jitter doesn't affect it Aug 25 21:58:12 zmatt, ddrown is measuring and accounting and working out temperature compensation Aug 25 21:58:14 I'm still not clear why you'd want to replace the osc, unless perhaps you want to slightly adjust its frequency as part of the synchronization process (rather than doing it in software) Aug 25 21:58:31 (in which case you'd replace it by a vcxo or something) Aug 25 21:59:16 ddrown, so using your method, swapping the main osc offers no accuracy gain Aug 25 21:59:27 yeah, I haven't bothered Aug 25 21:59:51 I mean there is some time-nuts related work that you could do with it Aug 25 22:00:35 but there's diminishing returns far before that point :) Aug 25 22:00:43 yea but replcaing the main osc would be far down that list Aug 25 22:00:50 right :) Aug 25 22:01:18 zmatt, I was wondering if a new main osc would help in better ptp Aug 25 22:01:46 seems unlikely Aug 25 22:02:12 or well Aug 25 22:02:44 again depends on what problem you're fighting (short-term jitter? long-term temperature-dependent drift?) Aug 25 22:03:55 ddrown's method seems to skirt the typical on-board latency/jitter. for an amateur setup, temp drift is the biggest killer Aug 25 22:04:30 note that the core PLL adds its own flavor to the mix, both by absorbing clock jitter but also introducing its own Aug 25 22:04:32 easily observable by putting on a fan in the room as your ntpd :) Aug 25 22:04:46 there do seem to be some issues with the beaglebone PTP driver Aug 25 22:04:48 in particular it's not a low-jitter PLL and turned out inadequate for generating an RMII clock Aug 25 22:04:59 zmatt, how did you come to these figures yesterday - " from a power management point of view (and possibly long-time stability) it would be better if it used the 32768 Hz rtc clock instead probably" Aug 25 22:05:45 well the power management point of view should be obvious, the long-time stability was (as I mentioned then) based on a report on e2e by someone who observed clock was drifting relative to the more accurate RTC Aug 25 22:07:16 hm, nice numbers in section 5.3 of http://www.ti.com/lit/an/snla098a/snla098a.pdf Aug 25 22:09:09 although I've seen even crazier numbers with sync-E Aug 25 22:09:11 zmatt: ah, that's the PHY with PTP support built in. expensive but nice Aug 25 22:09:14 yes Aug 25 22:10:24 another solution in this area is white rabbit - https://en.wikipedia.org/wiki/The_White_Rabbit_Project Aug 25 22:10:25 [WIKIPEDIA] The White Rabbit Project | "White Rabbit is the name of a collaborative project including CERN, GSI Helmholtz Centre for Heavy Ion Research, and other partners from universities and industry develop together a fully deterministic Ethernet-based network for general purpose data transfer and sub-nanosecond accuracy synchronization..." Aug 25 22:11:15 which combines PTP and sync-E :) Aug 25 22:12:54 how else would you use sync-E ? Aug 25 22:15:13 http://www.ti.com/lit/an/snla100a/snla100a.pdf shows some numbers and pics for sync-E (again fancy external phy based solution) Aug 25 22:15:19 I have no actual experience with sync-E, so I wouldn't know Aug 25 22:16:04 well sync-e basically just means one device runs its timebase off the recovered ethernet clock of the other Aug 25 22:16:25 with some rules and stuff on deciding who will be the clock master Aug 25 22:17:00 that means in principle you can now have timers running at exactly the same rate on both devices Aug 25 22:17:22 but that still leaves the problem of actually getting them to display the same value Aug 25 22:17:34 rather than having some fixed delay Aug 25 22:17:38 / offset Aug 25 22:17:45 that's where PTP comes in Aug 25 22:17:55 ok, that all makes sense Aug 25 22:18:44 so then afaict remaining offset would be due to ptp-related errors and remaining jitter is just your clock jitter Aug 25 22:28:01 and this is how they introduce a specific place for time sync in ethernet like TDMA? **** ENDING LOGGING AT Fri Aug 26 02:59:59 2016