<wpwrak>
wolfspraul: naw, it actually doesn't look so nice. "fg" is the first generation of the atusb boards, "ng" the next generation.
<wpwrak>
wolfspraul: as you can see, i managed to "improve" it by about -10 dB :)
<wpwrak>
.. which means that "ng" isn't the last word on that design :) but first i have to verify a few simpler theories regarding possible design bugs
<wolfspraul>
I see.
<wpwrak>
i suspect that i may have put the antenna too close to the rest of the circuit
<wolfspraul>
btw you said it now days .5-1 days to make one board, what is the time spent on?
<wolfspraul>
s/now days .5/now takes .5/
<wolfspraul>
(no coffee yet :-))
<wolfspraul>
mirko: great news about the rfm12 module!
<wpwrak>
it's about equal parts making the pcb and soldering/testing
<wpwrak>
pcb-making is as follows: 1) put a pcb in the mill (or continue using the one already there - each is currently good for ~8 atusb boards)
<wpwrak>
2) install the drill bit in the mill, then use "make cng" (in atusb/cam2/) to check the position and to adjust the drill bit's heights
<wpwrak>
3) "make drill"
<wpwrak>
4) use "make cng" to replace the drill with an endmill.
<wpwrak>
5) "make mill"
<wpwrak>
6) remove the board, soak the side with the adhesive tape (used to keep the board in place in the mill) with paint remover, then pull off the tape
<wpwrak>
7) make the toner transfer sheets (mark a piece of paper to indicate its position in the tray, make front/back, cut a piece of toner transfer paper to the right size, wipe with alcohol, tape to the paper, make front/back again. do this for both sides)
<wpwrak>
8) scrub one side of the board with steel wool, then clean with alcohol.
<wpwrak>
9) put the transfer paper with the toner side facing up, and the board with the clean copper side facing down. get a piece of adhesive tape and attach it to the board's back (facing up), then position board and tape exactly in on the transfer paper.
<wpwrak>
(position and then fix, with the tape, which is a bit larger than the board)
<wpwrak>
10) cut a strip of paper and tape the "sandwich" on it. fold the paper in the middle so that there's paper above and below the "sandwich". the paper is used for transport and for keeping the sticky-when-hot transfer paper from touching things.
<wolfspraul>
sounds like if you would make a panel, you could save time per board. but of course then you couldn't experiment different things on each board.
<wpwrak>
11) heat up the laminator and send the package through it.
<wpwrak>
yes, i have a pretty high rate of variations in this case.
<wpwrak>
12) when the package comes out of the laminator, cut the board free (leaving the back still covered by tape) and remove the transfer paper. visually check that the traces are good.
<wpwrak>
13) wash the board with water, then gently dry. fix any small defects found with an etch resist pen.
<wpwrak>
14) set up the acid (HCl + H2O2) and etch the board
<wpwrak>
15) wash off the acid with water. then soak the tape with paint remover and peel off the tape.
<wpwrak>
16) repeat steps 7 through 15 for the other side of the board
<wpwrak>
17) visually inspect the board and test for short or broken traces. remove shorts with a cutter, remember interruptions for later repair.
<wpwrak>
18) cover one side of the board with flux, when "paint" solder on it, to cover/protect all the copper.
<wpwrak>
19) do 18 for the other side
<wpwrak>
20) done :-)
<wpwrak>
ah, there's a bit more washing after 16, also with paint remover, to remove the toner. then clean the board with alcohol.
<wpwrak>
i'm etching the two sides separateley in order to be able to obtain higher accuracy when positioning the toner sheets. with a bit of patience, i get what looks like about 0.1-0.2 mm.
<wolfspraul>
we should transfer this text into a small README file along with the sources
<wolfspraul>
at least we have it here now and it's archived...
<wpwrak>
my previous approach, where i did both sides at the same time had a larger error between the toner sheets and even worse between board and sheets. not good enough for boards with pre-drilled holes (back then, i did the holes manually at the end, but that's getting too messy with the huge number of vias i have now)
<wpwrak>
i guess i should document the process with some pictures ;-)
<wolfspraul>
sure, even better
<wpwrak>
a looong time ago, i did this for an earlier version of the process. lemme find it ...
<wpwrak>
going from manual to cnc drilling was a big step forward. i had to build quite a bit of extra sw infrastructure for it (cae-tools/cameo/), but i now have much more precise via holes, i can do proper mechanical mounting holes (e.g., for the USB connector), and i don't go through quite so many broken drills anymore either :)
<wpwrak>
i also found a wire that's just the size of the small drill (13.5 mil diameter). so i can put a bit of wire into the hole, and it will stay there, held by friction. before, the wires were loose and thus difficult to solder.
<wpwrak>
the bottom line is that the 38 vias i have now are less of a pain than the perhaps 10 vias i had on similar boards before
<wpwrak>
what still sucks are the ground zones. they quite literally suck, namely heat away from whatever it is i'm actually trying to solder. the experiments with the hot plate resulted in two devices plagued by mysterious defects, so i suspect that process still needs tweaking. for now, i went back to cold boards. (and 100% instead of 0% yield :)
<wpwrak>
added some more vias that i didn't consider necessary. measurements show that this assessment was amazingly correct. hehe :)
<wolfspraul>
don't understand
<wolfspraul>
then why add them?
<wolfspraul>
which assessment was correct?
<wpwrak>
i added them to confirm that they're really not necessary
<wpwrak>
and another experiment (shorting a cap that appears in some reference designs but not in others) ... also no change. good.
<wpwrak>
now the moment of truth ... what if i replace the antenna with the usual wifi version ...
<wpwrak>
after disconnecting the pcb antenna, the signal drops by another 15-20 dB. good. the matrix isn't failing just yet :)
<wpwrak>
and he we have an atusb (ng) board in the oqo. for comparison, -0 is with the board on a cable (like in all previous tests). then i put it into the oqo and moved it around a bit
<wpwrak>
zedstar: alas, my camera doesn't have a good wide-angle, so i can't get it all in one image (and i'm too lazy to stitch them together)
<zedstar>
wpwrak: im jealous!
<wpwrak>
should i mention that we have a nice 28 C at the moment ?
<zedstar>
growls
<wpwrak>
wolfspraul: i;m bringing you three bens closer to selling out :) need some more devices for experimenting
<wolfspraul>
eh, fantastic!
<wpwrak>
ah, you guys created an account for me already :) good that you have a password retrieval feature :)
<wolfspraul>
I plan to remove account creation on the new online shop
<wpwrak>
it's a mixed-blessing kind of feature. can be convenient of you buy a lot from the same place, to avoid problems with typos.
<wpwrak>
on the other hand, mandatory account creation is annoying for one-time customers. but you have both options, so that seems reasonable.
<wolfspraul>
I think not collecting and storing customer data is a feature. Handle the transaction, then purge all unnecessary data, handle the warranty stuff in an anonymous way.
<wolfspraul>
together with making every unique ID on the device both documented and removable that's going to be a challenge :-)
<wpwrak>
it's a risk/liability reduction feature at least :)
<wpwrak>
let's see how long the toys take. and tomorrow, the same with digi-key :)
<wolfspraul>
thanks a lot for the order!
<wpwrak>
we have to work together to beat ron's forecast ! ;-)
<wolfspraul>
yeah, ron...
<wolfspraul>
now he tries to poke into our Milkymist fun
<wpwrak>
he's good. knows exactly the right questions ;-)
<wolfspraul>
yes and no. wrong perspective. he should think about free software first.
<wolfspraul>
sure if you leave that out, his questions are spot on.
<wolfspraul>
say if we were Apple.
<wolfspraul>
but it's good he's around, keeps me grounded
<lekernel>
he should simply _do_ stuff instead of gawking and asking trivial questions that i've heard a thousand times
<wolfspraul>
sure, he will never :-)
<wpwrak>
well, the power consumption of that fpga is likely to be something to worry about.
<lekernel>
wpwrak: you see i'm using software libraries when they're good. I didn't write my own pdf rendering lib :)
<wpwrak>
hehe ;-)
<lekernel>
actually, flickernoise links against ~12 libraries that I didn't write for the most part...
<lekernel>
fortunately there's something else than GNU/Linux and X.org :)
<wpwrak>
ah, regarding LLHDL, someone (kristianpaul ?) mentioned that there's still one non-free tool in the path, place and route, i think. is this also among the things you plan to replace ? (being an fpga ignoramus, i don't know the whole synthesis process)
<lekernel>
btw it's pretty amazing that this 80MHz RISC softcore with mupdf is about as slow (or fast?) than kde's okular on my 2.5GHz superscalar dual core
<wpwrak>
(x.org) well, you mentioned kdrive as a more palatable alternative, didn't you ? you'll get there :)
<wpwrak>
(as slow) ah, i've been wondering about the performance and whether there would be any meaningful benchmarks for PDFs
<lekernel>
well even without any benchmark you can say KDE/X11 is bloated :)
<wpwrak>
(as slow) would be nice to be able to have some data to compare MM1 performance with systems "people know". well, as long as that data looks good. else fix first, publish later ;-)
<lekernel>
it's some 20% faster than microblaze at the same clock frequency
<lekernel>
that for the CPU power only
<wpwrak>
what worries me about things like KDE is the gazillion of helper threads and things they spawn before even beginning to do anything
<lekernel>
when rendering, most of the computationally intensive stuff is done with hardware acceleration on the fpga
<wpwrak>
so also the PDF renderer benefits from the hw acceleration ?
<lekernel>
no, it's software only
<lekernel>
all the GUI is entirely software
<lekernel>
I wanted something simple :)
<lekernel>
though I could still implement hardware accelerated blitting without much trouble
<kristianpaul>
hey nice pic :_)
<lekernel>
accelerating pdf decoding in hw would mean a lot of work
<wpwrak>
blitting may be useful, particular if your GUI stays away from compositing :)
<lekernel>
I wouldn't do that
<wpwrak>
that's the sort of work you'd only do for benchmarks ;-) have a little dhrystone engine :)
<kristianpaul>
(hw aceleration) i wonder if rtems people tought on that when developing it...
<lekernel>
no, but contrary to linux, rtems is easy to hack to your needs
<kristianpaul>
surelly :_)
<wpwrak>
give it time to get fatter and it'll be just as hard ;-) you'd be amazed how easy it was to get major changes into linux in the old days
<kristianpaul>
get fat is an unfair comparison as when gas expands
<kristianpaul>
wpwrak: i tought linux got fat mainlly because drivers..
<kristianpaul>
wpwrak: but even tought linux can run on my linksys router, thats neat :-)
<wpwrak>
drivers, architectures, sub-architectures, layers of abstraction, exotic protocols, it's all there
<kristianpaul>
oh dear..
<wpwrak>
also, simple implementations have been replaced by more efficient but more complex ones
<kristianpaul>
so simple is not always efficient at all?
<wpwrak>
the linux kernel is actually still remarkably clean and simple if you consider all the things it can do
<kristianpaul>
but all that is actually because hardware require it?
<kristianpaul>
new complex and big hardware everyday..
<kristianpaul>
so linux should run on it !
<wpwrak>
(simple/efficient) well, think of RCU. that's a non-trival approach that is much more efficient than the traditional solutions for this kind of locking problem
<kristianpaul>
what we do to run better...
<kristianpaul>
ah yes lets implement all this... you already mentioned
<wpwrak>
(rcu) and they built upon the basic concept, making it even more efficient. but yes, you lose simplicity this way. now you need to read a few research papers before you understand the concept.
<kristianpaul>
of course
<kristianpaul>
(linux kernel is actually still remarkably clean and simple if you consider all the things it can do) i agree
<kristianpaul>
i cant complain yet for soemthing i cant do :-)
<wpwrak>
and then, we have linux run on anything from that linksys of yours, to the whole world of pcs, to some huge mainframes. all with the same kernel. in many cases using exactly the same code.
<wpwrak>
this is a unique archievement. nobody else managed that kind of scalability.
<kristianpaul>
just Milkymist One missing ;-)
<kristianpaul>
in a proper not blamed way
<wpwrak>
yeah. MM1 is somewhere in the middle :)
<kristianpaul>
ah the mmu thing :-)
<wpwrak>
yeah, the nommu has to go
<wpwrak>
then get the arch properly into mainline. put X on top. and then it's just optimization beyond that ;-)
<wpwrak>
maybe even the wayward guys will eventually make something useable, who knows
<kristianpaul>
learn new word today *wayward*
<kristianpaul>
damn, how usefull dual ported ram are
<wpwrak>
well, they call it "wayland". but i like "wayward" better ;-)
<kristianpaul>
not intetionally related with some capricious
<kristianpaul>
hmm i remenber from a funny talk at 27c3 (desktop on linux), that wayland wanted to control the audio stuff in a more low level way..
<kristianpaul>
anyway.. lets see what Linux thinks about :-)
<wpwrak>
ah, 27c3 ... what was that thing about making pcbs with a modified ink printer ? did anyone have a look at that ?
<kristianpaul>
i did
<wpwrak>
did it seem reasonable ?
<kristianpaul>
looks interesting concept for me, but LOT of profesional work need to be if that thing wants to get work
<kristianpaul>
surelly the guy need more poeple involved
<kristianpaul>
reasonable not so much now
<wpwrak>
ah, not just "buy printer X, toss away the ink and replace it with acid Y, and you're all set" then
<kristianpaul>
from why understand its printer head self disamble after some prints
<wpwrak>
hehe ;-)
<kristianpaul>
when he fix that i'll take a look again
<wpwrak>
i was wondering how he'd keep the acid from eating the head :)
<kristianpaul>
actually what he metioned is been introduced in reprap project too
<kristianpaul>
is clear that floss injects are next step
<wpwrak>
what acid does he print with ?
<kristianpaul>
is not acid
<kristianpaul>
is soemthing avoid acid actually
<wpwrak>
oh, i thought he was etching the board directly
<kristianpaul>
you need a second step later
<kristianpaul>
mee too
<kristianpaul>
but no
<wpwrak>
aah. ! so he's printing acid resist and then etches. okay. that should be easier.
<kristianpaul>
some results he show looked pretty well
<kristianpaul>
but still too hackish appliance
<wpwrak>
(direct etching) i was wondering what kind of witchbrew he'd use. it would have to be extremely aggressive for direct application.
<kristianpaul>
my first tought was he finally found the mix to do cheap conductive wires
<kristianpaul>
but nah..
<wpwrak>
cheap conductive wires ? have you checked silver prices lately ? ;-)
<kristianpaul>
s/wires/printed wires
<kristianpaul>
conductive ink is expensive
<wpwrak>
adamw_, DocScrutinizer: Q: if i have a full-speed (11 Mbps) USB interface and i want to add a TVS, what would you consider the highest capacitance for the TVS that's still acceptable ? right now, i use 100 pF.
<adamw_>
wpwrak, second
<wpwrak>
ah, 50 pF, it seems. usb 2.0, page 130, figure 7-9.
<wpwrak>
good. i was planning to go to 33 pF. so that should be fine then.
<wpwrak>
ah, the one in xue clamps at 135 V. 42 V is the operating voltage. seems very high to me.
<adamw_>
correct,
<wpwrak>
hmm, high-speed. things get a little nasty there for sure. "A device that has been tested successfully is based on spark gap technology."
<adamw_>
you don't need to follow Xue, just pick a reasonable value!
<adamw_>
agreed...so the question is that how we estimate a spark gap?
<adamw_>
in advance? well...in practically you should can estimate it first.
<wpwrak>
yeah.  445-2559-1-ND looks friendly. plan B would be the stackpole ESD02A5V5R25VCT-ND. about twice as expensive, but only 0.2 pF. clamps at 25 V (with a slightly more expensive 17 V variant available as well)
<adamw_>
assume first
<wpwrak>
(spark gap) naw, that would be a chip. with built-in spark gap. F1320CT-ND
<adamw_>
carefully when you read that voltage at clamping value...always to see the real curve they plotted in datasheet to pick up.
<wpwrak>
or, better: F2594CT-ND
<wpwrak>
curves - where available - look reasonable. don't show things too clearly, though.
<adamw_>
page 6 of 445-2559-1-ND, page 8 for comparison of various element.
<adamw_>
are you planning that we need to do ESD test? or just choose a part which can suffer from ESD design-in.
<wpwrak>
just designing. the c8051f3xx chips need external ESD protection for USB (at least that's what the data sheet says)
<adamw_>
hmm...ok
<wpwrak>
in fact, in some of my prototypes i just leave it off. 45 cents saved per board ;-)
<adamw_>
for M1005C080MTACS, varistor voltage = 8V
<adamw_>
yeah...no problem on your diy kit or toy. :) but for Ben, yeah...let's take more carefully
<wpwrak>
MTACB ? yes, 8 V -> 5.5 Vdc
<adamw_>
yes
<adamw_>
page 8 for discharge waveform is good enough : M1005C080MTAAB / V1mA:8V, do you see that?
<wpwrak>
yes, looks pretty good. and the MTAAB has even a higher nominal clamping voltage than the MTACB
<adamw_>
yeah
<wpwrak>
alright. i think i have my new TVS. thanks a lot !