<qi-bot> [commit] Maarten ter Huurne: Added missing #include. http://qi-hw.com/p/gmenu2x/8995a3c
<qi-bot> [commit] Maarten ter Huurne: Added missing #include. http://qi-hw.com/p/gmenu2x/34a3d55
<qi-bot> [commit] Maarten ter Huurne: Merge remote branch 'origin/master' http://qi-hw.com/p/gmenu2x/f9db1fb
<qi-bot> [commit] Maarten ter Huurne: Cleaned up link flags. http://qi-hw.com/p/gmenu2x/23042f3
<kristianpaul> going home
<qi-bot> [commit] Maarten ter Huurne: Cleaned up link flags. http://qi-hw.com/p/gmenu2x/c22cc4d
<qi-bot> [commit] Werner Almesberger: atrf-path: added min/max values and corrected averaging algorithm http://qi-hw.com/p/ben-wpan/b159e00
<qi-bot> [commit] Werner Almesberger: atrf-path: generalized sweep interface (for reuse) http://qi-hw.com/p/ben-wpan/6df6487
<qi-bot> [commit] Werner Almesberger: - atrf-rssi.c (gui): moved system-dependent definition to gui.h http://qi-hw.com/p/ben-wpan/2967f99
<qi-bot> [commit] Werner Almesberger: atrf-path: added basic graphical output http://qi-hw.com/p/ben-wpan/0a40910
<wpwrak> ah ... and "xxx" from a few commits ago should have been a fixup. hmm ... to change history or not, this is the question ... i guess i'll just apply Sloth's Razor :)
<rjeffries> wpwrak is "sloth" the son of Occam?
<tuxbrain> Hi dudes :)
<wpwrak> whoa, the return of tuxbrain ! ;-)
<wpwrak> tuxbrain: have the fabs reached a conclusion regarding the hole for the connector ?
<tuxbrain> Wpwrak yes there in no problem with no hole :)
<wpwrak> tuxbrain: *hmm* so how will they solder the connector ? do they realize that the connector goes below the edge of the board ?
<wpwrak> tuxbrain: so they either have to remove (cut) the board there, depanelize, or solder the connector with a different process than the main SMT reflow
<tuxbrain> I will aks but no price rice no delays so watever is fine for me se you later
<wolfspra1l> wpwrak: let's hope that that won't end in painful realizations for tuxbrain later...
<wolfspra1l> I'm not following every detail, but everybody needs to be realistic how much a whole company can get done for 100 USD or 200 USD margin nowadays, if asking a plumber to come fix a water leak costs a similar amount...
<wolfspra1l> so they may just plow through the process, tuxbrain owns the yield :-)
<wpwrak> wolfspra1l: (painful realizations) yeah, it has that ring ...
<wolfspra1l> from following a bit between wpwrak and Adam I'm not entirely convinced yet... :-)
<wolfspra1l> most of them time when you think through such a process, and you realize "hey, that step at that point won't work because...", then everybody else better turn on their brain as well :-)
<wpwrak> wolfspra1l: i kinda wonder who actually "owns" the yield. i haven't seen this explicitly stated anywhere.
<wolfspra1l> the assumption that the other side has 'already thought about everything' is quite naive
<wolfspra1l> oh
<wolfspra1l> that's pretty clear to me ;-)
<wolfspra1l> tuxbrain is the boss, tuxbrain owns everything
<wpwrak> wolfspra1l: (trusting the other side) i think our experience at openmoko has thoroughly cured us of hat, hasn't it ? ;-)
<wolfspra1l> also we have to be realistic how much thought can actually go into it (=little)
<wolfspra1l> they don't have 2-3 guys looking at this for hours, which is what we do here
<wolfspra1l> because that alone would quickly cost 500-1000 USD
<wolfspra1l> anyway
<wpwrak> (ownership) it seems that the smt fab wants a bit of ownership, too. e.g., they do sourcing, which implies that they also do yield estimates on the component count (maybe not the at-end-of-smt yield but other component loss in the process)
<wolfspra1l> nah
<wolfspra1l> I highly doubt that
<wolfspra1l> in fact if they do sourcing, there may be lots of nasty surprises
<wolfspra1l> iqc is highly economical (=optimized), and to optimize it for your product is again not something they have many resources for
<wpwrak> heh ;-)
<wolfspra1l> so the yield of components may vary (very much) depending on how and where they are used exactly
<wpwrak> luckily, the boards are pretty simple. so there's only so much they can do wrong :)
<wolfspra1l> that is all impossible for them to 'get right', because they don't have enough time (enough eyes) for it
<wolfspra1l> all of this will end up on tuxbrain's side later
<wolfspra1l> whereas if you 'know everything', you can source with a lot of knowledge, let's say the run is 50, but some components you source 60, some 55, some 70, etc.
<wolfspra1l> "because you know"
<wolfspra1l> :-)
<wpwrak> well, some parameters also come from the fab. that makes it a bit more complicated. e.g., what presentation exactly they need for their machines.
<wpwrak> (and at what point they just don't use machines)
<wolfspra1l> the only thing I'm worried is that tuxbrain may just not imagine that some of his suppliers overlook something that will later turn into a big problem, which of course he will own
<wpwrak> well, we'll see how it goes. i don't like the idea of outsourcing sourcing either, but if tuxbrain is happier that way ... :)
<wolfspra1l> which isn't even their fault, it's just difficult to get all these parties to do 'just the right things', given the small margins and small amounts of money
<wolfspra1l> wpwrak: tuxbrain thinks "sourcing is taken care of"
<wpwrak> little thinks ... like baking ;-)
<wolfspra1l> which is a good theory
<wpwrak> thinGs
<wpwrak> my expectation is that it'll work without excessive pain. the quantity is small and if anything goes horribly wrong, you can always stop and look for a workaround
<wpwrak> then, in the next iteration, we can burden tuxbrain with some more details ;-)
<wpwrak> regarding sourcing, none of the components should be overly difficult. some of them aren't stocked by all major distributors, but you always have a number of choices. so worst case there would be a delay of a week to order something, plus preparation-for-the-machine overhead
<wpwrak> what should help is that they're all local, so he can go there and watch what happens. now he just needs to know what to look for :)
<wolfspra1l> he absolutely should go to the run
<wolfspra1l> wpwrak: my concern about sourcing is not so much the technicality of where/when/how many to order, but the iqc
<wolfspra1l> with a software mind, there is no iqc, and it doesn't have much value
<wolfspra1l> but with a hardware (analog) mind, you will soon realize _EVERYTHING_ has tolerances, everything is a matter of spending just the right amount of time to check for the right things that matter in your application
<wolfspra1l> and that is hard
<wpwrak> there probably isn't much we can do about iqc per se
<wpwrak> there are a few things you can detect in end-of-smt testing, though
<wolfspra1l> no but if you outsource sourcing, that's the thing tuxbrain should keep his eyes on
<asmanur> hello
<wolfspra1l> because that's where knowledge of the particular board matters, and whoever you outsourced sourcing to may not know it as well as you do
<asmanur> is this possible to solve the problem with suspending without kernel hacking ?
<asmanur> it has been suggested to wakup automatically the nanonote but can't find any ressources about it
<wpwrak> wolfspra1l: hmm, but are you talking about faulty components or replacements with diverging specifications ?
<wolfspra1l> I'm talking about no 2 components being exactly the same.
<wpwrak> asmanur: larsc would be your expert for this
<wolfspra1l> sourcing always has iqc
<wolfspra1l> but if you outsource it you create a dangerous potential knowledge leak
<wolfspra1l> tuxbrain could ask them to go over the components and let them tell him what iqc they are planning
<asmanur> wpwrak: yeah..i've read some logs but only saw vague methods :-(
<wolfspra1l> then they will tell him one by one "here we do this, here we only check label, here we check that"
<wpwrak> wolfspra1l: (exactly the same) but tolerances are a design issue. only components outside the tolerance range are an iqc issue.
<wolfspra1l> and tuxbrain can match that against his knowledge of the board (if he can)
<wpwrak> wolfspra1l: well, unless you buy with larger tolerances you need and then do the filtering yourself. but we don't want to go there ;-)
<wolfspra1l> nah. sourcing (components) are not binary
<wolfspra1l> the vendor may say 'sorry' and take them back
<wolfspra1l> but whether it costs you 10 USD to get to the 'sorry' state, or 1000 USD, that's your problem :-)
<wpwrak> wolfspra1l: yes, you can get a bad batch
<wolfspra1l> not just batch, also individual ones
<wolfspra1l> tuxbrain will find out, the more runs the more he will find out :-)
<wolfspra1l> it's all about economics
<wolfspra1l> in hardware that's pretty painful because you just have no time to test 'everything'
<wolfspra1l> because each individual component is so damned cheap
<wolfspra1l> and those stingy customers still want to slice off the last .1 cent
<wpwrak> wolfspra1l: i don't think you can spot individual bad components efficiently. they come out of the tape at the smt machine and the smt machine doesn't do iqc ...
<wolfspra1l> my only point is (it's about process): if you outsource sourcing, watch iqc
<wolfspra1l> no way, I talk about all components. something like the USB connector can, or cannot, be iqc'ed in many ways
<wolfspra1l> again: when you outsource sourcing, watch iqc
<wolfspra1l> :-)
<wolfspra1l> they do not know your board
<wolfspra1l> or at least not as well as you do
<wolfspra1l> later you will say "man, why didn't you see this?" but alas, they didn't...
<wpwrak> wolfspra1l: i'm still a bit confused about what exactly you mean. i understand taking a few samples from a batch and analyzing end-of-smt failures, but the potential for the checking of individual components seems to be limited. would you have some specific example(s) ?
<wpwrak> wolfspra1l: (checking batches) well, and checking that this is indeed the right component. small detail :)
<wolfspra1l> last m1 run we had a problem with lifted pins
<wpwrak> and that was a sourcing/supplier problem ?
<wolfspra1l> process problem
<wolfspra1l> we even did the sourcing, we just forgot to iqc lifted pins
<wpwrak> alright. that's the ones you can catch at the end. run one board, see what happens. rinse and repeat.
<wolfspra1l> the thing is that manufacturing is about economics, not about correctness
<wolfspra1l> everybody follows that
<wolfspra1l> so the reaction "they are so stupid" is just stupid in itself
<wpwrak> (iqc lifted pins) you mean the chip package was deformed ?
<wolfspra1l> they are not stupid, they operated with zero knowledge, on purpose to keep the costs low
<wolfspra1l> actually the pins have tolerances already, from the datasheet
<wolfspra1l> but parts for a small run may come from different parties, some free samples, some from another run somewhere
<wolfspra1l> then it gets messy
<wpwrak> (zero knowledge) i think the guys in spain know at least some things. they made some useful remarks and suggestions.
<wolfspra1l> just think about it - these things are so cheap, just pennies
<wolfspra1l> if you would be a component vendor, you know you have to cut your costs as aggressively as possible
<wolfspra1l> you can take those penny items back
<wolfspra1l> but what damage does a 'bad' component cause to your customer?
<wolfspra1l> is it 1 USD, or 100 USD or 1000 USD?
<wolfspra1l> you don't know!
<wolfspra1l> it depends on them
<wpwrak> (pins) okay, but as long as they're within spec, it's no longer an iqc issue.
<wolfspra1l> and their process, and how everybody makes sure that the right things are checked
<wolfspra1l> sourcing ... iqc ... smt
<wolfspra1l> I mean the iqc after sourcing and before smt
<wolfspra1l> so it's already product-specific iqc
<wpwrak> the customers will also remember whom they to thank for for their losses
<wolfspra1l> they will go back to the cheapest supplier
<wolfspra1l> and see whether they can catch it in their iqc next time
<wolfspra1l> my point was that the component vendor also is no messiah
<wpwrak> depends. as i said, something are virtually impossible to catch.
<wolfspra1l> they cannot do and see everything
<wolfspra1l> just remember, it's not sourcing ... smt
<wolfspra1l> it's sourcing ... iqc ... smt
<wpwrak> e.g., if you get a 10% tolerance cap that's 50% off. you'll never catch that one.
<wolfspra1l> and if you outsource sourcing, you have to be a bit careful about that
<wolfspra1l> tuxbrain should ask them to walk him through the iqc steps
<wolfspra1l> it's just a few components anyway
<wolfspra1l> this is valuable information that should be communicated
<wolfspra1l> if it is not, it may be the source of surprises later
<wolfspra1l> that's my only point, I rest my case :-)
<wpwrak> maybe you could post what things to look for in those iqc steps ? my expectation would be: 1) visual inspection of the general condition of the shipment. 2) checking the label(s). 3) with luck, for unmarked components (caps, etc.), pick one and measure it (to make sure they didn't send you the 1 NF reel where you wanted the 1 UF reel)
<wpwrak> for larger samples, you'd already need bigger volume. for testing more sophisticated components, you need a dedicated process, which nobody has.
<wpwrak> (nobody) that is, none of use nor the smt fab. if we'd make a few million boards, it would be worth developing one.
<wpwrak> other things to look for would be moisture sensitivity, baking requirements, reflow profiles.
<wpwrak> but that's already past IQC
<wpwrak> regarding mechanical issues, i expect that the usb connector will be more fun, but that's on the process side. and yes, that one wants watching. they may also mis-rotate some components. happens all the time. all but one can be checked visually. you can also see the led's orientation, but it's not so easy. but an ohmmeter will do the trick :)
<wolfspra1l> yes correct, roughly those things
<wolfspra1l> calling it a day, reading backlog tomorrow... n8
<qi-bot> [commit] Werner Almesberger: tools/atrf-path/gui.c: temporarily added code for sweep time measurements http://qi-hw.com/p/ben-wpan/6efe374
<qi-bot> [commit] Werner Almesberger: tools/lib/cwtest.c (cw_test_end): try "quick reset" on AT86RF231 http://qi-hw.com/p/ben-wpan/4244af2
<qi-bot> [commit] Werner Almesberger: tools/atrf-path/gui.c (gui): added pulsating disc as progress/status indicator http://qi-hw.com/p/ben-wpan/cee0296
<qi-bot> [commit] Werner Almesberger: atrf-path: the GUI is now activated with -g; also changed arguments in GUI mode http://qi-hw.com/p/ben-wpan/436c9fa
<qi-bot> [commit] Werner Almesberger: atrf-path/atrf-path.c: initialize the receiver only once, not for each sweep http://qi-hw.com/p/ben-wpan/5f153ca
<qi-bot> [commit] Werner Almesberger: libatrf: cw test mode can now be resumed, with lower overhead (231 only) http://qi-hw.com/p/ben-wpan/16a48d6
<qi-bot> [commit] Werner Almesberger: atrf-path.c: moved tx init out of sample loop (breaks 230 support) http://qi-hw.com/p/ben-wpan/e3463ef
<qi-bot> [commit] Werner Almesberger: atrf-path: sweep offsets separately, so that the we can reuse the cw setup http://qi-hw.com/p/ben-wpan/2c1cb71
<qi-bot> [commit] Werner Almesberger: atrf-path.c (usage): list common args only once, not in each synopsis http://qi-hw.com/p/ben-wpan/d263ffc
<qi-bot> [commit] Werner Almesberger: atrf-path.c (do_half_sweep, do_sweep): don't duplicate the loop - use a function http://qi-hw.com/p/ben-wpan/598582c
<qi-bot> [commit] Werner Almesberger: atrf-path: new option -T to sweep only one offset http://qi-hw.com/p/ben-wpan/e2a9c9d
<qi-bot> [commit] Werner Almesberger: atrf-path.c: do cw test setup only once if sweeping a single offset http://qi-hw.com/p/ben-wpan/a7d9dfd
<kristianpaul> I'm back !
<wpwrak> kristianpaul: back from ... ? :)
<kristianpaul> wpwrak: medellin :-)
<kristianpaul> labsurlab
<wpwrak> aha ! was it interesting ?
<kristianpaul> yes
<kristianpaul> met lot of people
<kristianpaul> brazil, argentina, france, mexico, españa..
<kristianpaul> not too much hardware related projects, but "el movimiento sin satelite" is enought for me :-)
<wpwrak> what would that be ?
<kristianpaul> well, there are two choices, re-use a sat or launch one
<wpwrak> err, in what context ?
<kristianpaul> have a satellite for own use?
<wpwrak> ah, i see. like some people have a cat. makes sense :)
<kristianpaul> :)
<kristianpaul> lorea.org
<rejon_> hahaha
<wpwrak> rejon_: i think we'll see it get a little fatter with time ;-)
<rejon_> yeah
<rejon_> hahaha
<rejon_> man, some group trying to get me to sign an NDA about mesh networking
<rejon_> bs
<rejon_> even though NDAs are meaningless
<rejon_> <rejon_> "The Chinese company Huawei Technologies Ltd., one of the original contractors for Libyana's cellular network backbone, refused to sell equipment for the rebel project, causing Mr. Abushagur and his engineer buddies to scramble to find a hybrid technical solution to match other companies' hardware with the existing Libyan network. Huawei declined to comment on its customers or work in Libya. The Libyan expats in the project a
<rejon_> sked that
<rejon_> <rejon_>  their corporate affiliations be kept confidential so that their political activities don't interfere with their work responsibilities. "
<rjeffries_> wpwrak have you looked at FunCubeDongle, softwrae defined radio? http://www.funcubedongle.com/
<kristianpaul> had one FunCubeDongle in his hands and pluged in his latop at labsurlab
<kristianpaul> rjeffries_: its hardware schematics is under DNA, but work out of the box with free software ;)
<kristianpaul> plus some atenas and RF stuff you can get excelent results, but i had heard it work fine just pluging the atena directly to it
<rjeffries_> kristianpaul sure is a cool concept. wonder how well it works. it is not very expensive I think
<rjeffries_> it==FunCubeDongle that is
<kristianpaul> (ow well it works) take your time, but this is a good source http://www.oz9aec.net/index.php/funcube-dongle
<wpwrak> rejon_: (libya) the devil's in the details ;-)
<rejon_> chinaaaaaa!
<rejon_> the world's drug dealer
<wpwrak> rjeffries: heard of it, yes. alas, not the most useful frequency range. also, very narrow-band. about 1000 times narrower than the usrp2. furthermore, rx-only.
<mth> FYI: I added pokeparadox to the gmenu2x contributors
<mth> so don't be alarmed if commits are coming in from a new name