<d1b2>
<esden> Based on the conversations we had during the stream. This is what I ended up doing to document the pinout on the top of the board. Thanks for the suggestion @tnt 😄 If you have better idea of having a "cheat sheet" for the pins on the top silk let me know. 😄
<d1b2>
<tnt> @esden Wrong side of the connector but okay 🙂 (It actually happenned to me a couple of time to connect the data wire on the 'GND' side and the grounds on the 'Data' side. ... I know the GND is always on the outside, but sometimes it slipped my mind ...)
<d1b2>
<esden> @tnt I would have to move a bunch of stuff around to make space on the other side of the connector... I did not feel up for it 😛
<d1b2>
<esden> I might still bite... 😉
<tnt>
esden: really knowing which side pin 1 is is good enough :p
<d1b2>
<esden> hands @tnt a thick silver and white paint marker... you can even choose a color :P
<d1b2>
<esden> But yeah I hear you loud and clear... I will have to think about it. 😄
<tnt>
esden: ATM I just put up the pinout on the whiteboard :p
<_whitenotifier-f>
[libfx2] artizirk commented on pull request #4: Add standalone url field to fx2 setup.py - https://git.io/Jf1UB
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
ali_as has joined #glasgow
futarisIRCcloud has joined #glasgow
simukis_ has quit [Ping timeout: 260 seconds]
simukis_ has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
<d1b2>
<JKT> Will these shrouded pinheaders be soldered by the users? Then the pinout cheatsheet on the top layer could go where the plastic part is and these users can use unshrouded pinheaders..
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #glasgow
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 246 seconds]
Stormwind_mobile has joined #glasgow
Foxyloxy_ has quit [Quit: Leaving]
Foxyloxy has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
FFY00 has quit [Remote host closed the connection]
<electronic_eel>
@JKT the current plan is to supply the boards with the THT parts to be soldered by the end user, so you could use unshrouded headers
<electronic_eel>
but I thinkt the shrouds make sense to allow keyed flat cables or addons that prevent miswiring
<electronic_eel>
@esden instead of painfully making space for the pin numbering on the silkscreen - how about putting it on the connectors instead?
<electronic_eel>
I printed these with a common brother label printer on 6mm label tape
<electronic_eel>
you could just print them out and put them in the bag with the unsoldered connectors, for the user to stick them on
<esden>
electronic_eel: that is indeed a solution that I was considering... I am trying to find out vendors that provide connector pad printing to do this
<esden>
I know they exist...
<electronic_eel>
ah, so use tampon printing or a similar method on the actual connectors, yes that would be nice
<esden>
Regarding the connectors, I think we will end up using a CM for the main assembly run of the glasgow, so the connectors will be all soldered down I think.
<electronic_eel>
it is a pretty manual labor intensive process, something that can probably found around Shenzen...
<electronic_eel>
a CM?
<esden>
a contract manufacturer
<electronic_eel>
I suggested something like that some time ago, and you said that you prefer to do it with your own pnp
<electronic_eel>
what has changed?
<esden>
realizing how time consuming and complex the assembly of glasgow is... and getting good contacts through friends that can do a good job fast
<esden>
also my pnp can barely hold that many reels as the bom lines of the glasgow
<esden>
glasgow has too many bom lines and too many placements to make building them on my machine efficient...
<electronic_eel>
yes, quite a complex board. the icebreakers are much simpler and making them took you quite a while
<esden>
exactly... anyways this is why we definitely need the pogopin tester to work as well as we can so we can let the assembly house use it
<esden>
it has to be idiot proof
<electronic_eel>
oh, so we need ten pogo pin test jigs, to have 10 lines of workers testing glasgows in parallel, working towards world domination ;)
<esden>
lol :D
<esden>
Today I have to do some stuff for the contract job. And this weekend I need to work on converting and documenting the process for the reflow oven. (it is a long outstanding project that I commited to) I hope monday I can send the pogopin tester information out to get a quote for it.
<esden>
So you have a bit of time to make your changes on the revC2.
<electronic_eel>
yes, I have planned to do that over the weekend
<esden>
sounds great! :)
<electronic_eel>
have you thought about what to do about testing the lvds?
<esden>
I think if we have at least a selftest that makes sure there are no shorts it would be a decent start.
<electronic_eel>
ok, so just internal testing
<electronic_eel>
with current monitoring by the test jig
<esden>
I do think we can interface to it with a connector from the top in the test jig.
<esden>
that is why I added the locating holes and pins
<esden>
So we could do a full test if we had the hardware for that.
<electronic_eel>
but you have to be very careful when pressing down the test jig, any misaligned pins will get bent otherwise
<esden>
that is not a problem if you align things right
<esden>
people do this in production all the time so it has to be a solved problem :D
<esden>
than is why you have the pogopin tester using rails to move the head
<esden>
there is no movement
<electronic_eel>
yeah, you can do automated tests on hdi smartphone boards, so it can certainly be done
<electronic_eel>
but that is the difference between some simple test jig and a precision one
<esden>
I will send the specs to the manufacturer on monday, so we will know more from them.
<electronic_eel>
yeah, ok
<esden>
considering the same jig system was used for fomu testing it has to be accurate enough
<esden>
that thing and it's testpads are really tiny
<electronic_eel>
before we design too detailed test hardware, we also have to think about the software side - and this is currently mostly missing
<electronic_eel>
or not working yet
<electronic_eel>
but we'll get there
<esden>
one more thought, maybe there is a way to just wire the test connector in a way so that the selftest can be more indicative of the connector state...
<esden>
(still talking about the lvds connector)
<electronic_eel>
a small pcb with a few muxes and 3 wires to the test jig pcb would be enough
<esden>
ok that sounds good :D
<electronic_eel>
then you can connect or disconnect some of the lvds pins between each other on command
<esden>
and we are putting a raspberry pi into the testjig to do the programming and testing?
<electronic_eel>
the test jig pcb has enough open aux pins and stuff for exactly something like this
<esden>
yeah I saw that, that is good :D
<electronic_eel>
yeah, a raspi or some other small linux board
<esden>
we should consider using exclave to drive the process
<electronic_eel>
raspis have the dicky sd cards that can get broken, so maybe better a beaglebone black
<esden>
it has to be an rpi as they can replace them easily... anything else is hard to get in china
<esden>
another "lesson learned the hard way"
<electronic_eel>
ok. but then you don't need to update them, just stick new microsds in them
<esden>
anyways, recommend reading the bunnie article once again, I have to do the same... there is a lot of info in there
<electronic_eel>
we don't need much code from this exclave thing, I think most of it will go into the glasgow factory applet
<electronic_eel>
maybe just the serial number thing with barcode reader integration
<esden>
yeah sure... the advantage of exclave is that it has very good mechanisms to select tests and make test dependencies
<esden>
it is built upon experience of running in line production testing
<esden>
so we can trigger glasgow scripts with it
<esden>
but we should have them broken down and triggered by exclave
<esden>
this will give us a possibility to adjust the test if/when we run into issues
<electronic_eel>
yeah, the options of the applet will always be individually controllable from commandline, so no problem to control it from exclave
<esden>
exclave is at the end just a thing that triggers scripts itself, so it is all compatible with each other
<electronic_eel>
do you have a simple 1d barcode reader to play with?
<esden>
(I am bit surprised that the bunnie test jigs have no text output to provide information about the error code...)
<esden>
I need to ask xobs what that is about :D
<electronic_eel>
maybe it goes like this: basic worker does the test, if there is an error put it in a special bin
<d1b2>
<esden> hey @xobs ... can you shine a light on how you decide on the UI features of a test jig?
<electronic_eel>
then there is a more experienced worker who has a monitor connected to his test jig, he re-does the test
<d1b2>
<esden> aka, just a go nogo light vs having character display to say what is wrong with the board?
<miek>
there is only pass or fail, the test jig step isn't for debugging :p
<esden>
I do have a linear barcode reader somewhere here. Need to find it.
<electronic_eel>
is it usb, serial or ps/2?
<esden>
miek: so they don't rework the boards at all just put the failed ones to the side?
<miek>
esden: pretty much, yeah. if there are enough failing that it's worth debugging them, there's probably something wrong
<esden>
interesting...
<electronic_eel>
I think they rework them. but the user that does the test is not the one that finds out how to do it
<esden>
ahh well we will learn all that I am sure... :D
<electronic_eel>
the more skilled worker that does the rework does it in a batch when enough failed boards are collected
<electronic_eel>
so just prepare to have a monitor connected to the raspi, output progress text in a console window
<esden>
yeah it is probably a good idea to have that option
<esden>
electronic_eel: reviewing the article from bunnie, there is a website that it generates with the test results...
<electronic_eel>
how does the user or supervisor access it?
<esden>
web browser? ;)
<electronic_eel>
you don't want complex network setup on the production line
<esden>
In the case of the HDMI interface, a browser configured to run in kiosk mode is pointed to the correct localhost webpage, and a jquery-based HTML document handles the dynamic generation of the UI based upon detailed messages from Exclave. Below is a screenshot of what the UI looks like in action.
<electronic_eel>
I think plugging in a monitor with a hdmi cable is simpler
<electronic_eel>
why not just show the progress of the scripts in a terminal?
<esden>
because that is not very flexible, and not remotely accessible. The people worknig there don't know what ssh is. But do know what a browser is.
<electronic_eel>
when I planned production tests at work, we had the complete output just on a monitor, plugged into a mini-pc we supplied to the contract manufacturer
<electronic_eel>
this worked really well
<electronic_eel>
we stored all the calibration and result data onto a flash drive and got it back with the products
<esden>
I think this exclave solution is more flexible and easier to understand to an average production line worker.
<esden>
even the boss
<esden>
better than terminal for sure
<electronic_eel>
hmm, depends on how you do your terminal output
<electronic_eel>
testing A...
<electronic_eel>
OK
<electronic_eel>
testing B...
<electronic_eel>
OK
<esden>
it seriously does not matter regarding monitor output
<esden>
you either have a text terminal or a kiosk browser window ...
<esden>
it is really bike shedding in my opinion
<esden>
I like the use of exclave as we don't have to reinvent the wheel
FFY00 has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
karlyeurl has quit [Quit: No Ping reply in 180 seconds.]