ender| has quit [Quit: “Hey, I don’t think Tristan has actually killed any deities yet.” I winced. “…I certainly hope he hasn’t.” — Andrew Rowe: The Torch that Ignites the Stars]
bvernoux has quit [Read error: Connection reset by peer]
Stephie has quit [Read error: Connection reset by peer]
Stephie has joined #glasgow
modwizcode has joined #glasgow
<whitequark>
Attie: likely going to go over the slides today
<d1b2>
<Attie> @whitequark ok, thanks! ... only minor changes and continuation since what I sent you. I'll share if I can get to a computer in time
<_whitenotifier>
[glasgow] electroniceel commented on issue #221: Qualification tests for revC2: post INA233 - https://git.io/JLhlH
<_whitenotifier>
[glasgow] electroniceel commented on issue #221: Qualification tests for revC2: post INA233 - https://git.io/JLhRv
<d1b2>
<zipferli> Hi, has someone already tried soldering a USB4105 socket onto the USB-C footprint of the RevC2 board by any chance? From the drawings it looks like it should fit, though the footprint doesn't exactly match the recommended one (The PTH for the shield contacts are .2mm short) Alternatively, are there any known options sourceable from the likes of mouser/digikey? I'd hate to place an LCSC order just to have a single part shipped to me accross the globe
<electronic_eel>
zipferli: i wouldn't worry too much about the pth contacts, they are about the same and should fit
<electronic_eel>
but have you checked the pinout of the data pins? iirc, there was one connector at digikey that looked like it would match, but one data pin pair was swapped
<d1b2>
<zipferli> From my understanding the pinout appears to be identical, though I'll make sure to double and tripple check now that you've mentioned it. 😄 Haven't ordered the PCBs yet luckily, so thanks for pointing that out! Looks like the BOM will be mostly untouched though besides maybe the I2C issue and LEDs?
<electronic_eel>
bom will be mostly untouched, it will most probably just be a resistor and capacitor for the filtering of the ADC that will be changed
<electronic_eel>
the new revC3 pcb will have to be ready soon, because there are some people out there waiting for their early bird pcbs...
<d1b2>
<zipferli> I'll keep an eye on it. On the github it says one should only try RevC1 for self assembly, is there a specific reason for that?
<d1b2>
<Attie> @zipferli because revC2 has a bug and firmware support isn't finished, revC3 isn't done yet.
<d1b2>
<zipferli> I see, thanks. If I end up finishing my board, is there some donation page to support the developers of this project? I don't want to take away from them, it's just that I enjoy the assembly process so the crowd supply thing did not fit me that much.
<electronic_eel>
now the firmware is not really an issue, there is already a PR in the latest stage of being merged
<electronic_eel>
whitequark has a patreon
richbridger has joined #glasgow
<d1b2>
<zipferli> Awesome, thanks
<_whitenotifier>
[glasgow] electroniceel commented on issue #221: Qualification tests for revC2: post INA233 - https://git.io/JLhur
<alen>
hi
<electronic_eel>
alen: hi
<sorear>
10001 boards…
<sorear>
*1001
<electronic_eel>
?
<electronic_eel>
oh, the campaign
DarthCloud has quit [Read error: Connection reset by peer]
DarthCloud has joined #glasgow
siriusfox has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
<_whitenotifier>
[glasgow] electroniceel commented on issue #221: Qualification tests for revC2: post INA233 - https://git.io/JLhra
<electronic_eel>
if Glasgow didn't exist yet, it should be invented: accessing i2c random devices is just so much easier with it
<electronic_eel>
for my qualification test i had to communicate with a INA233 on a protoboard
<electronic_eel>
in the past i would either have wired up a STM32 and wrote a short firmware snippet, or used the bus pirate with it's complicated commandline syntax
<electronic_eel>
now i could just use the script mode from glasgow and mix the register access with python code
<electronic_eel>
that is waaay faster and more convenient than any of the other methods
<kmc>
yeah I'm super excited about that :)
<whitequark>
electronic_eel: :D
<kmc>
programmatic use of the bus pirate is a total afterthought, which was one of several reasons i found it a disappointing product
<whitequark>
it brings me joy to see people just... do what they want more comfortably with my tools
<kmc>
but obviously it doesn't support the plethora of buses and protocols that Glasgow does
<kmc>
adafruit have written compatibility library so that you can use that board from Python code on a PC the same way you would use RPi GPIOs from Python code or uC GPIOs from CircuitPython, and all their sensor libs work with it
<kmc>
it would be cool to integrate that with Glasgow too
<electronic_eel>
kmc: i haven't looked at their sensor libs yet and how they work, but i guess you could write a python wrapper that accomplishes that
<kmc>
I might give it a go, once I have my Glasgow
<electronic_eel>
that would be welcome
<kmc>
:D
emberian_z has quit [Quit: FIN]
emberian_z has joined #glasgow
<kmc>
they also have a physical connector spec for I2C called STEMMA QT (compatible with SparkFun's Qwiic) based on a JST SH 4-pin connector
<kmc>
and it would be easy to make a cable which plugs into a Glasgow port and provides one (or four) of those
<kmc>
the only thing i'm not sure is whether the glasgow Vio pin can source enough current to power all the peripheral boards they sell which use that connector
<electronic_eel>
hmm, just looked at the MCP2221A. could it be that it is a PIC16F1455 with some pre-programmed firmware?
<kmc>
don't know
<kmc>
i haven't used it a ton
<kmc>
just plugged in my sensors and confirmed i could read them from python code
<electronic_eel>
just looked at this stemma thing, it is JST PH, that is 2.0 mm pitch. SH would be 1.0mm and really a pain
<electronic_eel>
so you'd just need a 4-pin PH to 2.54mm flywire patch cable, or maybe a dedicated thing that plugs into the glasgow ports
<electronic_eel>
hmm, i tried these SH connectors and didn't like them. i settled on molex picoblade (1.25mm) when i want something in this size ballpark
<electronic_eel>
the picoblades are more common and i also really prefer crimping them to the JST SH
<gruetzkopf>
my random i2c device driver of choice was always the nearest non-displayport computer display connector combined with i2c-dev
<gruetzkopf>
(dp++ in hdmi mode counts as non-dp for this purpose)
<kmc>
whoa, that works?
<kmc>
it's possible to use a VGA port on Linux as a general purpose I2C port?
<kmc>
that's awesome
<kmc>
(seeing as I am typing this from a Linux laptop with a VGA port)
<cyrozap>
Yup. I've done it to reprogram those RTD266x LCD driver boards--just plug in the VGA/HDMI cable, point flashrom to the right I2C bus, and flash away.
<gruetzkopf>
yup - it also should work with tunneled i2c over displayport (even for multistream!)
<gruetzkopf>
(tunneled i2c is absurdly slow for short reads though)
<electronic_eel>
hehe, didn't think of using the monitor cable
<d1b2>
<Attie> thinking on a tangent... we should probably produce an EDID applet
<electronic_eel>
isn't that a bit risky? you'd fry your graphics card or your whole mainboard if something goes wrong
<electronic_eel>
i really prefer having glasgow for this kind of stuff now.
<d1b2>
<Attie> @electronic_eel - i was meaning to pull the EDID data out of a monitor, rather than connect glasgow to PC
<electronic_eel>
with "fry your graphics card" i meant using the graphics card as i2c adapter, not your edid applet
<electronic_eel>
an edid applet for glasgow would be useful, i concur
<gruetzkopf>
memory-24x and edid-decode is a good workaroud
<d1b2>
<Attie> ah, isee
<electronic_eel>
an edid emulator could also be useful
<sorear>
they make graphics cards that are cheaper to replace than glasgow
<electronic_eel>
but glasgow isn't as easily fried as a graphics card i guess
<electronic_eel>
how big are edid memories?
<d1b2>
<Attie> not big iirc
<d1b2>
<Attie> few-hundred KiB
siriusfox has joined #glasgow
<d1b2>
<Attie> oh, way less... oops... ~2 KiB
<d1b2>
<Attie> use an M24C02 on a project a while ago
<electronic_eel>
ok, that would still fit into bram, so an emulator would be feasible
<d1b2>
<Attie> the "core data" is tiny... extended data can get a bit larger
<electronic_eel>
we should really think about designing a hyperram addon for the lvds port. then all these flash/eeprom emulators, display buffers for your led panels and so on would become much easier
<d1b2>
<Attie> that could be pretty shiny
<electronic_eel>
don't know if we have enough height left to be able to squeeze it under the aluminium case
<electronic_eel>
@timonsku could you do me a favor and measure that in your cad model? the clearance above the end of the pins of the lvds connector to the case
<d1b2>
<timonsku> with the connector soldered or pads to top? with the connector in place you can not fit anything else there, there is just enough space so you can still use the case should you choose to solder that connector yourself
<d1b2>
<timonsku> I could make a bit more space though now that the thickness is increased
<electronic_eel>
i think the glasgows manufactured by esden will have the lvds connector soldered on
<d1b2>
<timonsku> just the prototypes, at least thats my last status, the production units will not have it in place afaik
<electronic_eel>
1.2mm space above the end of the pins should be enough for a 0.8mm pcb
<electronic_eel>
oh? didn't know about that. i thought the lvds connector will be on all the pcbs, just the headers for the pull resistors will not be soldered
Ghostibles has joined #glasgow
Ghostibles has left #glasgow [#glasgow]
<electronic_eel>
that picture is with the female part of the connector on, right?
<electronic_eel>
there are different variants of the female connectors available, higher ones and flatter ones
<d1b2>
<timonsku> ok just checked with him, they will come with the connector populated
<agg>
you can even get connectors that have holes all the way through and the header pins can go right though, even through holes in the pcb
<electronic_eel>
ok. would also have been strange to show it on the campaign page with the connector and then deliver without...
<agg>
becomes a pain to route out at that point but in theory a mated pcb could take up no extra height than the bare pins
<d1b2>
<timonsku> thats the male part that sits on the PCB
<agg>
(samtec CLM with BE option for example)
<d1b2>
<timonsku> the blue marked part is the pocket that is milled out to accomodate it
<electronic_eel>
timonsku: now i'm really confused
<agg>
the case is upside down in the render i think