#milkymist IRC log for Tuesday, 2011-12-06

wolfspraulaw_: good morning!01:59
wolfspraulthanks a lot for pushing Werner's package and the one for our new Australian customer out yesterday02:00
wolfspraullots of details, all done - THANKS!02:00
wolfspraulnow, let's chat about rc4 status02:00
aw_wolfspraul, hi good morning !02:00
wolfspraulI understand the reset ic, usb power switch and adv7181c already are 'almost' design-verified02:00
aw_I ought to and tried to send them.02:00
wolfspraulare you 100% confident about those 3 changes?02:01
aw_not 100% confident though. because we only have finished one board without reliability test like Werner did tons of power-cycles.02:02
wolfspraulwell sure02:03
wolfspraulbut so far it all looks good, right?02:03
wolfspraulso you will finish a second board, and eventually Werner will get his and test some more...02:03
wolfspraulbut it sounds like those 3 are 'almost' finished, to me :-)02:03
aw_yes, all looks good so far now.02:03
wolfsprauldo we want to remove the audio expansion header in rc4 ?02:04
aw_mmm ... this I've not looked into but just knew Joerg's good idea.02:05
wolfspraulthat's not Joerg's idea02:07
wolfspraulJoerg said something about R11, but I am wondering whether we should just *remove* the entire audio expansion header02:07
aw_1. If I am a hacker with enthusiasm on audio, I would still like to keep it. But this seems that very rare condition to use it02:07
aw_hup ? so misunderstood by me.02:08
wolfspraulwe have too many loose ends on Milkymist One already, removing this expansion header means one less of them02:08
wolfspraulno you are right, but Joerg tried to fix the audio expansion header and I am wondering whether we should remove it :-)02:08
wolfspraullet's see what Werner or Sebastien think02:08
wolfspraulI rather focus our super limited resources on making more out of the fpga expansion header02:09
wolfspraulaw_: ok, which other big items do we still have now?02:09
wolfspraul1. dvi-i, single-link or dual-link. 6-layer vs. 8-layer pcb, question whether we should move fpga pins and break (some) bitstream compatibility02:09
wolfspraul2. new leds02:09
aw_Until now, I don't see any hacker except Werner who may try to use this audio expansion header to link/connect with other instruments.02:10
wolfspraul3. proposal to go to 3 or 4 usb connectors. depends on space, maybe connector like http://search.digikey.com/us/en/products/690-008-621-013/151-1085-ND/80618402:10
wolfspraulWerner is not using the audio expansion header and doubt has plans to do so02:10
wolfspraulbut let's see what he says later02:10
wolfspraulaw_: did you hear about the idea of increasing the number of USB connectors?02:11
wolfspraulit's just an idea, and most likely will cause too many space problems02:11
wolfspraulwe definitely don't want to change pcb size02:11
wolfspraulbut if you go to the layout house, maybe they can just think about that as well, 3 or 4 usb ports...02:12
aw_about idea of those expected adding fpga pins, I think that we should a clear 'fpga pins of allocations' to estimate how many pins will be added in usb/DVI/led/usb.02:17
aw_I'll estimate adding pins then go to make an appointment with house.02:18
wpwrakwolfspraul: you're 100% right ;-)02:19
aw_I seemed heard from you about increasing the number of usb con. But don't know the final.02:19
wolfspraulwait02:19
wolfspraulaw_: one by one02:19
wpwrakwolfspraul: i don't care about J3. if it's there, it doesn't bother me. if it goes, i won't mourn its passing02:19
wolfspraulaw_: please let's plan to remove j3 in rc4, unless Sebastien objects02:20
wolfspraulwe have too many loose ends, and that is one of the best to start cutting, imho02:20
wolfspraulaw_: can you add that to the wiki page or should I do it?02:20
aw_wolfspraul, you meant directly add 'remove' idea in known issue wiki page firstly ?02:21
wolfspraulyes02:21
wolfspraulremove J3 (audio expansion header)02:21
wolfspraulI don't remember Sebastien fighting for it strongly anywhere, but if I'm wrong and he objects we just keep it, otherwise remove02:22
wolfspraulI know the product and future path well enough to feel that this is a good move :-)02:22
wolfspraulaw_: then, second thing02:23
wolfspraulabout "adding fpga pins" - let's clarify the language02:23
wolfspraulby default, we don't want to change any current pin/wire assignments02:24
wolfspraulso when we 'add' new wires, they have to be routed to pins that are currently free (!)02:24
wolfspraulthat's the first idea02:24
aw_I don't know what the reasons about 'remove' J3 is. Just because Werner don't care ?02:24
aw_yes, go on02:24
wolfspraulnobody uses it today or tomorrow02:24
wolfspraulaw_: no it's not just because Werner doesn't care, that would be a bit drastic :-)02:25
wpwrakand i think it contains some signals that don't really make sense. i think that was what started the discussion. don't remember the details, though02:25
wolfspraulwe discussed J3 before several times, and there was always confusion, lack of interest, etc.02:26
wpwrak(drastic) poof, there go 99.99% of the world ;-)02:26
wolfspraulso the bottom line of that now is that I say "let's remove it"02:26
wolfsprauland then I find out whether someone objects02:26
wolfspraulbut in order to get those people to speak up, let's just start by removing it :-)02:26
wolfspraulso add to the wiki page etc.02:26
aw_1. usb switches circuit: 6 pins are added, FLG * 2, LED (usb-A/B) * 2, EN * 202:27
aw_okay .. I'll remove J3 later02:27
wolfspraulyeah :-)02:27
wolfspraulthanks02:27
wolfspraulthe only reason to keep it would be an objection from Sebastien, which we will find out about in a few hours02:28
wolfspraulotherwise it's gone02:28
wolfspraul(or maybe someone makes a killer argument why to keep it, who knows :-))02:28
aw_2. reset circuit: IO_L48N_1 * 102:28
aw_wait ... I don't want to discuss too many though. :-)02:28
wolfspraulyes02:28
wolfspraulsorry02:28
wolfspraulJ3 is settled for now02:29
wolfspraulnow ... new fpga pins02:29
wolfspraulgo on02:29
aw_for me, I need firm data which is the added(expected) pins that I talk to house. :-)02:29
aw_so let's estimate how many we 'probably' add in. :-)02:29
aw_so:02:30
aw_a) usb power switch: 6 pins.02:30
aw_b) reset circuit: IO_L48N_1 * 1pin02:30
wolfspraulthe 6 pins from usb already include 2 leds, right?02:31
wpwrakmaybe mention J3 on the list ? some people may not pay attention to everything that happens here02:31
aw_yes, 2 of 6 pins are 2 leds came from fpga02:31
wolfsprauloh wait02:32
wolfspraulthe J3 is already on the wiki :-)02:32
wpwrakthe LEDs wouldn't be just USB. it would be one LED per connector. USB, video, MIDI, ...02:32
wolfspraulwe discussed this several times already :-)02:32
wolfspraulwiki says "DNP J3 in RC4, and all resistors connected only to it (which is R6 to R12, but keep R2 to R5 and R14 to R16) "02:32
wpwrakwiki is the attic ;-)02:32
wolfspraulI think not only 'dnp', but totally remove02:32
aw_c) there's an idea about leds array (maybe), so this may also combine those two led from usb switch circuit.02:33
wolfspraulled array?02:33
wolfspraulwhat is that?02:33
aw_led array likes one arrow with 8 leds.02:33
wpwraki think the led array was a misunderstanding. all we really talked about was a lot of leds02:34
wolfspraulyes02:34
wolfspraulno led array02:34
aw_wpwrak, so what kinds of led type ?02:34
wolfspraulhttp://search.digikey.com/us/en/products/APT1608SGC/754-1121-1-ND/174783802:35
wolfspraulaw_: http://en.qi-hardware.com/wiki/Milkymist_One_RC3_Known_Issues02:35
aw_ah ? single led still.02:35
wolfspraulaw_: we only want 1 type of led on the whole board02:35
wolfspraulso same as the D1/D2/D3 we have now, or we change all leds to that one from digikey02:36
aw_i see02:36
aw_so how many real leds related to CONs we want ? so let's define now. Can we ?02:37
wolfspraulwait02:37
wolfspraulit's all on the wiki already02:37
wolfspraullet's go through the items like you started02:37
wolfspraulso 6 new wires for usb, including leds02:37
wolfspraulb) reset circuit: IO_L48N_1 * 1pin02:38
wolfspraulI didn't know there was a new wire from the reset circuit to the fpga :-)02:38
aw_oah ~ sorry. so total is 14 pcs led02:38
wolfspraulwhat is that for?02:38
wpwrakthe led situation is still unclear. lekernel wants white leds, but that would mean that they need a fet/bjt to switch (and supply from 5V)02:38
wpwrakwe also don't have the locations yet02:38
wolfspraulaw_: yes, *proposed* is 14, including 2 usb, from wiki "total of 14 new leds proposed: 2*dmx, 2*midi, 3*video-in, power, 2*usb, ir, dvi-i, ethernet, memcard "02:39
wolfspraulbut we need to see what fits etc02:39
aw_ha ~ good02:39
wolfspraulso first we try to list all our *goals*02:39
wpwrakissue #3 is that, if at some point in time we go for an M2 with a metal (= not transparent) mounting plate, adding LEDs will be harder. so that might imply a feature regression02:39
wolfsprauland then we prioritize the goals02:39
wolfspraulthe leds are not a very high priority for me02:40
wolfspraulbut I like the idea you proposed about demand/activity/problems02:40
wolfspraulaw_: highest priority now (with reset/usb power/adv7181c done) is dvi-i02:40
aw_i need to calculate how many we would like, so i have firm account to discuss with house.02:41
wolfspraulI think we should first try to get our highest-priority problems solved02:41
wolfsprauland then the lesser ones, if still possible02:41
aw_wolfspraul, okay on priority02:41
wolfspraulof course we can keep the lesser ones in mind from the beginning02:41
wolfspraulbut there is no point in adding leds and then removing them again when we start working on dvi-i :-)02:42
wolfspraulI didn't even know we already added 2 leds for usb02:42
wolfspraulbut ok, fine. leave them there now, use same leds as d1/d2/d3 for simplicity02:42
aw_okay on same leds.02:43
wolfspraulnext big thing is dvi-i02:43
wolfspraulsingle-link or dual-link02:43
wolfspraul6-layer vs. 8-layer (need info on costs and risks to go to 8-layer)02:43
wolfspraulin my opinion dual-link would be good because easily accessible pins would be exported and could be used for hacking purposes02:44
wolfsprauleven if we don't need dual-link for pure high-res reasons02:44
aw_wpwrak, btw, the shipment to you that I didn't soldering tow wires from J21 for usb switch two pins, fyi. :)02:44
wolfspraulin the dvi-i/single/dual-link work, there is a twist02:47
wolfspraulaw_: let me explain02:47
wolfspraulwerner proposed to move *existing* vga/codec wires to a new place, basically cleaning up some of the current wiring02:47
wolfspraulor maybe move the memcard to a new place02:48
wolfspraulanyway he wants to make space for the new digital video wires on the same side as the dvi-i connector will be02:48
aw_when heard of that 8-layer to approach for dvi purpose, it's tough though. :)02:48
wolfspraulmoving existing wires (memcard I believe) is a challenge for the Milkymist project overall, in my opinion02:48
wolfspraulnot necessarily a bad challenge, but a challenge02:49
wolfspraulwe have to support old and new users, possibly do more builds, explain people which one they need, or auto-detect, etc.02:49
wolfspraula lot of small little usability details that we are already weak at02:49
wolfsprauldo we want that challenge now?02:49
wolfspraulI don't know02:50
wolfsprauldepends on how bad dvi wiring is without moving memcard (or whatever it was)02:50
wolfspraulbut I don't want to be the only one who has to care about users that fall into traps because later we are too lazy to communicate and smooth over the breakage we caused02:50
wolfspraulwpwrak: aw_ what do you think?02:51
wolfspraulaw_: do you understand what I'm talking about?02:51
aw_wolfspraul, understood the background of dvi need in m1 now.02:52
wpwrakmy concern would be that you have to run a lot of signals across the FPGA if you don't rearrange. this can produce the most interesting signal integrity problems02:53
wolfspraulyes02:53
wpwrakand, of course, increases routing pressure just where it's already the worst02:53
wolfspraulaw_: do you understand that?02:53
wolfspraulwe need to make sure this message goes to Adam and layout folks without too much loss-in-translation02:53
wolfspraulotherwise very bad things may happen :-)02:54
wolfspraulaw_: basically we are thinking how to route the new digital video signals to the fpga02:54
wolfspraulI think with single-link we have 6 new wires, with dual-link 12. is that correct?02:55
aw_i could only to probe/know some real routes if house they really did dvi in 6 layers. like wpwrak just said 'rearrange' and 'increasing routing pressure' already let m1 get the WORST even if we stick on 6 layers.02:56
wolfspraulof course, we have to define what we want first02:56
wolfspraulwe want dual-link02:57
wolfspraulwe want to stay with 6 layers02:57
wolfspraulwe want to not move existing pins02:57
wolfspraulnow... most likely we cannot get all three of those things02:57
wolfspraulso we are thinking ahead how/where to make compromise02:57
wpwraki think you need the clock too. so 8 for single, 14 for dual02:57
wolfspraulok thanks, was just checking02:57
wolfspraulpin 16, hot plug detect? http://en.wikipedia.org/wiki/DVI-I02:59
wpwrakdunno. if useful, routing isn't critical03:00
wolfspraulok03:00
wolfspraulaw_: so let's first define the goals, as I wrote above03:00
wolfspraul1. dual-link, total of 8+6=14 new wires03:00
wolfspraul2. stay with 6 layers03:00
wpwrakall you really care about are those fast signals. the rest can come from the other end of the board ;-)03:00
wolfspraul3. do not move existing pins on fpga like memcard03:00
wolfspraulmost likely we cannot achieve all these goals03:00
wolfspraulthat depends on feedback from layout03:01
aw_wpwrak, I don't think lekernel will agree even to rearrange those a lot of signals due to added routes for dvi. But your three 'wants' will never be happened to take if we still take conditions into 'most interesting digital/analog signal integrity'.03:01
wolfspraulyes03:01
wolfspraulwe know that03:01
wolfspraulbut first we define the goals03:01
wolfspraulthen we find out the problems03:02
wolfspraulthen we compromise03:02
wolfspraulwe can do single-link, no problem03:02
wolfsprauldual-link is really only for hacking, because in my opinion it neatly exposes some wires, easily accessible outside03:02
wolfspraulwe can move memcard wires03:02
wolfspraulI also have no problem with that, I like the challenge of making milkymist in general more flexible/robust/documented to survive such changes03:02
wolfspraulbut it's a lot of work too!03:03
wolfspraulunless we don't care about our users and just create a fragmented mess where everybody who doesn't like to go through messy tools and sources will just die03:03
wolfspraulwe can go to 8-layer, but that depends on feedback from layout or Adam about costs and risks03:03
wolfspraulhey03:04
wolfspraulworst case03:04
wolfspraulno dvi at all :-)03:04
wolfspraulaw_: we try to explain the goals and compromise thoughts here, to get us all onto the same idea...03:04
wolfsprauldo you roughly understand those thoughts?03:05
aw_wolfspraul, yes. i know what you are doing to me and get the same picture.03:05
wolfspraulyes, good. great.03:05
wolfspraulso are we all 100% in sync already?03:05
wolfspraulWerner, Adam, Wolfgang ?03:05
wolfspraulanything I forgot?03:06
aw_thinking ... second03:06
wolfspraullet me try to lookup which signals werner proposed moving03:06
wolfspraulsure take your time03:06
wolfspraulok there are a lot more details in Sebastien's notes http://lists.milkymist.org/pipermail/devel-milkymist.org/2011-October/001966.html03:07
wolfspraulwerner "Would moving some of the bank 0 I/Os to bank 2 to make room be an03:08
wolfsprauloption ? If bank 0 is U22A, SD_* and LED1/2 may be suitable03:08
wolfspraulcandidates for a relocation."03:08
wpwrakwhat voltage is this anyway ?03:09
wpwrakah, sebastien's mail already has the bank. perfect03:10
wolfspraulI don't understand the exact consequences of moving pins03:12
wolfspraulthat's a problem (for me :-))03:12
wolfspraulif we succeed, it's definitely good for milkymist as a platform. but this is a communication and documentation challenge as much as a pure source/hacking challenge, and I'm not even sure everybody understands what that means :-)03:12
wolfspraulit's super easy to change a few numbers in the sources, of course03:13
wolfspraulbut how about builds? how about testing? how do people find out which build/image/binary they need? can we auto-detect? etc.03:13
wolfsprauldo we even have the patience to go through those things?03:13
wpwraki think the consequences would be:03:13
wpwrak- some build-time switch03:13
wpwrak- twice the distribution build time03:14
wolfspraulcan the 'twiceness' be localized to the bitstream?03:14
wpwrak- "rushed" changes would only be available for one hw version (most likely the latest)03:14
wolfspraulin other words, is this change transparent for bios/rtems ?03:15
wpwrakyes, i think the rest of the system could probably stay the same03:15
wolfspraulso the web update could detect which hw revision it's running on and download the appropriate bitstream?03:15
wpwrakmaybe you cuold even have a run-time switch in the fpga, but that may create routing pressure issues in there and may have other unintended consequences. so i wouldn't count on that possibility03:16
wolfspraulhow big is the testing risk? i.e. if the person doing build testing only has the latest hw revision, can he assume the differences to older hw revisions are small enough to avoid having to do separate testing on the older hw?03:16
aw_wpwrak, i think i need to absorb sebastien's mail and see the directional trend of routes on wiring bank2.03:17
wolfspraulaw_: yes, think about all this a little, that's good03:17
wolfspraulit is important that we do dvi well03:17
wpwraki think once the two versions have been tested, there's little risk of regression on the part that's not receiving continuous attention03:18
wolfspraulI totally agree that we don't need that TI TMDS buffer03:18
wolfspraulthe only reason the TI TMDS buffer is on that devel board is because TI paid and that's how devel boards are financed...03:19
wolfspraulwpwrak: ok, so..03:19
wolfspraulyou still think moving memcard and 2 leds to another bank is a good idea?03:19
wpwraki'll bookmark this comment for the day we find some reason why we need that driver chip ;-))03:19
wolfsprauloh sure, i understand03:20
wolfsprauleverything has risks03:20
wolfspraulbut blindly adding 'safety' chips is also a risk03:20
wolfspraula bigger one than following practical design experience of people who have made working products without this chip03:20
wolfspraulif we one day understand very well why this tmds buffer chip should have been there from day 1, so be it03:21
wolfspraulI looked into it a while ago and some people gave me feedback, and I remember "not needed"03:21
wolfspraulthat's just me though03:21
wolfspraulwpwrak: in general I even like the idea of moving/cleanup up fpga pins, because we will have more of that kind of challenge in the future03:22
wolfspraulso maybe we can just take it on now :-)03:22
wolfspraulplus, Sebastien may say, the memcard is even disabled in software right now03:22
wolfspraulso worst case we break something nobody can be using anyway, he he03:22
wolfspraulMilkymist logic03:22
wolfspraulbut seriously, if we can survive such a pin move and support everybody well, it's actually a win for Milkymist imho03:23
wpwrak(banks) if you look at the schematics and the board, you see that everything video is nicely on the same side03:23
wpwrak(banks) U22C is just on the other end of the chip -> routing hell03:24
wpwrak(driver chip) not sure if they measured our kind of scenario, i.e., with possibly long cables and such03:25
wolfspraullet's see what Sebastien says about moving memcard/led pins, we need his help on those matters anyway03:26
wolfspraulI described my current thinking about the idea03:26
wolfspraulI like it, but I think it's a challenge. good or bad challenge, or good or bad timing - I am not sure.03:26
wpwrak(survive the move) this sound to me a bit like the fear of going from one .c file to having multiple compilation units ;-) at some point in time, pin reassignment is inevitable. the only thing you can choose is whether you become good at doing it earlier or later03:27
wolfspraulyes03:27
wolfspraulit's just about timing of the challenge, agreed03:27
wolfspraulbut I don't want to rush into this and cause breakages and ignore the pain of our users03:27
wolfspraulI think you know what I mean03:27
wolfspraulthe ti tmds buffer chip is meant for cases where the connector is far away from the signal processing chip, for example in a large TV03:29
wpwrakwhat does the distance to the connector matter if there are meters of cable afterwards ?03:30
wolfspraulthat doesn't mean that it cannot be helpful in other cases as well, I don't know how the different parts are standardized, cables etc. but we should plan without this chip, the only reason we discuss it is because TI made sure it's on one particular devel board03:30
wolfspraulwpwrak: yes but we are talking about standards, and they set requirements for connectors, cables, etc. I would think...03:31
wpwrak(only because it's there) yeah, that's true :)03:31
wolfspraulif the signal arrives in too bad of a shape due to an out-of-standard cable, I wouldn't count on a wonder-chip to help me either...03:31
wpwrakhehe :)03:32
wolfsprauland actually on that devel board, one hdmi input goes through that tmds buffer, the other one doesn't :-)03:32
wolfspraulthat's all fine for a devel board, but for now we can and should plan without this chip03:32
wolfspraulit's meant for large tvs where the connector is 1m or more apart from the signal processing chip03:32
wolfsprauleven if we need this chip, there is no shortcut for us to understand why we need it03:34
wolfspraulor worst case we have to try on a that devel board, for example, where we can quickly switch to an hdmi path with and without that chip03:34
wolfspraulbut adding blindly is wrong03:34
wolfspraul(especially with prior experience that it is not needed, see the links from stekern)03:34
wpwrakyeah. life's easier with fewer chips anyway :)03:35
xiangfuHi07:59
xiangfuI am play the DMX device now.07:59
xiangfuand try to learn the DMX stuff.07:59
xiangfuthere are address and channels.07:59
xiangfuDMX-light is kind of simple then the DMX-MOVING-HEAD08:01
Scopeukwhat are you trying to do xiangfu?08:02
xiangfuwow. those kind of device have the 'Sound Activated modes'08:02
xiangfuScopeuk, I bought four DMX devices.:08:03
xiangfuhttp://en.qi-hardware.com/wiki/Milkymist_One_accessories#DMX08:03
Scopeukahh, what devices?08:03
xiangfuone LED light, one Moving-Head, one Laser.08:03
xiangfuone DMX controller.08:03
Scopeukgot it all up and running?08:03
xiangfuScopeuk, learning now.08:04
xiangfuScopeuk, I tried LED light and Moving Head.08:04
xiangfuI can control that under 'DMX desk' under flickernoise.08:05
xiangfuand the only one DMX-output patch works out of box.08:05
xiangfuI want understand the 'channels' and how to connect them all to m1.08:05
Scopeukok08:05
Scopeukdmx protocal has 512 channels08:05
Scopeukeach channel has a data value between 0 and 12808:06
Scopeukwell 0 and 127**08:06
xiangfuScopeuk, is those kind device can connect like  light----moving_head----laser---m1?08:06
Scopeukyes08:06
Scopeukeach device has an address08:06
Scopeukthis is itsfirst address08:06
Scopeukfirst channel**08:06
Scopeukeach light (lets call them fixtures to include the laser) will use a number of channels probably 3 or 4 for the led light, around 6 to 12 for the moving head and i'd guess between 4 and 10 for the laser08:08
Scopeukgenerally you set each fixture so that none of its channels overlap with the other fixtures, then you run a wire from dmx out on the controler to dmx in on the first fixture08:10
Scopeukthen from that fixtures dmx out to the next fixtures dmx in08:10
Scopeukhttp://bruce.pennypacker.org/2009/12/04/dmx-512-primer-an-end-users-perspective/ a little reading08:10
xiangfuthanks.08:11
Scopeuknp08:11
xiangfu"It is possible to split a DMX cable"08:11
Scopeukits recomended that you don't08:12
Scopeukgenerally your much better off running a single chain through each light. if you need to split it is highly recomended you use a "dmx buffer" which is basicalyl a big set of opto isoltors08:13
xiangfuScopeuk, ok.08:14
xiangfuScopeuk, there are 'address' and 'channels' right?08:14
Scopeukthe address of a light is the number of the first channel it will listen to08:14
xiangfuok.08:16
xiangfu"each channel has a data value between 0 and 128"08:16
xiangfubut in the manual. it said ' 0 ~ 255 '08:16
xiangfulike:08:16
xiangfu| CH2 |  play speed | 0 ~ 255 |08:17
xiangfuwe need a DMX value display under 'DMX desk'08:18
Scopeuksorry it is 255, 127 is midi08:19
Scopeuksorry08:19
xiangfuScopeuk, sorry. what do mean " each device have an address, this is the first channel"08:25
xiangfujust a little bit confuse in 'address' and 'channel'08:26
Scopeuklet me phrase it diferently08:26
Scopeukyour lightting desk or M1 outputs 512 channels, the device has an "address" setting, this address is a channel number, the adress specifies the first channel which has an effect on the light  (the address will determine which channel on your desk relates to CH1 in your lights manual)08:28
xiangfuScopeuk, thanks. I got it.08:32
Scopeukok i gotta run, good luck08:33
xiangfuis this device have 5 channels. and I set the address to 1. then it will react when m1-DMX-DESK-1/2/3/4/5 changed08:33
xiangfus/is/if08:33
xiangfuif I set the address to 10. it will react when m1-DMX-DESK-10/11/12/13/14 changed.08:33
xiangfuScopeuk-AFK, thanks08:33
xiangfuok. just play those three devices.09:12
xiangfu(only problem is those devices is really Noisy)09:14
xiangfum1 works out of box with those kind of DMX device.09:15
xiangfuwe have to improve our flickernoise to support more output in patches.09:15
xiangfuso far. it like. m1 can control 8 DMX-lights, because there are 8 DMX variable output. and DMX-light only needs one channel.09:16
xiangfuthe laser using 3 channels. and moving-head using 5 or 13 channels(depends on the configure)09:17
xiangfuwhat is the 'Chain' and 'DMX spy' for?09:18
lekernelchain -> connect the M1 DMX out to M1 DMX in (otherwise DMX out is controlled from the patch)09:23
lekernelDMX spy -> display last modified channels in DMX in09:23
azonenbergwpwrak: what i was saying earlier today09:24
azonenbergwas that it passes timing09:24
azonenbergfaster than the numbers the datasheet says it should09:24
azonenbergi havent yet tested to see if it actually works09:24
azonenberglekernel: So apparently my really fast adder is pointless09:25
azonenbergBUFGs, according to the datasheet, top out at 400 MHz09:25
azonenbergand i'm pretty sure the normal xilinx 32-bit adder still works at that speed09:25
azonenbergBut somehow my design passes timing at 50009:26
azonenbergso either trce doesnt check component switching limits on PLLs and BUFGs09:26
azonenbergor i'm misreading something09:26
xiangfuabout Media wall and DMX devices.09:27
xiangfuthere are 4 lights. 1 laser. (not sure if there is moving-head device inside media wall, didn't see that in media wall)09:27
xiangfulet's said there are 4 lights + 1 laser + 1 moving-head inside media wall.09:28
xiangfuthen for now. patches can controller 4 light + 1 laser or only moving-head.09:28
xiangfulight  needs one channel09:29
xiangfulaser needs three channel09:29
xiangfumoving-head needs 5 channels09:29
wolfspraulinteresting09:29
wolfspraulwhat exactly can those things do?09:29
wolfspraulthe light can be turned on/off?09:29
xiangfuwe have 8 DMX output variables in flickernoise.09:29
wolfsprauleach pixel/led individually? or only all of them together?09:29
xiangfuwe should make it to 512. :D09:29
wolfspraulcan the color be controlled?09:30
wolfspraulintensity?09:30
xiangfu( light can be turned on/off?) yes.09:30
lekernelazonenberg: you can route clocks without BUFGs, only you'll get a lot of skew *g*09:30
wolfspraulI don't mean in theory in the protocol, but with the specific equipment you bought and have now...09:30
azonenberglekernel: lol09:30
azonenbergNot an option :p09:30
azonenbergI mean even 400 would be nice09:31
xiangfuthe light have 6~8 colors ( I count them manually. nothing in manual :)09:31
xiangfuyes. color can be controlled.09:31
lekernelah? I thought your design was about squeezing every picosecond out of the timing :)09:31
wolfspraulyou can switch between those fixed colors? like green, blue, red?09:31
xiangfupixel/led individually. not this device.09:31
lekernelyou should rewrite a new P&R algorithm that doesn't use the BUFG, since they are slow ;)09:31
azonenbergLol09:32
wolfspraulhow about intensity?09:32
azonenberglekernel: I also have to be able to fill the entire device with a working design09:32
xiangfuwolfspraul, yes.09:32
xiangfuswitch between those fixed colors <-- yes09:32
xiangfuintensity <--- no.09:32
wolfspraulwow so it's either full on, or totally off?09:33
xiangfuit can be configure to 'auto color chase'09:33
xiangfuwolfspraul, full on or totally off: yes.09:33
wolfspraulmore like a giant blinking led :-)09:33
xiangfuwolfspraul, yes.09:33
wolfspraulwould be great if each pixel could be controlled individually, colors could be set more freely, intensity could be controlled :-)09:34
wolfspraulbut ok, we start09:34
wolfspraulso we have 4 of those giant blinking leds, ok09:34
wolfspraulyou can probably lit your entire room with one of them, no?09:34
xiangfuwolfspraul, sort of.09:35
wpwrakazonenberg: if you can try to make it run at way out of whack speeds, perhaps you can find out if that speed limit is being checked ? it wouldn't be uncommon for a data sheet to give you a pessimistic estimate, and the real device still performing well under worse conditions09:35
wolfspraulxiangfu: and how about the laser09:36
wolfspraulhow exactly does it work?09:36
wolfspraulcan you control the color? intensity? direction? (how freely)09:37
wolfspraulis it 1 beam or what?09:37
wolfspraulI think you have to take some videos :-)09:37
wolfspraulhow quickly can the laser move?09:37
xiangfucontrol color <-- no09:38
xiangfuintensity <-- no09:38
xiangfudirection <-- no09:38
xiangfunot 1 beam.09:38
wpwrakcontrolling the color of a laser is kinda hard ;-) not impossible, but ...09:38
azonenbergwpwrak: What i mean is, there are two differnet specs09:38
azonenbergtiming analysis and the datasheet disagree09:38
azonenbergso 500 is either barely within spec or 20% out of spec09:38
xiangfuit like some 'Pattern'09:38
azonenbergand i have no idea how far i'm pushing it09:38
azonenbergthis is for a relatively accuracy-critical application so i dont want somethign that will misbehave if it gets warm etc09:39
azonenbergalso...09:39
azonenberghow much do you guys know about spartan6 IO clocks?09:39
azonenbergCan you drive LUT logic with them?09:39
xiangfusome 'random pattern'09:39
xiangfusome 'random pattern' keep changing. I can control the change speed.09:40
xiangfuthere are only 'green' and 'red' laser.09:40
wpwrakmaybe the pattern is for safety. so that you can't aim the laser too long at the same spot09:40
wolfspraulwow so also not much control there ,interesting09:41
wolfspraulis that a limitation of the DMX protocol, or just of those lasers?09:41
xiangfu4 lasers: two green. two red.09:41
xiangfuwpwrak, (aim the laser too long) that is a weapon right? (just kidding)09:42
wpwrakazonenberg: i guess you;ll have to ask xilinx on how to interpret those limits. could be that they don't really expect people to read the data sheets and the tools are designed to enforce the real limits. but then, maybe not.09:43
xiangfuwolfspraul, DMX protocol is send out 512 channels with different value.09:43
xiangfuwolfspraul, how to use those value depends on the device design.09:43
azonenbergWell, in any case once exams are over i will be testing on the real chip09:43
azonenbergOf course, i have a problem there too09:44
azonenbergthere is a heatsink on my board09:44
azonenbergi cant see if the chip is a -2 or a -3 :p09:44
wpwrak(4 lasers) oh, wow. isn't that twice the armament spaceship enterprise had ? :)09:44
azonenbergthe datasheet is unclear09:44
lekernelwhat's that board?09:44
wolfspraulxiangfu: but the laser has 3 channels, right?09:44
wolfspraulwhy 3? one for green, one for red, one for?09:44
xiangfuwolfspraul, yes.09:44
xiangfuCH1: mode select09:45
xiangfuCH2: pattern select09:45
xiangfuCH3: speed controll09:45
wolfspraulah ok09:45
wolfspraulwhat kind of integration makes sense for Milkymist, or for a particular patch?09:45
wolfspraulmaybe just at the beginning of the patch you set the laser to a certain behavior?09:46
wolfspraulone needs to try that out with a real device I guess, and see what looks good and makes sense09:46
xiangfuwe have DMX1~8 .09:46
xiangfuwolfspraul, I have tried the DMX-OUT patch with light.09:46
xiangfufor example. at the begin. we can set CH1 to 50 mean DMX mode.09:47
xiangfuthen always change the CH2 by audio-in. the laser will change pattern depends on audio-in09:48
wolfspraulmake some videos09:48
wolfspraulthen we also need to try with jj and see what she likes, or what kidn of music she wants to play09:49
wolfspraulwe can download a selection of free electronic music for example, if that's easy to find :-)09:49
xiangfuwolfspraul, first , needs to finish some patch.09:49
xiangfuthe only one in patchpool. not react to audio-in.09:49
wpwrakmaking a collection of good electronic tracks would be useful for use in demos09:50
wpwrakit's not easy to find good tracks. there's a lot of free stuff around that's only instrumental, but that gets boring quickly when used for a demo09:51
xiangfuwolfspraul, the laser and moving-head device have 'Sound Activated Mode'09:51
wpwrakin a demo, you want something quick, with a strong character. after all, the viewer will most likely be sober, will have context-switched from something else and thus hasn't settled into a clubbing mood, etc.09:52
xiangfumode basically is like : Shutdown, DMX, Sound Activated, Auto.09:53
xiangfuwill try to finish one patch, make DMX react to audio-in09:54
xiangfuchain -> connect the M1 DMX out to M1 DMX in (otherwise DMX out is controlled from the patch)09:56
xiangfuthis is cool. that make this happen. DMX_Controller --------- M1 ------ DMX_fixture_1 ------- DMX_fixture_2 ....09:57
wolfsprauldon't understand09:57
wolfspraulin the current media wall, we have a dmx controller that is hooked up to the 4 leds and 1 laser, right?09:57
xiangfuit's like M1 can take control from DMX_Controller. and give back the control to DMX_controller.09:57
xiangfuwolfspraul, yes. then we just connect m1 between Controller and DMX_fixtures.09:58
wolfspraulyes that sounds good09:58
wolfspraulbut for that m1 would need to continuously forward packages from dmx_in to dmx_out, no?09:58
wolfspraulis it doing that right now?09:59
xiangfulekernel, ^^^^ :)09:59
xiangfuI don't know it's flickernoise side or FPGA side.10:00
Action: xiangfu checking now.10:01
xiangfuthis is controlled by hardware. not software side I think. needs make sure with Sebastien.10:04
xiangfuThru Mode:10:05
xiangfu'to be able to act as a traditional DMX receiving device. the transmitting DMX core can simply forward the incoming DMX signal10:06
xiangfuinstead of transmitting the data from the host CPU.10:06
wolfspraulideally we would want to plug the m1 into an existing wiring, and then be able to listen to or send out messages, in addition to passing through stuff. true?10:07
xiangfuwolfspraul, true.10:07
xiangfubut I think we have to do this:10:08
xiangfuDMX_Controller --------- M1 ------ DMX_fixture_1 ------- DMX_fixture_2 ....10:08
xiangfuif we do this: DMX_Controller------ DMX_fixture_1 ------- DMX_fixture_2 ....  --------- M110:08
xiangfuI don't know what happen. there are two DMX signal send out by DMX_controller and M1.10:08
xiangfuok.10:09
xiangfuif we do this: DMX_Controller------ DMX_fixture_1 ------- DMX_fixture_2 --------- M1 --------- DMX_fixture_3 ------- DMX_fixture_410:09
xiangfuController will control 1 and 2 and M1 will control 3 and 410:10
xiangfuthere will not two DMX signals. because M1 block the Controller signals.10:11
xiangfuin theory.10:11
lekernelif you enable "chain" mode, it will let the controller signals reach 3/410:12
xiangfulekernel, yes.10:12
lekernelbut you won't be able to control 3/4 from the patches, only receive signals from controller10:12
xiangfuok. then M1 is like the DMX device with 8 channels. COOL.10:13
wolfspraulI still don't get it10:18
wolfspraulso M1 can sit in between an existing DMX wiring and route/pass-through so that the devices that were on the bus don't notice any difference at first?10:19
xiangfuwolfspraul, true.10:20
xiangfuwolfspraul, it like M1 can configure to be a DMX_device or DMX_controller.10:21
wolfspraulhow about the media wall? will m1 be able to fit into/integrate with the existing dmx wiring and devices?10:22
xiangfuwolfspraul, perfect fit.10:22
wolfspraulthat's good10:22
xiangfulekernel, http://pastebin.com/58kDPYk010:26
xiangfulekernel,  dmx: if request DMX fail don't change the button status10:26
xiangfujust in case I misunderstand the code again.. if ok. I will commit it. :)10:27
lekernelok10:28
GitHub33[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/r9Ioiw10:29
GitHub33[flickernoise/master] dmx: if request DMX fail don't change the button status - Xiangfu Liu10:29
xiangfulekernel, this one should be also ok. :) http://pastebin.com/jpHk5eSg10:46
xiangfuwe also don't need the  'load_dmx_config(); '  in ' init_dmx()'10:49
xiangfulekernel, here is the new one: http://pastebin.com/bVXNxTLN10:50
lekernelnah, it needs to stay this way10:53
lekernelto reset the configuration on cancel10:53
lekernelvalue = i+1; -> yes10:56
xiangfuhttp://pastebin.com/y7xLucwK10:56
xiangfuI think we can add 'load_dmx_conifg' under 'open_dmx_windows'10:56
xiangfuwait. this one is good I think: http://pastebin.com/bVXNxTLN10:59
xiangfuto reset the configuration on cancel or on open10:59
xiangfuthe bug is like:11:00
xiangfuI fill 600 under DMX8.11:00
xiangfuwhen I click ok. it change 600 to 8. but not change the GUI value.11:00
xiangfuso if I open_dmx then ok (for close the window) the 600 will be always in GUI.11:01
GitHub112[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/6JBDkg11:04
GitHub112[flickernoise/master] fix the value check don't write 0 to dmx variables - Xiangfu Liu11:04
xiangfupush the value = i+1 first :)11:04
lekernelhmm the other (last one) should be ok too...11:06
lekernelthese things are a little messy at times11:07
GitHub145[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/QISXtw11:26
GitHub145[flickernoise/master] load dmx config when open window not close - Xiangfu Liu11:26
xiangfuwpwrak, will send another patch about makefile soon.11:27
wpwrakgreat !11:32
xiangfufix the 80 problem some time lazy to wrap them. and I don't have the line(GUI) that indicate 80 in my Emacs. :(11:33
wpwrakhmm, the 80 characters limit should simply be the right border of the window, no ? or do you use a proportional font ?11:37
xiangfumine is 125 to the right border of the window.11:38
xiangfuthe window is 80. but I always make windows full-screen.11:39
wpwrakargh. so much wasted screen space !11:40
wolfspraullekernel: I think you already ok'ed the DNP'ing of J3 earlier, just double-checking whether that's still ok11:46
wolfspraulI think we should remove it even, not just dnp, since we also have some new routing work to do...11:46
lekernelI don't think the routing in the J3 area is affected, is it?11:50
Last message repeated 1 time(s).11:52
wpwrakshouldn't be unless J21 is moved11:52
wpwraki wish we had something mechanically a bit more reliable for extensions. not just one connector on which any board would act as a lever. more like an inverted U shape, e.g., like the arduino shields or the usrp daughterboards11:54
wpwrakwhat also works is connector on one side and a purely mechanical support on the other. may be difficult to match connectors and standoffs, though11:55
wpwrakGreat Chinese Firewall hard at work ? :)11:56
wolfspraulyeah, terrible11:56
wpwrak(bridge) e.g., there should be room around C25 and C237 (both unpopulated) for another header11:59
wpwrakthat would create a bridge of about 5-6 cm12:00
xiangfuin the DMX-Light manual. there is some text :12:01
xiangfuAt last fixture, the DMX cable has to be terminated with a terminator to reduce signal errors. Solder a 120-ohm 1/4W resistor between pin2(DMX-) and in 3(DMX+) into.12:02
xiangfuis that necessary for all DMX usage? like always have a Terminator at last fixture?12:03
lekernelit's only necessary for long cables, and the M1 has built in terminations and also acts as a repeater in chain mode12:04
wolfspraullekernel: in case you wrote earlier, can you repeat? your feedback on:12:05
wolfspraul1. j3 dnp or remove12:05
xiangfuwhat is the 'repeater' mean?12:05
wolfspraul2. moving memcard and led wires to different bank to simplify dvi routing12:05
lekernel1. DNP, routing in this area shouldn't be affected imo12:06
lekernel2. will break bitstream compatibility12:06
wpwrak(2) #ifdef ?12:09
lekernelI don't think there's a UCF preprocessor12:09
wolfspraulwe know (or assumed) that it breaks bitstream compatibility12:10
wolfspraulbut the question is how you feel about it still :-)12:10
lekernelalso, this will mean 4 bitstreams will have to built and will have to meet timing for each SoC modification12:10
lekernelwell, this sounds rather messy12:11
wolfspraulso you would rather not do this right now12:11
lekernelit's better if it can be avoided, yes12:11
wolfspraulok that's helpful12:11
lekernelare there problems for single-link DVI?12:12
lekernelI think the memory bandwidth will pretty much limit useful resolutions in dual-link modes anyway12:12
wolfspraulwe don't know yet, werner proposed the cleanup as a fresh idea, and we wanted to understand the consequences of moving existing wires around12:12
wolfspraulI see dual-link as interesting mostly because it exports some easily accessible wires out of the box, for hacking12:13
wolfspraulyes I agree for the high video resolutions and framerates I doubt we will need dual-link anytime soon12:13
wolfspraulbut some easily accessible wires coming out of the box? if it's easy sounds like useful to me, no?12:14
wpwrakif you can run two independent displays from dual-link, the 2nd link could also be used for a GUI, with very limited bandwidth requirements12:14
wolfspraulthat's not how it's meant at least, it's dual-link not dual-head12:14
wolfspraulas I said I see them simply as wires for hacking, coming out of the box on a neat connector. anything wrong with that idea?12:15
wpwrakdual-head seems to be possible :) http://www.amazon.com/Tripp-Lite-Dual-Link-Splitter-1-foot/dp/B000VLZ98612:16
lekernelit it comes at a large cost, better not do it and use J21 instead12:16
wolfspraulbtw we are mixing different arguments now12:16
wolfspraulone is the value of dual-link over single-link, for what purpose the additional wires might be useful etc.12:17
wolfspraulthe other one are the difficulties arising from moving existing wires, for example memcard and led12:17
wolfspraulthe third one are actual routing problems, which we don't know yet12:17
wolfspraulso far I understand sebastien would rather not move existing wires now12:18
wolfspraulso we try to avoid that12:18
wpwrakheh, we should PWM VGA. then we'd have enough lines left ;-)12:18
wolfspraulso the easy ones first. I still did not hear any objection against removing j3.12:31
wolfspraullekernel: do you favor dnp over removal of j3?12:32
lekerneldnp12:36
lekernelremoval is probably more work actually12:36
wolfspraulok, dnp12:37
wolfspraulthanks!12:37
wolfspraulmove existing wires: rather not12:37
wolfspraulalso answered12:37
wolfspraulthen I have one remaining question ;-)12:37
wolfspraulhow do you see the value of dual-link as a way to get hackable wires from the fpga out of the box, easily accessible on a connector12:38
wolfspraul?12:38
lekernelnot very important, people who do electronics can as well open the case12:41
wolfspraulyes but they may want to give whatever they make to normal m1 users12:42
wpwraki would see more value in improving J21. a DVI-based solution would be complex, just because you also need to bring out the regular video signal12:47
wpwrakso it would either have two DVI connectors, M and F. or it would require a splitter cable12:47
wolfspraulI'm always in favor of improving J21 :-)12:47
wpwrak(and still have one DVI connector)12:48
wolfspraulI tried to understand the 'value' of the idea, sounds like it's > 0 at least12:48
wolfspraulassuming there are no wiring problems12:48
wolfspraulI think dual-link is quite clear to me. not needed for high-res, and somewhat valuable for hacking purposes12:49
wolfspraulimprove J21 - any time12:49
wpwraki think dual link could be interesting for dual link/head. but for add-on circuits, i'd doubt its value.12:49
wolfspraulyes but you pointed to the splitter cable yourself, it does look like another form of 'expansion' to me12:51
wpwrakyes, but it's a complicated one. not many people will want to have to add a DVI connector to their experimental board12:52
wpwrakon the other hand, 100 mil headers are everywhere12:53
wpwrakso i see limited demand for DVI-as-hacking-interface12:53
wpwraki can imagine uses for dual-link DVI-as-extra-video-output12:54
wpwrakand it may have value as dual-link DVI-with-synthetic-signal-for-prototyping12:55
wpwrake.g., to find out whether a board with faster memory could drive this or that screen. or do demo what it would look like, etc.12:55
wpwrakor come up with some crazy architecture that generated screen content on the fly, without a frame buffer :)12:56
wolfspraulwhy do you think that Amazon DVI splitter will split the first and second link?13:00
wolfspraulthe commenters seem to not get it to work, the description is also not clear13:00
wolfspraulthe text says "same image on two monitors"13:00
wpwrakoh. i just thought it would work like this. same image sounds kind silly. lemme read the details ...13:03
wpwrakall those that have a description do indeed just seem to duplicate the signal13:13
wpwrakin some fora, they write things that suggest that dual -> 2 x single is possible. but it's not entirely clear if they really mean that13:14
wpwrakmaybe there's a market opportunity - advanced DVI splitter cables ;-)13:15
wolfspraulthat sounds like Sebastien said - limited value of dual-link for hacking, better to focus on the expansion header13:20
wolfspraulso we only need to do dual-link if it's really easy and doesn't cause much problems13:20
Scopeukxiangfu, did you make any progress on the DMX stuff?19:26
--- Wed Dec 7 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!