ender| has quit [Remote host closed the connection]
ender| has joined #glasgow
m4ssi has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #glasgow
<marcan>
esden: glasgow arrived! :D
<marcan>
(save me one of the white-on-blue ones too please though :3)
<tnt>
marcan: nice, lucky you :)
<whitequark>
!
<marcan>
LED brightness actually looks reasonable
<marcan>
I noticed the LVDS connector has some sort of clip, is this the part we specced? not that there's anything wrong with it, looks like it could be useful and should still interop with a plain pin header.
<whitequark>
marcan: ok, so the message is misleading
<whitequark>
what's happening is that the B-side pulls are broken somehow
<marcan>
of course they're broken, they're unpowered
<whitequark>
huh?
<marcan>
it runs fine if I first power both ports
<marcan>
you can't set the pulls without vio
<whitequark>
yes, I know
<whitequark>
the default is --port AB
<whitequark>
and that doesn't work
<gruetzkopf>
(just hope that i don't get the annoying timiing outlier again ;) )
<marcan>
"glasgow run benchmark" doesn't power *either* a or b
<whitequark>
marcan: i'm talking about uart now
<marcan>
so of course the pulls aren't going to work
<whitequark>
i already committed a fix for benchmark
<whitequark>
yeah, so uart --port A works, uart --port B doesn't work
<marcan>
btw, the crowbar response is quite beautiful
<marcan>
ramp down from 5.24V to 4.36V over 25µs, then ramp back up to 4.92V over 120µs or so
<whitequark>
excellent
<marcan>
(this is internal 5V)
<whitequark>
at 4.36V it resets, right?
<marcan>
if I power the glasgow off of an unpowered USB hub with way too much shit connected to it over a long cable (lol), it browns out and resets within half a second or so
<marcan>
no, it doesn't reset
<marcan>
the ramp down is the onboard capacitance draining through the vio current limit resistor + regulator impedance; the ramp back up is current picking up on the upstream USB (due to cable inductance/etc)
<whitequark>
ahhhh
<whitequark>
wow, 120 µs
<whitequark>
that's quite a lot of inductance
<marcan>
yeah I dunno, maybe the usb limit switch has a slow response too or something
<whitequark>
marcan: can you run `glasgow run uart --port B` on yours?
<marcan>
keep in mind it has to charge the onboard cap back up
<marcan>
so it's like 25µs of inductance lagging
<whitequark>
ah
<marcan>
and then 120µs to charge back up at 800mA or whatever
<marcan>
probably a tRC of 80µs or something? eyeballing it
<marcan>
AttributeError: module 'asyncio' has no attribute 'create_task'
<marcan>
lolol
<marcan>
do I need py3.7 or something?
<whitequark>
uh I think so
<marcan>
ehhhh
<whitequark>
we do test it on 3.6 on travis, but evidently not everything
<whitequark>
hang on
<whitequark>
that's like 1 line patch
<whitequark>
marcan: fixed
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fj6Ui
<whitequark>
marcan: electronic_eel: here's an idea for the jig
<whitequark>
we can use the unpopulated PTH headers for the bed of nails
<whitequark>
so it works whether the big headers are soldered or not
<whitequark>
since most likely, most glasgows sold will not have the big headers soldered for cost reasons
<whitequark>
anyway, wtf is happening with B-side...
<whitequark>
hm, a thermal camera would sure be nice
<whitequark>
I don't see it :/
<whitequark>
esden: are the PCBs 100% etested?
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
electronic_eel has quit [Ping timeout: 252 seconds]
electronic_eel has joined #glasgow
<tnt>
whitequark: didn't find the short ?
<whitequark>
tnt: nope
englishm has quit [Excess Flood]
englishm has joined #glasgow
pie__ has quit [Ping timeout: 246 seconds]
<marcan>
whitequark: run 5V 30A into vio, see where the smoke comes out? might even fix the short :-)
<marcan>
(I may or may not have once fixed a Vcc short while reworking some RAM chips with the "fuck it, I can't see it, it must be small, turn the power on and it'll melt off" method)
<miek>
i've found a few shorts by spraying IPA over the board and seeing where it evaporates quickly
<marcan>
hah
<whitequark>
miek: the problem is that the dissipation is all in the LDO
* whitequark
. o O ( heat dissipation is stored in the LDO )
<whitequark>
and i already know it is specifically LDO because i burned myself at least thrice on it
<whitequark>
fucking painful too
<tnt>
But how did the self-test succeed ? I mean, ok, it doesn't test the pull-ups, but still without VIO, nothing should have worked right ?
<whitequark>
tnt: it doesn't test the level shifters without pins-ext
<whitequark>
and actually, maybe it should
<whitequark>
mh
<whitequark>
tnt: basically it checked that there are no shorts between FPGA pins and whatever they are connected to
<whitequark>
which is exactly what I designed it to check for
<tnt>
mm, ok I see now, there is another test but it needs a dongle/cable plugged in.
<tnt>
so I guess it wasn't run.
<whitequark>
yes
<whitequark>
it might actually be possible to do the same kind of test as pins-int but with level shifters engaged
<whitequark>
but it wouldn't find this issue
<whitequark>
that's because without Vio the shifters are in hi-z
<tnt>
And the ldo itself isn't the issue ? (I know, not very likely, but just last week I was chasing a short on a rail and it turnd out the LDO itself powering that rail was damaged and shorted internally ...)
<whitequark>
tnt: it might be
<whitequark>
but i'm hesitant to do any rework on this board because the shrouded connectors won't survive it...
<whitequark>
well, i could try being very careful, but right now i'm too tired to do so
<tnt>
yeah, I melted the connector a bit on my revB while bypassing the fxma ...
<tnt>
whitequark: instead of old routers you should ask your roomate to bring you an x-ray machine for joint inspection :)
<whitequark>
tnt: i can x-ray it, actually
<tnt>
oh. Well that'd be useful. My best guess for a short would be U33 ...
owo has joined #glasgow
<whitequark>
tnt: yeah, my guess is exactly the same
<whitequark>
that goddamn package
<tnt>
I think I'd just cover up 19/20/21 with soldermask and not solder those pads at all ...
<electronic_eel>
whitequark: about the test jig - you suggest to have the bed of nails connect J6 and J8, the ones that allow the user to bridge pullups, but are DNP by default?
<whitequark>
yeah
<electronic_eel>
they are 1.27mm pitch, not 2.54
<electronic_eel>
that makes it harder to connect. you can't use the cheap pogo pins for it
<electronic_eel>
and maybe also need more precise board holders and so on
m4ssi has quit [Remote host closed the connection]
<electronic_eel>
don't know if that is worth it when almost all boards won't have the port headers populated
<whitequark>
point
<electronic_eel>
on the ones that have the port headers populated, esden could do the testing before
<electronic_eel>
as the port headers will probably soldered by hand
<electronic_eel>
I mean before soldering them in
<whitequark>
yeah
<electronic_eel>
do you want to talk/think more about test jigs right now? or do you prefer to debug your glasgow or do something else?
<whitequark>
electronic_eel: I've exhausted the things I can easily do with the glasgow
<whitequark>
rework will have to be done later
<whitequark>
and maybe after xraying it?
<whitequark>
anyway, yes, I do need to design a jig, and I've never done that, so I would very much like to talk about it
<electronic_eel>
do you have experience with analyzing x-rayed circuits?
<whitequark>
I do not
<whitequark>
I just did this once for shits and giggles a year ago or two
<electronic_eel>
when I looked at some the manufacturer for my dayjob did, I couldn't immediately spot the problems
<electronic_eel>
the operator had to show me, then I could see them
<electronic_eel>
but I think it needs some practice
<whitequark>
I think the guy who x-rays these things for me doesn't have experience analyzing electronics either
<whitequark>
I actually have no idea what he is even doing as his job, it is a very unofficial arrangement. cheap tho.
<electronic_eel>
so xray wouldn't be my first step in debugging this
<whitequark>
I've spent half a hour staring at it (no bridges I can see) and I've aggressively cleaned it with an antistatic brush (no change)
<tnt>
Well if you had a thermal imager, you should see the chip heat up too.
<whitequark>
I can feel it just fine with my finger
<tnt>
But it will be 'faint' (i.e. not something you can feel by hand)
<whitequark>
hm
<tnt>
With the thermal cam you can see chips getting 0.5C hotter than the surrounding ...
<electronic_eel>
thermal cam often works well for me when debugging too
<whitequark>
no thermal cam tho
<electronic_eel>
I also have a new toy, the iprober from tti. it is a current probe you can hold over your circuit and measures the current underneath. works nice for finding shorts too
<whitequark>
whew, 700 euro
owo_uwu_owo has joined #glasgow
<electronic_eel>
I helped some guy with designing a circuit and he wanted to do something good for me so I didn't complain...
<tnt>
Ah yeah ... flux gate magnetometers based probe :)
<electronic_eel>
whitequark: the problem is the vreg for port b getting hot, correct?
<electronic_eel>
just when enabled or always?
owo has quit [Ping timeout: 246 seconds]
<whitequark>
electronic_eel: only when enabled
oeuf has quit [Ping timeout: 272 seconds]
<whitequark>
no matter what the feedback is set to, it still gets very hot at 1.65V
<electronic_eel>
did you try to remove the series resistor on the output?
<whitequark>
and Viob sits near zero
<whitequark>
I did not try any rework
<electronic_eel>
R49
<electronic_eel>
removing it would be my first step
<electronic_eel>
then you can see if it is the vreg itself or something connected to its output
<whitequark>
mm, good point
<electronic_eel>
you should be able to remove it just with a soldering iron
<whitequark>
I know
<sorear>
Viob is much less than a diode drop above ground?
<whitequark>
sorear: less than 0.7V, yes
<whitequark>
unless I screwed something up, but I'm pretty sure it is less than 0.1V
<whitequark>
electronic_eel: so I don't normally have issues with rework but today is a day where chronic pain got bad enough it affects my fine motor skills
<whitequark>
I could probably still do it but it'd be very hard
<electronic_eel>
ok. if it were me, I probably couln't get any sleep because my brain would be in full debugging mode thinking through all possibilities, automated test ideas and so on...
<whitequark>
oh, I already went through and exhausted the options
<electronic_eel>
but we can then talk test jigs now
<electronic_eel>
the idea was to have one glasgow acting as test runner to do tests on the dut-glasgow in the jig
<electronic_eel>
but I'm not sure what it's job really is, as most of the tests run on the dut-glasgow itself
<whitequark>
hmmmm
<electronic_eel>
putting as many tests as possible into selftests would also benefit users building their own glasgow
<whitequark>
it might actually be sufficient to do selftest-only
<whitequark>
easier, too
<whitequark>
so then it would be completely passive? maybe with some LEDs to show power rail status etc?
<electronic_eel>
what a selftest can't do is measuring current draw of the whole glasgow and to measure the voltages on rails
<electronic_eel>
but another glasgow wouldn't be a good tool for measuring these
<whitequark>
yeah
<whitequark>
so what, do we just stuff some jellybean voltage and current monitors there?
<electronic_eel>
the question is if we want to develop that or if it makes more sense to just hook remote controlled multimeters in there
<whitequark>
maybe throw some opamps to show pass/fail
<whitequark>
that's not a whole lot of development
<electronic_eel>
for current I'd want a fine resolution readout
<whitequark>
then use one of those inline usb current meters, i would say
<electronic_eel>
exercise the board in different ways and compare the current draw to a predefined value
<whitequark>
that seems like a serious case of overkill, given that esden's current procedure doesn't even use a jig at all
<electronic_eel>
I don't know how good the cheap ones that I have seen are. I always use a multimeter for that
<electronic_eel>
but if you can get a reliable 0.5mA resolution then it should work
<electronic_eel>
for the test procedures at work I always do a current check
<electronic_eel>
I have found some issues with it that would be hard to find otherwise
<electronic_eel>
like a partly cracked capacitor or similar
<electronic_eel>
and it is not hard to implement
<whitequark>
mmm
<electronic_eel>
but it wouldn't be possible with just opamps, you need an adc or external multimeter
<whitequark>
yes
<electronic_eel>
but if we use an inline usb meter then the rest could be done with comparators
<whitequark>
yeah
<electronic_eel>
do you have a link to an usb current meter with remote readout?
<whitequark>
not offhand
<owo_uwu_owo>
how come .5mA resolution is needed
<electronic_eel>
if it is just a brandless chinese thing it could be a problem to buy the same one again after a few months
<owo_uwu_owo>
if it's for an automated production test the manufacturing variations will probably be more than that
<whitequark>
it is yeah
<electronic_eel>
that is what I usually spec for it. has some room for resolution != accuracy
<owo_uwu_owo>
i do some low-medium volume run projects and so far i've just used one of those cheapie usb current meters
<owo_uwu_owo>
doesn't necessarily need to be accurate but needs to be repeatable
<electronic_eel>
do you have a link to a model you have experience with?
<owo_uwu_owo>
it's just those common usb-pd ones from aliexpress
<electronic_eel>
what do they use as protocol for readout?
<owo_uwu_owo>
there isn't
<electronic_eel>
manual readout?
oeuf has joined #glasgow
<owo_uwu_owo>
yes
<electronic_eel>
urgh
<owo_uwu_owo>
the test operator has to plug the thing in anyways
<owo_uwu_owo>
it's only like 50-100pcs a batch
<electronic_eel>
then you have to remember the different current limits for the different tasks you set up
<owo_uwu_owo>
oh yeah if you are doing many products or variations then yes
<owo_uwu_owo>
so far i have just one product
<owo_uwu_owo>
and it's not very high volume
<owo_uwu_owo>
but i do have a custom test jig that is a "shield" on an orange pi
<electronic_eel>
not variations in the product. I let the dut do different tasks and record what the current draw for each task is
<owo_uwu_owo>
ohhh
<owo_uwu_owo>
yeah i would integrate that into the test jig
<owo_uwu_owo>
my test jig right now is a "shield" on an orange pi
<owo_uwu_owo>
it talks to the device over usb and then measures some rf characteristics for different modes
<electronic_eel>
the full electronics doesn't need to be in the jig itself. it just must be connected to it and somehow accessible by a computer running the test
<owo_uwu_owo>
wouldn't be hard to add current sensing there
<owo_uwu_owo>
well
<owo_uwu_owo>
the main reason i made a jig is to have it be standalone and not need a pc
<electronic_eel>
I use an external multimeter for it
<owo_uwu_owo>
i have made two test jigs, one for the pcba house and one for me
<electronic_eel>
and connect it via ethernet
<owo_uwu_owo>
ah
<owo_uwu_owo>
yeah i'd go for having everything on the jig itself
<owo_uwu_owo>
makes it easier for someone at the pcba house to quickly check your boards
<electronic_eel>
yes, similar setup for me. I have sent a fully loaded raspberry pi to the pcba company. It has all the tests on it and executes them
<owo_uwu_owo>
in my case they just plug everything in and it automatically runs through the tests and displays pass/fail on a lcd
<owo_uwu_owo>
if it fails it displays some measured parameters
<electronic_eel>
so they don't need to mess with their own computers and there are no compatibility problems and so on
<owo_uwu_owo>
and they can take a photo and send it to me
<owo_uwu_owo>
hmm
<owo_uwu_owo>
yeah
<electronic_eel>
the raspberry pi has a hdmi out, so they just connect a monitor. my test script outputs everything on the console
<owo_uwu_owo>
i use a cheapie spi lcd that is bitbanged on the pi ;)
<owo_uwu_owo>
i did have to poke the registers directly to bitbang it fast enough and it doesn't lag
<owo_uwu_owo>
basically the setup looks like this
<owo_uwu_owo>
a custom pcb "shield" is plugged into the orange pi
<owo_uwu_owo>
then the lcd is plugged into the shield
<owo_uwu_owo>
since ofc the lcd pinout can't mate directly to the pi
<owo_uwu_owo>
the custom board has some rf circuitry and is controlled by the pi's gpios
<electronic_eel>
don't know if this development effort pays off. just connecting the monitor through hdmi and using stdout in the test script is easier
<owo_uwu_owo>
don't think it took very long
<owo_uwu_owo>
and since then i don't really worry about testing anymore
<owo_uwu_owo>
just plug it in and let it run, then quick manual sanity check on the pc before shipment
<owo_uwu_owo>
but yeah i think you can find plenty of pi lcd interfacing examples out there
<electronic_eel>
back to current measurement
<owo_uwu_owo>
just a current shunt + opamp + spi adc lol
<owo_uwu_owo>
oh yeah you wanna use a current sense amplifier
<owo_uwu_owo>
like the ina199
<electronic_eel>
I think taking a regular multimeter is a better idea than developing something custom
<owo_uwu_owo>
hmm right
<owo_uwu_owo>
i guess at OwOComm we are kind of biased towards doing things in house
<electronic_eel>
esden already said he wants to buy a new one
<owo_uwu_owo>
still though i think spi adc into pi is at most two afternoons of work maybe
<electronic_eel>
owo_uwu_owo: I like developing stuff myself. But not if there is a cheap and common solution availalble
<owo_uwu_owo>
well it's not so much the cost
<owo_uwu_owo>
but more like
<owo_uwu_owo>
a simpler setup with everything in the jig is just nicer to deal with
<owo_uwu_owo>
less to "hook up" at the pcba side when you send them the jig
<owo_uwu_owo>
and less to go wrong
<electronic_eel>
you can put the whole multimeter in the jig-box if you want
<owo_uwu_owo>
lol
<electronic_eel>
so the operator doesn't see it or has to operate it
<owo_uwu_owo>
sure that works
<electronic_eel>
reading it out should be done by software, not manually
<owo_uwu_owo>
yeah
<electronic_eel>
whitequark: there are connections between the two ports for the selftest, right?
<electronic_eel>
is it ok to have the connection for the whole duration of the test?
<electronic_eel>
or is there a part of the test without this connection, like for testing if there is a short between the ports?
<electronic_eel>
if yes, then the jig needs a way to make/brake this connection. otherwise the pogo pins would be just connected through
<whitequark>
electronic_eel: i don't see how there would be a short across the ports
<whitequark>
so i think we can connect them through
<electronic_eel>
short between nearby bga balls on the fpga?
<electronic_eel>
or can the i2c io extender be used as input too?
<electronic_eel>
then you can cross-check the effect of the level shifter and the io extender
<electronic_eel>
but if there is a connection between the ports the whole time it is hard to isolate if a level is set by one port or the other
<electronic_eel>
my gut feeling says to make the connection between the ports switchable
<electronic_eel>
doesn't need to be really low resistance. just needs to switch all pins at once
<electronic_eel>
we could use photomos ics for example
<whitequark>
electronic_eel: yes, the io extender can be used as input
<electronic_eel>
but would need to coordinate with esden
<whitequark>
electronic_eel: wtf, that chip is ridiculously integrated
<whitequark>
i love it
<whitequark>
definitely going to use it in future designs
<electronic_eel>
I thought maybe ti had something like this
<electronic_eel>
and yes they do
<electronic_eel>
last time we talked about test jigs here, esden said he wanted to try out one of the chinese made ones
<tnt>
15A ... wow
<electronic_eel>
don't know if he contacted one of the manufacturers yet
<whitequark>
electronic_eel: that's the mechanics only, right?
<whitequark>
the bed of nails pcb is still on us
<electronic_eel>
I think the pogo pins are mounted on a milled acrylic sheet or similar
<electronic_eel>
so they are held in place by the jig
<electronic_eel>
they are probably wired up and you can connect them to your pcb
<whitequark>
I thought you solder them (the outer sleeve that is) in
<whitequark>
and then use acrylic as a guide
<electronic_eel>
this is another way to do it
<electronic_eel>
I think esden has to find a manufacturer for the jig first and check with them how it is done for their design
<electronic_eel>
then we can design the pcb for it
<electronic_eel>
but the schematics could be done without this info
<whitequark>
indeed
<tnt>
Well, even the PCB. I think in either case you'd have a different pcb for the actual 'electronics' and the 'pogo-pin' part.
<whitequark>
really? that seems wasteful
<electronic_eel>
the electronics we just came up with seem to be rather simple to me
<electronic_eel>
don't know if you need an extra pcb for that
<whitequark>
yeah, it'd be INA260, some opamps, some optorelays, another I2C GPIO expander, and a few LEDs
<electronic_eel>
I'd replace the opamps with i2c-adcs
<whitequark>
could be a problem
<whitequark>
because of addressing
<electronic_eel>
ah, maybe not. if 3v3 or 1v2 isn't there, then the i2c wouldn't work
<whitequark>
only 3v3
<whitequark>
1v2 is solely used for fpga vcore
<electronic_eel>
ok, so window comparators and red/green leds
<whitequark>
yup
<electronic_eel>
but that still doesn't warrant an extra board i think
<whitequark>
does not
<whitequark>
actually even if you wanted to solder pogo pins to wires
<whitequark>
couldn't you then just solder wires into the holes on the pcb where pogo pins would go?
<electronic_eel>
yes, you could
<electronic_eel>
but a regular pin header connector would be easier
<whitequark>
it's qty 1 anyway
<electronic_eel>
yeah, right
<electronic_eel>
but I'd have to care about the exact dimensions and coordinates for the test points
<electronic_eel>
would be easier if I wouldn't have to
<whitequark>
but that needs to be taken care of anyway
<electronic_eel>
by the jig manufacturer
<whitequark>
also, you don't need to care
<whitequark>
you can extract their coordinates with like, grep
<whitequark>
just copy and paste the kicad_pcb chunks that define testpoints
<electronic_eel>
yeah, I know. I'd probably import them from the glasgow pcb
<electronic_eel>
I still think we should first check with esden if he has made any progress with selecting/contacting a jig manufacturer
<whitequark>
of course
<electronic_eel>
do you know if esden has any glasgow samples left? would make testing the jig much easier for me...
<whitequark>
not sure
<esden>
whitequark: damn, that sucks, I did test everything that came to mind before sending the glasgows out. Sorry yours has a short. :(
<electronic_eel>
esden: that's exactly why we are discussing the test jig right now!
<electronic_eel>
I think with the current sensor we are planning to use you would have easily spotted that
<whitequark>
electronic_eel: just the passive loopback jig would have
<esden>
electronic_eel: I do have one assembled unit that I am keeping as reference for me. And I have materials to assemble more. But my plate is ultra full at the moment, so I am not sure when I will come around to assemble more glasgows. I hope before the end of the month but that is maybe 10% probability. I will be then gone for pretty much all August due to BlackHat,DefCon and ChaosCamp.
<esden>
so ... things don't look good at all for a while.
<whitequark>
electronic_eel: you might be able to ask Greg Davill to assemble one
<electronic_eel>
I wouldn't need it right now, but when I get the first revision of the jig board from the board house
<esden>
I will still try to assemble more glasgow before the end of the month. Also anything that requires elaborate jigs is less desirable than a small harness and good selftest.
<electronic_eel>
but just thought I mention it now to not cause it any delays later on
<esden>
anything that requires multiple tools that need to be attached into a test system is also not great. Self contained is much better.
<electronic_eel>
esden: the idea was to do most of the stuff with the selftest
<esden>
Do not overengineer things, try to make it as ultra simple as possible.
<whitequark>
yeah, the original plan was to have 2 usb devices for the test
<whitequark>
but i think that is a bad idea
<esden>
with as little special mechanical things that is doable.
<electronic_eel>
but glasgow can't measure it's own current for example
<whitequark>
so the new plan is to use just 1 glasgow
<whitequark>
with some more stuff hanging off ic
<whitequark>
*i2c
<esden>
and coverage of 90% of possible issues is good enough in my book... squeezing out anything beyond that if it is hard to do and requires expensive hardware is not worth it.
<esden>
if it is easy then go for it :)
<whitequark>
esden: the only mechanical thing we are thinking of is one of those holders for the pcb that press it against the pogo pin nail bed
<electronic_eel>
no expensive hardware - I think we found easy solutions for everything we want to do
<esden>
Also, if you build a generic tool that can be used as a test driver for other projects that is a huge bonus, and makes the whole thing more interesting. :)
<whitequark>
very unlikely
<electronic_eel>
this could be done, but makes it much more complicated
<esden>
Ohh I am not arguing for anything specific. Just listing my feelings. :)
<whitequark>
that was actually the original plan
<whitequark>
use a 2nd glasgow as such generic tool
<esden>
yeah that does sound best to me :)
<whitequark>
but it's probably ill advised
<whitequark>
because then you have to deal with 2x usb issues, more pcbs, more complexity
<esden>
I like xobs / bunnie test jigs, it is just a Raspberry pi with some additional custom boards if needed. All test is implemented in rpi with gpio bitbanging.
<esden>
including usb host
<gruetzkopf>
who has one right now? wq, mar_can and es_den (i need a ZWS macro)?
<electronic_eel>
I think I saw Greg Davill post a photo of one
<gruetzkopf>
i mean a es_den run one
<gruetzkopf>
i have a RevB that TD Linux assembled
<whitequark>
esden: sure, so the jig would need a computer (anything that can run python, an rpi works... though i am totally against bitbanging usb host, that is insane), and a single adapter pcb
<whitequark>
the adapter pcb has the usb connector and any additional test logic
<esden>
ohh I did not say bitbanging usb
<esden>
sorry
<esden>
use the rpi usb host, and everything else is through the gpio header
<whitequark>
in this case we can use everything else through glasgow itsefl
<esden>
like programming, or enabling tings, or injesting data
<whitequark>
which means it is not dependent on a specific board like rpi
<electronic_eel>
but then it would be rpi specific
<electronic_eel>
I think the self-testing approach is more generic
<whitequark>
i don't even have any rpis
<electronic_eel>
it would just be extended by also checking for the i2c ics on the adapter board
<esden>
yeah, I would throw in the box a rpi and a glasgow, and build everything I can with that, maybe add some power supplies and current measurement shunts.
<esden>
if that is really necessary
<electronic_eel>
don't need no shunts, we found a nice current/voltage monitor ic with everything integrated
<electronic_eel>
when whitequark was searching ali some time ago, they suggested some other peoples search terms to her
<electronic_eel>
was some sex toy thing IIRC
<whitequark>
yes, and quite profane at that
<esden>
will we only have contacts on one side of the glasgow?
<whitequark>
esden: yes, all relevant testpoints are at bottom or duplicated at bottom
<whitequark>
this was taken care of for c1
<esden>
ok cool!
<esden>
humm... I can't find the type I saw in other places, will have to look later. Need to do a few things first. All the ones I found so far look like the one above. I want something where we can have a test start button, a LCD text display and some good/bad indicator led.
<electronic_eel>
hmm. why lcd and so on?
<esden>
so you know what failed without hooking up a monitor to it
<esden>
it should be stand alone if possible
<electronic_eel>
I suggest to have a regular monitor connected
<esden>
nononono... please dont
<esden>
altough... I do not know... >_<
<whitequark>
it just seems a waste of time to develop some custom display solution
<electronic_eel>
you suggested the self-test route
<whitequark>
where all you need to do is to hook up some cheap hdmi monitor
<whitequark>
they're like $10
<esden>
yeah I know... hook up the test jig to laptop maybe?
<electronic_eel>
self-test means the regular glasgow cli runs
<esden>
over usb?
<esden>
and run some test software on laptop?
<whitequark>
yes, that would make more sense
<whitequark>
bring any pc
<whitequark>
and i give you a docker container or whatever
<electronic_eel>
for example on a lapop, yes
<whitequark>
it doesn't have to be a cli, i can write some code that displays PASS/FAIL on the entire screen
<esden>
the problem is if we ever want to deploy the test not in my house self contained is better...
<electronic_eel>
then we could integrate all this in a raspi
<whitequark>
then we put that all on an rpi and connect a cheap hdmi monitor to it
<esden>
ok fair enough...
<electronic_eel>
so no lcd
<esden>
ok... I need to do some accounting now... :P bbl
<electronic_eel>
esden: can you select a jig design and contact the manufacturer?
<whitequark>
though they cranked up security recently and it might be a prolem
<electronic_eel>
I can begin thinking about the schematics of the test board
<esden>
electronic_eel: for schematic purposes. I would think you will have screw terminals, or some wago quick connects for the cables coming from the pogopins. I am pretty sure we will end up with a test jig that uses that. The reason is that the sockets they use for the pogopins already have wires attached.
<esden>
you want sockets as the pogopins wear out and you want to be able to replace them.
<esden>
As far as I see the test points on the glasgow should be far apart from each other enough that we will not have a problem with that.
<whitequark>
esden: definitely not
<esden>
I will search more for a test jig source later today.
<whitequark>
look at the USB test points
<esden>
ohh shoot ... you are right :)
<electronic_eel>
ok, wago style quick connect terminals for the test points, that is easy
<electronic_eel>
how to start the test?
<esden>
2.45mm distance is what would be better...
<electronic_eel>
pressing enter on the laptop would be the easy solution
<esden>
electronic_eel: a big arcade button :)
<whitequark>
or no button at all
<esden>
or that...
<whitequark>
the moment an usb device is detected it starts the test
<electronic_eel>
the arcade button has to somehow be connected back to the software
<esden>
no button is definitely better, autodetect if possible
<electronic_eel>
whitequark: no that is too early. you have contact bounce and maybe a misaligned board
<whitequark>
autodetect would be easy
<whitequark>
electronic_eel: so it just waits a few seconds
<electronic_eel>
autodetect and wait 2 seconds would be ok
<esden>
that might add to the turnaround whitequark
<esden>
I would have a place for a button just in case we need it and can't do the autodetect
<whitequark>
of course we can do autodetect
<electronic_eel>
good idea
<whitequark>
i mean one of {libusb hotplug,polling each 0.5s} is guaranteed to work
<esden>
if the first test is short we can run that one in a loop until it succeeds and then move on to the next step
<esden>
so yeah, there are ways to get around that
<whitequark>
all tests take less than a second
<whitequark>
on a warmed up instance, ie with bitstream built
<esden>
right
<electronic_eel>
how should the jig be powered? usb host or a separate supply?
<whitequark>
just from usb
<whitequark>
i think
<whitequark>
could add some unpopulated terminals just in case, and a trace to be cut
<electronic_eel>
that means there needs to be a very wide pass range for the 5V supply check
<whitequark>
no, that means the factory should not use 7 hubs before the glasgow
<electronic_eel>
the usb spec allows down to what, about 4.5v or something?
<whitequark>
yes
<whitequark>
because it has to handle shit cables and ridiculous topologies
<whitequark>
but we don't
<electronic_eel>
hmm, what we are actually interested in is not the absolute value, but the drop through the TPD3S014
<electronic_eel>
if there is a short on the dut, the TPD should limit the current and we see a large drop
<electronic_eel>
that should then light the red fail led
<whitequark>
don't we already have the current sensor for that?
<electronic_eel>
the current sensor won't work in this case because it does not have power
<whitequark>
right
<electronic_eel>
such a test led would make it much easier to spot the problem
<electronic_eel>
but it adds a bit of complexity to the test board
<electronic_eel>
but a simple voltage window comparator should still work for this case
<whitequark>
yeah
<electronic_eel>
ah, and the INA260 also has a voltage sensor. so we could use that for a fine test once the basic stuff in online
<whitequark>
yeah
<electronic_eel>
so a basic comparator test is enough
<electronic_eel>
so I think I'll create a git repo and begin to draw up some schematics
<whitequark>
the original idea was to have everything in the main Glasgow repo
<whitequark>
so feel free to work in a branch against that
<electronic_eel>
ah, ok, that would work too
<electronic_eel>
hardware/test-jig or some other dir?