| CIA-48 | flickernoise: Sebastien Bourdeauducq master * r7433d6b / (src/sysconfig.c src/sysettings.c): Full network settings dialog box - http://bit.ly/kXDQOP | 00:13 |
|---|---|---|
| wolfspraul | wpwrak: saw your comment about iqc in the backlog :-) | 00:21 |
| wolfspraul | this is probably more qi/copyleft hw specific, not milkymist specific, hope people on this channel don't mind | 00:22 |
| wolfspraul | but... here's my experience on iqc in manufacturing | 00:22 |
| wolfspraul | compare to driving a car and a car accident. the accident happens _although_ you make a lot of precautions. | 00:23 |
| wolfspraul | so the argument "I wear no selt belt because I always drive carefully" just doesn't work. | 00:23 |
| wolfspraul | seat belt | 00:23 |
| wolfspraul | in manufacturing, you really have to embrace the concept that every run is different | 00:23 |
| wpwrak | wolfspraul: (iqc) your comments to qc (with the ben-wpan production) had that feeling of "recently burnt" ;-) | 00:23 |
| wolfspraul | every piece of physical hw is a new one | 00:23 |
| wolfspraul | not at al | 00:23 |
| wolfspraul | it's always the same thing | 00:23 |
| wolfspraul | but it's a fundamental conceptual difference between sw and hw | 00:24 |
| wolfspraul | so many sw people just don't get their minds around it | 00:24 |
| wolfspraul | "let's switch vendors to REALLY GOOD ONES" | 00:24 |
| wolfspraul | that kind of thing | 00:24 |
| wolfspraul | won't help | 00:24 |
| wolfspraul | "let's switch all components to gold" | 00:24 |
| wpwrak | maybe a little ... | 00:24 |
| wolfspraul | 100% gold, just in case! :-) | 00:24 |
| wolfspraul | so the problem is that every run, every piece, is a totally new piece | 00:25 |
| wolfspraul | with a sw mindset you try to solve it fundamentally "once and for all" | 00:25 |
| wolfspraul | because in sw that's how it works | 00:25 |
| wpwrak | but if you run into a lot of such problems, this may also mean that your tolerances are too narrow | 00:25 |
| wolfspraul | it may mean many things. if we find this bad beads now - that's bad. | 00:26 |
| wolfspraul | I'm curious to see what's the root cause in the end. | 00:27 |
| lekernel | it's the bead - period. their DC resistance is too high. | 00:27 |
| wpwrak | yes, i wonder what's up with those beads | 00:27 |
| wolfspraul | and the most annoying thing is, and that's what keeps me thinking about iqc, whatever we do now, there will be new component problems in rc3 | 00:27 |
| wpwrak | lekernel: do you have several of them ? | 00:27 |
| wolfspraul | think of the car accident... | 00:28 |
| lekernel | wolfspraul: one order of magnitude above specified maximum resistance isn't tolerance | 00:28 |
| wolfspraul | lekernel: yes sure, I believe you. and actually it's a creat catch - thanks a lot! | 00:28 |
| wolfspraul | absolutely | 00:28 |
| wolfspraul | annoying | 00:28 |
| wolfspraul | annoying component quality problems :-) but that's how it is... | 00:28 |
| wolfspraul | wpwrak: what I tried to tell you is that this iqc thing tries to catch not a systematic problem, but a sporadic one | 00:29 |
| wolfspraul | it's like the seat belt in a car | 00:29 |
| wolfspraul | you don't know when you need it, or where exactly it will be needed | 00:29 |
| wpwrak | if some of those beads (same shipment) are still around but unsoldered, it may be worth checking them. wouldn't be the first time that a component only goes bad in reflow, and this may point to other issues, such as a mismatched profile | 00:30 |
| wolfspraul | agreed, can be many root causes | 00:30 |
| wpwrak | wolfspraul: (iqc) yes, i understand. basically catch the ones that are broken or out of spec. | 00:31 |
| wolfspraul | also human error | 00:31 |
| wpwrak | wolfspraul: okay, and wrong labels ;-) | 00:31 |
| wolfspraul | and the nice thing about human error is that every time it's a different kind/shape :-) | 00:31 |
| wolfspraul | yes! | 00:31 |
| wolfspraul | and another 1000 options | 00:31 |
| wolfspraul | "oh, I thought..." | 00:31 |
| wpwrak | famous last words :) | 00:32 |
| wolfspraul | I looked at those 10 measurement tables from Adam again, and 5V on the board seems to low across all of them | 00:33 |
| wolfspraul | too low | 00:33 |
| wolfspraul | http://en.qi-hardware.com/wiki/Protection_of_Reversed_Polarity_on_DC_plug-in | 00:33 |
| wolfspraul | lekernel: do you think we should remove the beads? | 00:36 |
| wpwrak | when the device was tested for emc compliance, were these beads already there ? | 00:38 |
| wpwrak | ah, and is the problem now just the beads or both, the beads and the protection circuit ? | 00:39 |
| wolfspraul | maybe just the beads | 00:49 |
| wolfspraul | yes they were there in emi testing | 00:49 |
| wpwrak | (emi testing) then removing the may backfire. better if you can find out what went wrong | 01:10 |
| kristianpaul | hmm, wonder if there is an alredy wishbone cross bar bus implementation, that *may* leads to build an network switch.. | 02:38 |
| kristianpaul | 2 Layer switch at least :) | 02:38 |
| kristianpaul | oh well.. | 02:41 |
| kristianpaul | s/an/a | 02:46 |
| kristianpaul | hmm at cern.. terpstra :-) | 02:57 |
| kristianpaul | so, mimimac2 core is currently been forked to make something else :) | 03:09 |
| kristianpaul | seems the ethernet phy tranceiver is quite similar in protocols to the sige chip :D | 03:10 |
| lekernel | wolfspraul: as wpwrak said... | 07:34 |
| lekernel | not sure what it's going to do EMC-wise | 07:34 |
| lekernel | if it's still ok without yeah remove them | 07:34 |
| lekernel | less sources of problems | 07:34 |
| wolfspraul | lekernel: you mean adam should test removing them, and if the board still works and looks good, we remove them in rc3? | 09:05 |
| wolfspraul | on the emc side, I am not so worried about unknowns. only if someone has a strong feeling, from knowledge or experience, that they could indeed worsen emc a lot on our board, then we should be careful | 09:06 |
| wolfspraul | that doesn't seem to be the case yet. | 09:06 |
| lekernel | wolfspraul: we could do that, yes | 10:19 |
| lekernel | next time we'll go to EMC without any beads and add them only if we get problems... we went a bit too fast here | 10:20 |
| wolfspraul | I don't see which keynote Jon meant to show m1 at... http://www.libregraphicsmeeting.org/2011/program/ | 10:41 |
| wolfspraul | I see two talks for Jon, maybe he means the one at 5 PM on Friday, or maybe something entirely different | 10:41 |
| wolfspraul | we first need to get the facts straight before we can claim something | 10:42 |
| wolfspraul | my current headline for the release is a simple 'Milkymist One video synthesizer shown at 6th Libre Graphics Meeting in Montreal' | 10:42 |
| wolfspraul | that's a very standard press release like issued by the dozen from normal companies, but we can walk through the exercise once if we get enough facts for it together actually :-) | 10:43 |
| lekernel | well, let's ask him | 10:48 |
| CIA-48 | flickernoise: Sebastien Bourdeauducq master * rdc31fa5 / src/sysettings.c : sysettings: autostart mode - http://bit.ly/kCISCQ | 12:05 |
| CIA-48 | flickernoise: Sebastien Bourdeauducq master * r339fec4 / (src/cp.c src/main.c src/performance.c src/performance.h): Simple performance working - http://bit.ly/kgqOY2 | 12:52 |
| lekernel | wolfspraul: switching through all patches on flash with the pushbutton works now | 12:53 |
| lekernel | maybe it can also detect if a video signal is present and skip the video-in patches if not? | 12:54 |
| lekernel | that's a little bit messy though so maybe later ... | 12:56 |
| lekernel | this thing is definitely best used with the camera anyway | 12:56 |
| wpwrak | lekernel: (video in) maybe display an indicator ? "PATCH USES VIDEO IN - IS IT CONNECTED ?" (make it disappear after a while). lazy implementation: just show "PATCH USES VIDEO IN" for a few seconds and don't even try to detect the video. so people know at least what's wrong if they don't get much of a result. | 13:09 |
| lekernel | the (slightly) messy parts are a) retrieving cleanly whether a video signal is present b) determining if a patches uses video in | 13:10 |
| lekernel | so this does not help :) | 13:10 |
| wpwrak | this would allow you to ignore a) for a while :) | 13:22 |
| wpwrak | see also my suggestion on #qi-hardware: add a LED at each input and turn it on if the input is selected | 13:23 |
| wpwrak | (i know you'll hate anything that smells of hw changes ;-) | 13:23 |
| wolfspraul | lekernel: nice, you are fast :-) | 13:30 |
| lekernel | wpwrak: yeah but such messages popping up all the time would be very annoying to the user in the end | 13:30 |
| wolfspraul | I was thinking about one message, appearing for a few seconds right after switching to the next patch, that says | 13:32 |
| wolfspraul | "Milkymist - patch_name by patch_author" | 13:32 |
| wpwrak | lekernel: (message) you could let them slowly fade away, decrease by 5% each time you show it :) (and have a config option somewhere, for those who want the warning always/never) | 13:32 |
| wolfspraul | that way we have the most important stuff covered, all in one line | 13:32 |
| lekernel | the demo firmware (without rtems, gui, etc.) already does that | 13:33 |
| lekernel | but really this would be a mere annoyance in live situations | 13:33 |
| lekernel | so that's one thing I deliberately left out when porting the render code to flickernoise | 13:34 |
| wpwrak | in live situations, it would have to be very discreet, indeed | 13:35 |
| wpwrak | lekernel: how do you like the LEDs idea ? maybe for rc4 | 13:44 |
| CIA-48 | flickernoise: Sebastien Bourdeauducq master * r56a75ab / src/config.c : config: fix problem with last line read twice - http://bit.ly/jckw0n | 13:45 |
| lekernel | naah no more PCB spins | 13:45 |
| lekernel | maybe in a major one, if/when we switch to xilinx 7 series, implement a complicated power supply and replace the adv7181 that is phasing out already | 13:46 |
| lekernel | (read: not anytime soon) | 13:46 |
| wolfspraul | adv7181 is phasing out? | 13:47 |
| wolfspraul | expect problems there at some point? normally these things remain available for many years, but I didn't check in detail on that one. | 13:47 |
| wolfspraul | btw I started to work on http://en.qi-hardware.com/wiki/Press_Release:_Milkymist_One_video_synthesizer_shown_at_6th_Libre_Graphics_Meeting_in_Montreal | 13:55 |
| wolfspraul | need to fill in a lot more | 13:55 |
| wolfspraul | my goal is to make this a complete typical press release, with all the bits and pieces you typically need | 13:55 |
| wolfspraul | then run it through the system once (i.e. distribute to journalists and submit stories) | 13:56 |
| wolfspraul | I don't expect much uptake because the story is rather dry, but it's a very typical story so we can exercise the process once | 13:56 |
| wolfspraul | 'very typical' in the sense that companies spit out this type of small news every day | 13:56 |
| wolfspraul | but we first need to make it complete, and get all facts straight. And the actual m1 usage must happen, otherwise we loose our credibility. | 13:57 |
| lekernel | mention a few features maybe? twitter wall, milkdrop stuff... | 14:03 |
| lekernel | rejon: hi | 16:23 |
| rejon | hi lekernel | 16:32 |
| rejon | in montreal | 16:32 |
| rejon | yes, i have to figure out the details of my presentation | 16:32 |
| rejon | i will push to go on thurs | 16:32 |
| rejon | got my milkymist here | 16:32 |
| rejon | i didn't get pictures with jeri | 16:33 |
| rejon | but i did see pictures others took | 16:33 |
| CIA-48 | flickernoise: Sebastien Bourdeauducq master * r0c9cf94 / src/firstpatch.c : firstpatch: update text on dialog open - http://bit.ly/kxUNxP | 17:38 |
| lekernel | yay. flash subdirectory bug fixed. | 18:13 |
| CIA-48 | rtems-milkymist: Sebastien Bourdeauducq master * r93fd6c5 / (14 files in 14 dirs): Consistent use of printk + fix compiler warnings - http://bit.ly/jXFCar | 19:55 |
| --- Sun May 8 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!