<wolfspraul>
wpwrak: saw your comment about iqc in the backlog :-)
<wolfspraul>
this is probably more qi/copyleft hw specific, not milkymist specific, hope people on this channel don't mind
<wolfspraul>
but... here's my experience on iqc in manufacturing
<wolfspraul>
compare to driving a car and a car accident. the accident happens _although_ you make a lot of precautions.
<wolfspraul>
so the argument "I wear no selt belt because I always drive carefully" just doesn't work.
<wolfspraul>
seat belt
<wolfspraul>
in manufacturing, you really have to embrace the concept that every run is different
<wpwrak>
wolfspraul: (iqc) your comments to qc (with the ben-wpan production) had that feeling of "recently burnt" ;-)
<wolfspraul>
every piece of physical hw is a new one
<wolfspraul>
not at al
<wolfspraul>
it's always the same thing
<wolfspraul>
but it's a fundamental conceptual difference between sw and hw
<wolfspraul>
so many sw people just don't get their minds around it
<wolfspraul>
"let's switch vendors to REALLY GOOD ONES"
<wolfspraul>
that kind of thing
<wolfspraul>
won't help
<wolfspraul>
"let's switch all components to gold"
<wpwrak>
maybe a little ...
<wolfspraul>
100% gold, just in case! :-)
<wolfspraul>
so the problem is that every run, every piece, is a totally new piece
<wolfspraul>
with a sw mindset you try to solve it fundamentally "once and for all"
<wolfspraul>
because in sw that's how it works
<wpwrak>
but if you run into a lot of such problems, this may also mean that your tolerances are too narrow
<wolfspraul>
it may mean many things. if we find this bad beads now - that's bad.
<wolfspraul>
I'm curious to see what's the root cause in the end.
<lekernel>
it's the bead - period. their DC resistance is too high.
<wpwrak>
yes, i wonder what's up with those beads
<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
<wpwrak>
lekernel: do you have several of them ?
<wolfspraul>
think of the car accident...
<lekernel>
wolfspraul: one order of magnitude above specified maximum resistance isn't tolerance
<wolfspraul>
lekernel: yes sure, I believe you. and actually it's a creat catch - thanks a lot!
<wolfspraul>
absolutely
<wolfspraul>
annoying
<wolfspraul>
annoying component quality problems :-) but that's how it is...
<wolfspraul>
wpwrak: what I tried to tell you is that this iqc thing tries to catch not a systematic problem, but a sporadic one
<wolfspraul>
it's like the seat belt in a car
<wolfspraul>
you don't know when you need it, or where exactly it will be needed
<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
<wolfspraul>
agreed, can be many root causes
<wpwrak>
wolfspraul: (iqc) yes, i understand. basically catch the ones that are broken or out of spec.
<wolfspraul>
also human error
<wpwrak>
wolfspraul: okay, and wrong labels ;-)
<wolfspraul>
and the nice thing about human error is that every time it's a different kind/shape :-)
<wolfspraul>
yes!
<wolfspraul>
and another 1000 options
<wolfspraul>
"oh, I thought..."
<wpwrak>
famous last words :)
<wolfspraul>
I looked at those 10 measurement tables from Adam again, and 5V on the board seems to low across all of them
<wolfspraul>
lekernel: do you think we should remove the beads?
<wpwrak>
when the device was tested for emc compliance, were these beads already there ?
<wpwrak>
ah, and is the problem now just the beads or both, the beads and the protection circuit ?
<wolfspraul>
maybe just the beads
<wolfspraul>
yes they were there in emi testing
<wpwrak>
(emi testing) then removing the may backfire. better if you can find out what went wrong
<kristianpaul>
hmm, wonder if there is an alredy wishbone cross bar bus implementation, that *may* leads to build an network switch..
<kristianpaul>
2 Layer switch at least :)
<kristianpaul>
oh well..
<kristianpaul>
s/an/a
<kristianpaul>
hmm at cern.. terpstra :-)
<kristianpaul>
so, mimimac2 core is currently been forked to make something else :)
<kristianpaul>
seems the ethernet phy tranceiver is quite similar in protocols to the sige chip :D
<lekernel>
wolfspraul: as wpwrak said...
<lekernel>
not sure what it's going to do EMC-wise
<lekernel>
if it's still ok without yeah remove them
<lekernel>
less sources of problems
<wolfspraul>
lekernel: you mean adam should test removing them, and if the board still works and looks good, we remove them in rc3?
<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
<wolfspraul>
that doesn't seem to be the case yet.
<lekernel>
wolfspraul: we could do that, yes
<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
<wolfspraul>
I see two talks for Jon, maybe he means the one at 5 PM on Friday, or maybe something entirely different
<wolfspraul>
we first need to get the facts straight before we can claim something
<wolfspraul>
my current headline for the release is a simple 'Milkymist One video synthesizer shown at 6th Libre Graphics Meeting in Montreal'
<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 :-)
<lekernel>
wolfspraul: switching through all patches on flash with the pushbutton works now
<lekernel>
maybe it can also detect if a video signal is present and skip the video-in patches if not?
<lekernel>
that's a little bit messy though so maybe later ...
<lekernel>
this thing is definitely best used with the camera anyway
<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.
<lekernel>
the (slightly) messy parts are a) retrieving cleanly whether a video signal is present b) determining if a patches uses video in
<lekernel>
so this does not help :)
<wpwrak>
this would allow you to ignore a) for a while :)
<wpwrak>
see also my suggestion on #qi-hardware: add a LED at each input and turn it on if the input is selected
<wpwrak>
(i know you'll hate anything that smells of hw changes ;-)
<wolfspraul>
lekernel: nice, you are fast :-)
<lekernel>
wpwrak: yeah but such messages popping up all the time would be very annoying to the user in the end
<wolfspraul>
I was thinking about one message, appearing for a few seconds right after switching to the next patch, that says
<wolfspraul>
"Milkymist - patch_name by patch_author"
<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)
<wolfspraul>
that way we have the most important stuff covered, all in one line
<lekernel>
the demo firmware (without rtems, gui, etc.) already does that
<lekernel>
but really this would be a mere annoyance in live situations
<lekernel>
so that's one thing I deliberately left out when porting the render code to flickernoise
<wpwrak>
in live situations, it would have to be very discreet, indeed
<wpwrak>
lekernel: how do you like the LEDs idea ? maybe for rc4
<CIA-48>
flickernoise: Sebastien Bourdeauducq master * r56a75ab / src/config.c : config: fix problem with last line read twice - http://bit.ly/jckw0n
<lekernel>
naah no more PCB spins
<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
<lekernel>
(read: not anytime soon)
<wolfspraul>
adv7181 is phasing out?
<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.
<wolfspraul>
my goal is to make this a complete typical press release, with all the bits and pieces you typically need
<wolfspraul>
then run it through the system once (i.e. distribute to journalists and submit stories)
<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
<wolfspraul>
'very typical' in the sense that companies spit out this type of small news every day
<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.
<lekernel>
mention a few features maybe? twitter wall, milkdrop stuff...
<lekernel>
rejon: hi
<rejon>
hi lekernel
<rejon>
in montreal
<rejon>
yes, i have to figure out the details of my presentation
<rejon>
i will push to go on thurs
<rejon>
got my milkymist here
<rejon>
i didn't get pictures with jeri
<rejon>
but i did see pictures others took
<CIA-48>
flickernoise: Sebastien Bourdeauducq master * r0c9cf94 / src/firstpatch.c : firstpatch: update text on dialog open - http://bit.ly/kxUNxP
<lekernel>
yay. flash subdirectory bug fixed.
<CIA-48>
rtems-milkymist: Sebastien Bourdeauducq master * r93fd6c5 / (14 files in 14 dirs): Consistent use of printk + fix compiler warnings - http://bit.ly/jXFCar