2011-08-25 00:10 [commit] Xiangfu Liu: not working without asound.conf, asound.conf make MIC not working (master) http://qi-hw.com/p/openwrt-packages/7d202ed 2011-08-25 01:09 [commit] Xiangfu Liu: nanonote-files: add hwclock --hctosys when shutdown (master) http://qi-hw.com/p/openwrt-packages/b685397 2011-08-25 02:27 interesting treatise on how the structure of names varies across cultures: http://www.w3.org/International/questions/qa-personal-names 2011-08-25 03:27 steve|m: nice sandpaper work with c123 :) 2011-08-25 03:31 really interesting to realize a 3 layer phone 2011-08-25 03:31 just in case not body here follow rss from osmocom track http://www.steve-m.de/pictures/compal_e88/ 2011-08-25 03:31 not all body** 2011-08-25 03:46 oh another rss I don't know about 2011-08-25 03:46 kristianpaul: if you see any good rss missing in the qi planet, please let me know 2011-08-25 03:47 wow this is a nice job! 2011-08-25 03:49 kristianpaul: what is the rss url? 2011-08-25 03:49 http://bb.osmocom.org/trac/timeline?wiki=on&max=50&daysback=90&format=rss 2011-08-25 03:50 not sure if qi planet fits well with trac rss.. but you asked 2011-08-25 03:50 ah trac rss, yeah, probably not so good 2011-08-25 03:51 :) 2011-08-25 03:51 but that's a really nice sanding job there 2011-08-25 03:51 indeed 2011-08-25 03:51 http://planet.osmocom.org/rss20.xml just in case you were aware of 2011-08-25 03:51 we should spread the word how easy it is to see inside a pcb 2011-08-25 03:51 since some people prefer to make a big fuss about that 2011-08-25 03:52 actually i still dont get full understand of procedure or at least sandpaper ref.. 2011-08-25 03:52 steve did a really wonderful job there, I'm wondering how many hours it took him 2011-08-25 03:52 it's super easy, you should try yourself :-) 2011-08-25 03:52 take some old broken electronics 2011-08-25 03:54 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 2011-08-25 03:54 so is just hold PCB and start sanding? 2011-08-25 03:54 for that amount of layers steve did there (compal 88), I would estimate a total working time of ca. 10 hours though 2011-08-25 03:55 steve said "using a few rows of gaffer-tape as an underlayment, since the non-adhesive site is quite resistant to the sandpaper" 2011-08-25 03:56 so he just puts the tape on his wooden desk, then the pcb on top, then work starts :-) 2011-08-25 03:58 maybe an even easier approach would be to mill off a little, take a picture, mill off 50-100 um more, etc. 2011-08-25 03:59 would of course be slower, but it would be all automated 2011-08-25 04:00 you can mill that resolution wow ! 2011-08-25 04:01 should take about 1/2 hour per layer. ~20 layers. so it's an overnight job. 2011-08-25 04:01 kristianpaul: 0.1 mm isn't particularly precise :) 2011-08-25 04:02 heh 2011-08-25 04:02 I'll say that when some day get a milling machine... 2011-08-25 04:02 you need something that blows away the dust before taking the picture, though 2011-08-25 04:03 my mill should be able to do about 25 us 2011-08-25 08:54 kristianpaul: hehe, thanks 2011-08-25 08:55 kristianpaul: it took ~4 hours, this time I etched off the layers I already scanned, and only sanded the material between the layers 2011-08-25 08:55 worked quite nice 2011-08-25 10:14 steve|m: duh, what you're doing? 2011-08-25 10:20 nm, I read backscroll 2011-08-25 10:24 http://www.steve-m.de/pictures/compal_e88/07_front_layer1.jpg  WTF!?! spark gaps - that's stone age 2011-08-25 10:26 DocScrutinizer: what do you mean exactly? 2011-08-25 10:26 by sparkgaps? the structures left to the LCD connector pads 2011-08-25 10:27 DocScrutinizer: ah right, for ESD discharge 2011-08-25 10:28 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) 2011-08-25 10:29 but never use spark gaps as a "replacement" for proper tranzorb/varistor ESD protection 2011-08-25 10:31 http://www.steve-m.de/pictures/compal_e88/05_front_layer3.jpg is kinda hard to decode. You'd need a second board to do the front layers on that 2011-08-25 10:37 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 2011-08-25 10:39 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 2011-08-25 10:41 I've done that sort of RE on somewhat simpler layouts and it's a *real* nightmare 2011-08-25 10:44 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 2011-08-25 10:44 sth like eagle shouldn't mind about weird schematics layout. Then you can "de-route" it 2011-08-25 10:45 and fill in proper component symbols 2011-08-25 10:48 idly ponders about floodfill algo of painting programs 2011-08-25 10:51 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 2011-08-25 10:55 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 2011-08-25 10:57 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 2011-08-25 10:58 you *could* even think of via 1->2 and another one 3->4, but I guess that's no good practice 2011-08-25 10:59 and I don't know if PCB manufs can build such crazy stuff at all 2011-08-25 11:03 first doing all layer lamination, then care about vias - for sure the most easy manufacturing procedure 2011-08-25 11:07 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 2011-08-25 11:13 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 2011-08-25 11:14 -> while floodfill algo stepping up/down the layers on a via, the via stops on a via layer that has no hole 2011-08-25 11:15 sorry for flooding channel with my spam :-D 2011-08-25 11:15 o/ 2011-08-25 11:15 no no, keep going ;) 2011-08-25 11:16 seems I'm done :-D 2011-08-25 11:16 :) 2011-08-25 11:26 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) 2011-08-25 11:29 add in traveling-salesman distance evaluation for beauty of schematics' sake 2011-08-25 11:30 otherwise you get a lot of star topology trace networks, which might look really annoying 2011-08-25 11:32 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 2011-08-25 11:34 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) 2011-08-25 11:55 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 2011-08-25 11:57 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 2011-08-25 11:59 at least according to "9:2<->top vias" 2011-08-25 12:00 err "10:2<->top vias" 2011-08-25 12:01 and s/TP018/TP017/ sorry 2011-08-25 12:03 GND TP018 is even more puzzling 2011-08-25 12:21 anyway doing a complete RE of the schematics of a PCB the complexity of http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#PCB_layers is probably a life's work (as you might go mad and die during this effort) 2011-08-25 12:22 unless you have some smart tools doing the "heavy lifting" for you 2011-08-25 12:41 wolfspraul: hey, http://en.qi-hardware.com/w/images/6/6b/Sciphone_G2_I10_v3_schematics.pdf p.4 "HANDSET MI COPHONE" has built-in buzz-fix :-D 2011-08-25 12:42 C409 ;-D 2011-08-25 12:48 and WTF they did to p.7 BT MT6601 U706:B4 TX_OUT ??? :-O 2011-08-25 12:56 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 2011-08-25 12:56 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) 2011-08-25 12:58 err, sorry, you completely lost me. All I got was you tackle on a level that seems way more basic than mine 2011-08-25 13:00 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 2011-08-25 13:01 this is probably what you meant by netlists 2011-08-25 13:02 Eagle does auto-netlist-naming 2011-08-25 13:03 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 2011-08-25 13:03 this can get automated 2011-08-25 13:03 via macros 2011-08-25 13:03 afaik 2011-08-25 13:04 connect(U208:G4; R555:1) 2011-08-25 13:05 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 2011-08-25 13:07 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 2011-08-25 13:07 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. 2011-08-25 13:08 and don't use proprietary eagle ;-) 2011-08-25 13:08 I like Eagle a lot 2011-08-25 13:08 it's still non-Free :) 2011-08-25 13:08 NB I didn't suggest to use PADS ;-P 2011-08-25 13:09 Eagle is non-FOSS, it's free-as-in-beer for eurocard doublesided 2011-08-25 13:09 and has proper manuals and docs 2011-08-25 13:10 yeah. a bit limited. not quite crippleware, but close ... 2011-08-25 13:10 but sure it's irrelevant what frontend you run the macros to generate the netlist against 2011-08-25 13:11 yup. the important thing is the netlist. the rest is just presentation :) 2011-08-25 13:20 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 2011-08-25 13:20 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 2011-08-25 13:20 maual step of preprocessing 2011-08-25 13:21 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? 2011-08-25 13:21 which front layer? 2011-08-25 13:23 I basically didn't fully remove the very thick finish from this layer and just painted it with textmarker to make it almost transparent 2011-08-25 13:23 because the stuff between the second and third layer was very thick and it took a long time to remove it 2011-08-25 13:24 the next layer "beneath" that is http://www.steve-m.de/pictures/compal_e88/04_dbb_layer3.jpg 2011-08-25 13:24 so all layers are there, no second board needed 2011-08-25 13:24 steve|m: aah. Well I just meant the last layer is hard to work on, as it gets so thin. you better use a seconf 2011-08-25 13:25 ah right 2011-08-25 13:25 second board and keep the back 3 layers while doing the front layers 2011-08-25 13:25 yes, it's very thin 2011-08-25 13:25 I cracked it a bit in the middle 2011-08-25 13:25 or you glue the whole thing firmly to a basis, like a board or sth 2011-08-25 13:26 that's probably how they did http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#PCB_layers 2011-08-25 13:26 but well, if you have all the pics you need using just one board, and wasting just one phone.. 2011-08-25 13:26 why care 2011-08-25 13:27 they couldn't do "12 : top silk" otherwise ;-) 2011-08-25 13:28 obviously "top silk" been glued to some basis board, or glass, or sth 2011-08-25 13:29 well, maybe not. Think they cheated and just mirrored a picture "from the outside" 2011-08-25 13:30 otherwise you'd not see the white printing where copper is supposed to be seen "from inside" 2011-08-25 13:31 ah well, they've done that just like me 2011-08-25 13:31 yep 2011-08-25 13:31 I started from both sides and just mirrored the other 3 layers in gimp 2011-08-25 13:32 :nod: 2011-08-25 13:33 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 2011-08-25 13:33 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 2011-08-25 13:34 don't know if that works out so well.. 2011-08-25 13:34 but would be worth a try 2011-08-25 13:40 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/ 2011-08-25 13:42 (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) 2011-08-25 13:44 I.E. you need a good distinction method to tell apart a hole from lawn on PCB 2011-08-25 13:44 so lawn isn't taken for a hole 2011-08-25 13:45 then you safely can copper-fill holes in copper areas, while leaving alone holes in lawn areas 2011-08-25 13:47 given all via holes are of same minuscule size and round shape shall ease that task 2011-08-25 13:48 detection of via holes in via layers is more of a problem I guess 2011-08-25 13:49 you probably could clog them easily with dust 2011-08-25 13:55 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 2011-08-25 13:57 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 2011-08-25 13:58 or you actually fill traces with a new color that indicates "processed" and thus would stop child processes from walking back to origin automatically 2011-08-25 13:59 also nice to watch on screen while it works, I guess :-D 2011-08-25 14:00 wonders if you could easily implement all this as a gimp macro or plugin 2011-08-25 14:01 ihttp://www.steve-m.de/files/pcb_lastlayer.webm 2011-08-25 14:02 gr 2011-08-25 14:02 http://www.steve-m.de/files/pcb_lastlayer.webm 2011-08-25 14:02 hmm, unknown format 2011-08-25 14:03 hm, plays fine here, even updated mimetypes to auto-play in firefox 2011-08-25 14:04 mhm, FF. Lemme try 2011-08-25 14:04 VLC works fine as well 2011-08-25 14:05 sorry, no codecs for this format 2011-08-25 14:05 then you are on a totally outdated system :p 2011-08-25 14:06 well, this PC is really poor on codecs 2011-08-25 14:06 yes 2011-08-25 14:07 that's a webm container, 3mbit VP8 video encoded with libvpx, 128kbit audio with libvorbis 2011-08-25 14:07 basically what youtube uses for their html5-beta 2011-08-25 14:07 mhm, that doesn't work either here 2011-08-25 14:08 might try it on my phone, it has way better codecs (and also better GFX at alrge) 2011-08-25 14:09 seems like I should have used theora instead 2011-08-25 14:11 meh, "open with mediaplayer (extended media support)" -> download 12MB -> "media format not supported" 2011-08-25 14:14 wait a second.. 2011-08-25 14:14 sure 2011-08-25 14:19 DocScrutinizer51: http://www.steve-m.de/files/pcb_lastlayer.ogv 2011-08-25 14:20 let's see... 2011-08-25 14:21 open in mediaplayer(ogg) :-) 2011-08-25 14:25 shit, mediaplayer shows his special flavour equivalent of a sand-clock for ever 2011-08-25 14:25 kaffeine works :-D 2011-08-25 14:25 firefox can play theora since version 3.1 natively 2011-08-25 14:25 on PC 2011-08-25 14:26 seems like there's still a long way down the road until flash-less webvideo arives everywhere :P 2011-08-25 14:27 +open 2011-08-25 14:30 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 :-/ 2011-08-25 14:30 ah well 2011-08-25 14:31 next time I'll upload it on youtube I promise 2011-08-25 14:37 nice video, thanks :-D 2011-08-25 14:38 kicks N900 for not playing OGG 2011-08-25 14:43 continues pondering idly over generic floodfill algorithms and realizes this is a nontrivial problem, esp for resource-optimized operation 2011-08-25 14:44 bah, use a reasonably fine raster. memory and cpu cycles are very very cheap these days :) 2011-08-25 14:44 I envision a *huge* stack of points_yet_to_process 2011-08-25 14:45 more than 1 GB ? ;-) 2011-08-25 14:45 prolly not, though - who knows, when floodfilling a ground plane layer 2011-08-25 14:46 the number of points to process grows only with something like O(r*layers) where r is the radius from the origin 2011-08-25 14:46 really not exactly trivial to do this in a optimized way, by any metrics 2011-08-25 14:47 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 :) 2011-08-25 14:48 although even the ben probably has enough memory for it. the actual images are more of an issue, with O(x*y*layers) memory 2011-08-25 14:48 prolly not, yet I just pondered a "run the border" algo, that aborts when crossing same pixel twice 2011-08-25 14:48 wouldn't probably need *any* stack 2011-08-25 14:49 you need one for the current periphery. plus you need a memory for which points you've already visited 2011-08-25 14:49 but all this is really quite simple. the hard bit is converting the image into a substrate/copper map 2011-08-25 14:51 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 2011-08-25 14:51 i like the idea of using a cnc mill to shave off layers. shredding a board like this sound like lots of fun ;-) 2011-08-25 14:52 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. 2011-08-25 14:53 (the searching. the to do list is efficient) 2011-08-25 14:53 abort on crossing a non-killed-non-victim_pixel that you already been on before 2011-08-25 14:54 yes yes, i know the algorithm. they've had it in c't some 20+ years ago ;-) 2011-08-25 14:54 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 2011-08-25 14:55 really? in c't? So my memory inspired me to think I just invented that? 2011-08-25 14:55 naw, add line line of substrate pixels as a border. then your algorithm will never try to leave the canvas 2011-08-25 14:56 it's ANCIENT ;-) 2011-08-25 14:56 I bet it is 2011-08-25 14:56 I didn't *know* of it 2011-08-25 14:57 it's an algorithm sometimes used for calculating traces (in a layout auto-route) in a grid-based context 2011-08-25 14:57 just thought this would result exactly in a filling pattern I actually observe in painting programs 2011-08-25 14:57 yes, it's the same concept 2011-08-25 14:58 the routing algorithm even finds the shortest path. if you don't need this, your storage requirement drops by O(log2 max_distance) 2011-08-25 14:58 I forgot what O() means 2011-08-25 14:59 order of. e.g., O(n^2) means that the algorithm will need approximately resources something+something*n^2 2011-08-25 15:00 for n towards infinity, this then simply becomes something*n^2 2011-08-25 15:00 indeed for routing it's ideal as it propagates equally in all directions (well actually only into x and y and maybe also diagonal) 2011-08-25 15:01 see also http://en.wikipedia.org/wiki/Big_Oh_notation 2011-08-25 15:01 hmm, with diagonal moves it covers all directions :-) 2011-08-25 15:01 and http://en.wikipedia.org/wiki/Analysis_of_algorithms 2011-08-25 15:02 and if you have the stomach for it http://en.wikipedia.org/wiki/Computational_complexity 2011-08-25 15:03 you only need diagonals if your resolution is close to the structure width. otherwise (+1, +1) is simply (+1, 0) followed by (0, +1) 2011-08-25 15:03 sure, but the distance is incorrect 2011-08-25 15:04 depends on your metric ;-) see also my recent posting about the logo (part 2, the keep out areas) 2011-08-25 15:05 something on +X+Y has real distance sqrt(+X^2 + +Y^2) while this algo calculates distance as +X +  +Y 2011-08-25 15:06 correct. the so-called manhattan distance 2011-08-25 15:06 well, o it uses sqrt(X^2 + Y^2) :-P 2011-08-25 15:06 for distance 2011-08-25 15:07 but then it's not an implicit find of shortest anymore 2011-08-25 15:07 if you're in a manhattan geometry it still does :) 2011-08-25 15:07 yup 2011-08-25 15:07 it all depends on how you define the problem 2011-08-25 15:08 well, here we got no problem related to distance. Just find all possible pathes 2011-08-25 15:08 if you really want to screw with people's heads, use a hyperbolic n-space. euclid would get a big headache :) 2011-08-25 15:09 too 2011-08-25 15:09 yup, distance is just one bit :) 2011-08-25 15:10 yet I think it should be easy to augment gimp to do this PCB layer analysis job 2011-08-25 15:10 oh dear ;-) 2011-08-25 15:10 i'd just write a few lines of C 2011-08-25 15:10 a few? 2011-08-25 15:11 well, maybe a few hundred. it's not complicated. 2011-08-25 15:11 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 2011-08-25 15:12 you have N+2 types of points, derived from the images: substrate, copper, and pad(i) 2011-08-25 15:12 yeah - AFTER preprocessing the raw photos 2011-08-25 15:12 correct 2011-08-25 15:12 that's a completely separate processing strep 2011-08-25 15:13 which could be done in gimp as well 2011-08-25 15:13 denoise, maybe correct along gradients, etc. 2011-08-25 15:14 a bit of object detection, at least for via holes 2011-08-25 15:14 sure. gimp has all the features you need. 2011-08-25 15:14 so you care about via holes ? they're just copper, no ? 2011-08-25 15:14 sort of thin traces 2011-08-25 15:15 if the same pixel in adjacent layers has copper, the two are connected 2011-08-25 15:15 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 2011-08-25 15:16 i don't see where the hole matters 2011-08-25 15:16 copper on via layers is rarely ever to be seen, it's too thin 2011-08-25 15:16 that would be a problem 2011-08-25 15:16 what you see though is the hole 2011-08-25 15:17 okay, just treat hole like copper 2011-08-25 15:17 I don't assume a sub-pixel precision of the raw input data 2011-08-25 15:18 i would try to have as many pixels as possible. the more pixels, the easier to fish out the errors :) 2011-08-25 15:18 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 2011-08-25 15:18 all VIA holes 2011-08-25 15:19 shouldn't fill larger holes though 2011-08-25 15:19 (as many pixel as possible) that's obvious 2011-08-25 15:19 why not ? they're probably unconnected within the layers as well 2011-08-25 15:20 otherwise, they may have accidental connections anyway 2011-08-25 15:20 e.g., if you have non-plated holes that just pinch through solid copper layers 2011-08-25 15:21 why not: because I'd assume a hole that's not the size and shape of a via is some error in raw data 2011-08-25 15:21 could be a through-hole component, a mounting hole, etc. 2011-08-25 15:21 yup 2011-08-25 15:22 but i don't think it matters. if it connects to copper horizontally, it probably is as good as a via :) 2011-08-25 15:22 but could as well be a problem in via layer raw data. Via layer pictures are really noisy 2011-08-25 15:23 look at "10: 2 <-> top vias" in http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#PCB_layers 2011-08-25 15:25 hmm, scratch marks 2011-08-25 15:25 the pictures are quite amazing indeed. just looked at them now. 2011-08-25 15:30 I tried http://en.qi-hardware.com/wiki/File:Sciphone_G2_PCB_10.png in gimp and played with "Swellwert anwenden" a bit 2011-08-25 15:31 I'd guess you for sure would want better pictures and still would see a benefit in shape recognition for the via holes 2011-08-25 15:31 dunno, maybe "unscharf maskieren" etc could also help 2011-08-25 15:32 emphasize small dust-alike structures, etc 2011-08-25 15:33 sharpen edges 2011-08-25 15:38 DocScrutinizer: edge-detect 2011-08-25 15:39 wpwrak: see my prev comment >> 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 2011-08-25 15:39 actually TP017 2011-08-25 15:39 larsc: yep 2011-08-25 15:42 hmm shuld've used this: http://en.qi-hardware.com/w/images/e/e7/Sciphone_G2_PCB_10.png 2011-08-25 15:44 for now I have no clue if the dim white somewhat larger round blobs are also vias, this time filled ones 2011-08-25 15:45 impossible to tell without the original in front of me. If they are, we'd probably need better photos 2011-08-25 16:33 I would like to setup a irc bot similar to qi-bot, anyone can tell me how to? 2011-08-25 16:33 watch git repository, when there is commit, send to channel 2011-08-25 16:59 wanox: there is a server setup page at en.qi-hardware.com/wiki 2011-08-25 17:11 kristianpaul: reading that, thanks 2011-08-25 19:50 http://spectrum.ieee.org/automaton/robotics/industrial-robots/fukushima-robot-operator-diaries 2011-08-25 20:38 watching the video, those robots look pathetic compared to what e.g. boston dynamics does 2011-08-25 21:23 ^ http://www.steve-m.de/projects/osmocom/bsp_sniffs/bsp_sniffing_setup.jpg 2011-08-25 21:23 ah, damn 2011-08-25 21:23 -ECHAN