| 00:48.53 | *** join/#edev dijenerate (~dijenerat@69.73.197.224) |
| 00:51.54 | *** join/#edev nemik_ (~cyanact@c-67-162-60-211.hsd1.il.comcast.net) |
| 01:52.37 | *** join/#edev dijenerate (~dijenerat@204.212.240.159) |
| 01:59.44 | *** join/#edev djerome (~djerome@ip24-251-138-141.ph.ph.cox.net) |
| 03:46.01 | *** join/#edev pepsi (mork@unaffiliated/jbutera) |
| 03:46.23 | pepsi | hello |
| 03:53.16 | SpeedEvil | o |
| 03:58.31 | *** join/#edev calculu5 (~calculus@gentoo/user/calculus) |
| 04:19.56 | *** join/#edev mbuf (~user@nat/redhat/x-wmscjelgnhpemmov) |
| 05:09.07 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 05:27.29 | *** join/#edev miltonm (~miltonm@71.22.127.106) |
| 06:00.33 | *** join/#edev gvandenbosch (~gvandenbo@86.81.67.223) |
| 06:22.30 | *** join/#edev amarsman (~marsman@89.184.175.76) |
| 08:01.20 | *** join/#edev florian (~fuchs@port-217-146-132-69.static.qsc.de) |
| 08:01.20 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 08:23.20 | *** join/#edev bsdfox_ (~h36sa@unaffiliated/bsdfox) |
| 08:25.26 | *** join/#edev pytey_ (~pytey@howler.blatero.com) |
| 11:23.35 | *** join/#edev T0mW (~Tom@24.102.196.152.res-cmts.tv13.ptd.net) |
| 12:26.07 | *** join/#edev gvandenbosch (~gvandenbo@86.81.67.223) |
| 12:49.42 | *** join/#edev madsy (~madsy@188.113.83.44) |
| 12:49.42 | *** join/#edev madsy (~madsy@fu/coder/madsy) |
| 12:56.31 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 12:56.31 | *** mode/#edev [+o GPSFan] by ChanServ |
| 13:23.30 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 13:50.24 | *** join/#edev kergoth_ (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 14:02.00 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 14:32.42 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 14:40.18 | *** join/#edev roxfan (dunno@91.180.60.174) |
| 15:06.20 | *** join/#edev kergoth_ (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 15:11.12 | *** join/#edev florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 15:11.12 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 15:15.05 | *** join/#edev risca (~risca@h241n2-n-a31.ias.bredband.telia.com) |
| 15:26.40 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-ajaivdytldezcmir) |
| 15:38.24 | *** part/#edev nemik (~cyanact@c-67-162-60-211.hsd1.il.comcast.net) |
| 16:18.19 | *** join/#edev JoeLlama (~snork@cpe-76-172-203-123.socal.res.rr.com) |
| 16:18.22 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 16:29.42 | *** join/#edev prpplague (~danders@nat/ti/x-qvktszrolhygoaph) |
| 17:16.31 | wmat | Crofton|work: any progress with those interview questions? |
| 17:28.50 | *** join/#edev kergoth__ (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 17:32.15 | prpplague | kergoth: ping |
| 17:32.19 | prpplague | kergoth_: ping |
| 17:32.23 | prpplague | kergoth__: ping |
| 17:32.32 | prpplague | wheeee that was fun |
| 17:32.50 | kergoth__ | pong |
| 17:32.51 | kergoth__ | hehe |
| 17:35.49 | prpplague | hehe - http://hardware.slashdot.org/story/11/07/11/2313247/Ask-Slashdot-An-Open-Handheld-Terminal-For-Retail-Stores |
| 17:36.30 | prpplague | funny, aml stopped making linux handhelds because their marketing department said there wasn't a demand |
| 17:37.04 | kergoth` | heh, i'd say there's no demand for things like pdas, but special purpose ones, hell yes. people aren't going to want to use their phones or something general purpose for things like that.. |
| 17:37.08 | kergoth` | heh |
| 17:37.57 | prpplague | kergoth`: yea, it was a bad decision on their part, they are suffering pretty bad right now |
| 17:59.45 | Crofton|work | wmat, sadly no, gotta go out of town for a few days |
| 17:59.57 | Crofton|work | I am trying to calm my travel down for the next few weeks though |
| 18:34.34 | kergoth_ | dangit, I can't go to linuxcon, I *still* haven't gotten a passport |
| 18:34.37 | *** join/#edev Crofton|work (~balister@pool-74-107-168-228.ronkva.east.verizon.net) |
| 18:34.39 | kergoth_ | I should really fix that |
| 18:38.54 | prpplague | kergoth_: you have time |
| 18:39.12 | prpplague | kergoth_: i assume linuxcon NA is what you are talking about |
| 18:39.29 | kergoth_ | think I need to get a full birth cert issued too, to get the passport process going.. even expediting both I doubt I'd make it |
| 18:39.48 | prpplague | kergoth: expeditied usually is about 10 days |
| 18:40.12 | *** part/#edev prpplague (~danders@nat/ti/x-qvktszrolhygoaph) |
| 18:40.16 | *** join/#edev prpplague (~danders@nat/ti/x-qvktszrolhygoaph) |
| 19:08.36 | *** join/#edev sndcrb (~sndcrb@gprs-prointernet-ffb76a00-220.dhcp.inet.fi) |
| 19:33.50 | *** join/#edev kergoth_ (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 19:38.37 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-vgwcmkmvksfxeouf) |
| 19:52.23 | *** join/#edev florian (~fuchs@sign-4d094e50.pool.mediaWays.net) |
| 19:52.23 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 19:56.59 | *** join/#edev gravity_ (40f54422@gateway/web/freenode/ip.64.245.68.34) |
| 19:57.09 | gravity_ | Anyone know how hardware PLL works? |
| 19:57.16 | gravity_ | Would this be helpful in synchronizing the timing of two "identicle" embeded Linux devices? |
| 19:57.17 | *** join/#edev alexander (~alexander@ns2.lexterieur.net) |
| 19:59.30 | wmat | Crofton|work: man, you travel a lot |
| 20:38.36 | MonMotha | gravity_: in general, you're not going to be able to do that without some sort of feedback loop between the two devices |
| 20:39.04 | MonMotha | even identical settings of the PLL on each device will be subject to component variability, though if everything's from the same lot, it may be small |
| 20:39.52 | MonMotha | what is your end objective, and what's the nature of the devices? |
| 22:17.04 | gravity_ | MonMotha: What does a feedback loop entail? Here's what I'm working with |
| 22:17.20 | gravity_ | I have these Embedded Linux video devices, they're tiney displays |
| 22:17.37 | gravity_ | They're all of identical manufacturing, flashing, etc |
| 22:17.49 | gravity_ | I load them with the same video file, and I want them to play synchronously |
| 22:17.50 | gravity_ | however |
| 22:18.33 | gravity_ | when I power them up, their spash screens all come on at the same time, then they flip away from the flash screen at different rates, offsetting when they each play their media file |
| 22:19.01 | MonMotha | that's more due to a non-deterministic startup process than anything else, probably |
| 22:19.20 | gravity_ | I'm locked out of the EL system at the moment, working on getting some UART pin breakouts for the processor so I can explore more practical configuration based solutions |
| 22:19.41 | gravity_ | as it is, its a black box, reading the chip spec I saw this PLL feature and thought it could be a starting point |
| 22:19.44 | MonMotha | why must they be fully synced up? |
| 22:20.08 | MonMotha | it seems odd to have a bunch of systems with no communication in an environment that requires such perfect synchronization |
| 22:20.34 | gravity_ | because they must be fully synced ;p that's what they need to do. the arrangements must initiate their playbacks simultaneously. Ideally, if this worked with the same video clip I could cut one clip up so fragments are playing on each at the same time |
| 22:21.14 | gravity_ | ahah, yes, I'm working with what I have, the chip supports I2C, but the board manufacturer doesn't break that out either |
| 22:21.41 | gravity_ | If I can get into console, that would be sweet. Next would be breaking out I2C and establishing a synchronization protocol |
| 22:21.42 | *** join/#edev dijenerate (~dijenerat@69.73.249.143) |
| 22:22.07 | gravity_ | I was just being hopeful that PLL could maybe be synched through some hardware patch between modules |
| 22:22.18 | gravity_ | I'm aware that this may be a completely unrealistic expectation |
| 22:22.54 | MonMotha | I assume these are all running the same kernel and such? Chances are the PLLs are already configured identically. |
| 22:23.12 | MonMotha | No matter what, you'll still have component variability that will result in things getting off-sync over time |
| 22:23.17 | SpeedEvil | gravity_: Absolute absolute best-case, you're going to get 100-200ppm drift. |
| 22:23.33 | MonMotha | the real way to do this is that you need to network them somehow and distribute a "start playback" and a frame clock over the network |
| 22:23.36 | SpeedEvil | Or .4 seconds/hour |
| 22:23.41 | gravity_ | hm, I was thinking this would be a hardware solution, phase locking the processors to compensate for any subtle device variablity |
| 22:23.45 | MonMotha | (which need not be something as complex as ethernet - it could just be a serial port or ismilar) |
| 22:24.02 | MonMotha | if you want to phase lock the CPU clocks, you'll need to distribute a reference clock between them al |
| 22:24.19 | MonMotha | and then you must ensure that the startup process is 100% deterministic, which Linux isn't particularly good at |
| 22:24.29 | gravity_ | I wanted to use the first device's clock as the reference clock for all others |
| 22:25.05 | MonMotha | far easier to just wait for every device to check in as "ready", then have some master device initiate playback and control the frame rate with some sort of networked clock signal (sending timecodes, etc.) |
| 22:25.17 | gravity_ | .4 seconds/hr wouldn't be terrible, I could re-initialize every 15 minutes (or at the end of every playback loop) |
| 22:25.39 | gravity_ | Monmotha, yes that requires system access which I'm still working on |
| 22:25.50 | gravity_ | I can accomplish this a dozen ways through code or configuration |
| 22:25.54 | gravity_ | I don't have this yet |
| 22:25.59 | gravity_ | pins are not broken out |
| 22:26.01 | MonMotha | well, I don't think the PLL on the system is going to help you with this |
| 22:26.14 | gravity_ | I'm going to frankenstine the boards soon |
| 22:26.26 | MonMotha | the PLL is just used to generate a high frequency CPU/peripheral clock from a fixed, lowish frequency reference, such as a crystal |
| 22:26.31 | gravity_ | I figured, thanks for your insights, this is just one of many avanues of exploration |
| 22:27.06 | gravity_ | I think phase locking would be more appropriate for an analogue sync, like maybe video output interlacing |
| 22:27.12 | MonMotha | any solution is going to involve either networking the systems in some way or making the startup process fully deterministic and living with the aforementioned drift |
| 22:27.14 | gravity_ | than CPU synchronization |
| 22:27.43 | MonMotha | syncing up video like you described is referred to within the video industry as "genlocking" |
| 22:28.04 | MonMotha | it allows things like flash cuts without needing buffers or framerate conversion |
| 22:28.21 | MonMotha | you can also do overlays by rapidly cutting back and forth between two sources, though it doesn't allow for blending |
| 22:28.42 | MonMotha | the latter use is somewhat obsolete, but not needing to worry about framerate conversion is still quite handy |
| 22:28.51 | MonMotha | it requires quite a bit of infrastructure, though |
| 22:28.57 | MonMotha | basically, it's a networked clock signal |
| 22:29.30 | MonMotha | and, on long distance networks, compensating for the speed of light |
| 22:33.55 | *** join/#edev kergoth__ (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 22:43.13 | *** join/#edev causticsand (~quassel@pool-71-114-243-164.austtx.dsl-w.verizon.net) |
| 22:51.23 | *** part/#edev gravity_ (40f54422@gateway/web/freenode/ip.64.245.68.34) |
| 23:03.49 | *** join/#edev dijenerate (~dijenerat@72.22.134.88) |
| 23:27.47 | calculus | the beagleboard video wall does something similar, one board to keep the clock for everybody else |
| 23:57.24 | *** join/#edev dijenerate (~dijenerat@72.22.146.70) |