wafer.space Community

Andrew Wingate

A batch of test harness boards have been created Again, these are for testing the bonds and the reason for so many is we have them time out after a number of tests to keep connectors from wearing out.

I've pinged HCTL to see if they have anything like an industrial connector with higher mating cycle rating that we could use - or any other solution they can suggest for testing

what about a massive array of pogo pins lol

1

probe cards say hi

1

BreakingTaps

probe cards say hi

Wow!!! Haha

woa that looks insane

kris

what about a massive array of pogo pins lol

Pogopins just swap one headache for another. Every PCB would need probing pads, which complicates the COB PCB layout, and design changes may require creating new fixtures. And also alignment gets tricky as we'd want to test CoBs while they're in the panel, but some get pulled out during wirebonding, so we might need two different fixtures for the same PCB. The current connector isn't as durable, but it works for every design we make, and we (can) have plenty of those adapter boards for now.

Lauri

Pogopins just swap one headache for another. Every PCB would need probing pads, which complicates the COB PCB layout, and design changes may require creating new fixtures. And also alignment gets tricky as we'd want to test CoBs while they're in the panel, but some get pulled out during wirebonding, so we might need two different fixtures for the same PCB. The current connector isn't as durable, but it works for every design we make, and we (can) have plenty of those adapter boards for now.

Tell us how you really feel

1

Andrew Wingate

Tell us how you really feel

pins and needles

Lauri

Pogopins just swap one headache for another. Every PCB would need probing pads, which complicates the COB PCB layout, and design changes may require creating new fixtures. And also alignment gets tricky as we'd want to test CoBs while they're in the panel, but some get pulled out during wirebonding, so we might need two different fixtures for the same PCB. The current connector isn't as durable, but it works for every design we make, and we (can) have plenty of those adapter boards for now.

ohh i didn't know they got tested whilst on the panel, i figured that the reason you wouldn't want to swap is because you're also testing the connector itself here tbh i was thinking of this (https://www.raspberrypi.com/products/cm5-programming-jig/) when i mentioned it lol

Buy a Raspberry Pi Compute Module 5 Programming Jig – Raspberry Pi

A single-head provisioning system designed to program Raspberry Pi Compute Module 5

Andrew Wingate

Wow!!! Haha

yeah probe cards are nuts. had a friend who helped manufacture them, crazy expensive too. Used to be cantilever probes assembled onto PCBs, but over time they've moved to MEMS pins and photochemically-etched bumps/tabs due to density requirements. think they are used to test wafers more often than finished/packaged chips though.

2

1

BreakingTaps

yeah probe cards are nuts. had a friend who helped manufacture them, crazy expensive too. Used to be cantilever probes assembled onto PCBs, but over time they've moved to MEMS pins and photochemically-etched bumps/tabs due to density requirements. think they are used to test wafers more often than finished/packaged chips though.

That's so cool!!

kris

ohh i didn't know they got tested whilst on the panel, i figured that the reason you wouldn't want to swap is because you're also testing the connector itself here tbh i was thinking of this (https://www.raspberrypi.com/products/cm5-programming-jig/) when i mentioned it lol

The connector based design has already helped us catch some bad soldering and bent pins. While pogopin jigs are cool, we have plenty of different designs and some CoBs use custom PCB and making jigs every custom board doesn't seem feasible. For now, connector based testing keeps it simple and flexible. Also, as @Tim 'mithro' Ansell mentioned, in the future we may offer CoB testers to the community so a connector based design will definitely help to keep the cost down.

Lauri

The connector based design has already helped us catch some bad soldering and bent pins. While pogopin jigs are cool, we have plenty of different designs and some CoBs use custom PCB and making jigs every custom board doesn't seem feasible. For now, connector based testing keeps it simple and flexible. Also, as @Tim 'mithro' Ansell mentioned, in the future we may offer CoB testers to the community so a connector based design will definitely help to keep the cost down.

thanks for the info, definitely got it thought through lol

BreakingTaps

yeah probe cards are nuts. had a friend who helped manufacture them, crazy expensive too. Used to be cantilever probes assembled onto PCBs, but over time they've moved to MEMS pins and photochemically-etched bumps/tabs due to density requirements. think they are used to test wafers more often than finished/packaged chips though.

I can smell the hole in the bank account from here.

2

1

Bond tester update: smarter, more die-agnostic testing Sorry for the long post. TLDR

Neighbouring-bond short check removed
New 10 µA and 1000 µA test currents for much clearer ESD diode detection
Pseudo-Kelvin (3-wire) measurement: force and sense paths separated through the MUX
Results simplified to OPEN / GOOD, the tester no longer judges shorts
Power pads now tested via capacitor charging curve monitoring Design principle: the tester knows less* about die

Two of these changes come from the same place. A generic tester shouldn't assume anything about the die under test:

Neighbour short check removed. We previously used spare MUX channels to check neighbouring bonds. But we've already seen this backfire on a real die: one of the designs we tested has DVSS on adjacent pads, so a perfectly good die looks like it has a short. A generic tester can't distinguish "shorted by design" from "shorted by a bond defect," so the check is gone.
Results are now just OPEN or GOOD. The tester confirms a bond exists by comparing the measurement against a wide acceptance threshold; it doesn't interpret the result in detail. For example, on analog designs an IO pad may be replaced with a power pad (e.g. GND) on an otherwise standard CoB board. Measuring that pad could look like a short to a supply rail, but it's by design, not a failure. So the tester now answers one question: is it an open, or not? Better ESD diode detection

Added 10 uA and 1000 uA current sources alongside the existing one. Now have ~10uA, ~100uA, ~1000uA. They're simple resistor-based sources and not precision-calibrated, but that's fine for v1: this revision is a platform for us to learn on and improve our detection, and with the extra measurement points a diode is now much easier to detect. Pseudo-Kelvin measurement We had a free COM output on the MUX, so might as well put it to use: the force (current injection) and sense (ADC reading) paths are now separated through the MUX, instead of the ADC probing the current-source node directly. This removes the force-path MUX on-resistance from the measurement. It's not true 4-wire Kelvin, effectively 3wire: the return path is still shared through the MUX, so the return-leg R_on still contributes, as do the connector and its contact resistance. Fully removing those would need a separate sense contact per pad, and pogo pins would be a suitable way to achieve this

. But let's try to leave that to next year. For our simple pass/fail testing, the current setup does the job. Power pads: capacitor charging curve Power pins used to cause trouble because of the decoupling capacitors on the PCB. Instead of fighting that, the tester now measures the charging curve itself: a good bond connects the pad to the die, whose ESD diode clamps the voltage before the capacitor charges fully. An open bond has no such clamp and lets it charge to full. What's next I expect there are still plenty of surprises waiting once we start bonding more CoBs. So far I've only managed to test a handful of different dies, and with new upcoming CoBs I expect the tool to fail in new ways, which is a good thing: every failure shows how to make the tester better and more universal. Once the run 1 CoBs are done, we should be in a good position for an updated PCB design. Longer term, I'd like to keep improving the tester, with upgrading the current sources and the ADC at the top of the list. If you have any questions or suggestions, please feel free to leave a reply

1

I'm wondering if it'd be useful to allow customers to provide a specific test profile for their chips. In the failed TT samples I got, several had shorts to GND and not detecting them seems not a good idea ...

1

tnt

I'm wondering if it'd be useful to allow customers to provide a specific test profile for their chips. In the failed TT samples I got, several had shorts to GND and not detecting them seems not a good idea ...

Can you elaborate a bit? Such as what tests would you like to see? Would this be some json blob or something?

5:29 p.m.

also, are you sure those were ever tested? TT got a bunch of the first stuff, so I assume you got the rawest of the raw

Maybe a simple step would just be for the customer to indicate whether any changes have been made to the power pad config compared to the default padframe - i.e. whether any IO pins have been replaced with power/ground, or whether any power/grounds have been switched around? It sounds like if the design uses the default setup then the more enhanced checks could be used safely.

Yeah like a json describing expected pad type for instance ( GND / PWR / IO ) or even IV curve bounds if you want to go that far.

Thank you @tnt, @Andrew Wingate , @RebelMike for your responses. I also, at some point thought it would be very useful to know the pads and their functions before testing. But I came to the conclusion that it would be very time consuming to collect this information and then create and validate the tests, and after a run, throw them away and start over for the next one. That's why I'm trying to lean toward having less die specific knowledge. It makes more sense to measure first, then analyze the results later (re: below). re: customer pad config Relying on user provided config is not ideal. Perhaps the platform can figure out the pad types automatically? I'm not familiar with the inner workings of the platform, but maybe someone more familiar with it can confirm?

even IV curve bounds if you want to go that far.

Custom IV curves raise a yield question: if a wrong curve is provided, the tester fails every CoB and the customer gets near 0% yield. A wrong customer provided spec shouldn't be able to make hard pass/fail decisions at test time. My suggestion is to add filtering capability to the results website. By applying filters to the CoB test results, it would be possible to find the CoBs that match the required curve. This kind of post-test analysis would also enable another useful feature: once all CoBs are tested and measured, the site could reveal outliers and flag potentially faulty ones.

Sure, I agree that the ability to save all results and analyze later is better, but this creates an inventory and data management burden since now every COB needs individual ID and tracking.

Also keep in mind the PCB for all the cob must be the standard. So that limits what kind of variability there would be from the outset. I was more curious what you were suggesting?

tnt

Sure, I agree that the ability to save all results and analyze later is better, but this creates an inventory and data management burden since now every COB needs individual ID and tracking.

Currently the panels have ID-s and CoBs in the panel have their position. Basically as long as panel is intact you can find the CoB's test results easily. For later runs I think we are exploring option to get unique id's printed on the CoB's themselves. Overrall, data is good and afaik we have space to store data.

Well limits yes and no. GND pins are shorted so those need to be gnd. But a user could add more if they wanted to. Power pins have decoupling, but are separate so user could use them for power but also for internal bias and those have different IV curves and they could also use them for very high or very low internal bias and use pads without some of the diodes for instance.

Basically we have 2 directions: 1. [current] stay generic, focus on basic 'is there a wire between PCB pad and die pad'. During manufacturing the testing will pass CoB's with wirebonds. Later, when analyzing the results, more die-specific conditions can be applied and the best CoBs selected. 2. go more die specific. Platform will provide pad types and expectected characteristics. The tester needs to know exactly what is being tested and how to test it. I think making a run or two with current generic testing will provide us valuable data and lessons on feasibility of die specific testing.

2:12 p.m.

Could always offer a more expensive CoB packaging option that would allow custom testing options??

Does anyone have a working 1-edge pad ring template for the long edge of the quarter slot?

Thanks for the update @Lauri. A few more minor questions: 1) I too would be very interested in getting my hands on your tester (custom configurations and false fails are no issue). Are there any plans of having the tester included with the CoB packaging option long term ? 2) Was the neighboring short check removed because it was wrong ? Or was it primarily done because it relied on none generic information ? Comments: A) I found your yield dataset very interesting and useful, I would be really appreciative it you could please keep uploading to it.

Essen

Thanks for the update @Lauri. A few more minor questions: 1) I too would be very interested in getting my hands on your tester (custom configurations and false fails are no issue). Are there any plans of having the tester included with the CoB packaging option long term ? 2) Was the neighboring short check removed because it was wrong ? Or was it primarily done because it relied on none generic information ? Comments: A) I found your yield dataset very interesting and useful, I would be really appreciative it you could please keep uploading to it.

1) Doubtful, but I do think we're planning on including one of the header motherboards so you can do real testing simply. 2) I will defer to Lauri A) We plan to continue sharing what we can as more info allows us all to improve. Thanks

1

Andrew Wingate

1) Doubtful, but I do think we're planning on including one of the header motherboards so you can do real testing simply. 2) I will defer to Lauri A) We plan to continue sharing what we can as more info allows us all to improve. Thanks

1) Noted. Are the plans of the tester available by any change so we can build our own? Because shorted pins could damage the boards, so this might call for a separate board for testing to be safe. (edited)

Archit3ch

Does anyone have a working 1-edge pad ring template for the long edge of the quarter slot?

https://github.com/MichaelBell/ws02-minimal-tinyQV uses a single edge on a quarter slot. Whether it works is yet to be seen

I think the pad config script that removes unused edges is all merged into the template now so it should just happen automatically if you remove all the pins from the three unwanted sides. However, as is this leaves the corners adjacent to the used edge in place, so might not be exactly what you want. (edited)

1

Ah, I guess you were thinking of a CoB board for that design. I don't have one of those yet but I intend to make one

Essen

1) Noted. Are the plans of the tester available by any change so we can build our own? Because shorted pins could damage the boards, so this might call for a separate board for testing to be safe. (edited)

Slight update here re (1) - we are in fact planning on making up a few of the 'simple' (without camera) test boards and can send some out to people willing to do some testing and give feedback

1

stuart started a thread. 2026-09-04 3:24 p.m.

Essen

Thanks for the update @Lauri. A few more minor questions: 1) I too would be very interested in getting my hands on your tester (custom configurations and false fails are no issue). Are there any plans of having the tester included with the CoB packaging option long term ? 2) Was the neighboring short check removed because it was wrong ? Or was it primarily done because it relied on none generic information ? Comments: A) I found your yield dataset very interesting and useful, I would be really appreciative it you could please keep uploading to it.

1) what @stuart said 2) It was due to 3 circumstances: 1. the dies we were testing in the beginning followed standard pad definitions. (all adjacent pad signals we're different0 2. poor wirebonding - initial bonding house often reworked the bonds manually and that lead to sometimes bonds being bent and very close to each other, if not touching. 3. having extra mux channels - first tester schematic used Analog's MUXs with 2 outputs for testing. Unfortunately due to export restrictions I couldn't source this part in China and had to switch to WCH CH446X MUX's. As the 2. was likely to happen in production, the next/previous test made some sense. Now as have better bonding houses, that feature is less relevant. Also, removing this, it conveniently freed up channels for different current tests. I think that was a good decision, as the bond is not judged based on 1 datapoint, but use 3 datapoints. 3) With all the hardware and software changes over the summer, the data format has changed couple of times. But now, I think it's stable enough that I'd be happy to upload more recent test results. I will probably make a simple document to go with the newer results. I can let you know once I've pushed new results?

1

Lauri

1) what @stuart said 2) It was due to 3 circumstances: 1. the dies we were testing in the beginning followed standard pad definitions. (all adjacent pad signals we're different0 2. poor wirebonding - initial bonding house often reworked the bonds manually and that lead to sometimes bonds being bent and very close to each other, if not touching. 3. having extra mux channels - first tester schematic used Analog's MUXs with 2 outputs for testing. Unfortunately due to export restrictions I couldn't source this part in China and had to switch to WCH CH446X MUX's. As the 2. was likely to happen in production, the next/previous test made some sense. Now as have better bonding houses, that feature is less relevant. Also, removing this, it conveniently freed up channels for different current tests. I think that was a good decision, as the bond is not judged based on 1 datapoint, but use 3 datapoints. 3) With all the hardware and software changes over the summer, the data format has changed couple of times. But now, I think it's stable enough that I'd be happy to upload more recent test results. I will probably make a simple document to go with the newer results. I can let you know once I've pushed new results?

Nice, thanks for the update. 1) I would be very interested in eventually testing out the simple test board if you need volunteers. 2) Thanks for the info, this makes perfect sense. 3) Please do, I am looking forward to it as I have a small data analysis tool on my end that I have been running. I will update these to accommodate the new test format. Also, don't stress too much about doc, I will figure it out.

1

Archit3ch

Does anyone have a working 1-edge pad ring template for the long edge of the quarter slot?

I believe @RebelMike was doing a test of something like that in Run #2?

BreakingTaps

yeah probe cards are nuts. had a friend who helped manufacture them, crazy expensive too. Used to be cantilever probes assembled onto PCBs, but over time they've moved to MEMS pins and photochemically-etched bumps/tabs due to density requirements. think they are used to test wafers more often than finished/packaged chips though.

@digshadow - I know you are a fan of probe cards

1

Lauri

Bond tester update: smarter, more die-agnostic testing Sorry for the long post. TLDR

Neighbouring-bond short check removed
New 10 µA and 1000 µA test currents for much clearer ESD diode detection
Pseudo-Kelvin (3-wire) measurement: force and sense paths separated through the MUX
Results simplified to OPEN / GOOD, the tester no longer judges shorts
Power pads now tested via capacitor charging curve monitoring Design principle: the tester knows less* about die

Two of these changes come from the same place. A generic tester shouldn't assume anything about the die under test:

Neighbour short check removed. We previously used spare MUX channels to check neighbouring bonds. But we've already seen this backfire on a real die: one of the designs we tested has DVSS on adjacent pads, so a perfectly good die looks like it has a short. A generic tester can't distinguish "shorted by design" from "shorted by a bond defect," so the check is gone.
Results are now just OPEN or GOOD. The tester confirms a bond exists by comparing the measurement against a wide acceptance threshold; it doesn't interpret the result in detail. For example, on analog designs an IO pad may be replaced with a power pad (e.g. GND) on an otherwise standard CoB board. Measuring that pad could look like a short to a supply rail, but it's by design, not a failure. So the tester now answers one question: is it an open, or not? Better ESD diode detection

Added 10 uA and 1000 uA current sources alongside the existing one. Now have ~10uA, ~100uA, ~1000uA. They're simple resistor-based sources and not precision-calibrated, but that's fine for v1: this revision is a platform for us to learn on and improve our detection, and with the extra measurement points a diode is now much easier to detect. Pseudo-Kelvin measurement We had a free COM output on the MUX, so might as well put it to use: the force (current injection) and sense (ADC reading) paths are now separated through the MUX, instead of the ADC probing the current-source node directly. This removes the force-path MUX on-resistance from the measurement. It's not true 4-wire Kelvin, effectively 3wire: the return path is still shared through the MUX, so the return-leg R_on still contributes, as do the connector and its contact resistance. Fully removing those would need a separate sense contact per pad, and pogo pins would be a suitable way to achieve this

. But let's try to leave that to next year. For our simple pass/fail testing, the current setup does the job. Power pads: capacitor charging curve Power pins used to cause trouble because of the decoupling capacitors on the PCB. Instead of fighting that, the tester now measures the charging curve itself: a good bond connects the pad to the die, whose ESD diode clamps the voltage before the capacitor charges fully. An open bond has no such clamp and lets it charge to full. What's next I expect there are still plenty of surprises waiting once we start bonding more CoBs. So far I've only managed to test a handful of different dies, and with new upcoming CoBs I expect the tool to fail in new ways, which is a good thing: every failure shows how to make the tester better and more universal. Once the run 1 CoBs are done, we should be in a good position for an updated PCB design. Longer term, I'd like to keep improving the tester, with upgrading the current sources and the ADC at the top of the list. If you have any questions or suggestions, please feel free to leave a reply

Can you share some of the reports that the tester has been producing? I know there was https://github.com/wafer-space/ws-run1-cob/ and https://wafer.space/ws-run1-cob/ but that doesn't seem to have been updated recently? There also seems to be https://data.wafer.space/ten64-welland/lauri/public_html/run1-wb/ Can you also share the bond tester PCB/source code/etc?

GitHub - wafer-space/ws-run1-cob: Results from the wafer.space Run ...

Results from the wafer.space Run #1 chip on board packaging. - wafer-space/ws-run1-cob

1

Tim 'mithro' Ansell

I believe @RebelMike was doing a test of something like that in Run #2?

Yes, Leo suggested I did a version of Tiny QV using pads on a single edge to test the tweaks he made to the pad ring script to remove unused edges

Essen

1) Noted. Are the plans of the tester available by any change so we can build our own? Because shorted pins could damage the boards, so this might call for a separate board for testing to be safe. (edited)

I'm hoping we can have the tester boards on sale for people to purchase. @stuart can keep you in the loop on that.

1

Lauri

Basically we have 2 directions: 1. [current] stay generic, focus on basic 'is there a wire between PCB pad and die pad'. During manufacturing the testing will pass CoB's with wirebonds. Later, when analyzing the results, more die-specific conditions can be applied and the best CoBs selected. 2. go more die specific. Platform will provide pad types and expectected characteristics. The tester needs to know exactly what is being tested and how to test it. I think making a run or two with current generic testing will provide us valuable data and lessons on feasibility of die specific testing.

Sounds like we might need to increase / improve the CoB verification on the platform which makes sure the bond testing will work? @Leo Moser (mole99) - Thoughts? I'm okay with people doing custom / weird things needing to figure out their own bonding / testing plans -- they can always contract @stuart & @Lauri themselves for custom work.

@Essen, I've uploaded more data to https://github.com/wafer-space/ws-run1-cob/ (pages can be viewed at https://wafer.space/ws-run1-cob/).

Tim 'mithro' Ansell

Can you share some of the reports that the tester has been producing? I know there was https://github.com/wafer-space/ws-run1-cob/ and https://wafer.space/ws-run1-cob/ but that doesn't seem to have been updated recently? There also seems to be https://data.wafer.space/ten64-welland/lauri/public_html/run1-wb/ Can you also share the bond tester PCB/source code/etc?

Can you also share the bond tester PCB/source code/etc?

Tester PCB files https://github.com/szfate/BondTest72, firmware https://github.com/szfate/BondTest72-Firmware. PCB files haven't been updated since v1, but can do that in coming weeks as we're doing v1.1.

3:53 p.m.

@tnt re: latest bonding run, I grouped the test results by die pad to see how much deviation we can see and if it's possible to find outliers. This contains 100 CoB's test results: https://wafer.space/ws-run1-cob/BRWN/2026-09-02/BRWN-636-PADS.html

Lauri

@Essen, I've uploaded more data to https://github.com/wafer-space/ws-run1-cob/ (pages can be viewed at https://wafer.space/ws-run1-cob/).

Thanks so much ❤️

Leo Moser (mole99) started a thread. 2026-09-05 7:46 p.m.

Bonding diagrams for 0p5x0p5 and 0p5x1 dies.

2026-09-08_0p5x0p5_bonding_diagram_TQVA.pdf

1.06 MB

2026-09-08_0p5x1_bonding_diagram.pdf

1.29 MB

1

Lauri

Bonding diagrams for 0p5x0p5 and 0p5x1 dies.

These look correct to me

1

Thank you @Lauri

1

Lauri

Currently the panels have ID-s and CoBs in the panel have their position. Basically as long as panel is intact you can find the CoB's test results easily. For later runs I think we are exploring option to get unique id's printed on the CoB's themselves. Overrall, data is good and afaik we have space to store data.

This was serialized per-board from JLC with me getting full assembled panels shipped. I specified a prefix and counter start value and they incremented the counter such that each board on the panel got it's own serial. You can do much smaller if you don't want as much entropy in your prefix.

tnt

Sure, I agree that the ability to save all results and analyze later is better, but this creates an inventory and data management burden since now every COB needs individual ID and tracking.

If they're in some simple vacuum formed tray or the like it should be easy to scan them for possible post-test sorting? But the major benefit would be unlocked without having to offer sorting based on test results: you could let whoever plugs them into the carrier boards hold them to a scanner that's loaded with the prefix and list of PASS serials, for example stock https://github.com/markusfisch/BinaryEye on Android supports 1024 long regexes for matching on which can hold many serials with even very simple minimization algorithms to reduce its size. Also I guess I should just file a feature request to increase that cutoff anyways not like there's a truly good reason for it to be so low (I've managed to run into it using it for PASS picking of HDDs after batch processing with some shell scripts spitting out serials of the different sorting classifications/grades)...

GitHub - markusfisch/BinaryEye: Yet another barcode scanner for And...

Yet another barcode scanner for Android. Contribute to markusfisch/BinaryEye development by creating an account on GitHub.

namibj

This was serialized per-board from JLC with me getting full assembled panels shipped. I specified a prefix and counter start value and they incremented the counter such that each board on the panel got it's own serial. You can do much smaller if you don't want as much entropy in your prefix.

We're adding JLC's serials to top silk but so far the results have not been reliable. Our designated area for serial number is kind of small and the printed surface is not flat (re traces and vias underneath), making these difficult to read. I've attached couple of pictures I could quickly find to show what results we've seen recently:

sometimes they ignore their own requirement (re: rectangle area)
our PCB design had untented vias making the serial unreadable
iirc we even received 2 panels with same serial numbers. I think we'll continue to add these serials to the PCBs and if results improve or become more consistent then it would be great to actually use these serials one day

Lauri

We're adding JLC's serials to top silk but so far the results have not been reliable. Our designated area for serial number is kind of small and the printed surface is not flat (re traces and vias underneath), making these difficult to read. I've attached couple of pictures I could quickly find to show what results we've seen recently:

sometimes they ignore their own requirement (re: rectangle area)
our PCB design had untented vias making the serial unreadable
iirc we even received 2 panels with same serial numbers. I think we'll continue to add these serials to the PCBs and if results improve or become more consistent then it would be great to actually use these serials one day

don't use human readable ones, given the space nature I'd suggest a rectangular datamatrix

1:41 a.m.

do you have an image of the backside of the COB on hand by chance?

1:42 a.m.

....they don't offer rectangular datamatrix codes

so yeah 5x5mm it is

1:43 a.m.

you shouldn't get repeat numbers unless you order such; they should be at most wasting IDs by panels that get scrapped before they're delivered

namibj

do you have an image of the backside of the COB on hand by chance?

Not much space here either

oh yeah there's space for a 5x5mm I'd feel?

1:43 a.m.

or not enough again?

1:44 a.m.

ofc needs to be tented then

1:45 a.m.

to depend on it I'd always do the approve production files thing and get them to confirm the code target area was registered as such.

1:50 a.m.

yeah best idea then I guess would be an extra large font size alphanum rectangle with a minimal serial number on one side of the plug (backside) and a panel/board version encoding identifier on the other side of that connector; think like 1 or 2 rows of text in as big of a font as fits between the capacitors and the mezzazine solder pads with just enough gap to each of those two to be not too sensitive to the angle it's photographed from regarding those obscuring the text from the camera's view.

1:51 a.m.

didn't quite realize how limited the space is on these quite minimal size boards.....

1:52 a.m.

also giant benefit of back side is that it's not gonna suffer lensing/refraction distortion from the cover goop spreading over the ID text

1:54 a.m.

if anyone wants a front side ID it could be a sticker on the front side in a corner

1:54 a.m.

(the adhesive of which could be selected in thickness to take care of the underlying height differences that come from the traces/vias)

1:59 a.m.

so yeah best of luck it does seem substantially harder here than I had hoped. You may consider putting a perhaps DIY-rendered datamatrix code like their ID would be in a place where it could fit to trial scannability of it

2:00 a.m.

(on one strip on the back side)

namibj

so yeah best of luck it does seem substantially harder here than I had hoped. You may consider putting a perhaps DIY-rendered datamatrix code like their ID would be in a place where it could fit to trial scannability of it

Anything DIY won't index. All the ones JLC do, index even within the panel (edited)

one of the corners top side might sacrifice it's ground-plane-ness to use it's copper resolution and superior printing-reliability to manufacture a version ID code, especially if ENIG with solder mask exclusion zone.

Having serials or barcodes on bottom side will make it difficult to scan. Factory testing tool has camera that's looking at the globtop. It would be difficult to add a camera on bottom side

1

Andrew Wingate

Anything DIY won't index. All the ones JLC do, index even within the panel (edited)

I'm aware but you can still trial printing reliability this way to a substantial extend. OFC finer pixel-interacts-with-background-structure effects won't be caught, but you'd retain the use of printing large font alphanumeric serial during it

Lauri

Having serials or barcodes on bottom side will make it difficult to scan. Factory testing tool has camera that's looking at the globtop. It would be difficult to add a camera on bottom side

mirror

need to consider the mating height

and I wouldn't suggest if I'd see a place where it could reasonably fit with large enough font to not be itself a substantial yield impact

Lauri

need to consider the mating height

can't the factory tester use a tall one and/or have the interposer board that's a consumable be laid out to let the COB overhang enugh that the mirror could extend below the interposer board?

2:08 a.m.

(I'm not saying trivial but unless you can get them to do a big fat 2-row 10-column hamming coded binary ID on the front with their serializing uniquness I don't see how you're gonna get much beyond 2 nines of yield from the front side serial ID print....)

2:09 a.m.

the blue board approach might kinda lacking enough samples to really tell

2:10 a.m.

might require plated over vias to be reliably readable print; I'm not sure if that's COB compatible pricing at the COB run quantities to be offered at Run2.

@namibj / @Lauri / @stuart - I was wondering if NextPCB's rev0 service where everything is supposedly automated / computer controlled rather than human might make the IDs more reliable or something? I don't think we know what the cost difference between them and JLC PCB would be at the moment?

oh AFAIK the questionable step at JLC is at the up front engineering human treatment/review

2:58 a.m.

I would not rule them out unless they tell you they can't promise that/work out a way that allows it to be promised.

2:59 a.m.

there should be pretty much no reason they can't promise to re-make a board they already did just with fresh IDs for e.g. the next customer code on your side and appropriate non-overlapping serials unique on each COB.

3:00 a.m.

the rest of JLC is very much automated

Tim 'mithro' Ansell

@namibj / @Lauri / @stuart - I was wondering if NextPCB's rev0 service where everything is supposedly automated / computer controlled rather than human might make the IDs more reliable or something? I don't think we know what the cost difference between them and JLC PCB would be at the moment?

I'd suggest to do a single board (not a full panel) through their process to see how it prints, assuming they have decent pricing for that workload?

namibj

I'd suggest to do a single board (not a full panel) through their process to see how it prints, assuming they have decent pricing for that workload?

Generally to see how this stuff works you need to do X number of panels - otherwise you don't see the issues we are seeing from JLC PCB...

oh well sure for overall organizational reliability sure; but I mean whether they even manage to get the serials printed in good enough print quality to make that even be useful. Good organization doesn't help if the print quality is unreadable

(edited)

Lauri

@tnt re: latest bonding run, I grouped the test results by die pad to see how much deviation we can see and if it's possible to find outliers. This contains 100 CoB's test results: https://wafer.space/ws-run1-cob/BRWN/2026-09-02/BRWN-636-PADS.html

talked with @Tim 'mithro' Ansell about test results earlier today and that reminded me of an interesting finding in this 100 CoB test results worth sharing. The diode IV curve outlier detection flagged 20 CoBs. All of them are from panels 000 and 001. Panels 000 and 001 have black globtop, while panels 002-009 have soft clear globtop. Picture attached Kind of interesting how the globtop material (or perhaps light, as Tim suggested) has an effect on the IV curve measurements.

1

10:04 a.m.

Did you try covering a clear top one ?

tnt

Did you try covering a clear top one ?

No, I haven't retested these CoB's

tnt

Did you try covering a clear top one ?

My idea also, I believe I heard somewhere that every diode is a photodiode...

2

Just tried on one of the hackaday badge we made. When you measure with a multimeter at a fixed 1mA current you don't see much difference.

12:55 p.m.

But if instead you apply a constant voltage at the beginning of the conduction ( say ~ 0.3~0.4V ), then the current changes drastically when covering it or not.

12:56 p.m.

Interestingly the current drops if you shine light on it.

@tnt is this badge for only for hackaday europe or will it be used for the one coming up on in pasadena as well?

ah I see it was not for the main badge but a goodie bag thing

@m_w Yeah it was just a TT goodie in the bag

I think it was just HaD europe and IIUC correcly we'll give extra left over to people at ORConf.

ohhh orconf is tomorrow

The boards are the reason I ended up at HaD europe

Generated bonding diagrams for run1 and run2 dies: https://github.com/szfate/ws-bonding-diagrams (pdfs included).

GitHub - szfate/ws-bonding-diagrams: wafer.space bonding diagrams

wafer.space bonding diagrams. Contribute to szfate/ws-bonding-diagrams development by creating an account on GitHub.

Chips4Makers aka Staf Verhaegen

My idea also, I believe I heard somewhere that every diode is a photodiode...

Yes, I've heard that said before too

tnt

But if instead you apply a constant voltage at the beginning of the conduction ( say ~ 0.3~0.4V ), then the current changes drastically when covering it or not.

@BreakingTaps @Ethan Mahintorabi - I think this might prove that is could be possible to do some type of photo diode on GF180MCU?