<wolfspraul>
we should spread the word how easy it is to see inside a pcb
<wolfspraul>
since some people prefer to make a big fuss about that
<kristianpaul>
actually i still dont get full understand of procedure or at least sandpaper ref..
<wolfspraul>
steve did a really wonderful job there, I'm wondering how many hours it took him
<wolfspraul>
it's super easy, you should try yourself :-)
<wolfspraul>
take some old broken electronics
<wolfspraul>
kristianpaul: last time steve|m said he started with corning 120 paper, and once he started to see the next layer, he switched to corning 400 for polishing
<kristianpaul>
so is just hold PCB and start sanding?
<wolfspraul>
for that amount of layers steve did there (compal 88), I would estimate a total working time of ca. 10 hours though
<wolfspraul>
steve said "using a few rows of gaffer-tape as an underlayment, since the non-adhesive site is quite resistant to the sandpaper"
<wolfspraul>
so he just puts the tape on his wooden desk, then the pcb on top, then work starts :-)
<wpwrak>
maybe an even easier approach would be to mill off a little, take a picture, mill off 50-100 um more, etc.
<wpwrak>
would of course be slower, but it would be all automated
<kristianpaul>
you can mill that resolution wow !
<wpwrak>
should take about 1/2 hour per layer. ~20 layers. so it's an overnight job.
<wpwrak>
kristianpaul: 0.1 mm isn't particularly precise :)
<kristianpaul>
heh
<kristianpaul>
I'll say that when some day get a milling machine...
<wpwrak>
you need something that blows away the dust before taking the picture, though
<wpwrak>
my mill should be able to do about 25 us
<steve|m>
kristianpaul: hehe, thanks
<steve|m>
kristianpaul: it took ~4 hours, this time I etched off the layers I already scanned, and only sanded the material between the layers
<steve|m>
DocScrutinizer: what do you mean exactly?
<DocScrutinizer>
by sparkgaps? the structures left to the LCD connector pads
<steve|m>
DocScrutinizer: ah right, for ESD discharge
<DocScrutinizer>
you *may* use spark gaps, given it's 100% additional and just because we get it for free, and also only if it's properly covered by protective varnish (which is the case here it seems)
<DocScrutinizer>
but never use spark gaps as a "replacement" for proper tranzorb/varistor ESD protection
<DocScrutinizer>
thinking about spark gaps: you mustn't use them on unprotected outer layer as random dirt may collect between the spikes and create a short. But then when you cover the spark gap with protective varnish (the green stuff) it's no longer a free air spark gap and your break down voltage rises massively, thus rendering the spark gap useless for the intended purpose
<DocScrutinizer>
I'd love to learn there's a software that can scan and parse the layers as of  http://www.steve-m.de/pictures/ (nice job steve|m ! :-D) and reverse this into a semi-proper schematic
<DocScrutinizer>
I've done that sort of RE on somewhat simpler layouts and it's a *real* nightmare
<DocScrutinizer>
but I guess you probably could create s schematics that looks exactly like all the layers in one stack, and just create connections between traces where due - e.g on vias
<DocScrutinizer>
sth like eagle shouldn't mind about weird schematics layout. Then you can "de-route" it
<DocScrutinizer>
and fill in proper component symbols
<DocScrutinizer>
idly ponders about floodfill algo of painting programs
<DocScrutinizer>
hmmm, a semi-smart algo: pic an arbitrary component pin; floodfill topmost layer trace; when floodfill algo hits a via, start a new floodfill on layers that have a trace in same location; when any of the floodfill processes hits another component pin, create a connection between starting pin and this pin in your schematics
<DocScrutinizer>
obviously the via processing needs to get smarter yet. There may be vias from e.g. layer 3 to layer 4 of a 6 layer PCB. Layer 1, 2, 6 may have traces at location of that via, but they have no via hole so are not connected to the via. Even worse: you *might* see 2 vias in same location: one from layer 1 to 2, one from layer 4 to 5
<DocScrutinizer>
so via processing is: step up and down the layer stack until you find a layer that has no via hole in this location - this is the layer were your via ]ended
<DocScrutinizer>
you *could* even think of via 1->2 and another one 3->4, but I guess that's no good practice
<DocScrutinizer>
and I don't know if PCB manufs can build such crazy stuff at all
<DocScrutinizer>
first doing all layer lamination, then care about vias - for sure the most easy manufacturing procedure
<DocScrutinizer>
or maybe they laminate 3 doublesided PCBs together and vias are done from front to back of either one doublesided PCB payer, or from front to back of PCB #1 and #2 lamitated (which was e.g from layer 1 to layer 4 then), then laminate the 3rd doublesided PCB (with its own front to back vias) and then you can create vias from layer 1 to 6
<DocScrutinizer>
http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#PCB_layers has via layer shots, which tell you if a via travels between the layer just removed and the one not yet visible. So including these steps our via problem is 100% solvable
<DocScrutinizer>
-> while floodfill algo stepping up/down the layers on a via, the via stops on a via layer that has no hole
<DocScrutinizer>
sorry for flooding channel with my spam :-D
<DocScrutinizer>
o/
<kristianpaul>
no no, keep going ;)
<DocScrutinizer>
seems I'm done :-D
<kristianpaul>
:)
<DocScrutinizer>
one more note: you have to prepare your transparent stack of layers by tagging each component pin, and same time create the component in your ECAD schematics. So when you analyze the layer stack with that floodfill algo, the algo knows which two pins to connect in the schematics (e.g Eagle could do this via a list of macros to execute. The macro list could get created by your floodfill algo)
<DocScrutinizer>
add in traveling-salesman distance evaluation for beauty of schematics' sake
<DocScrutinizer>
otherwise you get a lot of star topology trace networks, which might look really annoying
<DocScrutinizer>
maybe all that is moot, as I seem to recall at least one of all those Eagle, PADS and whatnot can backpropagate layout changes to schematics view
<DocScrutinizer>
so maybe it's just enough to import your RE'd layers to the layout view and *voila* schematics are born out of thin air (well almost, you still need to define the components)
<DocScrutinizer>
from starting on layer-6, it seems the via pattern changes from a four-dot to a 5-dot (as on die) on layer-5, then continues and connects to layer-2, and seems to me it even connects to layer-1 as well
<DocScrutinizer>
at least according to "9:2<->top vias"
<DocScrutinizer>
and WTF they did to p.7 BT MT6601 U706:B4 TX_OUT ??? :-O
<wpwrak>
DocScrutinizer: i would first eliminate the concept of layers. just cut thin enough slices that you have at least one point between layers. the apply your flood fill to construct the netlist. after that, see how to convert it into something your schematics capture can use. e.g., auto-name nets, then put each component and just attach the nets as global labels. that way, you don't have to draw connecting lines. group things with a high
<wpwrak>
degree of connectivity close to each other. make some tool for global net renaming in the schematics (or each your EDA system the necessary tricks)
<DocScrutinizer>
err, sorry, you completely lost me. All I got was you tackle on a level that seems way more basic than mine
<DocScrutinizer>
I.E. I never draw connecting lines. I teach my floodfill algo to create a list of macros that make Eagle draw connection lines in a schematic that has only components to start with
<DocScrutinizer>
this is probably what you meant by netlists
<DocScrutinizer>
Eagle does auto-netlist-naming
<DocScrutinizer>
in interactive mode I click one component's pin and draw a rubberband line to an arbitrary 2nd pin, there I fix the rubberband and a new net gets created
<DocScrutinizer>
this can get automated
<DocScrutinizer>
via macros
<DocScrutinizer>
afaik
<DocScrutinizer>
connect(U208:G4; R555:1)
<DocScrutinizer>
obviously you have to tag the pads for U208:G4 and R555:1 in your layers stack. Then the floodfill algo will create the macro as suggested 2 lines above
<DocScrutinizer>
execute all the mocros generated by floodfill in Eagle, on a schematic that has only components placed on an empty sheet, and you get a schematic - though still an ugly one. Beautifying is rather easy in Eagle - that'S after all one of the topmost tasks of a EE CAD
<wpwrak>
yes, the list of nets and the things they connect to is called the netlist. this would be the principal output of your scanning. what you do then with it us a secondary step.
<wpwrak>
and don't use proprietary eagle ;-)
<DocScrutinizer>
I like Eagle a lot
<wpwrak>
it's still non-Free :)
<DocScrutinizer>
NB I didn't suggest to use PADS ;-P
<DocScrutinizer>
Eagle is non-FOSS, it's free-as-in-beer for eurocard doublesided
<DocScrutinizer>
and has proper manuals and docs
<wpwrak>
yeah. a bit limited. not quite crippleware, but close ...
<DocScrutinizer>
but sure it's irrelevant what frontend you run the macros to generate the netlist against
<wpwrak>
yup. the important thing is the netlist. the rest is just presentation :)
<DocScrutinizer>
you need #) (automatic) preprocessing on your layer stack: clearly distinguish trace-copper pixels from "lawn" pixels, detect and mark via holes. #) Manual preprocessing: tag pads with component:pin labels. #) Floodfill starts "filling" from a not-yet-processed random pin, fills pixel by pixel, looks via layer above and below for a via tag for this position. If via detected: spawn a child floodfill for each layer in this direction of
<DocScrutinizer>
stack that has either a lawn pixel with via tag or a copper pixel in this position, stop walking thru layer stack in this direction as soon as a via layer has no via tag in this position. // if the processed pixel has a pin tag, create a line in macro list to connect the origin pin where top level floodfill started to the pin we just found. /// start over with next unprocessed pin, pick it from a list of all pins/pads user marked in
<DocScrutinizer>
maual step of preprocessing
<steve|m>
DocScrutinizer: "05_front_layer3.jpg is kinda hard to decode. You'd need a second board to do the front layers on that" <- how do you mean that?
<steve|m>
which front layer?
<steve|m>
I basically didn't fully remove the very thick finish from this layer and just painted it with textmarker to make it almost transparent
<steve|m>
because the stuff between the second and third layer was very thick and it took a long time to remove it
<steve|m>
but well, if you have all the pics you need using just one board, and wasting just one phone..
<steve|m>
why care
<DocScrutinizer>
they couldn't do "12 : top silk" otherwise ;-)
<DocScrutinizer>
obviously "top silk" been glued to some basis board, or glass, or sth
<DocScrutinizer>
well, maybe not. Think they cheated and just mirrored a picture "from the outside"
<DocScrutinizer>
otherwise you'd not see the white printing where copper is supposed to be seen "from inside"
<steve|m>
ah well, they've done that just like me
<DocScrutinizer>
yep
<steve|m>
I started from both sides and just mirrored the other 3 layers in gimp
<DocScrutinizer>
:nod:
<steve|m>
which is totally awesome btw.. to match the layers after scanning, I adjust one via on the edge to match the other layer, and freely rotate the layer using that via as the center of the rotation
<DocScrutinizer>
I'd probably glue the board with "top silk" side to a thick glass plate, and take off layer by layer until only the white printing remains
<steve|m>
don't know if that works out so well..
<steve|m>
but would be worth a try
<DocScrutinizer>
s/ stack that has either a lawn pixel with via tag or a copper pixel/ stack that has either a lawn pixel with via tag AND COPPER PIXEL NEXT TO VIA HOLE or a copper pixel/
<DocScrutinizer>
(actually you'd not need to tag via holes in trace layers, just filling occasional via holes in copper areas with copper should suffice. Make sure you don't detect via holes in lawn as via holes in copper though)
<DocScrutinizer>
I.E. you need a good distinction method to tell apart a hole from lawn on PCB
<DocScrutinizer>
so lawn isn't taken for a hole
<DocScrutinizer>
then you safely can copper-fill holes in copper areas, while leaving alone holes in lawn areas
<DocScrutinizer>
given all via holes are of same minuscule size and round shape shall ease that task
<DocScrutinizer>
detection of via holes in via layers is more of a problem I guess
<DocScrutinizer>
you probably could clog them easily with dust
<DocScrutinizer>
HAH, given the recursive nature of parent and child flood fill processes, you only need to check if (via)layer self-1 and/or self+1 have a hole. If yes: spawn child floodfill on next (trace)layer self+/-N that has copper in same position. Dont walk layer stack any further than that first layer with copper, child floodfill process will take care of that
<DocScrutinizer>
ooops, of course child floodfill process mustn't walk back over the areas parent process already processed. You could take care of this by blocking child from walking layer stack in opposite direction for this one via
<DocScrutinizer>
or you actually fill traces with a new color that indicates "processed" and thus would stop child processes from walking back to origin automatically
<DocScrutinizer>
also nice to watch on screen while it works, I guess :-D
<DocScrutinizer>
wonders if you could easily implement all this as a gimp macro or plugin
<DocScrutinizer>
shit, mediaplayer shows his special flavour equivalent of a sand-clock for ever
<DocScrutinizer>
kaffeine works :-D
<steve|m>
firefox can play theora since version 3.1 natively
<DocScrutinizer>
on PC
<steve|m>
seems like there's still a long way down the road until flash-less webvideo arives everywhere :P
<steve|m>
+open
<DocScrutinizer>
MEH! kaffeine tries to stream, which fails due to my DSL not supporting the needed datarate, so the movie eventually blocks and doesn't restart. Need to download wnd play from local copy now :-/
<steve|m>
ah well
<steve|m>
next time I'll upload it on youtube I promise
<DocScrutinizer>
nice video, thanks :-D
<DocScrutinizer>
kicks N900 for not playing OGG
<DocScrutinizer>
continues pondering idly over generic floodfill algorithms and realizes this is a nontrivial problem, esp for resource-optimized operation
<wpwrak>
bah, use a reasonably fine raster. memory and cpu cycles are very very cheap these days :)
<DocScrutinizer>
I envision a *huge* stack of points_yet_to_process
<wpwrak>
more than 1 GB ? ;-)
<DocScrutinizer>
prolly not, though - who knows, when floodfilling a ground plane layer
<wpwrak>
the number of points to process grows only with something like O(r*layers) where r is the radius from the origin
<DocScrutinizer>
really not exactly trivial to do this in a optimized way, by any metrics
<wpwrak>
you'll never find anything with even remotely the resolution for this number of points to become even the slightest problem. well, unless you insist on running it on a Ben maybe :)
<wpwrak>
although even the ben probably has enough memory for it. the actual images are more of an issue, with O(x*y*layers) memory
<DocScrutinizer>
prolly not, yet I just pondered a "run the border" algo, that aborts when crossing same pixel twice
<DocScrutinizer>
wouldn't probably need *any* stack
<wpwrak>
you need one for the current periphery. plus you need a memory for which points you've already visited
<wpwrak>
but all this is really quite simple. the hard bit is converting the image into a substrate/copper map
<DocScrutinizer>
look around you, clockwise. Find first pixel of "victim" color that sits right of a "killed" pixel. Kill it. Jump on it. Restart. On error: jump to first pixel that is neither killed nor victim and right to a killed pixel. Restart
<wpwrak>
i like the idea of using a cnc mill to shave off layers. shredding a board like this sound like lots of fun ;-)
<wpwrak>
for these jumps, you either need a "to do" list or you have to search the bitmap every once in a while. not very efficient.
<wpwrak>
(the searching. the to do list is efficient)
<DocScrutinizer>
abort on crossing a non-killed-non-victim_pixel that you already been on before
<wpwrak>
yes yes, i know the algorithm. they've had it in c't some 20+ years ago ;-)
<DocScrutinizer>
for the sake of easy handling of canvas borders: don't jump on a non-victim-non-killed pixel, but rather on the killed pixel left to it
<DocScrutinizer>
really? in c't? So my memory inspired me to think I just invented that?
<wpwrak>
naw, add line line of substrate pixels as a border. then your algorithm will never try to leave the canvas
<wpwrak>
it's ANCIENT ;-)
<DocScrutinizer>
I bet it is
<DocScrutinizer>
I didn't *know* of it
<wpwrak>
it's an algorithm sometimes used for calculating traces (in a layout auto-route) in a grid-based context
<DocScrutinizer>
just thought this would result exactly in a filling pattern I actually observe in painting programs
<wpwrak>
yes, it's the same concept
<wpwrak>
the routing algorithm even finds the shortest path. if you don't need this, your storage requirement drops by O(log2 max_distance)
<DocScrutinizer>
I forgot what O() means
<wpwrak>
order of. e.g., O(n^2) means that the algorithm will need approximately resources something+something*n^2
<wpwrak>
for n towards infinity, this then simply becomes something*n^2
<DocScrutinizer>
indeed for routing it's ideal as it propagates equally in all directions (well actually only into x and y and maybe also diagonal)
<wpwrak>
you only need diagonals if your resolution is close to the structure width. otherwise (+1, +1) is simply (+1, 0) followed by (0, +1)
<DocScrutinizer>
sure, but the distance is incorrect
<wpwrak>
depends on your metric ;-) see also my recent posting about the logo (part 2, the keep out areas)
<DocScrutinizer>
something on +X+Y has real distance sqrt(+X^2 + +Y^2) while this algo calculates distance as +X +Â Â +Y
<wpwrak>
correct. the so-called manhattan distance
<DocScrutinizer>
well, o it uses sqrt(X^2 + Y^2) :-P
<DocScrutinizer>
for distance
<DocScrutinizer>
but then it's not an implicit find of shortest anymore
<wpwrak>
if you're in a manhattan geometry it still does :)
<DocScrutinizer>
yup
<wpwrak>
it all depends on how you define the problem
<DocScrutinizer>
well, here we got no problem related to distance. Just find all possible pathes
<wpwrak>
if you really want to screw with people's heads, use a hyperbolic n-space. euclid would get a big headache :)
<DocScrutinizer>
too
<wpwrak>
yup, distance is just one bit :)
<DocScrutinizer>
yet I think it should be easy to augment gimp to do this PCB layer analysis job
<wpwrak>
oh dear ;-)
<wpwrak>
i'd just write a few lines of C
<DocScrutinizer>
a few?
<wpwrak>
well, maybe a few hundred. it's not complicated.
<DocScrutinizer>
I'd write a few lines of C for a gimp plugin, exploiting gimp's handling of jpg, of layers, of canvas, of floodfill even
<wpwrak>
you have N+2 types of points, derived from the images: substrate, copper, and pad(i)
<DocScrutinizer>
yeah - AFTER preprocessing the raw photos
<wpwrak>
correct
<wpwrak>
that's a completely separate processing strep
<DocScrutinizer>
which could be done in gimp as well
<wpwrak>
denoise, maybe correct along gradients, etc.
<DocScrutinizer>
a bit of object detection, at least for via holes
<wpwrak>
sure. gimp has all the features you need.
<wpwrak>
so you care about via holes ? they're just copper, no ?
<wpwrak>
sort of thin traces
<wpwrak>
if the same pixel in adjacent layers has copper, the two are connected
<DocScrutinizer>
hmm of course I care. Both for via planes that have holes and lawn on your original pictures. As well as for via holes in copper areas that need filling
<wpwrak>
i don't see where the hole matters
<DocScrutinizer>
copper on via layers is rarely ever to be seen, it's too thin
<wpwrak>
that would be a problem
<DocScrutinizer>
what you see though is the hole
<wpwrak>
okay, just treat hole like copper
<DocScrutinizer>
I don't assume a sub-pixel precision of the raw input data
<wpwrak>
i would try to have as many pixels as possible. the more pixels, the easier to fish out the errors :)
<DocScrutinizer>
wpwrak: that's a good idea, and only needs a preprocessor step that actually does that filling of all holes with copper, on all layers
<DocScrutinizer>
all VIA holes
<DocScrutinizer>
shouldn't fill larger holes though
<DocScrutinizer>
(as many pixel as possible) that's obvious
<wpwrak>
why not ? they're probably unconnected within the layers as well
<wpwrak>
otherwise, they may have accidental connections anyway
<wpwrak>
e.g., if you have non-plated holes that just pinch through solid copper layers
<DocScrutinizer>
why not: because I'd assume a hole that's not the size and shape of a via is some error in raw data
<wpwrak>
could be a through-hole component, a mounting hole, etc.
<DocScrutinizer>
yup
<wpwrak>
but i don't think it matters. if it connects to copper horizontally, it probably is as good as a via :)
<DocScrutinizer>
but could as well be a problem in via layer raw data. Via layer pictures are really noisy
<DocScrutinizer>
I'd guess you for sure would want better pictures and still would see a benefit in shape recognition for the via holes
<DocScrutinizer>
dunno, maybe "unscharf maskieren" etc could also help
<DocScrutinizer>
emphasize small dust-alike structures, etc
<DocScrutinizer>
sharpen edges
<larsc>
DocScrutinizer: edge-detect
<DocScrutinizer>
wpwrak: see my prev comment >><DocScrutinizer> if you're curious about what's the deal with vias, a nice execise is to follow the TP018(?) marked "VBAT" in http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#PCB_layers<< ff