**** BEGIN LOGGING AT Wed May 06 02:59:58 2015
May 06 03:16:20 <PDogJr> Tonisius, what do you mean you can't get the "image off"? As you can't boot from eMMC?
May 06 03:29:30 <Tonisius> PDogJr: I can boot off of it, but when I boot from the SDcard, the autorun.sh doesn't see the eMMC
May 06 03:31:30 <PDogJr> I don't have any experience trying to manually flash the eMMC but if the process is supposed to be automated and it's not working, you should check your download, maybe verify the checksum
May 06 03:32:40 <PDogJr> I've been able to flash a few distros in the past, not sure why it would fail for you
May 06 03:34:29 <Tonisius> It's verified, there is no checksum to check against, the wiki doesn't provide one:  http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents
May 06 03:36:17 <PDogJr> oh I see
May 06 05:47:15 <manish_> Hi all ,
May 06 05:47:18 <manish_> I wanted to cross compile kernel for Beaglebone Omap3 but I could not find the Omap3 defconfig at arch/arm/configs.  Can anyone point me out which defconfig I need to use to get Beaglebone Omap3 kernel compile ?
May 06 05:48:52 <tbr> I think there's a generic arm defconfig that should work
May 06 05:49:15 <tbr> there might also be one named omap2something, which is usually specific to TI SoCs
May 06 05:52:18 <av500> omap2_plus or so
May 06 05:52:43 <manish_> tbr: Yes with name omap1_defconfig and omap2plus_defconfig files are their but I am not sure whether it will work perfectly with Omap3
May 06 05:55:59 <tbr> manish_: you are aware that the beaglebone is NOT an OMAP3, btw.
May 06 05:58:24 <manish_> tbr : Please confirm shall I go ahead with Omap2plus_defconfig or Is there any generic defconfig for Omap ?
May 06 05:58:52 * tbr won't grace that withan answer
May 06 05:59:19 <av500> AM335x != OMAP3
May 06 06:02:33 <manish_> tbr : Sorry,  actually I am new to this ... I got it now
May 06 06:04:21 <manish_> trb : you mean to say I can use any omap defconfig for this
May 06 06:04:55 <Tonisius> manish_: no, it's an AM335x... not an OMAP3
May 06 06:05:04 <Tonisius> so use an AM335x defconfig
May 06 06:06:39 <Tonisius> manish_: does that make sense?
May 06 06:07:13 <manish_> tonisius : I want to compile kernel for omap3
May 06 06:07:16 <Tonisius> manish_: did you consider using google for the questions?
May 06 06:07:24 <Tonisius> OH, that makes some sense.
May 06 06:07:57 <Tonisius> so you want to compile for omap3 on your am335x ?
May 06 06:08:15 <manish_> tonisius: my question is which defconfig I should use for omap3 ?
May 06 06:08:42 <Tonisius> sorry, this isn't the place for that question, we work on armhf and specifically the am335x in this channel :(
May 06 06:08:44 <tbr> the ones that were named before
May 06 06:08:57 <tbr> so you're not targetting a BBB?
May 06 06:09:27 <manish_> Tonisius : I want to  build for Qemu
May 06 06:09:52 <tbr> Tonisius: technically it's still on topic due to BB-classic and BBxm. Although asking on the arm linux channel might be better for him
May 06 06:10:09 <tbr> ok, qemu is off topic here
May 06 06:10:18 <Tonisius> ah, the original BB, ok makes some sense for now, and qemu is way off topic
May 06 06:11:02 <manish_> tbr : Sorry I think I should ask with some TI forum
May 06 06:11:41 <tbr> manish_: ask TI about qemu? good luck...
May 06 06:11:57 <manish_> Tonisius : Thanks
May 06 06:12:03 <manish_> tbr : Thanks
May 06 06:12:08 <Tonisius> that would be off toipic with them too, but the worst that can happen is they say "that is off topic, ask in qemu channel"
May 06 06:12:19 <Tonisius> Go ask, it doesn't hurt.
May 06 06:12:23 <tbr> or you know #armlinux
May 06 06:14:08 <manish_> tbr : no
May 06 06:15:21 <manish_> Tonisius : Its not specific to Qemu ... Its a arm kernel specific
May 06 06:16:08 <tbr> so, which specific device do you want to build a kernel for?
May 06 06:16:17 <Tonisius> If I were you, I would just give it a shot, and use the omap3 defconfig, since it's an omap3xxx chipset.
May 06 06:16:28 <Tonisius> since you're building for the original bb
May 06 06:16:45 <Tonisius> or answer tbr's question, becvause I'm just assuming it's the original bb's chipset.
May 06 06:17:11 <tbr> Tonisius: there is no omap3 defconfig, that's what confuses him :)
May 06 06:17:18 <manish_> tbr : beaglebone
May 06 06:17:27 <tbr> manish_: black or white?
May 06 06:18:16 <tbr> it's easy: which colour is the PCB of the board in front of you
May 06 06:18:45 <Tonisius> tbr: I've seen a few random ones on github, and then this one from omap: http://omappedia.org/wiki/Building_Linux_OMAP_Kernel
May 06 06:19:10 <tbr> Tonisius: I'm referring to a vanilla tree from kernel.org
May 06 06:19:55 <Tonisius> yeah... I know what you mean: http://stackoverflow.com/questions/30055811/omap3-defconfig-missing
May 06 06:20:04 <Tonisius> because manish is the one asking it.
May 06 06:20:17 * Tonisius points at the name
May 06 06:20:32 <manish_> tbr : Sorry If I am wrong .., I am new a beginner ... Just basic question .. I want to build a kernel for arm omap3 SoC ... and I am not able to figure out which defconfig to use .... should I have to consider first for which board ?
May 06 06:20:51 <tbr> 05:55:59< tbr> manish_: you are aware that the beaglebone is NOT an OMAP3, btw.
May 06 06:20:54 <tbr> 05:59:21<@av500> AM335x != OMAP3
May 06 06:21:32 <tbr> manish_: fess up, what is the *REAL* hardware you are building for. Because neither of the BeagleBones is OMAP3!
May 06 06:22:54 <Tonisius> manish_: which board are you working on, that has the omap3 chipset.
May 06 06:22:57 <tbr> I'll ask one last time before I'll leave you to be devoured by a Grue: What is the colour of the PCB of the board that you are building for?
May 06 06:23:18 <Tonisius> isn't the semi colon the proper usage in your sentence?
May 06 06:23:38 <tbr> 06:22:56< tbr> I'll ask one last time before I'll leave you to be devoured by a Grue: What is the colour of the PCB of the board that you are building for?
May 06 06:23:50 <Tonisius> manish_: which board are you working on, that has the omap3 chipset.
May 06 06:24:40 <Tonisius> tbr, isn't the bb omap3530 ? http://beagleboard.org/beagleboard <--
May 06 06:25:04 <tbr> Tonisius: the BB and BBxm are OMAP3. the BBW and BBB are AM33xx
May 06 06:25:11 <manish_> Tonisius : Yes I have only posted that question on stack overflow
May 06 06:26:42 <manish_> tbr : So you said BB and BBxm are omap3
May 06 06:27:11 <manish_> tbr : So how to build kernel image for this
May 06 06:27:21 <Tonisius> manish_: https://eewiki.net/display/linuxonarm/BeagleBoard
May 06 06:29:32 <Tonisius> manish_: does that help?
May 06 06:31:06 <manish_> tonisius : I have pulled kernel from main line  . arch/arm/configs/   is not having anything related to omap3
May 06 06:31:16 <Tonisius> did you read the link I gave you?
May 06 06:34:18 <tbr> manish_: it would really help if you would tell us twhat is really on the board that you are working on. And by that I mean an exact chip designation.
May 06 06:34:43 <tbr> As it won't help neither you nor us if we tell you how to build for the wrong hardware
May 06 06:34:45 <Tonisius> the language barrier kills me :(
May 06 06:35:14 <tbr> if you are not willing to cooperate and answer our questions, I strongly suggest to go back working on iMX.
May 06 06:35:51 <manish_> tonisius : yes so do I need to take armv7-multiplatform kernel ?
May 06 06:37:24 <manish_> tbr : Sorry if i am confusing you ..  My requirement is I need a kernel image for arm omap3 SoC ... which I am going to run on Qemu
May 06 06:37:27 <tbr> I'd take a ppc64 defconfig for my mips32 soc on a pandaboard.
May 06 06:39:37 <KotH> tbr: +1337
May 06 06:41:16 <tbr> manish_: then try the omap2plus defconfig, but make sure you configure qemu to vaguely resemble the ARM side of a OMAP3
May 06 06:41:20 <manish_> tbr : you want to know on which board I am going to use this ... but I will run this on Qemu ... thats the reason I am not talking about any board
May 06 06:41:30 <LetoThe2nd> manish_: nowdays arm kernels need a dtb. pick your poison: http://lxr.free-electrons.com/source/arch/arm/boot/dts/Makefile#L349
May 06 06:41:39 <LetoThe2nd> manish_: which obviously gets set by http://lxr.free-electrons.com/source/arch/arm/configs/omap2plus_defconfig
May 06 06:41:44 <tbr> you were giving us all sorts of shit and fairytales about boards
May 06 06:42:16 <Tonisius> but he said on qemu
May 06 06:42:33 <tbr> Tonisius: and then he said beaglebone and then beagleboard and then beaglebone
May 06 06:42:37 <LetoThe2nd> manish_: so please stop repeating over and over again. get started with omap2pus_defconfig, and otherwise, please do not bother this channel anymore
May 06 06:43:01 <manish_> tbr : Sorry I am beginner .. I will try omap2plus_defconfing ... If it helps me
May 06 06:43:12 <tbr> do that
May 06 06:43:26 <LetoThe2nd> manish_: we are *NOT* here to help you with your qemu woes. qemu does *NOT* behave the way a beagle{board, bone} does.
May 06 06:43:38 <tbr> and please don't come back, as we don't know any answers to any of your possible further questions. thanks.
May 06 06:44:01 <manish_> LetoThe2nd : Yes you are correct
May 06 06:44:25 <LetoThe2nd> manish_: see, thats why we are not the people you should ask. nice tat you understand. good luck.
May 06 06:45:31 <Tonisius> the worst part of language barriers :(
May 06 06:45:36 <manish_> LetoThe2nd: Thanks
May 06 06:46:32 <manish_> Tonisius : Thanks for help
May 06 06:46:58 <KotH> Tonisius: considering that manish_ lives in the states, while tbr and LetoThe2nd are Yuropeeans
May 06 06:47:17 <Tonisius> no, manish is using a web proxy in the usa....
May 06 06:48:34 <LetoThe2nd> KotH: Tonisius: manish_: if no further beagle-related, productive content is coming up, i'd like everybody to stop quitly here for a few moments so we can all come down and refocus on #beagle-stuff, okay? :)
May 06 06:48:45 <manish_> Sorry guys ... My question is more about kernel but related to beagle ..
May 06 06:48:57 <KotH> LetoThe2nd: am i allowed to focus on theoretical computer science stuff?
May 06 06:49:00 <Tonisius> manish_: it's not related to beagle.
May 06 06:49:08 <manish_> thats why I asked some help here
May 06 06:49:18 <LetoThe2nd> *sigh*
May 06 06:49:31 <LetoThe2nd> please, no more justifications over and over. just stop it here.
May 06 06:49:57 * KotH thumbs a bit, to apease the sandworm
May 06 06:50:01 <manish_> I extremly sorry ...  anyway .. Thanks for help
May 06 06:55:51 <Tonisius> you know what, I looked up the IP address 192.88.169.1, that's like where I'm at... that's so close
May 06 06:57:51 <tbr> Tonisius: he's likely from some indian Freescale office. It's just the address of freescale HQ that you probably found
May 06 06:57:58 <Tonisius> it is
May 06 06:58:09 <Tonisius> VPN's or an outsourced resource here in the USA
May 06 07:05:39 * tbr ponders if he'd been accused of cruelty for pointing to http://vm-kernel.org/blog/2008/12/15/linux-is-running-on-qemu-omap3/
May 06 07:07:06 <Tonisius> tbr: he got us all wondering about how to make it work...
May 06 07:09:05 <tbr> Tonisius: I know how to make "it" work. BTDT. But I also know the severe limitations.
May 06 07:46:37 <JW> Is there any news on the release of the X15?
May 06 07:46:53 <JW> And cost?
May 06 07:46:59 * Tonisius reads up on X15
May 06 07:47:19 <Tonisius> wow... that's a nice system
May 06 07:47:28 <JW> yep
May 06 07:47:58 <Tonisius> no rtc battery?
May 06 07:49:43 <av500> its doomed
May 06 07:50:12 <nicezic> hello
May 06 07:50:30 <Tonisius> Wonder if the Dual ethernet is gigabit speeds...
May 06 07:50:49 <JW> 8 pin RTC
May 06 07:50:55 <JW> Why is it doomed?
May 06 07:51:58 <JW> And if doomed - what is best alternative?
May 06 07:52:12 <Tonisius> why is it doomed? no traction?
May 06 07:53:25 <tbr> dooooom!
May 06 07:53:51 <Tonisius> should we sing the doom song?
May 06 07:53:52 * LetoThe2nd would rather have it wolfensteined
May 06 07:54:36 <Tonisius> https://www.youtube.com/watch?v=fqcn_TPu4qQ
May 06 07:55:12 <tbr> LetoThe2nd: no, if then Duke'd. forever, of course.
May 06 07:55:48 <Tonisius> But Duke did get released... forever was a really long time
May 06 07:55:57 <Tonisius> hail to the king of course
May 06 07:57:35 <tbr> Tonisius: that's about the same scale as with all beagle* boards. Sales announced, demand outstrips production capacity by 20 orders of magnitude, wide availability 1+ years later.
May 06 07:58:01 <Tonisius> you sound like an ex-coworker of mine, always talking in orders of magnitude
May 06 07:58:04 <tbr> (note that x15 isn't even announced yet, at all, let alone sales)
May 06 07:58:28 <tbr> did he also use dB to express that?
May 06 07:58:47 <Tonisius> at times...
May 06 07:58:56 * tbr loves to confuse people by giving prices in db€/db$
May 06 08:05:38 <JW> Does the X15 have a release date?
May 06 08:06:24 <JW> http://elinux.org/Beagleboard:BeagleBoard-X15
May 06 08:06:39 <Tonisius> JW: as mentioned, it's not even announced.
May 06 08:06:57 <JW> https://eewiki.net/display/linuxonarm/BeagleBoard-X15
May 06 08:07:03 <JW> It's been announced.
May 06 08:07:25 * Tonisius points to the data, says not available yet
May 06 08:11:19 <JW> https://www.riscosopen.org/forum/forums/9/topics/2922
May 06 08:11:39 <Tonisius> How do these small systems keep up with RTC?  do they have a cap that lasts for months?
May 06 08:12:41 <Tonisius> or some magical way of keeping track of time? or completely unrelated, I know my rpi does an ntp
May 06 08:17:45 <av500> battery
May 06 08:17:47 <av500> goldcap
May 06 08:17:54 <Tonisius> ah, ok.
May 06 11:26:13 <Zsolt--_> hello
May 06 12:43:45 <Rotti> hi
May 06 13:05:02 <wmat> JW: that info has been on elinux.org for awhile now http://elinux.org/Beagleboard:BeagleBoard-X15
May 06 14:07:43 <Prem> hi
May 06 16:32:41 <Ben__> I have the BBB from one generation ago (2GB eMMC), and I had a question about the recommended operating system to use to reflash the eMMC
May 06 16:32:58 <_av500_> debian
May 06 16:33:09 <_av500_> see the "latest software" link on the homepage
May 06 16:34:01 <Ben__> Thank you for the quick response, I did see that. It looks like the recommended one isn't for reflashing however
May 06 16:34:20 <rcn-ee> Ben__, there's one labeled specifically for the 2gb.. just got click..
May 06 16:34:21 <_av500_> there should be a flasher too
May 06 16:34:36 <Ben__> But debian is not recommended over angstrom?
May 06 16:34:47 <Ben__> now**
May 06 16:34:56 <_av500_> yes
May 06 16:35:02 <rcn-ee> Ben__, under "Recommended Debian Images" there's a link to "other' ... click that..
May 06 16:35:14 <Ben__> Gotcha, yeah I do see that
May 06 16:35:30 <rcn-ee> it'll take you here: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-03-01 where the 2GB eMMC flasher exists..
May 06 16:36:18 <Ben__> I ask because I had had Ubuntu installed, but it removed some of the functionality of the board (PWM and UART no longer worked), this is fixed with debian?
May 06 16:38:14 <rcn-ee> Ben__, downgrade to v3.8.x..
May 06 16:38:28 <rcn-ee> sudo apt-get update ; sudo apt-get install linux-image-3.8.13-bone71 ; sudo reboot ....
May 06 16:39:51 <Ben__> Interesting, okay will do. And just to confirm, I run this after installing the most recent debian release?
May 06 16:41:00 <rcn-ee> Ben__, on newer images i ship v3.14.x by default, but v3.8.x is available in the repo for all dist's on repos.rcn-ee.net...
May 06 16:45:17 <Ben__> Okay, thank you for your help!
May 06 16:46:02 <rcn-ee> Ben__, and v4.x is available too, full breakdown for all distro's here: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Kernel_Options
May 06 16:46:13 <rcn-ee> at somepoint everything will work on mainline...
May 06 16:50:05 <James_Johnson> weird question: anyone know of an emacs major mode for dts files?
May 06 16:51:11 <James_Johnson> I found a github repo where a guy wrote a readme for one but there’s nothing else.
May 06 16:54:49 <vvu> James_Johnson: maybe this ? https://github.com/morbidrsa/dts-mode
May 06 16:55:01 <vvu> i'm not an emacs user but that is what google says as first link for emacs dts search :)
May 06 16:56:09 <James_Johnson> All I found from google was https://github.com/deactivated/dts-mode
May 06 16:56:11 <James_Johnson> thanks
May 06 20:14:57 <foundatron> rcn-ee, thanks again for the help yesterday. I'm trying to build an image using that "chroot_after_hook" right now
May 06 20:15:16 <foundatron> I'm curious what hardware do you use for building images?
May 06 20:16:05 <foundatron> I've been playing around and using scaleway which offer bare metal arm servers...located in france
May 06 20:16:15 <foundatron> works pretty good actually
May 06 20:17:02 <rcn-ee> foundatron, typically i.mx6/omap5 sata based boards..
May 06 20:18:00 <foundatron> Any particular that you really like?
May 06 20:18:38 <rcn-ee> well the wand quad is about the cheapest $/performance...
May 06 20:19:18 <rcn-ee> the omap5_uevm's are about 30% faster, but 2x the cost...
May 06 20:20:21 <foundatron> Have you played with the scaleway servers?
May 06 20:20:37 <foundatron> I've been impressed so far
May 06 20:20:47 <foundatron> like linode....but arm7
May 06 20:21:02 <foundatron> scaleway.com
May 06 20:21:29 <rcn-ee> i've heard of them, but already have 6 i.mx6q's and 3 omap5's thru ssh. .;)
May 06 20:21:46 <foundatron> so many toys...
May 06 20:22:12 <rcn-ee> those are just the ones that run 24/7.. ;)
May 06 20:22:19 <foundatron> nice
May 06 20:26:18 <foundatron> is this omap5 board you referred to? http://svtronics.com/omap/omap54xx?product_id=33
May 06 20:26:43 <rcn-ee> that's the one... aka.. PandaBoard 5.. ;)
May 06 20:36:05 <ds2> btw - are you guys keeping the full size sim holder on the Neo900?
May 06 20:36:52 <Humpelstilzchen> Pandaboard ist sooo dead
May 06 20:37:02 <ds2> oops
May 06 20:37:25 <Humpelstilzchen> bzw any news on the new beagleboard? ;)
May 06 20:39:04 <veremit> why IS the pandboard site so crap!?
May 06 20:39:44 <veremit> makes the others look positively Good. Even the beagle ones *duck* lol
May 06 20:40:12 <Humpelstilzchen> veremit: it hasn't been updated in a while..
May 06 20:41:40 <veremit> oh dear its a cco product :/ -sigh- I was gettin my hopes up lol
May 06 20:42:27 <rcn-ee> the site for panda, is just a read only version, from the day it died..
May 06 20:42:51 <veremit> lol rcn
May 06 20:43:09 <veremit> pity the x15 is in the same boat (cco project)
May 06 20:43:39 <rcn-ee> well, cco is only doing production, they no longer have an engineering staff..
May 06 20:44:10 <rcn-ee> the x15 board is also going to be ti's evm...
May 06 20:44:14 <rcn-ee> so one board to rule them all..
May 06 20:44:39 <veremit> no built-in phy.. crap lol
May 06 20:44:58 <rcn-ee> 22nm...
May 06 20:45:00 <veremit> rcn .. I haven't seen anything great coming out of ti's evm's bein outsourced
May 06 20:45:14 <veremit> makes everything expensive imo
May 06 20:45:25 <rcn-ee> true... but this gerald's design. ;) (with ti feedback..)
May 06 20:45:49 <veremit> well I hear gerald's made some ... interesting.. design decisiions on the BBB for example :)
May 06 20:46:08 <Humpelstilzchen> veremit: you have a source for that?
May 06 20:46:16 <veremit> but I'll be interested on the final design/pricing
May 06 20:46:28 <veremit> Hump: which statement(s)?!
May 06 20:46:57 <Humpelstilzchen> veremit: design decisions
May 06 20:47:06 <veremit> #beagle :)
May 06 20:47:20 <veremit> various discussions I have seen .. not to mention those I haven't :)
May 06 20:47:41 <Humpelstilzchen> and any news when the x15 will be out?
May 06 20:47:53 <rcn-ee> veremit, i still think the led's on the bbb aren't bright enough...
May 06 20:48:06 <veremit> zmatt was explaining some interesting implications of the 3v3 power rail arrangements
May 06 20:48:11 <veremit> rcn-ee .. you Sure?!
May 06 20:48:46 <veremit> perhaps an upgrade to powerLED would help?
May 06 20:49:02 <Humpelstilzchen> LEDs...who needs sleep anyway
May 06 20:49:09 <veremit> +1 Hump
May 06 20:49:36 <rcn-ee> all those people who forced gerald to make it dimmer in later bbb versions.. ;)
May 06 20:49:49 <ds2> so we should be planning a fellowship of the dogs to dispose of the x15?
May 06 20:49:50 <veremit> my boss made a nice controller for those RGB led strips
May 06 20:50:01 <veremit> ds2: +1
May 06 20:50:20 <veremit> boss's cousin made a nice sound-to-light module for JACK lol
May 06 20:51:04 <veremit> next upgrade would be addressable strips ..
May 06 20:51:17 <veremit> but I think the underlying protocol works fine for that :D
May 06 20:52:26 <rcn-ee> like matt's presentation at elc: https://events.linuxfoundation.org/sites/events/files/slides/Open%20Lighting%20Presentation%202015.pptx_.pdf
May 06 20:58:17 <vagrantc> i thought the LEDs on the BBB were almost apinfully bright, but apparently the boards i've got are the milder ones...
May 06 20:58:54 <veremit> rcn: I was doin DMX in the 90s
May 06 20:59:06 <veremit> didn't know standards had moved on so fast
May 06 20:59:49 <veremit> our standard serial protocol is based on rs485 too
May 06 21:00:18 <veremit> it is point-to-point which i like
May 06 21:01:55 * veremit looks around for his lighting effects .. ah there's one...
May 06 21:03:02 <veremit> hardware interface was always an issue .. I built a parallel-to-rs485 based on an avr chip
May 06 21:03:11 <veremit> And then I met the FTDI chips :)
May 06 21:03:48 <veremit> ft230 + il485 .. boom.
May 06 21:48:43 <zmatt> veremit: ftdi chips? can you even get a remotely accurate break and MAB time with those?
May 06 21:49:03 <zmatt> (and frame timing in general)
May 06 21:49:25 <veremit> zmatt .. I heard there was a trick with changing the baud rate ;)
May 06 21:49:41 <veremit> mid-packet iirc
May 06 21:49:58 <veremit> or .. yanno .. there's a trick
May 06 21:50:08 <zmatt> dmx is nice and simple (ignoring RDM) but it does have fairly stringent timing requirements
May 06 21:50:56 <zmatt> and RDM has even tighter timing requirements
May 06 21:51:36 <veremit> http://www.sabretechnology.co.uk/dmxwork.htm
May 06 21:51:36 <zmatt> (frame rate stability is officially not important but in practice it is for various fixtures)
May 06 21:52:12 <veremit> these guys did the firmware for the units I have...
May 06 21:54:36 <zmatt> ick, they don't even mention the mark-after-break -.-
May 06 21:55:30 <veremit> stop bit?
May 06 21:55:35 <veremit> :P
May 06 21:56:23 <veremit> its a trick .. and to manually do it is a real pain (I did...) and trouble shot it without a scope :/ man that wasn't fun.
May 06 21:56:27 <zmatt> yeah was calculating whether that meets the requirements
May 06 21:56:32 <zmatt> also, 88 us break is too short
May 06 21:56:48 <veremit> I can't remember the spec.. I got the plasa book somewhere
May 06 21:56:55 <veremit> its a 'min' requirement iirc
May 06 21:57:07 <zmatt> DMX std says min 92, typ 176, no max.  RDM tightens this to min 176 max 352
May 06 21:57:10 <veremit> but remember your stop bit, etc.
May 06 21:57:23 <veremit> startbit**
May 06 21:57:32 <veremit> wtf is rdm?!
May 06 21:58:26 <zmatt> remote device management... two-way communication over DMX which allows for discovering devices and assigning them a dmx address
May 06 21:58:34 <zmatt> (among other things)
May 06 21:58:41 <veremit> ah I see .. bi-directional
May 06 21:59:01 <veremit> thats a bit chunk of latency though
May 06 21:59:04 <veremit> big*
May 06 22:00:14 <zmatt> why would there be?  (not that it's important for the RDM messages anyway)
May 06 22:00:36 <veremit> increasing the break time
May 06 22:00:51 <veremit> no .. its a fairly natural evolution of the protocol
May 06 22:00:54 <zmatt> oh that
May 06 22:01:02 <veremit> but looks like its slowly being superceded
May 06 22:01:06 <zmatt> eh, what does break time have to do with latency?
May 06 22:01:16 <veremit> as I said .. it was a standard in the 90s ..its officially Old now :)
May 06 22:01:24 <zmatt> well RDM is 2006
May 06 22:01:37 <veremit> yea give it a couple of years... it'll be Old too lol
May 06 22:01:41 <zmatt> maybe
May 06 22:01:45 <zmatt> I think not
May 06 22:02:05 <veremit> surprised with the advent of small arm chips with ethernet its not gone ethernet
May 06 22:02:17 <veremit> or some bastardisation of it
May 06 22:02:21 <zmatt> Ethernet has no guaranteed timing
May 06 22:02:23 <zmatt> unless you go AVB
May 06 22:02:37 <zmatt> (and AVB has serious complexity)
May 06 22:03:06 <zmatt> I don't see DMX disappearing any time soon for professional applications
May 06 22:03:48 <zmatt> nor cheapass applications actually... a μC with ethernet is still more expensive than one that handles DMX
May 06 22:03:52 <rcn-ee> and with long life of led's, probally never. ;)
May 06 22:04:26 <veremit> well dmx always seemed to Work .. if it worked.
May 06 22:05:50 <GenTooMan> DMX sounds familiar for some reason.
May 06 22:05:58 <zmatt> dmx-not-working checklist: crappy cheapass controller? crappy cheapass fixtures? is that DMX cable or microphone cable? terminator? :P
May 06 22:06:22 <veremit> rdm is the natural follow-on. Since it involves no infrastructure change for existing installs
May 06 22:06:44 <veremit> zmatt .. works fine with mic cable .. and 3 cores :p
May 06 22:07:05 <veremit> or 2c/screen pedantics :P
May 06 22:07:06 <zmatt> if you have few fixtures and short cables, sure
May 06 22:07:14 <zmatt> same with omitting the terminator
May 06 22:07:33 <veremit> yea terminator is a bit more critical .. my fixtures have built-in termination and regeneration
May 06 22:07:43 <zmatt> ehhh
May 06 22:07:55 <zmatt> that sounds sucky
May 06 22:08:05 <veremit> with relays lol
May 06 22:08:12 <veremit> they work really well actually
May 06 22:08:19 <veremit> and the firmware is good
May 06 22:09:21 <veremit> I need to get some LED spots though
May 06 22:09:55 <zmatt> except one of those fixtures in the chain will at the very least mean RDM is broken after that point, getting the grounding right is tricky but doable I guess... are they zero-delay? :P
May 06 22:10:19 <veremit> they're dip-switches old skool :D
May 06 22:10:38 <veremit> and they're never gonne be in a fixed install so I'll always have access
May 06 22:12:53 <zmatt> it still makes no sense to me to do it like that... unnecessarily complicated, harder to comply with specs... and dunno if you repeat purely electrically or by receiving and retransmitting, but in the former case you probably disturb the timing (in a cumulative way with more fixtures in the chain) while the latter adds latency
May 06 22:13:40 <veremit> that is the only caveat .. but the theory is you can extend the chain .. i say Theory..
May 06 22:14:12 <veremit> If I ever get near 100 fixtures, I'll let you know ..
May 06 22:14:31 <agmlego|skynet> Ethernet can be used for precise timing.
May 06 22:14:41 <veremit> but at that point I'll probably own a yacht .. so doubt if i'll be here XD
May 06 22:14:43 <zmatt> (RDM does also address in-line devices like repeaters btw, but they're obviously even more complicated)
May 06 22:15:25 <agmlego|skynet> Like, nanosecond-level timing.
May 06 22:15:31 <agmlego|skynet> No problem.
May 06 22:15:50 <zmatt> agmlego|skynet: if you mean timesync then yes, but not *reliable* delivery
May 06 22:15:59 <agmlego|skynet> PTP.
May 06 22:16:05 <zmatt> that's timesync
May 06 22:16:11 <agmlego|skynet> And NTP, if you care about calendar time.
May 06 22:16:22 <agmlego|skynet> zmatt: So send the pakcet before you need the thing to happen.
May 06 22:16:34 <agmlego|skynet> And tell the fixture when you want the thing to happen.
May 06 22:16:35 <zmatt> agmlego|skynet: that's often not acceptable
May 06 22:16:45 <agmlego|skynet> zmatt: ::shrugs::
May 06 22:17:01 <agmlego|skynet> All sorts of realtime things going on Ethernet for industrial automation.
May 06 22:17:05 <veremit> agm .. you could 'upload' a program .. I like that.
May 06 22:17:19 <veremit> or even just a sequence and trigger
May 06 22:17:20 <zmatt> for some applications that will do, but not all
May 06 22:17:24 <agmlego|skynet> I cannot imagine that some lightsand smoke machines care more about timing than an entire assembly line.
May 06 22:18:04 <veremit> our company is using ethernet within the machine control.
May 06 22:18:16 <veremit> its a local net .. works fine.
May 06 22:18:21 <agmlego|skynet> Most these days are.
May 06 22:18:25 <zmatt> agmlego|skynet: I don't know what the timing requirements are for industrial automation
May 06 22:18:38 <veremit> ms is easily achievable
May 06 22:18:40 <agmlego|skynet> Siemens and Rockwell both use Ethernet as the base communications to remote IO and other devices.
May 06 22:18:53 <agmlego|skynet> zmatt: sub millisecond generally.
May 06 22:19:00 <agmlego|skynet> Well, sub to single-digit.
May 06 22:19:30 <veremit> aight brb a few
May 06 22:19:40 <agmlego|skynet> And if better is needed, PTP steps in with messages to trigger when the time gets to the right point.
May 06 22:20:36 <zmatt> *shrug*  still sounds like gambling to me, unless a dedicated net is used with a very strictly disciplined protocol between the communicating parties
May 06 22:20:44 <zmatt> in all cases it's waaaaaay more complex than DMX
May 06 22:21:04 <agmlego|skynet> Whoever said it was not?
May 06 22:21:15 <agmlego|skynet> \But commodity hardware, long distances, and no fucking terminators.
May 06 22:21:34 <agmlego|skynet> And far more addresses available.
May 06 22:22:00 <agmlego|skynet> Besides, why would you *not* run things on a dedicated network?
May 06 22:22:17 <agmlego|skynet> Not like you let people check Facebook over your DMX networks now.
May 06 22:22:20 <zmatt> because if you use ethernet, enough idiots will...
May 06 22:22:37 <agmlego|skynet> And even in the face of that, it still works fine.
May 06 22:23:01 <agmlego|skynet> At least one of my customers uses the same hardware for controls network and IT network.
May 06 22:23:09 <zmatt> .... as long as the gods favor you
May 06 22:23:31 <agmlego|skynet> 10 million cars and counting, so I doubt we need to bring deities into this.
May 06 22:24:07 <zmatt> veremit: also, w.r.t. your devices being repeaters:   "4.11 Unpowered devices -- Unpowered connected DMX512 devices shall not degrade the performance of the DMX512 transmission system nor materially lower the impedance they present to the data link."
May 06 22:24:15 <zmatt> :P
May 06 22:24:30 <agmlego|skynet> zmatt: I totally understand skepticism when confronted by what appear to be extraordinary claims from your limited perspective.
May 06 22:24:45 <agmlego|skynet> zmatt: But this is how we have been doing things for close to a decade. ;-P
May 06 22:25:15 <zmatt> agmlego|skynet: also, ethernet max cable length is afaik considerably less than DMX
May 06 22:25:35 <agmlego|skynet> DMX can go 100m on copper or kilometers on fibre?
May 06 22:26:17 <veremit> zmatt : switch-through relay .. doubt that's gonna hit the impedance wildly :)
May 06 22:26:24 <zmatt> I'm looking for the number as we speak (and comparing with fibre is not exactly fair since you won't be able to connect that to any plain device)
May 06 22:26:37 <agmlego|skynet> zmatt: Why not?
May 06 22:26:43 <veremit> I've seen ethernet switches (got one) with fibre interface
May 06 22:26:45 <agmlego|skynet> Plenty of stuff talks fibre.
May 06 22:26:51 <zmatt> agmlego|skynet: endpoint devices?
May 06 22:27:29 <agmlego|skynet> It is pretty common in plants to have the switches talk to one another over fibre, and to run fibre directly to devices in high-EMI areas (see: welding, induction furnaces, etc.)
May 06 22:28:05 <veremit> eg. http://www.netgear.co.uk/business/products/switches/smart/GS724Tv4.aspx
May 06 22:28:12 <veremit> agm .. makes sense
May 06 22:28:29 <agmlego|skynet> veremit: You can usually tab-complete nicks. ;-
May 06 22:28:30 <zmatt> sure, but that's getting really incomparable with DMX
May 06 22:28:43 <veremit> agm: too lazy .. and I'll probably pick up one of your alts ;P
May 06 22:28:43 <zmatt> as in, under those circumstances it's not replacing DMX, DMX would never have been there :P
May 06 22:29:00 <agmlego|skynet> zmatt: Do you want a new standard that uses commodity hardware, or do you want an exact clone of the shitty system you already have? ;-P
May 06 22:29:03 <veremit> oh wait .. no alts today lol
May 06 22:29:22 <veremit> +1 agmlego
May 06 22:30:20 <agmlego|skynet> zmatt: And no, we do not use DMX to control big industrial machines. It is imprecise, low-performance, lacks addressing in the quantities needed, and is overly cumbersome to use in a noisy environment.
May 06 22:31:01 <zmatt> I wouldn't expect DMX in those applications either
May 06 22:31:14 <zmatt> but it's perfectly well suited for its intended applications
May 06 22:31:40 <zmatt> and switching to something that's much more complicated and harder to get right does not sound like a benefit to me
May 06 22:31:46 <agmlego|skynet> Then again, I would not expect anyone to be using DMX even for what it is theoretically designed for.
May 06 22:31:54 <agmlego|skynet> How is Ethernet harder to get right?
May 06 22:32:13 <zmatt> getting guaranteed reliable timing over Ethernet right
May 06 22:32:22 <agmlego|skynet> How guaranteed do you really need?
May 06 22:32:28 <agmlego|skynet> Like, for reals?
May 06 22:34:33 <zmatt> to be honest I do not know any concrete numbers there on what you can or can't get away with, so I'm not going to guess either, but it replaced directly driving lights with big multicables of analog signals
May 06 22:34:47 <zmatt> :P
May 06 22:35:16 <zmatt> ethernet by itself is just "best effort delivery"
May 06 22:35:19 <GenTooMan> The solution is obvious WIRELESS DMX! :D
May 06 22:36:02 <agmlego|skynet> zmatt: I can see I am not talking with someone who is willing to talk, so i will stop.
May 06 22:36:07 <zmatt> and yes there are low-cost ARM-based microcontrollers with Ethernet, but DMX only needs a dirt-cheap uC with an UART (and a decent receiver)
May 06 22:36:10 <zmatt> ?
May 06 22:36:44 <zmatt> don't get me wrong, I do like ethernet control for plenty of applications
May 06 22:37:24 <agmlego|skynet> zmatt: You know no concrete numbers and yet you maintain that Ethernet could not possibly suti your special application. You repeatedly call Ethernet complex and disregard the fact that DMX is one of the few protocols in common use still using terminators.
May 06 22:37:48 <agmlego|skynet> I cannot make progress in this conversation, so O am not going to participate in it any longer.
May 06 22:38:17 <zmatt> agmlego|skynet: terminators are needed on any transmission line; by being a single line DMX does allow easy daisy-chaining
May 06 22:38:38 <zmatt> I don't seriously see a terminator as any sort of burden
May 06 22:39:04 <zmatt> a star topology would get a lot messier in practice
May 06 22:39:13 <zmatt> then you have lots of fixtures in a row
May 06 22:39:15 <zmatt> *when
May 06 22:42:43 <zmatt> I'm still looking for the official number of cable length btw, but iirc it is somewhere around 1 km
May 06 22:43:04 <zmatt> *official number for max cable length
May 06 22:45:58 <GenTooMan> so that would be 100kbps maximum data rate or such?
May 06 22:46:41 <zmatt> it may have been shorter, but definitely more than the 100m of ethernet
May 06 22:47:49 <zmatt> seeing 540m stated elsewhere, or 300m if RDM is used
May 06 22:49:23 <zmatt> I wish I could find it in the standards themselves... I suspect it may be in some other referenced standards instead :/
May 06 22:50:04 <ds2> 1Km loops? hmmmm
May 06 22:50:12 <ds2> that can generate some nasty spikes
May 06 22:53:03 <zmatt> ds2: very long dmx chains definitely are more sensitive to the quality of the cables and fixtures (and omitting the terminator would likely result in fun)
May 06 22:53:41 <zmatt> ugh, I'm done dredging through standards...
May 06 22:53:46 * zmatt washes hands
May 06 22:54:06 <ds2> don't think you can remove the stench of standards by washing
May 06 22:59:33 <zmatt> still need to write an E2E post inquiring why exactly they recommend connecting am335x VDDS to LDO1 of the pmic rather than LDO3, and whether they're aware that this completely breaks rtc-only mode (and actually seems to make leakage worse rather than better, although I still need to check its effect on peak currents)
May 06 23:04:59 <ds2> got a new desk?
May 06 23:05:48 <ds2> and need to crave a head sized dent on top of it?
May 06 23:21:43 <zmatt> hehe
May 06 23:24:40 <zmatt> agmlego|skynet: I guess part of the issue here is that ethernet has a rather large gap between the service it is *specified* to deliver and the service it usually delivers in practice.  I do tend to attach value to correctness based on specification (may be due to my background in mathematics) rather than merely "it works in practice"
May 06 23:24:58 <zmatt> agmlego|skynet: possibly I care more about that than I should
May 06 23:26:41 <zmatt> although with timing issues I get especially cautious, since failures there are likely to cause random and hard to reproduce/diagnose problems
**** ENDING LOGGING AT Thu May 07 02:59:58 2015