<_whitenotifier-1>
[Glasgow] electroniceel opened pull request #126: Add protection resistor between fpga and the level shifter for the sync connector - https://git.io/fjmnG
<_whitenotifier-1>
[Glasgow] electroniceel commented on issue #125: Protection resistor for FPGA & level shifter on the sync pin - https://git.io/fjmnc
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-1>
[Glasgow] marcan commented on pull request #126: Add protection resistor between fpga and the level shifter for the sync connector - https://git.io/fjmCG
<electronic_eel>
marcan: re moving the via to U24: what is the problem with that?
<electronic_eel>
I think there is enough clearance between the via and the pad so that no solder is sucked into the via
<electronic_eel>
or is it the beauty of the vias being in a line & symmetrical?
mehar has quit [Ping timeout: 268 seconds]
<_whitenotifier-1>
[Glasgow] marcan commented on pull request #126: Add protection resistor between fpga and the level shifter for the sync connector - https://git.io/fjmCH
<_whitenotifier-1>
[Glasgow] electroniceel commented on pull request #126: Add protection resistor between fpga and the level shifter for the sync connector - https://git.io/fjmCQ
<_whitenotifier-1>
[Glasgow] marcan commented on pull request #126: Add protection resistor between fpga and the level shifter for the sync connector - https://git.io/fjmWf
<_whitenotifier-1>
[Glasgow] electroniceel commented on pull request #126: Add protection resistor between fpga and the level shifter for the sync connector - https://git.io/fjmWI
<whitequark>
marcan: esden: stupid idea
<whitequark>
put two slots underneath the USB connector
<whitequark>
this way if you tear it off, you can use a tiny nylon cable tie to attach your cable directly to the PCB so you wouldn't tear off the test points you solder to
<marcan>
lol
<marcan>
I'm not sure we want to add gratuitous slots just for that
<marcan>
people can use hot glue :p
* marcan
hides
<whitequark>
hot glue doesn't actually hold on to a PCB.
<whitequark>
at all.
<marcan>
um, my experience is otherwise
<whitequark>
i've never been able to usefully attach anything to a PCB with hot glue
<whitequark>
or frankly, to most things
<marcan>
huh
<electronic_eel>
I suggest you use 2k epoxy to glue the usb connector to the board _before_ it tears of
<marcan>
I've had lots of success with hot glue
<marcan>
electronic_eel: ha
<whitequark>
electronic_eel: yes but you pay for it
<electronic_eel>
you mean the whol board is destroyed when it comes off?
<marcan>
electronic_eel: btw, yeah it's a beauty thing. hope you don't mind me re-rolling your change. I'm just anal about such things (and I think wq appreciates it :p)
<electronic_eel>
marcan: I don't mind, just move the via a bit up & right
<whitequark>
if i couldn't get all the things nicely lined up, in board layout, code and schematics, i would rather not have the project at all
<whitequark>
so that's how i do things.
<marcan>
electronic_eel: lol, I just added a GND via up there because I flipped R10 to make it neater
<marcan>
so I can't really do that any more
<marcan>
but really I think it's fine
<marcan>
solder's not going to wick down there
<marcan>
it's not like the via actually overlaps the pad
<marcan>
it's just closer than the DRC distance, but that's fine
<marcan>
we've done closer than that (e.g. all the GNDs for the LEDs, though there's no good reason for those, they could be pulled out)
<marcan>
and some of the caps on the Vio supply side
<electronic_eel>
I think it slightly increases the chance of a bad solder joint. The more often you do it on the board and the larger the batch the larger the rate of failed boards
<electronic_eel>
You can do it in a few places where there is no good other solution, but I'd prefer more distance over beauty
<electronic_eel>
but in the end you are the ones doing a larger batch, not me...
<whitequark>
marcan: let's tag revC1 on 16th
<marcan>
I'll let esden pitch in :-)
<marcan>
he gets the final say over DFM issues anyway
<electronic_eel>
whitequark: I've seen you added testpoints for usb to the bottom
<electronic_eel>
so you plan to use a bed of nails for testing on the bottom, correct?
<whitequark>
electronic_eel: it
<marcan>
that's the plan, mostly
<whitequark>
*it's an option
<marcan>
the LVDS connector still requires either a connector-based jig or won't be tested
<marcan>
whitequark: oh btw, this may be a kicad update, but something broke about the art on the back
<marcan>
I need to figure out what happened
<electronic_eel>
I'd suggest to add a testpoint for 1V2 to the bottom too
<marcan>
can't cut C1 until I figure out wtf is up with that
<marcan>
actually somehow it looks fine in the 3D view
<marcan>
if the gerbers come out fine I guess I don't care
<marcan>
could just be a graphical glitch
<marcan>
but I want to double check
<electronic_eel>
marcan: can you show a picture of what you mean
<marcan>
one of her eyes is missing, and the mouth and nose and eyebrows
<marcan>
electronic_eel: I don't think we need 1V2 for any actual testing?
<electronic_eel>
I see the silkscreen problem, but not on 3d - maybe a ordering issue
<electronic_eel>
I always test all the voltages in production testing. It helps to quickly narrow down any problems
<marcan>
yeah, might be a thing with the inner contours not being sorted properly
<whitequark>
it does make sense to have 1V2 on a testpoint
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±2] https://git.io/fjmWw
<_whitenotifier-1>
[Glasgow] marcan closed pull request #126: Add protection resistor between fpga and the level shifter for the sync connector - https://git.io/fjmnG
<_whitenotifier-1>
[Glasgow] marcan closed issue #125: Protection resistor for FPGA & level shifter on the sync pin - https://git.io/fjmTo
<marcan>
electronic_eel: I'll leave the via as is right now, but if esden objects I can flip the resistor again and move it up
<marcan>
(in that case it makes sense to adjust all the other instances though, they can also be improved)
<electronic_eel>
marcan: ok, just ask him about it
<marcan>
(we can do all of those in one commit if needed)
<marcan>
electronic_eel: fwiw the silk art used to look fine, so I think it must've broken in a kicad update
<electronic_eel>
marcan: re the silkscreen issue: might it be an incompatibility between the kicad versions? I use 5.1.0 and you checked in a change from me
<marcan>
electronic_eel: I haven't done electrical testing, but the pin worked fine
<marcan>
it was a brief short of course
<electronic_eel>
whitequark: "device side" is the DUT or port side or between fpga and level shifters?
<whitequark>
DUT side
<whitequark>
in general, i think that contention between FPGA and shifter is not a huge concern
<electronic_eel>
180 ohms is too much there IMHO
<whitequark>
it's one of the simplest piece of gateware in the system
<whitequark>
i have no idea what's the point in protecting that and not protecting the FX2 bus, which is probably more fragile
<electronic_eel>
just think about migen beginners like me trying out their code on Glasgow ;)
<whitequark>
you can't screw it up
<whitequark>
the applet code doesn't give you bare I/Os
<whitequark>
instead it gives you a TSTriple and the OE is hard tied to the shifter OE
<whitequark>
you *can* screw it up if you write your own bitstream completely from scratch in verilog or something, but like i said, in that case i would be more worried about contention on FX2 side
<whitequark>
(i think the FPGA is actually stronger than the FX2)
anuejn has joined #glasgow
espes has joined #glasgow
<electronic_eel>
from what I've seen you tweaked the usb comm through the fx2 into the fpga quite a bit
puck has joined #glasgow
<electronic_eel>
that part wouldn't be the one I'd first go at tweaking
Hellsenberg has joined #glasgow
<electronic_eel>
but nice to hear that there isn't immediate danger of destroying anything
<electronic_eel>
but on the dut side it is a completely different thin
<electronic_eel>
g
<whitequark>
right, so the thing is, the footprint between FPGA and shifter is there to keep our options open
<whitequark>
for revC i originally wanted to populate it with 0 ohm, actually
<whitequark>
but... it's cheaper to put 33 ohm there
<whitequark>
one less BOM line
<electronic_eel>
ok, but now back to the DUT side
<whitequark>
yeah
<electronic_eel>
how about 100 Ohms there. That should protect the '45 as it allows 50mA.
<whitequark>
1.6 volt drop at very conservative 16 mA
<whitequark>
so this will not work with TTL
Hellsenberg has quit [Client Quit]
bgamari has joined #glasgow
Hellsenberg has joined #glasgow
<whitequark>
actually, now that i look deeper into this, what the hell *is* the source current spec for TTL?
<whitequark>
i've seen at least five different values by now, from 4 mA to 32 mA
<electronic_eel>
but doesn't 5v ttl specify high >= 2,4V?
<whitequark>
0.8 i believe
<electronic_eel>
0.8v for high?
<whitequark>
so for example PS/2. 0.8 Vil(max), 2.0 Vih(min), 20 mA sink current
<tnt>
100 would deinitely be an upper bound, RC corner freq for 100 ohm vs 10p load is "only" 160 MHz.
<electronic_eel>
yes, <= 0.8v for low
<marcan>
yeah, I'm not too fond of the idea of >100 ohms for the DUT side
<whitequark>
i think 100 ohms is too high already
<marcan>
yeah
<whitequark>
33 is more like it
<marcan>
agreed
<whitequark>
even that might be on the high side
<whitequark>
but it seems fine generally
<electronic_eel>
47?
<whitequark>
that's 17 mA
<whitequark>
okay for 16 mA TTL, not so much for 20 mA TTL...
<electronic_eel>
you want glasgow to be safe and not break by some unexpected DUT behavior
<whitequark>
i also want it to be useful
<whitequark>
47 miiiiight be okay
<electronic_eel>
yes, of course. 47 ohms at 20mA is 0,94 volts - that is ok for ttl
<whitequark>
that's over 0.8
<whitequark>
so not in spec
<tnt>
it's not a portable multimeter either ... I'm not expecting it to survive plugging it into mains while set to ohms ...
<whitequark>
right now a shorted level shifter sources 90 mA
<whitequark>
at 5V
<whitequark>
so its internal impedance is 22 ohm
<marcan>
that sounds like 33 is a good value
<whitequark>
exactly
<electronic_eel>
do you really pull 20mA when outputting a ttl zero?
<whitequark>
electronic_eel: it depends on the specific kind of TTL
<electronic_eel>
IIRC it is more like 2mA or so
<marcan>
honestly we should just stress test this
<marcan>
I did buy a bunch of shifters
<whitequark>
also that
<marcan>
let me just flywire a couple to shorted, bypassing the resistors
<marcan>
and leave it on overnight
<whitequark>
'accelerated degradation' we can call it
<electronic_eel>
marcan: good idea
<marcan>
well, we have 100mA on the PSU anyway, right?
<marcan>
so that's another safety
<whitequark>
so, Modern TTL Circuits suggests Vil=0.8 but Vol=0.4 (!)
<marcan>
whitequark: we're sure the 90mA sourcing isn't limited by vio?
<whitequark>
marcan: hrm
<electronic_eel>
whitequark: but at what current?
<whitequark>
marcan: voltage sags to 4.95
<whitequark>
so i'm thinking no
<whitequark>
(from 5.05)
<electronic_eel>
marcan: there is 150mA written in the schematics
<whitequark>
yes but it's always good to check these things
<whitequark>
electronic_eel: spec'd to have Vol=0.4 at 16 mA sink
<electronic_eel>
ah, it is probably 10 inputs, 1.6mA each
<whitequark>
yep
<whitequark>
so to meet that we'd have to have 25 ohm total impedance, which means no resistor at all
<whitequark>
which is a bit naughty
<whitequark>
0.8 V at 16 mA is just what we have now
<electronic_eel>
ok
<electronic_eel>
let's see if marcans shifter survives tomorrow
<whitequark>
assuming marcan's test shows that shifters don't appreciably degrade i'd say keep 33 ohms
<electronic_eel>
and the input impedance is still ok
<whitequark>
people who do really hardcore TTL work can add an external buffer
<whitequark>
the floppy interface is technically specced at 32 mA per pin, which is insane
<whitequark>
why would you dissipate so much power doing nothing
<electronic_eel>
i think they used so much power in old circuits to get rid of emi problems
<electronic_eel>
use them more like current interfaces than voltage ones
<whitequark>
the 400 mV between Vil and Vol are supposed to be a buffer for that, yes
<electronic_eel>
i think that is more about wire & connector resistance
<whitequark>
hmm, so i tried to use my multimeter to measure the resistance of a shifter turned on
<whitequark>
that shows 43 ohms and not 55
<whitequark>
interesting
<whitequark>
it could be just that it's cold?
<electronic_eel>
I guess the multimeter current output gets confused by the active output
<whitequark>
why is it active? it's a turned on FET
<whitequark>
that should look very much like a resistor
<whitequark>
so i tried again but let it cool down
<electronic_eel>
best way to measure output impedance is to use a known resistance before a fet and wiggle the fet on and off
<whitequark>
that's a higher current than what i first measured
<electronic_eel>
then use a scope to measure the voltage difference on the output
<marcan>
whitequark: what's the easiest way to toggle pins on and off?
<whitequark>
marcan: copy examples/boilerplate.py
<marcan>
I'm shorting A0 to GND and B0 to +5V (yes +5V, not Vio)
<Hellsenberg>
wait there's examples?
<whitequark>
as of a few days ago, yes
<marcan>
whitequark: to a random subdir of applets?
<Hellsenberg>
owo
<marcan>
whitequark: can it eat both ports?
<whitequark>
marcan: yes and add that to applet.all
<whitequark>
yes it can
<electronic_eel>
wouldn't it be nice to have some gpio capability on the commandline?
<whitequark>
maybe but i don't know what the interface should look like
<whitequark>
so it's not there
<marcan>
NameError: name 'GlasgowApplet' is not defined
<marcan>
oh wait
<marcan>
nvm
<whitequark>
also i think my meter is lying
<whitequark>
i mean it's the cheapest piece of shit so that would be unsurprising
<whitequark>
uni-t ut33c
<marcan>
sooo some USB power meter I have says I'm drawing 400mA
<marcan>
that's like 180mA per pin plus extra
<marcan>
(this is bypassing the resistors)
<Hellsenberg>
I've seen meters measure stuff wrong when battery is dying
<marcan>
in-line USB power meter
<Hellsenberg>
usually voltages are measured higher than usual
<whitequark>
that's quite a bit
<marcan>
well, it's going to stay like this all night
<marcan>
but hey, a torture test is a torture test
<marcan>
it's staying like this all night
<marcan>
if this doesn't kill them, nothing will
* marcan
wonders if they will desolder themselves
<marcan>
actually that could be kinda dangerous to the iCE40, lol
<Hellsenberg>
poor thing
<electronic_eel>
don't you want to try it with the 33 that are planned?
<electronic_eel>
ohms i mean
<marcan>
margin
<marcan>
if they survive this, I don't need to try it with the 33s
<marcan>
and we know we're waaay fine
<marcan>
good night!
<electronic_eel>
I hope you have a smoke alarm in your room ;)
<marcan>
I do :-)
<marcan>
if this kills my glasgow entirely, it went to a good cause (and esden can hurry up with revC1 :D)
<electronic_eel>
wonder what urban fantasy fans think if they hear us talking about shifters
voxadam has quit [Read error: Connection reset by peer]
voxadam has joined #glasgow
<marcan>
whitequark: btw, the side pulled to gnd still has vio at 4.98V, even though I think this should be pulling 180mA or so
<marcan>
so we might want to double check that current limit thing
<marcan>
(hard to say though)
<whitequark>
interesting
<whitequark>
it might be a sharp cutoff
<electronic_eel>
i just looked at the datasheet of the tps...: current limit kicks in between 360mA and 500mA
<marcan>
waaaait
<electronic_eel>
and then it limits to 200
<marcan>
whitequark: you confused the spec output with the actual limit
<marcan>
limit is 150 to 500 mA, 360mA typ
<marcan>
per datasheet
<whitequark>
ah, crap
<whitequark>
but i mean
<marcan>
I mean this isn't *bad*, I might *want* to pull >150mA per port tbh
<electronic_eel>
regulators with precise current limit are hard to find
<whitequark>
yes, that's what i mean
<marcan>
but we should document it properly then
<whitequark>
24mA*8=192 mA
<marcan>
yup
<whitequark>
btw I found a potential issue
<whitequark>
if I short the LDO with my multimeter it briefly draws 700 mA
<whitequark>
then, 300 mA and doesn't cut off
<whitequark>
but the board is already dead
<marcan>
dead?
<whitequark>
FX2 not running
<marcan>
oh, so there's an inrush issue
<electronic_eel>
or is it frying the i2c bus?
<whitequark>
why the hell would it do that?
<marcan>
well, do we really care about guaranteeing glitch-free operation when you short outputs?
<whitequark>
marcan: the PWR LED is off
<whitequark>
but it's sourcing current
<marcan>
er
<whitequark>
which seems... suboptimal
<marcan>
how?
<whitequark>
i don't know?
<whitequark>
oh
<electronic_eel>
is it completely broken or does it work again if you replug
<marcan>
oh, 5V below brownout?
<whitequark>
yep
<marcan>
so 3V3 reg doesn't kick in?
<marcan>
yeah that makes sense
<marcan>
but 300mA shouldn't do that
<marcan>
if your USB PSU isn't crap
<whitequark>
it's just my laptop
<marcan>
ah
<marcan>
300mA, seriously?
<whitequark>
my meter might be lying
<whitequark>
lemme short 5V to ground
<whitequark>
uh yeah it's showing the same 300 mA
<marcan>
lol
<marcan>
cable?
<marcan>
I've some some absolutely amazingly shittacular USB cables
<electronic_eel>
marcan: yes I had my dose of those too
<whitequark>
it's some random ass braided cable by "VOXLINK"
<whitequark>
mind you, my meter COULD be lying
<whitequark>
lemme calibrate it against a lab psu
<whitequark>
"calibrate"
<marcan>
so, wait
<marcan>
how is Vio on if the FX2 is off?
<marcan>
EN should be low?
<whitequark>
that's the question.
<marcan>
measure EN?
<whitequark>
i only have one meter...
<whitequark>
oh i guess i can short it with something else
<marcan>
spec says 0.5V vil 1.7V Vih
<whitequark>
so the shitty meter is within 3 mA of the shitty lab PSU
<whitequark>
i'm going to say this is not a coincidence and it doesn't lie that much
<marcan>
well, that's measuring current
<whitequark>
sure
<marcan>
but it also probably has a high burden voltage
<marcan>
you need another meter to check that
<marcan>
well, you can use the psu
<marcan>
watch the output *voltage* while measuring current through the meter
<whitequark>
0.3V at 1A
<marcan>
hm, I guess that's not too horrible
<whitequark>
0.2V at 0.5A
<whitequark>
anyway let me check EN
<whitequark>
... huh
<whitequark>
meter says 0 V
<marcan>
err?
<marcan>
and you measured 300mA across vio?
<whitequark>
yep.
<marcan>
does not compute
<whitequark>
yep.
<marcan>
are you sure it's actually drawing 300mA now when vio is actually 0?
<marcan>
er, en
<marcan>
(also, seriously, you need two meters)
<whitequark>
i just reproduced it again
<marcan>
I mean you have two test cases here, one through the meter and one not
<marcan>
they are not identical
<whitequark>
oh I see
<whitequark>
lemme check the voltage on Vio when shorting it with something else
<electronic_eel>
btw, wouldn't it make sense to have leds for vioa and viob, so that you can see if they are enabled or not?
<marcan>
kind of an issue at 1.8V
<marcan>
could have leds for the enable pins though
<marcan>
(or throw in some fets)
<marcan>
but... I'm not sure we have the board space for that
<electronic_eel>
if the enable pins actually work that would be ok
<whitequark>
marcan: so, when Vio is shorted to GND, the Vio measures as 10 mV
<whitequark>
very consistently
<marcan>
maybe where the J2/J3 silk labels are now?
<whitequark>
if I remove the short and let the output stabilize, it measures 0 V
<marcan>
hm
<whitequark>
lemme see what happens on 3V3
<marcan>
really gotta go sleep now, but
<marcan>
whitequark: thoughts about what electronic_eel said?
<whitequark>
marcan: OH
<whitequark>
i figured it out
<whitequark>
lemme do one last check
<electronic_eel>
marcan: then they would be near the ports they relate to. but a case would need cutouts there that you can see them
<electronic_eel>
other position would be next to the other leds
<marcan>
electronic_eel: nah, these have to be next to the ports
<marcan>
hence where the J2/J3 silkscreen labels are now
<electronic_eel>
ok
<marcan>
it's either that or where the 3V3/5V testpoints are now (and the complementary side) and we move those to somewhere else, somehow
<electronic_eel>
there are voltage testpoints on the back side now
<electronic_eel>
so maybe these aren't necessary anymore
<whitequark>
marcan: iiiinteresting
<whitequark>
marcan: the board only brown outs if I short Vio with eg meter leads
<whitequark>
if I enable LDOs into dead short it stays there
<electronic_eel>
what do you mean with "stays there"?
<whitequark>
doesn't reboot
<whitequark>
responds over USB, etc
<marcan>
whitequark: that makes sense, because the LDOs have a progressive current limit, so if the output is dead shorted at 0V the current will be low and it won't start up
<marcan>
but what about EN going low on brownout?
<whitequark>
they get super hot though
<electronic_eel>
maybe contact bounce when touching with the meter leads?
<electronic_eel>
could create emi
<marcan>
well sure, it's a current limit, but it's not 0
<marcan>
so they will be actually dropping a ton of voltage
<whitequark>
it could be emi, but EN should be pulled low...
<whitequark>
mhm
<marcan>
anyway, I can test this myself after the shifter test
<marcan>
seriously, nn!
<whitequark>
yeah
<marcan>
I have at least 3 meters so
<marcan>
and a scope
electronic_eel has quit [Quit: Konversation terminated!]
Jasjar has quit [Ping timeout: 246 seconds]
Jasjar has joined #glasgow
Jasjar has quit [Remote host closed the connection]