<GitHub122>
[scripts] xiangfu pushed 18 new commits to master: http://bit.ly/qbys1L
<GitHub122>
[scripts/master] Added changes for OS X. - JP Bonn
<GitHub122>
[scripts/master] Added notes for OSX. - JP Bonn
<GitHub122>
[scripts/master] Added curl in addition to wget for OS X. - JP Bonn
<aw>
rc3 status: just mounted 1st piece, used snapshot 2011-07-13 temporarily to test
<aw>
two usb devices, midi, dmx, ir, switch, memory card, ethernet are all done. video preview is okay on gui's video input settings window but no video capture
<aw>
in test s/w: LOCKS: 7 AD_RESULT: 4 shows registers readback are okay, use camera's video source input on gui with ten times plug-in & plug out, and shows okay.
<aw>
audio I need to go home and test more, i am at smt site, so without bringing more accessories. :-)
<aw>
btw, i took out D16, so m1 can go into booted.
<lekernel>
what's the problem with D16?
<aw>
can't boot if D16 mounted. I'll compare my rc2 boards when I back home.
<wolfspraul>
lekernel: D16 was the reset IC? that was meant to fix one of the boot problems, right?
<lekernel>
[{#~'!
<lekernel>
yes
<aw>
so far now I tested at least 50 times power cycling.
<lekernel>
don't. it will fail, period
<aw>
D16 is connected to flash chip's reset pins.
<lekernel>
spend your time figuring out why that reset IC doesn't work
<wolfspraul>
ok fine, but why did we add D16, and why does it not work now? that's a quite serious bug we thought we fixed with it.
<lekernel>
have you checked footprint and pinout?
<lekernel>
for d16?
<wolfspraul>
aw: yes, I agree with lekernel. We need to find out why D16 doesn't work, since there was a theory before why we needed it and why it should work and we did tests too.
<aw>
lekernel, no, D16 is diode not reset IC. yes, i checked them are good connection.
<lekernel>
what is the voltage at the output of the reset IC and at the flash reset pins?
<aw>
i need bring back and measure them. here I can't.
<lekernel>
can you fedex me this problem board right away, plus a few reset ICs and diodes? I don't want more delays
<aw>
let me checked some tonight, i should go back firstly
<lekernel>
the reset IC is still connected to the FPGA's PROGRAM_B, right?
<aw>
and here they smt keep mounting and do their though holes parts
<aw>
correct, PROGRAM_B
<lekernel>
so I guess its output should go to logic high state, otherwise the FPGA wouldn't configure at all
<lekernel>
but you tested the diode on the RC2 board as well, right?
<wolfspraul>
good. all 80 being made now? we will get to the bottom of the D16 problem, and there will probably be other discoveries. so no chaos please, Adam needs to get a little work done first.
<aw>
the first one is I interrupted their process normally, so i requested them to keep working.
<wolfspraul>
lekernel: remember that Adam is chatting right now sitting somewhere in the corner of the smt fab, just give it a few hours to settle...
<lekernel>
oh, is the polarity of the diode correct?
<lekernel>
otherwise the FPGA will deconfigure itself when attempting to reset the flash before booting
<lekernel>
the cathode should be connected to the reset IC
<aw>
lekernel, yes, D2 is off slightly while stays in reconfiguration mode, thus power-on, this is now shows but I already removed D16 apart now.
<lekernel>
the most probable explanation I see atm is D16 is connected the wrong way around
<aw>
lekernel, hi, yes I checked D16's polarity and well. then if mounted the D2 keeps lightly ON which is not correct.
<aw>
well...i need to go home now. and bring some parts back.
<wolfspraul>
sure, chat later
<aw>
chat you guys later.
<wolfspraul>
first get things back and under control
<aw>
cu
<wolfspraul>
lekernel: is there any significance in Adam successfully booting 50 times? is it possible that the original bug we tried to fix is also fixed properly without the diode?
<lekernel>
maybe
<lekernel>
but the diode shouldn't cause any problem
<wolfspraul>
ok
<lekernel>
my guess is that the polarity was indeed wrong, when designing the schematics Adam had a lot of trouble understanding which way it should go ...
<wolfspraul>
give it a few more hours then Adam has a much better environment to dig into this. a lot of the major tests are successful, which is good.
<lekernel>
or the diodes you got are broken (after the IR receivers and ferrite beads, I wouldn't be surprised either)
<wolfspraul>
it's surprising that we tested this on rc2 and I thought it was all good, so there must be a small mistake somewhere, I guess
<wolfspraul>
sure mistakes can happen anywhere, let's just see
<wolfspraul>
it doesn't sound like a major problem to me right now
<lekernel>
yeah at least all the major parts seem working :)
<wolfspraul>
there were so many issues on rc2, if this is the only one on rc3 (which I doubt), then it would still be a big step forward
<wolfspraul>
I don't just mean design problems, also manufacturing problems, parts, wrong pick & place behavior, etc.
<wolfspraul>
so let's not dramatize now that Adam is just in the very first minutes, literally, after receiving the first board off the line
<wolfspraul>
that's a veyr high stress moment because Adam has to decide whether to let the remaining 79 through the machines or not
<wolfspraul>
which he did green-light, and from the distance sounds like the right decision
<wolfspraul>
even if we have to manually rework D16 on all boards, that sounds like a very minor issue. I am fully expecting us to find other issues.
<aw_>
hi, just tell my tasks/goals tonight firstly, :-)
<aw_>
since I only brought only one rc3 board back, factory keeps their own internal process on other customers's works; so QC jobs needed after 90pcs boards mounted and today already finished. :-)
<aw_>
for all other through holes parts, factory planed to hold next Monday, so all remaining works will be finished by factory next Tuesday or so and send 89pcs assembled back to me.
<wolfspraul>
nice
<wolfspraul>
no stress please, it's great that you keep us updated in such a timely way
<aw_>
so my priority now is not to figure D16 issue, I have to use test program boot.bin to finish all items done successfully and review audio, video signals noise which we met rc2 before. If found somethings error or parts mounted wrongly, I have to feedback to factory before next Monday to provide reworks or others.
<wolfspraul>
how many parts are wrong?
<aw_>
no, no
<wolfspraul>
any big problems in fixing them?
<aw_>
i am supposedly to say a plan as my side.
<aw_>
i think I'll post a link about logs of test program on my 1st board in 20 minutes firstly.
<aw_>
stay tuned. :-)
<wolfspraul>
ok, I'm out to dinner briefly then back
<aw_>
yes, i saw previous list emails about it. just sent to you about xiangfu's one.
<lekernel>
ok, xiangfu's script looks good
<aw_>
now VGA DDC is passed after ten times plug & unplug VGA cable. of course no obvious part wrong. I must be not well-connected last time I recorded log. :-)
<aw_>
alright...thanks for checking. :-)
<aw_>
now I am going to measure audio noise signals. I already heard it's pretty good though. well...scope measure is good.
<lekernel>
cool :)
<wolfspraul>
just back from dinner, all looks good here :-)
<wolfspraul>
let me see those anode/cathode drawings....
<aw_>
scheduled: reconfigured --> booted (music appears) --> music source muted --> I shutdown m1
<wolfspraul>
still downloading
<wolfspraul>
20mV is good or bad?
<wolfspraul>
I thought I remember we had something like 100mV before? vague memory...
<aw_>
meaured point at between Pad C21 and R18
<wolfspraul>
well, mostly you can trust your ears I think :-)
<aw_>
pretty good though, i am checking my previous video record to compare. :-)
<wolfspraul>
trust your years (the numbers are good for archival purposes of course)
<wolfspraul>
ears
<wolfspraul>
:-)
<wolfspraul>
we don't need to become obsessed about the mV numbers, but of course they are good to keep track over time.
<aw_>
sure sure I already hear that it's good compared to our bad/worse rc2. :-) second...
<wolfspraul>
also maybe the mV numbers help us compare with other products or literature, if anybody even measures this kind of noise and in the same way, which I guess is not standardized...
<lekernel>
do the sound tests work btw? (beep, recording, playback)
<aw_>
this is the one LM4550B we had have before. :-)
<aw_>
yeah..good! we compare out. the older one (LM4550M has 500mV)Â Â now(rc3 has very lower level) .:-)
<wolfspraul>
good, although the noise level in rc2 was unacceptable for a consumer, let alone professional, product
<wolfspraul>
still downloading the new ogg :-)
<wolfspraul>
the joys of the great firewall
<aw_>
btw, i should use the same scale though. but it's clear for me now. :-) rc3 have good static white noise about 40mV ~ 50mV. only :-)
<wpwrak>
aw_: what's the maximum amplitude ?
<wolfspraul>
he yes, nice video. only the scope is not in focus unfortunately.
<aw_>
no need to check maximum. the older ogv at 1:30 was that I mated audio source, then the noise is 500mV!!!
<aw_>
now our rc3 surely supposed to be under or around 50mV lookly average. :-)
<wolfspraul>
alright, what's next? how about beep/recording/playback lekernel mentioned?
<aw_>
bad things is that I did those two with different scales. :( You may confuse though if don't see carefully.
<aw_>
yes, those three I heard while using test program also pretty good. :-)
<wolfspraul>
don't worry about it. if you take videos from the scope, try to focus on the scope though so the text on the scope's screen is more clearly visible.
<aw_>
yeah...alright
<wolfspraul>
but don't retake it now, otherwise lekernel will freak out that we worry about taking better scope videos :-)
<wolfspraul>
let's focus on the product...
<aw_>
now I list my works tomorrow morning:Â Â bad...i am a little asleeping now.
<wolfspraul>
of course, go rest, it's late
<wolfspraul>
smt factory days are stressful, I did it often enough
<aw_>
1, take full screen for camera source to see carefully.
<wolfspraul>
(this time Adam is alone, I thought I can save some money and not go there :-))
<aw_>
2. used xiangfu's new scripts and to see rendering status
<aw_>
3. back to check D16 to know why.
<aw_>
4. else?
<aw_>
I'll still record on irc first, you can see backlog.
<wolfspraul>
yes sure, it all looks good (looking at the test log)
<wolfspraul>
ddc is clear
<wolfspraul>
so the main thing is D16, thorough analysis
<aw_>
does anyone remind me else?
<wolfspraul>
we need to fully understand that, it's an important bugfix and we need to know what's going on
<wolfspraul>
have you started to collect RC3 known issues?
<wolfspraul>
or nothing yet?
<aw_>
not yet though...
<wolfspraul>
yes, definitely start it, even for minor things otherwise we forget...
<aw_>
so far now I knew: 1. L19 no need 2. now D16
<wolfspraul>
well yes, D16 we don't know yet what's going on
<wolfspraul>
alright, good plan
<aw_>
it's good now. actually everytime we smt run if we get in fail totally in my mind. :-) like pcb totally dad!
<aw_>
well...time to go.
<wolfspraul>
sure sure. all successful!
<wolfspraul>
but D16 still needs thorough understanding
<aw_>
cu everyone.
<wolfspraul>
because it's connected to a very important bug
<wolfspraul>
cu
<aw_>
yeah..cu
<wolfspraul>
wow if we really only have the D16 problem that would be fantastic. let's see what that turns out to be...
<wolfspraul>
wpwrak: I think there are some battle scars on ex-om folks. All we know are pcbs falling off the line that don't boot, have dozens of major problems, etc :-)
<wolfspraul>
it's amazing how many things we got wrong there, I think pretty much anything that could go wrong actually did
<wpwrak>
wolfspraul: yeha, OM SMT runs were quite some adventures :)
<wpwrak>
wolfspraul: at least we're likely to err on the side of caution now :)
<wolfspraul>
yes. rc3 looks really good, only D16 unclear now, hopefully tomorrow will bring clarity there.
<wolfspraul>
and then the other 89 boards and let's see how stable it all is (in terms of unexpected problems popping up on this or that board)
<wolfspraul>
it's time for more challenges
<wolfspraul>
rf, antennae, less space, etc.
<wolfspraul>
to be fair the freerunner was an 8-layer pcb with daughterboards, 4 antennae, in restricted space, etc. and completely incompetent/overwhelmed engineering (myself proudly included)
<wolfspraul>
so that was a loose-loose proposition
<wolfspraul>
but with rc3 going so smooth I think we should up the ante a little :-)
<wolfspraul>
but I will await more data first...
<wpwrak>
mm1 isn't too bad a challenge. it is a fairly complex board, although a little slow (low frequencies) by modern standards
<wpwrak>
so having it in good shape already is no mean feat
<wolfspraul>
yes sure, compared to the freerunner it's still very easy
<wolfspraul>
there is a reason you need a decent sized team if you want to have a realistic chance to produce a functioning smartphone in a given amount of time
<wolfspraul>
and the team needs experience, and good internal coordination, and and and
<wolfspraul>
otherwise it will just end in disaster, that simple
<lekernel>
here's a challenge for you: make it cheaper :)
<wolfspraul>
definitely, already mentally working on it
<wolfspraul>
for example (you will like this) I dropped the idea of that 12002 regulator
<wolfspraul>
too expensive
<lekernel>
the power supply module?
<wolfspraul>
we have a stable 5V solution, done
<wolfspraul>
yes
<wolfspraul>
we need to cost down, cannot add such expensive feel-good equipment to the board
<lekernel>
what are the main cost factors on the run 3 atm? having a quick look at the BOM it seems to me the flash chips are rather overpriced
<wolfspraul>
multiple?
<wolfspraul>
you mean the nor?
<lekernel>
yes
<wolfspraul>
was about 12 USD or so, right?
<lekernel>
yeah, something like that
<wolfspraul>
well, there are 2 other big items in the case and the trademark licensing fee :-)
<wolfspraul>
but I keep those out now, I focus on manufacturing cost reductions
<wolfspraul>
we can remove the jtag-serial board (but I have plenty right now)
<wolfspraul>
let me finish this whole rc3 run and product first, but yes, cost down is important
<wolfspraul>
so the regulator is definitely out, at least on my side, due to cost
<wolfspraul>
unless someone else wants it in
<wolfspraul>
removing jtag-serial is an easy decision but we need to keep 2 things in mind:
<kristianpaul>
lekernel: no more NOR all memcard :)
<wolfspraul>
1) not accidentally increase the barrier for would-be contributors who might want jtag
<lekernel>
kristianpaul, fpga's cannot configure from memory cards
<wolfspraul>
2) I have over 200 jtag-serial in stock now, so it may simply not matter much to me to remove it fast, since I am not selling them individually and don't plan to
<kristianpaul>
lekernel: i know ;)
<lekernel>
at least not without an additional microcontroller or such chip
<wolfspraul>
I want to avoid raising contributor barriers, so I rather keep the jtag-serial in a little longer
<kristianpaul>
lekernel: there was not a non-volatile spartan3? there is no same for s6?
<lekernel>
from my reverse engineering results, it seems the s6 die has similar bonding pads for the configuration flash die, but xilinx doesn't use them (and probably will never since they are focused on the 7)
<wpwrak>
lekernel: can't the fpga boot from some serial eprom ? nor does indeed seem rather fancy
<lekernel>
it can, but again, needs work
<wpwrak>
okay, mm2 then :)
<lekernel>
it uses nor flash atm because 1) it's ML401 legacy so I could simply drop in the existing FPGA code 1) it's fast
<wpwrak>
yeah, i though you needed it for some speed reason
<wolfspraul>
speed is good, I'm not really convinced about changing the nor from what I read so far
<wolfspraul>
we should also factor in that we need to support boards we sold for good, so if we create a wide diversity of different chips in our history, it will create a huge maintenance burden
<wolfspraul>
even testing problem
<wolfspraul>
another factor to consider is pcb real estate, less size is good. and lower power consumption, also good. (if it's a relevant amount of power)
<wolfspraul>
but speed sounds like it maybe something worth paying for...
<wpwrak>
NOR works against you in all those regards. it's expensive, usually relatively large, complicates the layout (needs a lot of signals), and can quickly become a sourcing issue
<wolfspraul>
yes I know :-) but speed is still good, need to compare real numbers though.
<wpwrak>
(speed) not sure how the NOR is used. it can give you in-place execution, which NAND/memory card/etc. can't give you. but you can get that with RAM as well. and depending on the NOR speed, you may even prefer to run from RAM anyway.
<wolfspraul>
sourcing issue seems ok btw, there was a little problem when the entire unit was sold from Intel to Micron or whatever, and some part numbers got shuffled, but other than that it seems ok
<wpwrak>
of course, you could have the other extreme and have a separate bus just for some fast NOR. then you'd win heavily in terms of speed. but at cost elsewhere.
<wpwrak>
(sourcing) where in the field of similar chips is it ? you usually have a few categories and there's a range of sizes that shifts with time. you're usually safe at the center, but the fringe gets messy.
<wolfspraul>
I don't know, but I'm not worried about that one :-)
<wolfspraul>
I wish we could throw a super-version of boom at the m1 bom though, crunching through multiple distributor databases etc. that could lead to interesting discoveries quickly (if the software existed).
<wpwrak>
the software will be your smallest problem ;-) you'd need a lot of manual work for classifying all the exotic items
<wolfspraul>
well yes, I assume the uber-smart boom, that knows everything
<wpwrak>
but yes, it may save you a few pennies on capacitors and resistors ;)
<wolfspraul>
no no, can be more
<wolfspraul>
for example on rc2 there was a sourcing errors on some beads, and we ended up paying 10-12 USD per board for those beads
<wpwrak>
the uber-smart one will likely never exist. needs someone who finds those things and enters them. the more exotic they are, the less you can automate things
<wolfspraul>
each of the 8 beads on each board was sourced for 1.46 USD or so
<wolfspraul>
instead of a few cents
<wpwrak>
ah, that sounds nasty
<wolfspraul>
a typical sourcing mistake (this was definitely not fraudulent or anything)
<wolfspraul>
and the beads didn't even work
<wolfspraul>
who knows what it really was, where/how/by whom it was mixed up, etc.
<wolfspraul>
but those things slip though without anybody noticing
<lekernel>
I wonder what those $1.46 beads are supposed to be used for
<wolfspraul>
nah, it's a mistake somewhere
<wolfspraul>
price & product separate :-)
<wpwrak>
what i hope boom will be able to do is to help you pick components that are easy to source. e.g., if you need an RC element with this or that characteristic, which combination will you pick ?
<wolfspraul>
it's definitely not on purpose, I am sure about that
<wolfspraul>
I have 100% trust in where we buy from
<wolfspraul>
but it was a mistake, and this type of thing can happen
<wolfspraul>
but that mistake cost me a cool 500 USD
<wpwrak>
yes, that's what you get when either mis-specifying by accident, or picking the wrong things from the right set. boom already helps you with the latter, by always picking the cheapest available match.
<wpwrak>
i hope to also get into the specification side. make sure you specify something that is common (unless you really need something very specific)
<wpwrak>
e.g., if i need a resistor of ~16 kOhm, should i specify 15, 16, 17, or maybe something like 16.2 kOhm ?
<wpwrak>
the likely answer is 15 kOhm. but there can be surprises.
<wpwrak>
with things like beads, the "well-known area" is even smaller. so the risk of ending up with something exotic by accident is higher.