whitequark changed the topic of #glasgow to: glasgow debug tool · code https://github.com/whitequark/Glasgow · logs https://freenode.irclog.whitequark.org/glasgow
<whitequark> hm
<whitequark> just tried reading glasgow's eeproms with glasgow
<whitequark> doesn't work well
<Ultrasauce> insufficient ouroborosity
Xesxen has quit [Remote host closed the connection]
Xesxen has joined #glasgow
<whitequark> yes
<Ultrasauce> is there enough ram to cache the configuration that lives there or does it allll need to go to buffers
<whitequark> elaborate
<whitequark> oh
<Ultrasauce> well, maybe i am not familiar enough with your architecture. whats in the eeprom
<whitequark> the buffer ram is completely separate
<whitequark> the eeprom is not used during runtime
<whitequark> unless you specifically do
<whitequark> but the DACs and ADCs are on the bus too
<Ultrasauce> oh then what's the sticking point
<Ultrasauce> ah yes
<whitequark> youcan use --keep-voltage but
<whitequark> the FPGA reset register for each applet
<whitequark> is on the same i2c
setrofim has quit [*.net *.split]
valloc has quit [*.net *.split]
setrofim has joined #glasgow
valloc has joined #glasgow
<esden> marcan: can you add more background to the second fix? Why we are doing this and what it fixes. I have not followed all the conversation in here and it would be good to understand why this fix is being done and how the replacement chip should be wired in. I understand that the new gpio chip will not require the i2c level shifters as it has a separate i2c supply voltage?
<esden> maybe even add that info to the wiki page instead of answering me here, so that everyone benefits that will undoubtly ask later. :D
<esden> I have added the PCA6408APW,118 to my arrow cart. I will order it. I think the mod to use it instead of the TCA9534 is not too horrible.
<esden> ohh, I see at the top of the wiki page that you mention the removal of the level shifters. Sorry about that.
<esden> Ok, upgrade parts ordered. :)
<marcan> esden: you can put it in by lifting 3 pins and fly-wiring them, I'm going to order them and do the same to validate it
<marcan> I'll add rationale info
<marcan> and also fix the design and push (not done yet)
_whitelogger has joined #glasgow
<marcan> esden: done
<marcan> whitequark: how much do you trust my judgement re: how bright the LEDs should be?
<marcan> PWR LED is currently using a 2k2 resistor. quick test suggests 10k is more reasonable but still too bright, 47k (!) is actually pleasant for use as an indicator.
<apo> 470 it is
<marcan> 47k/2 is kind of OK too
<marcan> whitequark: how's this for a benchmark: the LEDs have to be clearly visible (not attention-grabbing, but immediately decipherable) when the board is illuminated by http://elektrolumens.com/FireSword-V/FireSword-V.html in high mode at 1m distance.
<sorear> that's what, 3% of direct sunlight or a few times higher than typical office?
<sorear> is "it should be possible to use this outdoors in places with good weather" at all realistic?
<sorear> clearly STARSHIPRAIDER needs an ambient light sensor
<marcan> sunlight is 98000 lux; this thing is 3000 lumens but at 1m seems to have a hotspot that's about 20cm * 20cm, which makes it 75000 lux
<marcan> just a guesstimate but it *should* be in the ballpark of sunlight
<marcan> I tried 33kΩ and it's nice in my normal lighting, but I assume *someone* is going to complain about it being too dim, so I'm going to call it 20kΩ for the greens.
<marcan> the ERR LED gets 10kΩ
<marcan> and ACT needs a lot less
<marcan> 2K2 actually looks reasonable for that one
<tnt> marcan: how about independent software configurable current sources for each led ? :)
<marcan> yeah I'll let you figure out how to fit that in the layout :p
<tnt> hehe
<apo> no resistor at all and just ΔΣ it :D
<tnt> apo: yeah, I was thinking about that, but in the end for debug leds you probably want as little things that can go wrong.
<tnt> jut i was jk of course.
<marcan> jesus fucking christ I just turned on the user LEDs properly MY EYES
<marcan> the blue ones are almost safe for human consumption
<marcan> but fuck, I can't stare at the pink and white ones at all
<marcan> 680 ohm resistors is what they had, lol
<marcan> lessee, 4k7 for blues looks good
<marcan> amusingly, the blues make the adjacent pinks fluoeresce a bit
<marcan> 10K for the pinks looks fine
<marcan> maybe 6k8 for white?
<tnt> how many colors is there ? Are they all different ?
<tnt> nm, found the pic you posted.
<marcan> honestly they're still brighter than I'd like them, but I like dimmer than normal room lighting so
<marcan> I can live with this, and I don't think anyone is ever going to complain of using a glasgow in a situation where they're too dim
<marcan> they're pretty much right for a brightly lit workbench, which I think is a sensible benchmark
<marcan> and they aren't burning my eyes EVEN WITH A LAYER OF TAPE ON TOP like they used to
<_whitenotifier> [whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±3] https://git.io/fhpM3
<_whitenotifier> [whitequark/Glasgow] marcan e767dfa - revC1: adjust LED resistor values for eye safety
<marcan> part of the issue is that they're 0603 LEDs, mostly not diffused, so pretty pinpoint light sources
<marcan> I imagine if we had any kind of diffuser/lightpipe in front they'd be quite reasonable
<apo> you know that your LEDs are too bright when the guy with the big laser starts complaining ;)
<marcan> :D
<gruetzkopf> the last non-annoying green indicator leds i have are on decade-old ethernet switches
<gruetzkopf> before the big led tech switch
<_whitenotifier> [whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±2] https://git.io/fhpy8
<_whitenotifier> [whitequark/Glasgow] marcan a47714e - revC1: update schematic with current/voltage figures for LEDs
<_whitenotifier> [whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fhpSz
<_whitenotifier> [whitequark/Glasgow] marcan 48b61ff - applet.selftest: turn on the FPGA user LEDs
<whitequark> 13:24 < apo> no resistor at all and just ΔΣ it :D
<whitequark> you can't do that
<whitequark> 13:48 < marcan> the blue ones are almost safe for human consumption
<whitequark> note that esden will use a different blue led than what is currently on board
<marcan> esden will have to calibrate for that then
<marcan> for now I made what we have sane
<whitequark> alright
<marcan> greens at 55µA
<marcan> yes, 55µA
<whitequark> nice
<marcan> and it's still too bright for my taste, honestly
<marcan> (but at this brightness I doubt anyone will complain that they can't see it)
<marcan> see twitter thread for some photos and such
<whitequark> which?
<whitequark> nice
<marcan> fwiw I used 2k for ACT because that's what I had lying around in my sample book, but specced 2k2 because we use that elsewhere already
<marcan> I don't think 10% is perceptible (gamma yadda yadda)
<whitequark> sgtm
<whitequark> fwiw i'm having a particularly awful day and only barely aware of what you're telling me
<whitequark> things look good enough but yeah
<marcan> np, take it easy
<marcan> also if you saw that commit, I made selftest turn on the user LEDs (falls back cleanly for revB)
<whitequark> yes, looked at it
<marcan> glad I got that revB from TD-Linux, it's going to be very useful to make sure I don't break it
<yorick> so why isn't it usbc?
<marcan> because usbc connectors are kind of cursed to spec
<marcan> it's either dual-row smt or hybrid smt/thru-hole
<marcan> revD might be usbc
<marcan> we'll see
<yorick> neat!
<marcan> esden didn't really want to take chances on revC, enough fun stuff in there already
<whitequark> unsure if i want revC and revD to use different cable
<whitequark> that's because they are in many ways interchangeable
<whitequark> so you might want to swap one for the other easily
<marcan> yeah, makes sense
<marcan> revE will definitely be usbc anyway, because usb3
<whitequark> actually not
<whitequark> it will be usbc because usb pd
<whitequark> the programmable power supplies ought to support one amp to DUT
<marcan> whitequark: are we putting two ports on it, or are we going to require a PD-capable hub or something?
<marcan> i.e. obviously it has to work on type A USB3 ports with A-C cables, that won't do PD
<esden> marcan: you are too fast... :D I have to finally merge my schematic key additions. I am curious if I will have to redo it now or not. :)
<esden> And yeah, I was thinking of either performing a bit of exacto knife surgery before assembling the board, or lifting some legs to retrofit the new chip.
<esden> I like the surgery path, it is a fun one. :)
<esden> The chips will be here tomorrow. I guess I should start setting up my streaming desk again. It might be a fun thing to stream. :D
<sorear> (can't do that) how much inductance is there here, and how much peak current do you get up to if you connect a LED to 3V3 for 10 ns?
<whitequark> sorear: you can't do that because the MCU is far too slow
<sorear> oh I assumed they were connnected to fpga pins
<whitequark> marcan: that would transparently derate to however much USB3 supplies by itself
<whitequark> which is i think 3A?
<whitequark> sorear: user leds are
<whitequark> the rest aren't
<gruetzkopf> 0.9A@5V
<gruetzkopf> 3A is allowable under usb-pd conditions for usb-a, but *no one* implements the cursed FSK protocol
<whitequark> oh.
<whitequark> yeah.