<wpwrak>
ah, L19 is our old friend. didn't remember the number.
<kristianpaul>
wpwrak: kristianpaul why rc3 worst run? more hardware more issues pop, that is not a hiden secret i guess21:31
<wpwrak>
kristianpaul: oh, but it is like this. more boards, deeper testing, new users. this inevitably brings out more bugs.
<kristianpaul>
wpwrak: sure
<wpwrak>
and M1 is a complex device, which means many opportunities for issues
<wpwrak>
wolfspraul: hey, how was clubbing ?
<wpwrak>
did the crowd give standing ovations, clapping their hands and shouting "emm-one ! emm-one !" ? :)
<wolfspraul>
ha
<wolfspraul>
I think you don't want to hear me characterize the event :-)
<wolfspraul>
no but it's ok. Jon and I just showed our faces, and we will demo the m1 at a meeting in a restaurant where the nightlife guys meet regularly to 'be real' in a few days
<wpwrak>
what was it ? the local cumbia-reggaton fusion event ?
<wpwrak>
;-)
<wolfspraul>
it was the opening of a club, from that records company
<wolfspraul>
the speakers were 'pathetic' (jon's words)
<wolfspraul>
no DJ there
<wpwrak>
heh ;-)
<wolfspraul>
the audience was 20-30 'vip' guests (i.e. random friends and acquaintances of record label staff)
<wpwrak>
a records company needs no dj. they have records ! ;-)))
<wpwrak>
all 50+ ? :)
<wolfspraul>
keep in mind it's china...
<wolfspraul>
oh no, all young
<wpwrak>
yeah, i begin to imagine :)
<wolfspraul>
but no magazine journalists
<wolfspraul>
a super prime location though
<wpwrak>
at least the right age group then :)
<wpwrak>
was there a bar ?
<wolfspraul>
and this label is serious, they do all sorts of things
<wolfspraul>
yes sure
<wolfspraul>
lots of alcohol
<wolfspraul>
free too :-)
<wpwrak>
excellent
<wpwrak>
even better ! :)
<wolfspraul>
but I only had a bottle of water
<wpwrak>
eek
<wolfspraul>
this was just to show up and say hi. Jon and i left after an hour and will demo the m1 at daylight asap.
<wolfspraul>
(that was the plan before)
<wpwrak>
:)
<wolfspraul>
the record label is doing electronic music, very rare in china
<wolfspraul>
they are essentially the only one such label in China :-)
<wpwrak>
still no reason not to have a drink or five. there's a lot you can do in one hour :)
<wolfspraul>
so maybe they could buy some m1, yes. and once it's in their clubs or events, others would see them, etc.
<wolfspraul>
but it's China, and my expectations are realistic. it's far more important that we sell in the US and Europe.
<wolfspraul>
the scene here is small (but growing)
<wpwrak>
always nice if you can sell locally
<wpwrak>
well, meanwhile, we've had a bit of a party here, too
<wpwrak>
before, i had used my battery-powered kaossilator to feed sound to the M1
<wpwrak>
then i connected my stereo. M1 didn't show any response to the audio signal.
<wpwrak>
i went back to the kaossilator. and now it didn't respond either. hmm.
<wpwrak>
so i power-cycled
<wpwrak>
that brought audio in back. so i disconnected the kaossilator and tried the stereo again. this time the M1 simply froze. (no reaction to mouse or such)
<wolfspraul>
go on :-) should I act surprised? :-)
<wpwrak>
again, power-cycling brought it back to life. a third attempt left me without audio again, and also no audio with the kaossilator.
<wpwrak>
power-cycling solved that, too. well, as it turns out, audio has its own part of the ground plane, just like video has.
<wpwrak>
and it's connected via a bead (L3), just like video was (L19)
<wpwrak>
now i can refer to L3 in my M1 in the past tense as well, and i'm happy to report that it now works flawlessly with audio from the stereo :)
<wolfspraul>
excellent
<wolfspraul>
another rework, and that IS GREAT!
<wolfspraul>
so we remove L3 as well?
<wolfspraul>
short it?
<wpwrak>
yup :) better now than later ;-)
<wpwrak>
short it
<wolfspraul>
oh absolutely
<wolfspraul>
thank you so much!
<wpwrak>
it's easy reach and quite isolated
<wpwrak>
s/easy/easy to/
<wolfspraul>
I am not surprised, knowing how we got here. there will be more bugs...
<wolfspraul>
but this one is great, definitely (the fix)
<wpwrak>
np. sebastien figured out the culprit actually even while i was still describing the symptoms. we're getting quicker ;-)
<wolfspraul>
well it's perfect
<wolfspraul>
anything else you found not working so far?
<wpwrak>
some usability issues that are probably just software. and a narrowly missed opportunity for a nicer keyboard solution (should be sw-fixable, though)
<wpwrak>
haven't tried either yet. and i don't have MIDI nor DMX.
<wolfspraul>
in general we need to be on the lookout for more hardware bugs
<wolfspraul>
if something acts weird, even just once, there's a good chance it could be improved in hardware
<wpwrak>
ah, and I got joerg to look at the schematics. he did some grumbling about ESD protection and we had some fun imagining various catastrophic failures due to mismatched grounds coming in from the various peripherals
<wolfspraul>
any suggestions for improvement?
<wpwrak>
yes ... he thinks R11 should be 0R
<wolfspraul>
I think it's good that we leave jtag-serial in for all rc3
<wolfspraul>
we don't know how many will be bought by developers, how many by pure users
<wolfspraul>
that's a logistical problem
<wolfspraul>
ideally we get 50% devs, 50% pure users
<wpwrak>
with the current R11, you lose stereo separation on the CD input (from the header)
<wolfspraul>
and the devs give solid feedback, unlike how we mismanaged 90% of rc2
<wolfspraul>
if we can get that going, it'll be a great product in a little while
<wpwrak>
why do you think the devs now will give better feedback than the ones who bought rc2 ?
<wolfspraul>
you think we should 0R 11R for rc3 already?
<wolfspraul>
it's a matter of management, following up with people
<wolfspraul>
also with the accessories the product becomes more usable, lowering the boundaries of having fun with it
<wpwrak>
joerg also suggests to add about 2 x 50 pF to line in (R and L), for ESD and HF protection. that's a little trickier. you could just piggy-back them on the resistors, though.
<wolfspraul>
I meant 0R for R11. did you do it on your board?
<wpwrak>
(R11) no, i didn't do it. so far, i don't have a CD in scenario, so it doesn't matter
<wpwrak>
i don't know how important CD in is in the overall picture
<wolfspraul>
is there any reasonable risk in removing R11?
<wolfspraul>
what do you mean with "CD input"?
<wpwrak>
if it was me, i'd probably just document the problem and no spend time on it :)
<wolfspraul>
oh, the expansion header. got it.
<wpwrak>
there are input signals for "CD"
<wpwrak>
yes
<wolfspraul>
we can do that in rc4
<wolfspraul>
wait, lemme take notes somewhere
<wpwrak>
yeah, sounds good to me. it's a simple fix but still
<wpwrak>
joerg would put ~50 pF in parallel to R23 and R24, to filter HF and to absorb ESD (there's no ESD protection on line in)
<wpwrak>
in fact he'd change the whole line to an active circuit, with a transistor to provide better GND decoupling and acting as a victim component in case of a major ESD mishap
<wpwrak>
it may be worth noting that ground loops on audio, which the M1 should welcome rather eagerly, can be avoided with a "DI box": http://en.wikipedia.org/wiki/DI_unit
<wpwrak>
in its simplest form, that's basically a transformer, providing nice galvanic isolation
<wpwrak>
people who do stage work apparently know these little devices very well
<wpwrak>
but it may be a good FAQ item to have anyway. until the audio circuit is perhaps improved
<wpwrak>
he suggests to use a Zener for D4, to also add overvoltage protection
<wpwrak>
do you know why there are two Zeners on the 5 V input (D14 and D15) and not just one ?
<wolfspraul>
that was the overvoltage protection I think
<wolfspraul>
one wasn't enough
<wolfspraul>
well all suggestions are welcome, especially in forms that they become action items for me. i.e.: dumbed down :-)
<wpwrak>
why was one not enough ?
<wolfspraul>
too bad the electrical is still in Altium
<wpwrak>
(D4) consider replacing with 2V2 zener :)
<wpwrak>
he also found the buttons suspicious: they have some ESD protection of the case with C122 and R47, yet the button signals themselves aren't protected. what makes them so much safer, if you already expect something to jump into the button ? :)
<wolfspraul>
I want to avoid collecting all sorts of 'opinions' unless they are condensed into real action items
<wolfspraul>
what I've found is that in electrical, you ask 10 ee's, and they all have slightly different preferences to tweak the circuit this or that way
<wolfspraul>
quite annoying. even worse than writer only code.
<wolfspraul>
so whenever a new EE comes in, there's all these 'improvements' that have to be done here and there, because of the experience of that EE
<wolfspraul>
but that will never stop :-)
<wolfspraul>
whenever a new ee looks at it there is more
<wolfspraul>
and it's changed and changed and changed. seems ee's cannot easily agree on what is 'best'
<wpwrak>
yeah :) i already distilled things a little, down to the things that seem mysterious or those that look like real issues
<wpwrak>
EE is no exact science ;-)
<wolfspraul>
oh sure it's ok, just after my years I've noticed this
<wolfspraul>
at the beginning I still thought you make multiple ees work together for the best result
<wolfspraul>
now I know that will never happen
<wpwrak>
;-))
<wolfspraul>
they will change and overwrite each others suggestions at infinite
<wpwrak>
lock them in a room, take the advice of the one who survives ;-)
<wolfspraul>
those sound like small and clear improvements to me
<wolfspraul>
then... DI box? that's external I guess
<wolfspraul>
do something with D4?
<wolfspraul>
others?
<wpwrak>
the two zener diodes (D14+D15) seem dubious. most likely, one conducts and the other is just idle. if the loaded one blows, and it fails open (not shorted), then the other one gets roasted
<wolfspraul>
me: wait and see :-)
<wolfspraul>
Adam spent an ungodly amount of time on that protection circuit
<wolfspraul>
there's no way he will get back to it unless someone else comes up with the 'perfect one' and we just switch to that
<wolfspraul>
in fact the protection circuit was one of the main mistakes between rc2 and rc3
<wolfspraul>
lots of time waste with little value added
<wpwrak>
yeah, we would be good to know the full story. the purpose still seems a little unclear. if it's just to have a backup, fine. if they're both needed, that sounds like trouble.
<wolfspraul>
that wiki page I linked lists some of the painful history and experiments
<wpwrak>
oh, i think it's essential. people will connect incorrect power supplies.
<wolfspraul>
most (false) measurements got deleted, luckily
<wpwrak>
(DI box) yes, external. if you get ground hum with the M1, then you'll need such a box to make the humming stop. (or rearrange your equipment, but good luck with that :)
<wolfspraul>
but once it moves to opinions, I suggest to wait until it's real
<wpwrak>
s/loose/lose/ :)
<wolfspraul>
trying to act upon opinions will only confuse others
<wpwrak>
yup these are the reworkable items
<wolfspraul>
so either it's a proper schematic diff, or we cannot act upon it
<wolfspraul>
seems the D4 idea is next in line?
<wolfspraul>
for the protection circuit, I really don't want Adam to sink any more time into that
<wolfspraul>
better or not, if someone has an idea for improvement, they have to send an actionable patch. otherwise it stays the way it is.
<wpwrak>
(opinion) well, there are two general directions: a) add ESD to anything that goes in and out, and b) apply galvanic separation liberally. M1 sits like a spider in a net of widely distributed devices. some of them will have very different ground potentials. it's bad to rely that all of _them_ do their homework and have galvanic separation.
<wolfspraul>
that's because already 1-2 months were sank, and wasted, into this
<wpwrak>
wow ;-)
<wolfspraul>
yes sometimes one gets stuck. that's ok, but then someone needs to come in with a fresh view and clean it up. or it stays where it is, which I believe at least 'sort of' works.
<wolfspraul>
plus the typical 'ee override' problem
<wolfspraul>
every ee comes in and says "all of a, b, c, d has to be changed urgently" :-)
<wolfspraul>
problem is: it never stops, like you said ee is an unprecise science
<wolfspraul>
I'm fine with either esd or separation, it's all a matter of how real those problems are, and how big/expensive the components are that would address the issues inside m1
<wolfspraul>
looking at other equipment might give indications
<wpwrak>
i think these are all the things. if you want to fix the ground on audio, there's a more involved circuit he suggested. nothing too crazy, but some extra components. not sure if this could be an rc4 item, or something for later.
<wolfspraul>
sounds like something for later
<wpwrak>
DMX is a little scary. M1 has nothing there in terms of ground separation. all the USB-to-DMX boxes mention they're galvanically separate. which makes a lot of sense if we consider that lighting if usually far away and may even be on a completely different branch of the electrical installation
<wolfspraul>
most important in rc4 is still the reset circuit (gates), adv7181c, L3/L19
<wpwrak>
yeah. probably better not to have new circuits in rc4
<wolfspraul>
oh I'm fine, but it needs to come as a verified patch, not as an opinion
<wolfspraul>
as an opinion, I cannot process it
<wolfspraul>
so it just won't happen :-) no resources...
<wolfspraul>
just staying real and giving honest feedback and expectations
<wolfspraul>
we can add tons of ground, esd and what not protection on all i/o
<wpwrak>
oh, if you look at the backlog of the #qi-hw channel, you'll find joerg's detailed description of the audio circuit ;-)
<wolfspraul>
question is always: how real is the problem being addressed (compare to other devices in the market), size of components, price of components, who verifies the design and turns it into a clean schematics patch
<wpwrak>
but i think it all depends on your schedule. if you have urgent things that need to go into rc4, then it would be a bad idea to add changes that have a risk of causing delays
<wolfspraul>
let's see it the other way round
<wolfspraul>
Milkymist One must never go out of stock anymore
<wpwrak>
the risk is real. ground loops are a well-known and ages-old problem
<wpwrak>
hehe :)
<wolfspraul>
so the rcX schedule depends on sales
<wolfspraul>
if sales are slow, we can fit more and more into rc4
<wolfspraul>
because rc4 will not happen :-)
<wolfspraul>
if sales are fast, rc4 will happen fast and things will be pushed into rc5
<wolfspraul>
in general I try to start with the most valuable things first
<wolfspraul>
L3 being a good example :-)
<wolfspraul>
or the still badly designed reset circuit
<wpwrak>
they're also relatively safe
<wolfspraul>
adv7181c supposedly 'drop in'
<wolfspraul>
I already know it will not be just 'drop in', but we have to get over it
<wpwrak>
probably best to alternate "safe" with "potentially unsafe"
<wolfspraul>
'protection' is a relative thing, you know that
<wpwrak>
if things go wrong, you can always go back to the last "safe" version, without too much trouble
<wpwrak>
yes yes, protection is tricky
<wolfspraul>
someone wants to improve the overvoltage & polarity protection on DC in: great, do it. waiting for patch :-)
<wpwrak>
do you need it ? will it be good enough ? etc.
<wolfspraul>
someone wants to improvem protection on line in/out, dmx, whatever: same. patch welcome.
<wolfspraul>
see above. how real? what are others doing? size and price of components? solution verified or just 'an idea'? translated into clean schematics diff, or just 'rough idea'?
<wolfspraul>
I've learnt to not ask EEs for too many opinions. it's like asking for trouble.
<wolfspraul>
because you ask them, they have to say something
<wolfspraul>
"you could improve X"
<wpwrak>
;-)
<wolfspraul>
seriously
<wolfspraul>
that's what I've learnt
<wolfspraul>
it's like you say, it's an unprecise science
<wolfspraul>
everybody has their own experience, it's subtle
<wolfspraul>
don't ask an ee for opinions
<wolfspraul>
instead, always distill hard data and then see whether things can be improved
<wpwrak>
anyway, that's the list of things i got from joerg. maybe the buttons need clarification. something doesn't quite add up there. but maybe someone's just a little over-cautious on the button shell.
<wolfspraul>
for the DC jack protection, we had a very clear goal
<wolfspraul>
we wanted to make the m1 safe from people accidentally plugging the 12V camera supply into it
<wolfspraul>
which has the same mechanical jack
<wolfspraul>
and which we ship in the same box
<wolfspraul>
I think we achieved that. if you accidentally plug in the 12V supply, the M1 will not boot but should be safe. sort of. better don't try. :-)
<wolfspraul>
for the other protection things you mentioned, I think best is if we can first demo the problem.
<wpwrak>
regarding the NOR things, adam did some 100 cycles without trouble. what we're not sure about is whether this was with standby locked (in which case the test might show that this helped, or maybe it just shows that nothing happened), or it was without locking (in which case the test shows that 100 tries are not enough to make things happen)
<wpwrak>
(12 V) yes :)
<wolfspraul>
why are we not sure? I'm pretty sure it was with a locked standby
<wolfspraul>
we doubt that the locking worked?
<wpwrak>
(not sure) because adam vanished before we could ask him ;-)
<wolfspraul>
adam reflashed and locked both 4C and 7C
<wolfspraul>
well, I also wondered how we can be sure that it was locked
<wolfspraul>
:-)
<wpwrak>
now a good test would be to unlock, do 100 cycles, and see how often a corruption happens
<wolfspraul>
first Adam will do 100 cycles with 7C
<wolfspraul>
let's see how that goes
<wpwrak>
(once it happens, reflash and proceed)
<wpwrak>
(7c) fine
<wpwrak>
but the test is meaningless without baseline
<wolfspraul>
then maybe do the L3 rework on all boards?
<xiangfu>
(locked test) I have tested my code with 'erase' command inside flickernoise.
<wpwrak>
(l3) sounds good
<wolfspraul>
and then go through all now available boards, lock partitions (without reflashing), run 10 render cycles
<wolfspraul>
I need to find a way to start sales
<wolfspraul>
so I know the nor corruption is not fully understood, not fully made reproducible and fixed
<wolfspraul>
but if we are lucky and something just passes, we can start to ship boards out and then we have time for more fundamental tests
<wolfspraul>
I'm hoping that the locking will be such a 'lucky' thing ;-)
<wpwrak>
if no board turn up with the "pulse" failure (0x77 and friends) or some new NOR symptoms, then it's probably safe to start selling
<wolfspraul>
definitely
<wpwrak>
just keep back the ones with more severe NOR weirdness than the stray zeroed word
<wolfspraul>
oh sure
<wpwrak>
i think a boundary scan may be the best test for the ones with severe NOR issues. otherwise, adam can voltmeter himself to death ...
<wolfspraul>
xiangfu: remember you shorted L19 to fix the camera signal loss problem?
<xiangfu>
wolfspraul, yes
<wolfspraul>
now you can also short L3
<wpwrak>
for the single-word corruption, an automated test would be good to have to determine what's really going on
<wolfspraul>
we may also loose the audio signal
<wpwrak>
xiangfu: every 1-2 weeks, there will be another component to short ;-)
<xiangfu>
wpwrak, finally we will direct send 12V to VGA :)
<wpwrak>
xiangfu: that will be fun. no longer milky mist, but colorful smoke ;-)
<xiangfu>
the L3 fixed the not-boot problem? (needs read log)
<wolfspraul>
xiangfu: no. just a problem of loosing audio signal (line-in), similar to the camera signal loss.
<wolfspraul>
now that we know that fix2b is good, what's the latest idea for the reset circuit using gates and 4.4v ic ?
<wolfspraul>
still 2 reset ics? one? no more diodes?
<xiangfu>
wolfspraul, ok.
<wolfspraul>
or we wait a little longer until the dust settles, then think about it?
<wolfspraul>
xiangfu: yeah it's a great catch. werner lost the audio signal right on his first experiments :-)
<wolfspraul>
did you ever loose the audio signal (m1 rendering becoming unresponsive to audio)? I don't remember this ever happening to me, but who knows, it could have been.
<xiangfu>
wolfspraul, yes. great catch.
<wolfspraul>
when I have a problem, typically I just reboot.
<wpwrak>
the 2 reset ics idea was stupid. i realized that it would just make the system completely unpredictable.
<xiangfu>
wolfspraul, never pay attention to audio-in.
<wolfspraul>
well I'm sure you do
<wolfspraul>
you run m1, and the rendering won't react to audio.
<xiangfu>
wolfspraul, if I meet it. I  may can not find out it's audio problem.  :(
<wpwrak>
so i'd change the reset IC to one tied to 5 V, with ~4.3 V threshold, plus a gate to replace the evil D16
<wolfspraul>
yes, I also don't clearly remember seeing it, but it might have been.
<wpwrak>
xiangfu: it's audio in. the symtoms are: 1) no video response to audio and sometimes 2) M1 just hangs. you'll notice, don't worry ;-)
<wolfspraul>
one gate only now?
<wolfspraul>
do you think you are clear on the circuit, or we need some experiments?
<wolfspraul>
I've seen a lot of variants over the weeks, so I'm a little cautious now ;-)
<wolfspraul>
I think slowly every possible combination was proposed at some point...
<wpwrak>
(1 gate) one for each diode. after fix2b, only one is left :)
<wpwrak>
of course experiments should be made. never expect a circuit to work before you've actually tried it :)
<wolfspraul>
so just replace the reset ic with a 4.4v variant (powered from 5V), and D16 with a gate?
<wpwrak>
yes, that's basically it. C238 will no longer be necessary. and we should check the value of R30, for compatibility with the new chip.
<wpwrak>
and, of course, R30 will _still_ connect to 3V3 ;-)
<wpwrak>
anyway, time for a nap. tomorrow, i'll see if i can get my little switch box to work and later invoke NOR amnesia in the M1 :)
<wolfspraul>
n8
<wolfspraul>
thanks a lot for the super helpful feedback!
<wpwrak>
always fun to find bugs :)Â Â (specially if they're easy to fix :)
<xiangfu>
:( I have to glue all those three buttons.
<xiangfu>
I remove the small middle piece, replace with thick glue. seems works better then before.
<wolfspraul>
why do you have to glue buttons?
<xiangfu>
it break. the buttons drop from m1.
<xiangfu>
one is broken today. the another one is broken Monday I think. so i just re glue them all.
<wolfspraul>
hmm
<wolfspraul>
yes not surprised
<wolfspraul>
I'm really curious to see the new rc3 buttons
<wolfspraul>
hopefully it's a big step forward (should be)
<xiangfu>
hmm... now the ftp is not stable. not sure if this is my new system problem.
<xiangfu>
I always use 'ftp://192.168.0.42' in 'nautiles' copy file from/to m1.
<xiangfu>
now it freeze in my system. m1 is works fine.
<wolfspraul>
I don't understand
<xiangfu>
sound like my system app 'nautiles' problem.
<wolfspraul>
what freezes exactly? can you connect back to the m1 without rebooting m1? maybe you have to experiment/try a little to find the cause
<xiangfu>
I use a GUI tools to access m1's ftp for copy files from/to m1
<xiangfu>
now this GUI tools in my new ubuntu 11.04 freeze when copy file to m1.
<xiangfu>
I can connect back to m1 without rebooting m1.
<xiangfu>
try 'ftp' command now.
<xiangfu>
ftp command works fine.
<xiangfu>
keey my eyes on if my m1 will freeze in future after short L19 and L3
<wolfspraul>
no no, that's unrelated
<lekernel>
wpwrak, CD input is totally unimportant; in fact, I suggested the header and resistors connected to it be DNP'd
<lekernel>
just don't touch it on rc3
<wolfspraul>
sure we all agree, no worries :-)
<wolfspraul>
the only important new finding is L3, a great catch and immediate improvement
<lekernel>
wpwrak, the ESD protection circuits were there before the case was designed... and I was imagining we could have a large metal plate touching the shells of the buttons
<lekernel>
and when we had bare boards, the user would typically touch the button shells all the time
<lekernel>
also, it's probably easier for arcs to jump on the shell than inside the button
<rejon>
720p
<stekern>
rejon: what kind of 'artifacts' are you speaking about? is it because the output is lowres (i.e. pixelated) or because the display has to rescale the picture?
<lekernel>
the only noticeable artifact on M1 is banding, but this has to do with color depth, not resolution
<stekern>
ah, I see
<stekern>
don't see what the poinr of 720p would be then
<stekern>
*point
<lekernel>
I don't know if that is what rejon is talking about ...
<rejon>
yah, banding from stretching and is lowres
<rejon>
on projector not as bad
<rejon>
but on a new screen, is worse
<rejon>
i think there is a sales factor of at least having HD
<lekernel>
banding has nothing to do with stretching
<wpwrak>
lekernel: (CD in) yeah, i thought treating it as a documentation issue would be adequate :) (i.e., put it on the errata. the whole header isn't tested anyway, so who knows what else may be wrong there. e.g., SMT sometimes "loses" components)
<wpwrak>
lekernel: (button protection circuit) ah, that makes sense then. thanks !
<lekernel>
we'll probably DNP it... I wanted to DNP on run3 already, but wolfspraul wanted to keep it
<lekernel>
also it's done this way on the LM4550 "typical application" circuit (see qihw channel)
<wpwrak>
why not keep it ? just say that it's untested. a little extra for those who want to experiment.
<lekernel>
there are probably 0.001% of users who will actually do this experiment, and those can probably solder a few 0402 parts themselves ...
<wpwrak>
lekernel: it takes some courage and confidence to solder such small stuff on an USD 500+ device. there are not a lot of people who'd be ready to do this. that's probably the difference between your 0.001% and an exact 0% ;-)
<lekernel>
0402 isn't small
<wpwrak>
wolfspraul: oh, and we found an error in the WM9707 data sheet: they give the maximum analog voltage as AVDD +/- 0.3 V. they probably mean AVSS -0.3 V to AVDD + 0.3 V. had me puzzled for a while :)
<wpwrak>
lekernel: (0402) you should get out more ;-))
<wolfspraul>
DNP what?
<lekernel>
J3 and the resistors connected only to it
<wolfspraul>
lekernel: what did I want to keep?
<wolfspraul>
the audio/video expansion header?
<lekernel>
yes, but it's only audio
<wolfspraul>
why would I want to keep that?
<lekernel>
I don't know, but you were opposed to DNPing it when I suggested that
<lekernel>
being a trivial issue I didn't insist
<wolfspraul>
must have been a misunderstanding
<wolfspraul>
where did I say that?
<wolfspraul>
I mean I need to ask you: what can people do with the J3 expansion header? :-)
<wolfspraul>
I don't even know
<wolfspraul>
the fpga expansion header I have some ideas
<wolfspraul>
but not for J3
<lekernel>
yes, we keep the FPGA expansion
<lekernel>
but J3 can go
<wpwrak>
make fragile extension boards/connectors for more audio inputs.
<wolfspraul>
definitely
<wolfspraul>
well since I hardly can imagine that J3 can be good for, if I ever said I want to keep it there must have been some misunderstanding
<wolfspraul>
s/that J3/what J3/
<lekernel>
also, J3 made more sense when we used the LM4550, which had a built in headphones amp
<wpwrak>
and what else ... ah, SPDIF
<lekernel>
it was nice to connect headphones directly to the board
<lekernel>
yeah, now there's SPDIF instead :)
<wolfspraul>
we can schedule j3 removal for rc4
<wolfspraul>
out with it
<lekernel>
totally unsupported/untested though
<wpwrak>
(headphone output) heh, nicely confusing :) you have LNLVLOUT on the codec, going to HP OUT, going to J3, but all the components are DNP :)
<lekernel>
that's just a second line out
<wolfspraul>
wpwrak: you think removing J3 is ok, or you would keep it?
<lekernel>
but it cannot drive headphones correctly (I tried it)
<lekernel>
the LM4550 had more punch on that output
<wolfspraul>
can we complete the resistor list to be removed with J3? J3 and ?
<wpwrak>
wolfspraul: (j3) dunno. if you expect people to play with audio extensions, it may be nice to have. adding to it if DNP, would be hard/scary. but ... i'm somewhat unconvinced about the whole expansion header situation. i think mechanical issues need a bit more attention.
<wolfspraul>
I agree about mechanical. we are just starting. now we talk about J3 first.
<lekernel>
R6 to R12
<wolfspraul>
I am 100% neutral on it, because I have no clear understanding what J3 could be used for.
<wolfspraul>
if someone wants to keep it, fine by me. if someone wants to remove/DNP, also fine. Just both at the same time doesn't work :-)
<lekernel>
but keep R2 to R5 and R14 to R16
<wpwrak>
wolfspraul: seems we have one vote against it and two abstentions :)
<wolfspraul>
ok, that means DNP in rc4
<wolfspraul>
thanks! saves me a little money, no way I could not agree with that :-)
<stekern>
i don't think 0402 is any harder to solder than 1206, as long as you've got some room around it. but usually that's the reason of putting the 0402 there, lack of space
<wpwrak>
stekern: it's also a question of equipment and vision. also, details of 0402 contacts are hard to see even if your eyes are good, so you need experience to be able to find the right clues.
<wpwrak>
stekern: besides, a LOT of people consider SMT just the devil's work in general ;-) they'd rather drill and solder a thousand through-hole pins than one puny little 0805.
<wpwrak>
btw, i wish the M1 was about 5 mm shorter. then i could mill my own side plates ;-) (my mill does only up to 150 mm. i think M1 is ~151 mm. and i need a bit of slack.)
<wpwrak>
rejon: (720p) is the issue aspect ratio or really the pixel density ? if it's just aspect ratio, maybe some less demanding wide mode, 800x480 or such, could help
<wpwrak>
rejon: or maybe the video signal should just have black bars left and right for a "wide" screen. these don't consume memory bandwidth ;-)
<wpwrak>
rejon: in general, i think the "out of box experience" of M1 could be better. right now, it's fairly obscure what it does, with long pauses and very little feedback.
<lekernel>
otoh, displaying "Loading" screens on beamers is unwelcome
<lekernel>
but we could display a black picture instead of sending no signal
<lekernel>
it could also improve a bit the perceived boot time, since some screens take a few seconds to acquire the signal
<wpwrak>
could you have a configurable "loading" screen ? e.g., have a "tutorial" mode with lots of feedback and such, and a "stage" mode with a much more austere interface ?
<wpwrak>
and yes, i think a black picture would be preferable over no signal in any case. a lot of video equipment acts funny when the signal drops. i suppose even "pro" devices may have their unwelcome "smart responses" to such events
<lekernel>
"tutorial mode" sounds like a lot of work
<wpwrak>
yes, unfortunately :-(
<wpwrak>
what would be really great for a tutorial mode is a drawing of the M1 and its I/O, with indicators on their status
<wpwrak>
e.g., have a small camera image next to video in, have audio level indicator bars, maybe display DDC information on vga, show what has enumerated on USB ("keyboard", "mouse"), etc.
<wpwrak>
you could even make it an overlay and display effects underneath. but yes, someone would have to spend a bit of time on that.
<wpwrak>
maybe something to mention when there are a few more users. someone may look for an opportunity to contribute. and it's not the kind of thing that would require an excessive amount of expert knowledge. easier than MMU or speeding up the RAM ;-)
<lekernel>
it's not the kind of things that open source developers often do either ...
<wpwrak>
oh, they do. think KDE, Gnome :)
<wpwrak>
you'd have to explain the concept, though, because many such developers would look more for something where they can they can copy the concept than inventing something completely new
<wpwrak>
maybe make a few drafts of the visual design. then they have something they can work with.
<wpwrak>
but first more ... Developers ! Developers ! Developers !:)
<lekernel>
if people continue to only post crap like that raspberry pi all over the place, this isn't going to happen
<wpwrak>
let them chatter :)
<wpwrak>
lekernel: when you process those USB descriptors, do you only use the first interface descriptor ? or all of them ? e.g., if a HID device has kbd and mouse, all on the same device and in the same configuration, but on different interfaces, would M1 use both or just one ?
<lekernel>
it uses only one
<lekernel>
this is probably the problem you have, since other communications seem to work
<lekernel>
you can patch the AVR firmware in softusb-input in the soc distribution
<lekernel>
then debug with the demo firmware, and finally update the xxd-generated header in the RTEMS driver
<wpwrak>
yeah, i still have to set up any development environment
<lekernel>
in next sw version we should try to have a small readonly filesystem that comes with the application binary
<lekernel>
it could be useful to store fonts, icons, and that USB firmware
<lekernel>
the demo firmware has a little "paint" application to demonstrate mouse
<lekernel>
and it can take USB keyboard input into the console (like the BIOS)
<wpwrak>
hmm, do these things change more often than the rest of FN ?
<lekernel>
it's simply easier to have one large binary that gets flashed
<wpwrak>
yeah, agreed
<wpwrak>
so you meant something like initramfs on linux. not kind of yet another partition. good :)
<lekernel>
probably just a small FAT filesystem concatenated at the end of the application binary
<wolfspraul>
I have a question about web update running from the rescue image. We always say that that's what users can do to fix a CRC problem.
<wolfspraul>
But how does it actually behave as implemented today? Will it check for a newer version first, and only download and flash when it finds a newer version?
<wolfspraul>
Or will it always download and overwrite the nor?
<wpwrak>
maybe integrate an IRC client that log into #milkymist, so that users can scream for help ;-)
<wolfspraul>
I'm wondering whether what we ship today will actually let people do what we say, or it's just a theory
<wolfspraul>
we could also implement it in such a way that if web update is run from the rescue image, it will always download/reflash, but when it's run from the normal image, only if there is an update?
<wpwrak>
yes, i understand. don't know the answer. just try it ?
<wpwrak>
(i haven't set up ether yet)
<wolfspraul>
yes, will try. I have dodged testing web update because I'm pretty sure I will find a problem :-)
<wolfspraul>
that one just came to my mind because we always say "users can run web update to fix nor corruption"...
<wolfspraul>
so I was wondering whether that actually works :-)
<wolfspraul>
and we cannot update such a feature into the rescue image either, because those are not getting updated right now...
<wpwrak>
it would get updated in the field only after the problem struck once :)
<lekernel_>
wolfspraul, if you have booted in rescue mode, it will always flash no matter what