electronic_eel has quit [Ping timeout: 272 seconds]
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 272 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #glasgow
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #glasgow
samlittlewood has joined #glasgow
fridtjof[m] has quit [Quit: Bridge terminating on SIGTERM]
emily has quit [Quit: Bridge terminating on SIGTERM]
jschievink has quit [Quit: Bridge terminating on SIGTERM]
ZerataX has quit [Quit: Bridge terminating on SIGTERM]
whitequark[m] has quit [Quit: Bridge terminating on SIGTERM]
promach3 has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
disasm[m] has quit [Quit: Bridge terminating on SIGTERM]
Foxyloxy has quit [Ping timeout: 246 seconds]
Foxyloxy has joined #glasgow
gillesmauve has joined #glasgow
jevinskie[m] has joined #glasgow
ZerataX has joined #glasgow
promach3 has joined #glasgow
whitequark[m] has joined #glasgow
jschievink has joined #glasgow
emily has joined #glasgow
fridtjof[m] has joined #glasgow
disasm[m] has joined #glasgow
thaytan has quit [Ping timeout: 240 seconds]
thaytan has joined #glasgow
bvernoux has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 240 seconds]
thaytan has quit [Ping timeout: 246 seconds]
thaytan has joined #glasgow
Sellerie has quit [Quit: Ping timeout (120 seconds)]
Sellerie has joined #glasgow
thaytan has quit [Ping timeout: 256 seconds]
<d1b2>
<WillC> @whitequark thanks for the insight! @DX-MON do it! I am a horrible programmer and cant contribute much but I would be happy to test anything you come out with!
<d1b2>
<DX-MON> adds it to the project pile
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
oeuf has quit [Ping timeout: 246 seconds]
<whitequark>
esden: got my revC2's
<whitequark>
super happy with the silk
<electronic_eel_>
whitequark: nice that you like it. you were worried before that the section marking silk would be confusing
electronic_eel_ is now known as electronic_eel
<whitequark>
electronic_eel: yep
<whitequark>
i think it was the right decision, especially as i've had to explain a few times basically the exact same thing the silk does
<electronic_eel>
yes, i think the sectioning was a very good idea from esden
<whitequark>
electronic_eel: any objection if i start to pull in commits from your branch?
tomtastic_ has joined #glasgow
tomtastic has quit [Ping timeout: 265 seconds]
<esden>
whitequark: I am happy to hear that it finally arrived, and that you like silkscreen! I hope you have fun with it! :)
<whitequark>
hopefully!
<whitequark>
thanks for the A-C cables too :)
<whitequark>
i'll need those now that i've got a laptop with only one type-C port...
<esden>
whitequark: no problem, you are welcome. :)
<whitequark>
tbh for glasgow i prefer 2.0 only cables, since they are thinner and do not drag it around on my table
<whitequark>
but these will come in very handy as i didn't have any 3.0 A-C cables that actually, you know, work
<esden>
whitequark: I am getting quotes for 2.0 A-C cables to bundle with Glasgows. So there will be plenty of those down the road. (I agree that it does not make too much sense to have a 3.0 cable for glasgow)
<esden>
And I also prefer the flexibility...
<whitequark>
it's not like i can't buy the cables... i'm mostly just whining
<whitequark>
type-C is supposed to reduce the amount of cable types, but i think the amount of cable types i now own has at least doubled
<whitequark>
before: 2.0 A-B, 3.0 A-B (for a camera... which it lives with), A-mB, 2.0 A-µB, 3.0 A-µB (for external hard drives)
<whitequark>
after: all that plus: 2.0 C-C, 3.0 C-C, TBT3 C-C, 2.0 A-C, 3.0 A-C, 2.0 C-µB
<whitequark>
none of which are strictly interchangeable (yes, there are situations where 3.0 C-C specifically does NOT work, which have to do with how android fastboot is implemented)
<esden>
*sigh* yeah indeed... you can also add some, "high current capable" types ... and keep the list going...
<whitequark>
-______-
<whitequark>
at least USB4 has some good decisions, in theory
<esden>
Let's see how it works out in practice. :)
<whitequark>
yep
<whitequark>
one of those is upgrading a lot of existing cables (have i mentioned there are 20 Gbps capable 3.x C-C cables as well? i have ZERO idea if any of mine qualify) to 2x the bandwidth because they improved the link budget with better silicon
<Lofty>
> which have to do with how android fastboot is implemented
<Lofty>
I don't want to know, do I whitequark?
<whitequark>
Lofty: right, so fastboot is sometimes 2.0 only, and adb will use 3.0 if available
<whitequark>
which means that if you have a phone where 3.0 lines are faulty but 2.0 lines work (or maybe a cable)
<whitequark>
it means you can use fastboot but not adb, which is generally bad news
<Lofty>
...Ouch
<whitequark>
Guess How I Found Out
<whitequark>
you also probably want A-C cables if you do a lot of development work with type-C phones because on laptops without Thunderbolt but with type-C ports, sometimes the xHCI would fall off the bus and/or bluescreen your machine
<Lofty>
I don't have any C ports on my Loki-G anyway
<whitequark>
(on both windows and linux, there's some sort of race condition between USB PD, EC, ACPI, and the OS drivers that is present in many configurations)
<Lofty>
AFAICT my phone doesn't have an unlockable bootloader either.
<Lofty>
Well, my old one.
tomtastic_ is now known as tomtastic
<whitequark>
well, not with this attitude :p
<Lofty>
Also I dunno if Sony made the kernel public or not
<Lofty>
Either way, the USB-C plug on it is a bit cunted, so whatever
<d1b2>
<DX-MON> that USB PD, EC, ACPI and OS mix makes me wanna cry wq.. that's horrible
<whitequark>
don't forget that SMM is also involved
<d1b2>
<DX-MON> of course.. because thanks Intel
<whitequark>
it's how you talk through the EC mailbox, according to the instructions in ACPI
<d1b2>
<DX-MON> can the fastboot problem be "fixed" by turning android fastboot off and falling back to a legacy mode of any kind?
<whitequark>
(well, on some machines)
<whitequark>
you don't have any fallback from fastboot because fastboot is like... already a fallback
<d1b2>
<DX-MON> oh.. ohgod.. ;_;
<d1b2>
<DX-MON> so fastboot or bust
<whitequark>
well, fastboot usually works, cuz 2.0 only
<d1b2>
<DX-MON> mmm
<whitequark>
but you flash recovery through fastboot, and now you need to push an OTA update through adb sideload
<whitequark>
and *that* doesn't work
<whitequark>
without any indication as to why
<whitequark>
so if you don't already know why tf it is broken you might never figure out
<d1b2>
<DX-MON> so.. in the case of these fault phones, can you use a 2.0-only cable as a recovery mechanism?
<d1b2>
<DX-MON> *faulty
<whitequark>
(or faulty cables) yes
<d1b2>
<DX-MON> that's.. a relief.. at least, but still iew
<whitequark>
in my case i had a faulty cable AND a faulty phone connector. i think.
<d1b2>
<DX-MON> ouch
<whitequark>
it caused the xHCI controller to thrash wildly and it's a miracle it never crashed my kernel, too
<whitequark>
absolutely incredible
<whitequark>
oh, have i mentioned the thing where plugging an unconnected type-C cable into the type-C port caused my keyboard input to stutter heavily?
<electronic_eel>
may I interrupt the usb lament with some Glasgow question? whitequark, you mentioned i should increase CUR_API_LEVEL. should this be done even if i haven't introduced or changed any control requests yet? just because i introduced a new hw rev or what is the exact criteria?
<whitequark>
oh sure (btw have you seen my earlier Q?)
<whitequark>
regarding API level: increasing it is only necessary if an old firmware won't work with new software
<whitequark>
since there *isn't* an old firmware (because you just now add revC2 support), it's not necessary
<electronic_eel>
then i don't think it is necessary for now
<whitequark>
yup
<electronic_eel>
you can cherry pick stuff from my branch, no problem
<electronic_eel>
i just reserve the right to change my mind about code refactoring a bit as i go on
<whitequark>
fyi i'm going to edit the commits a bit (improve docs and naming in a place or two), i can rebase your branch if you want, or you can do it yourself
<whitequark>
no problem re changing your mind
<electronic_eel>
i prefer to do rebasing myself, otherwise it i have to be more careful when checking stuff in
<d1b2>
<DX-MON> that.. is an astounding mess wq, but I'm not surprised any more based on seeing how design by comittee the whole thing is and how hap-hazardly put together it is as a result
<whitequark>
electronic_eel: ack. i'll try to not make it too hard for you
<d1b2>
<DX-MON> talking of, I need to find a 2.0-mode UPD USB-PD negotation chip that can get me 1.5A@5V on a Type-C port without being an entire micro that I have to program externally or any kind of USB+TB+DP mux thing
<whitequark>
DX-MON: i've been told by some intel people that they plan to get rid of SMM
<d1b2>
<DX-MON> thank goodness
<d1b2>
<DX-MON> though, as long as that's not "to replace it with something else worse"
<whitequark>
which is... both relieving (SMM is horrible) and concerning (SMM is responsible for safety critical functions in laptops)
<whitequark>
no, it's replaced with uh
<d1b2>
<DX-MON> mhm
<whitequark>
"I can't believe it's not ACPI bytecode"
<d1b2>
<DX-MON> X_X
<d1b2>
<DX-MON> of course it is
<whitequark>
a VM under the control of the OS, basically
<d1b2>
<DX-MON> because who didn't need even more vendor-broken ACPI BS in their computer
<whitequark>
which means Linux is now responsible for not destroying my laptop
<whitequark>
and I don't trust Linux to do that
* whitequark
shrugs
<whitequark>
maybe it means vendors have to put more brains into the EC
<whitequark>
which would actually be not that bad, i mean, who doesn't like a safety critical 8051 sitting on the eSPI
<whitequark>
"it's not as bad as relying on linux to not fuck up"
<whitequark>
"I need to find a 2.0-mode UPD USB-PD negotation chip that can get me 1.5A@5V on a Type-C port" ok so
<whitequark>
you don't need to involve USB itself in any way
<whitequark>
and look at stusb4500
<d1b2>
<DX-MON> ty~!
<electronic_eel>
whitequark: re git, let me just clean up the branch a bit and remove the symlink commit we decided against
<d1b2>
<DX-MON> I'll nab from that what I need, way better than parts trawling on Farnell, hoping I can find something suitable and swearing loudly at all the parts I've been finding
<whitequark>
DX-MON: the best thing is parts with an MCU where the vendor pretends it doesn't have an MCU
<whitequark>
"yes, it has firmware. no, it doesn't have a processor in it. no, our configuration tool does not upload Thumb2 code into its flash"
<whitequark>
"no, you can't have docs even though literally every vendor in whose circuits you found our parts has clearly acquired a BSP from us because it sure as hell didn't involve our configuration tool"
<d1b2>
<DX-MON> oh, or worse for me.. "sure, you can have all these GPIO etc.. oh, you needed D+/D- for your own thing? Tough.."
<d1b2>
<DX-MON> esp as I'm highly board space constrained as it's going in an existing design
<d1b2>
<DX-MON> (MXKeyboarD)
<whitequark>
:S
<d1b2>
<DX-MON> ..with a small D
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to wip-revC2-firmware [+1/-0/±6] https://git.io/JkibJ
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel 902cd63 - firmware: implement voltage reading for the INA233
<d1b2>
<DX-MON> I'm building a keyboard that needs more than 500mA.. all I want is to negotiate 1.5A so I don't make a hub have a bad day
<whitequark>
uPD301B? did they buy the part from hitachi?
<d1b2>
<DX-MON> I.. don't know
<whitequark>
oh, "UPD" as in "USB Power Delivery"
<d1b2>
<Hardkrash> The Cypress USB-PD parts are reasonable. not perfect, but programmable. They also have a "Barrel Jack Replacement" part. it incorporates power switching and input protections.
<d1b2>
<Hardkrash> basically look for parts that have 20+ volt tolerant CC protections and such if you use higher voltages, as a cable break can put 20V to a pin you were not expecting.
<d1b2>
<DX-MON> when you say programmable, you don't mean a micro do you? I really want to be able to either set my current and mode via strapping resistors or via sending a few simple commands from my main micro (if I can find the pins to do it with) as part of start-up
<whitequark>
a fellow MCU disliker :)
<d1b2>
<DX-MON> so we don't keep things off topic here, there's a #mxkeyboard channel on the Discord server we can talk over the Cypress parts more
<whitequark>
fwiw PD has a standard-ish I2C configuration interface
<whitequark>
you might be able to use that
<d1b2>
<DX-MON> aye, whitequark, especially when already board constrained
<d1b2>
<DX-MON> huh, ok
<whitequark>
even with an MCU-based PD controller
seraxis has quit [Ping timeout: 240 seconds]
<d1b2>
<Hardkrash> I think USB-PD is reasonable for future glasgow hardware, i would like "high" voltage modes. Think interfacing with 12V and supplying it without a boost, or external power source.
<whitequark>
yes, revE will have PD
seraxis has joined #glasgow
<d1b2>
<Hardkrash> What level of Type-C are you looking for?
<d1b2>
<Hardkrash> Also i recall something about ethernet, was that ethernet over USB or ethernet over a RJ-45 + MAC
<d1b2>
<daveshah> A new ethernet alternate mode
<d1b2>
<daveshah> /me ducks
<whitequark>
Hardkrash: both
<d1b2>
<Hardkrash> ok, POE at all?
<whitequark>
"maybe"
<whitequark>
POE is $$$
<d1b2>
<Hardkrash> I would love it, but I'm in an office with POE ports everywhere...
<whitequark>
i like the idea of POE
<whitequark>
i did not like trying to design power management for it
<d1b2>
<Hardkrash> daughtercard is an answer like with the raspberry PI did.
<whitequark>
yes, it is an option
<d1b2>
<Hardkrash> i wish there was a nice POE module that was hobby friendly.
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to wip-revC2-firmware [+0/-0/±4] https://git.io/Jkijt
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel f46f7bb - firmware: implement initializing and reading alert limits for the INA233
bvernoux has quit [Read error: Connection reset by peer]
fibmod has quit [Ping timeout: 260 seconds]
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JkPv8
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark ab21295 - device.hardware: use hotplug events when waiting for re-enumeration.
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+1/-1/±7] https://git.io/JkPv9
<electronic_eel>
DX-MON: yes, you can now use master and then re-factory your glasgow to C2
<electronic_eel>
whitequark: you seem to dislike my code cross reference comments
<d1b2>
<DX-MON> thumbs-up excellent, thank you
<electronic_eel>
we use this kind of cross referencing ("// should match stuff in <filename>") extensively at $DAYJOB and i really like it
<whitequark>
electronic_eel: oh, i like cross-referencing, it's just that the revision byte encoding was specifically picked to *not* require cross-referencing
<whitequark>
i'm actually not sure if i intended to remove it, i mostly wanted to rephrase it to make that clear
<electronic_eel>
if you change something on one side, you will in nearly all cases also have to change the other. having the exact filename to look at will help IMO
<whitequark>
that is true but you don't change encode_revision at all
<whitequark>
you change GlasgowHardwareTarget for example
<d1b2>
<DX-MON> so, I've upgraded the version of the software I have on my main system and "FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/python3.8/site-packages/glasgow/device/firmware.ihex'"
<whitequark>
DX-MON: hm. are you sure you upgraded it? how did you do it exactly?
<whitequark>
nvm, I confirm that the wheel lacks the ihex file
<d1b2>
<DX-MON> yeah, I did it via bdist_wheel and pip install -U <new.whl>
<d1b2>
<DX-MON> I'm happy for now to just copy the file in from my main working copy, but I figured you should know
<electronic_eel>
it seems to be on github though
<d1b2>
<DX-MON> yeah, the file is present in the repo, just doesn't get put in the .whl and then as a result no installed file
<electronic_eel>
DX-MON: do you have sdcc installed? then you could build you own
<whitequark>
fixed now
<d1b2>
<DX-MON> I can have it installed (Arch, so..)
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JkPJX
<electronic_eel>
but my code is still messy and incomplete, so no checkin tonight
<whitequark>
\o/
<whitequark>
esden: hm, did you pick a different shade of green LED purposefully?
<whitequark>
(I don't even know which one I like more or whether it matters, I just noticed it by accident)
<electronic_eel>
i think esden didn't order the leds from our bom, but just used what he had on hand. i prefer the ones from the bom
<whitequark>
the ones from the BOM look like fresh cucumbers, and the ones esden used look like pickles
<whitequark>
mmmm, pickles
<electronic_eel>
what kind of veggies do the pink ones look like?
<whitequark>
well, it's um, the other way around
<whitequark>
so i was checking crowbar behavior
<electronic_eel>
you mean short circuit and if it recovers properly?
<whitequark>
yes. i actually forgot that crowbaring even revC1 doesn't like... do anything
<whitequark>
it just gets hotter
<electronic_eel>
if you switch both ports to 5v and short them at the same time, the reset triggers (at least on the c1, didn't test c2 yet)
<d1b2>
<OmniTechnoMancer> How badly does the discord<->irc bridge handle discord replies?
<whitequark>
reply to this and i can copy what i get
<d1b2>
<tnt> test reply
<whitequark>
22:59 < d1b2> <tnt> test reply
<electronic_eel>
so just the replied text, no trace of the message that was replied to
<d1b2>
<esden> interesting there is nothing the irc bridge does with this reply information. But I did not update it since the new feature was added to discord.
<electronic_eel>
i really like the reset button on revC2. i have used it a lot in the last 2 days during firmware dev
<d1b2>
<DX-MON> it is super handy isn't it
<d1b2>
<esden> electronic_eel: I used it a ton myself in the first seconds since I brought up the hardware on my desk. I think that was a great addition. It was a brilliand idea @whitequark 🙂
<whitequark>
\o/
<electronic_eel>
esden: also good job of selecting the part, i think it works well, looks like it is robust and won't be a burden to manufacture
<d1b2>
<esden> electronic_eel: 🙂 yey for group effort \o/
<whitequark>
so re crowbaring
<whitequark>
my revC1 does not ever reset for some reason
<whitequark>
my revC2 resets if i crowbar any port at 5V
<d1b2>
<esden> @whitequark regarding the led... I used LED I get from lcsc. For the full production batch we can definitely be more picky with the part choice. But I will not use the ones in the bom as they are like 3x the price from anything LCSC has to offer.
<electronic_eel>
they have a bit different trigger levels due to the different reset ics
<electronic_eel>
esden: we'll have to do a proper brightness matching then with the ones that will be used in the end
<whitequark>
esden: i think the new ones might go a bit better with the white PCB?
<whitequark>
the brightness is definitely different tho
<whitequark>
anyway, using all LEDs from LCSC stock is good, since we use 3 of them from LCSC already in any case
<d1b2>
<esden> @whitequark I am trying to keep the resistor value count to a minimum. The led I have are not as bright as the ones in the BOM so I could get rid of the 20k resistors from the bom.
<d1b2>
<esden> They have 2k2 resistors instead making it close enough in my book.
<d1b2>
<esden> but I am by far much less picky than some regarding led brightness
<whitequark>
lol
<whitequark>
we'll figure something out
<d1b2>
<esden> I just don't find it that important to make production more complicated that is all
<electronic_eel>
we also have to take the case into account. it uses light pipes doesn't it? they will absorb some brightness
<d1b2>
<esden> but yes, I am sure we can figure something out.
<whitequark>
i think we didn't have any resistor values exclusive for the LEDs in the BOM before
<whitequark>
specifically to simplify production
<esden>
and yes indeed, the brightness in the case will be less
<esden>
we just got a quote for the cases, you all will be happy as it turns out they will be less expensive than originally expected
<electronic_eel>
yey
<esden>
about one third of what I originally expected
<whitequark>
wow
<electronic_eel>
that is good new
<whitequark>
what process is this for the case?
<esden>
it is all cnc milled aluminium, anodized, and either laser cut legends or silkscreen legends.
<electronic_eel>
and then you plug in off-the-shelf lightpipes?
<whitequark>
TIL there are off the shelf lightpipes
<electronic_eel>
or are they custom too?
<whitequark>
custom lightpipes sound $$$$$
<whitequark>
so i was wondering
<DX-MON>
hmm, I might, esden, be interested at some point in talking with you about where you're sourcing them from as that sounds like it's almost exactly what I need for MXKeyboard
<d1b2>
<OmniTechnoMancer> Re devices that pretend not to have micros in them, don't you just love uploading firmware to your ethernet phy?
<whitequark>
OmniTechnoMancer: I do not like that.
<d1b2>
<esden> I think @timonsku is considering custom lightpipes, but they will be lasercut so I think it will end up being easy...
<whitequark>
oooh that's really clever
<esden>
sorry for jumping from client to client.. wanted to highlight timon :)
<d1b2>
<OmniTechnoMancer> Over helpful MDIO bus even
<electronic_eel>
OmniTechnoMancer: why don't they offer firmware updates for the magjack too?
<d1b2>
<OmniTechnoMancer> Thankfully transformers do not have firmware yet
<d1b2>
<timonsku> oh hai
<tnt>
esden: you need some kind of light isolation between then though ?
<DX-MON>
heh, interesting esden, I jumped clients because this one is less distracting so I can focus on what's being said easier
<esden>
tnt: no they are visible as separate without any special separation... timon made experiments and it looks goo
<d1b2>
<timonsku> yea off the shelf light pipes would probably me more work than the custom ones, we would have to completely re-arrange the LEDs and I think thats probably not something we wanna do at this point
<esden>
*good
<d1b2>
<timonsku> at the end of the day we just need straight upwards where a normal LED acrylic will probably be enough, so laser cutting that would be super cheap
<electronic_eel>
timonsku: don't you need some mechanical feature to keep them in place?
<d1b2>
<timonsku> they will be press fit
<d1b2>
<timonsku> one sec I can show you the prototype case I milled
<tnt>
esden: mmm, interesting. Curious to see the process, when I tried here with laser cut bits, I couldn't differentiate the leds. (like if only 1 was lit I wouldn't have been able to tell if it was #2 or #3 at a glance for instance)
<esden>
tnt: another thought would be to find laminated lightpipe material
<esden>
that would directly transport the led to the case surface
<esden>
like the fiberous stone stuff
<d1b2>
<timonsku> @tnt I did some early tests, I feel fairly confident that it will work ok but so far I only could test the user leds as they are the only ones that light up by default plus the one yellow led on the status bank. The only alternative would really be to move a lot of components around. I'm not sure how prominent the case will be in all this so not sure how much we wanna touch the design at this point to suite the case. I tried to work as much as I can
<d1b2>
around the current limitations to suit the case the current design.
<whitequark>
timonsku: let me properly wake up and i'll try to deliver a LED testing mode for you
<d1b2>
<timonsku> thanks! that would be awesome 🙂
<whitequark>
esden: electronic_eel: fwiw i think "reset on crowbar" is probably better than "no reset on crowbar"
<whitequark>
in fact we should probably set up INA233 to turn off Vio on gross overcurrent
<d1b2>
<timonsku> @electronic_eel thats just normal acrylic that I cut out. Mind that this is just spray painted acrylic for testing, the actual case will not look like this.
<electronic_eel>
whitequark: i plan to properly characterize the reset behavior and compare it with revC1
<d1b2>
<timonsku> the fit has to be good of course but if you laser cut it that can be easily fine tuned to have a nice press fit
<whitequark>
lmao @ the capacitor
<whitequark>
this looks incredibly silly. i love it
<whitequark>
electronic_eel: yup, sounds good
<esden>
I love the cute cap peeking out!
<whitequark>
i was just curious
<whitequark>
we probably shouldn't ship it like that but it's cute
<d1b2>
<timonsku> yea its still up to debate to keep it or not I guess but yea, I feel very similar about it, its very silly but I love the character of it 😄
<d1b2>
<tnt> Are cap body isolated ?
<electronic_eel>
tnt: yes, I just measured
<electronic_eel>
...same thoughts as you
<esden>
ahh good... I was about to say...
<d1b2>
<timonsku> I would love to just have two smaller caps to not increase thickness though, there is otherwise a conflict with accessibility of the sync cable connector
<electronic_eel>
I think getting two smaller caps will be difficult if we want to keep polymer and 10v
<electronic_eel>
there aren't many in 10v out there
<electronic_eel>
with 6.3v the choice is much larger
<d1b2>
<tnt> @timonsku Ah yeah, I see your llight pipes are much shorter than in my attemps (I was going up to the connectors top) which probably helps a lot keeping the leds separate.
<d1b2>
<timonsku> I tried a few LED diffusor acrylics from work, was promising but have to actually test with a case first, though even the normal acrylic in the prototype above worked quite ok. Key is that the sides stay glossy so the reflect when looking at it from the side, which would be the case when laser cut.
<electronic_eel>
it would be nice if there were an optical equivalent to the zebra strips available
<d1b2>
<tnt> There is
<d1b2>
<timonsku> that would be proper lightpipes, the isolate each led quite well :) but they are also a lot larger and need more space
<d1b2>
<tnt> optical fiber block that just "shift" the optical plane.
<d1b2>
<timonsku> hah yea or that 😄
<electronic_eel>
timonsku: the photo with the acrylic looks very promising i'd say
<d1b2>
<tnt> I think they're $$$ though
<d1b2>
<timonsku> yea think so too, looks even much better in real life, phone cam couldn't capture it well
<d1b2>
<esden> heh ... this is the laminated material I meant earlier...
<electronic_eel>
timonsku: you were running the glasgow without firmware (ICE led off). this means this was just the low brightness of just the pullups on the user leds
<d1b2>
<timonsku> ah nice, I was wondering if they could be brighter
<electronic_eel>
so should be much brighter if they are properly on
<d1b2>
<OmniTechnoMancer> Do the status LEDs have two same colour LEDs next to eachother?
<d1b2>
<timonsku> the brighter yellow status led was much nicer
<d1b2>
<esden> @timonsku ohh I am sorry... I should have told you that they are brighter when actually turned on.
<d1b2>
<timonsku> yea that would also be my question, while you do get a decent sense of position I think it would be a lot less clear
<d1b2>
<OmniTechnoMancer> Yea that is my worry
<electronic_eel>
timonsku: did you try to run the selftest? while it will give an error message, it will also switch on the user leds
<d1b2>
<timonsku> couldn't get the toolchain up and running so far, some python packages were either borked or didn't install
<d1b2>
<timonsku> but I didn't try all that much yet and my Linux install got broken when I did the stupid thing of upgrading it...
<d1b2>
<esden> @timonsku I recommend that you create a venv and then install glasgow framework in there.
<whitequark>
timonsku: very interested to hear about the details of breakage
<whitequark>
i agree with esden, venv is the way to go
<d1b2>
<esden> That will help with handling of breakage.
<whitequark>
(sadly debian fucks up even venvs...)
<d1b2>
<esden> @whitequark ugh...
<d1b2>
<timonsku> yea sorry, I wanted to report but then I upgraded and don't think I can recover. I could try running it in the current broken state, I think its mostly the window manager that got fucked
<whitequark>
timonsku: you can just copy paste the error for me to look at
<electronic_eel>
currently we have PWR green, FX2 green, ICE green, ACT yellow, ERR red. we could either use a different color for FX2 to not have the same colors next to each other or reorder the status leds
<esden>
electronic_eel: Do you have any alternatives you can propose for 652-CDSOD323-T36S? I am getting the first quote responses for the parts package and at least Mouser is grumbling that the availability of that part is "problematic"...
<electronic_eel>
esden: ouch
<esden>
we both already saw that the SC variant was so easy to get that we both misordered :P
<electronic_eel>
i have used the other variants on this series to great success on other projects, so this one was like an instant pick because of that
<electronic_eel>
i haven't really looked around for alternatives
<esden>
OK... what are your most important parameters on this part and I will let them provide us with alternatives if you are ok with that.
x56 has quit [Quit: Ծ-Ծ]
<d1b2>
<OmniTechnoMancer> What does that part do?
<electronic_eel>
36v reverse standoff voltage, unidirectional, low capacitance, not too large case
<electronic_eel>
it is a tvs diode that protects the sense pin
<d1b2>
<OmniTechnoMancer> Ah
<electronic_eel>
we now have a new adc (INA233) that is capable to sense up to 36v
<d1b2>
<timonsku> ok nice the install wasn't that broken, could still login and run. Error is the same as before (at least I think so) https://pastebin.com/AYnssX7v
<electronic_eel>
so we don't want to waste that capability by choosing a tvs with much lower voltage
<esden>
electronic_eel: I would say one constraint is to keep it in the same package so we don't have to alter the pcb. I will add the other constrains too.
<d1b2>
<OmniTechnoMancer> How much is that relatively large plastic optical fibre type stuff that gets used in toys?
<electronic_eel>
low capacitance because it would be nice being able to hook it onto a signal pin without distorting the signal too much
<d1b2>
<timonsku> @whitequark see above for log output
<d1b2>
<timonsku> ah heh, yea I was in the process of upgrading to 20.04
<d1b2>
<timonsku> so with 3.8 it should work?
<whitequark>
it... doesn't directly have much to do with 3.8
<electronic_eel>
esden: we already have done a few changes to the revC2 pcb. so a bit different footprint for the tvs isn't that much of an issue i'd say
* whitequark
sighs
<whitequark>
timonsku: yeah, try it
<esden>
electronic_eel: don't be so mean to wq ;)
<esden>
We both are already causing so much grief with our tweaky changes. :)
<whitequark>
timonsku: you can also just comment out all bitarray imports
<whitequark>
i'll get rid of it for good soon™, but not yet
<whitequark>
esden: eh, it's fine, i already decided to change the policy
<electronic_eel>
esden: so far the revC2 is living up to all expectations, so no reason for grief
<esden>
electronic_eel: quick knock on wood!
<d1b2>
<Hardkrash> There are some many details on getting mass production working. just be glad that you don't have second or third vendor requirements for your components.
x56 has joined #glasgow
<whitequark>
thankfully we aren't building hardware for DoD
<esden>
whitequark: or are we?... :P
<electronic_eel>
glasgow missile control
<whitequark>
well not any more than any other OSHW project...
<esden>
electronic_eel: suddenly we find out in 20 years that they used glasgow to hook up an old drive to something.
<whitequark>
oh, i would be completely unsurprised if DoD already uses some code i wrote.
<esden>
same :/
<whitequark>
i know DA does. not completely certain about DoD. not that there's a lot of difference.
<electronic_eel>
they use it in 20 years to reverse some old gear because they have no docs because the vendor went out of business
<whitequark>
this is being very optimistic about the ability to run 20 year old python code that uses USB :p
<electronic_eel>
by then glasgow is the de facto standard hw reversing tool ;)
<esden>
electronic_eel: do you have some more specific metric for "low capacitance"? ie "it should be under xpF capacitance"
<d1b2>
<timonsku> ah are we looking for caps alternatives? 🙂
<d1b2>
<Hardkrash> I don't want this just for reversing, but for creating as well!
<whitequark>
i haven't actually done much RE
<whitequark>
i think the JTAG stuff is the part most particularly suited to RE at the moment
<d1b2>
<esden> @timonsku no, at the moment trying to find an easier to source ESD prodection diode.