egg|anbo|egg has quit [Remote host closed the connection]
m42uko has joined #glasgow
d_olex_ has quit [Read error: Connection reset by peer]
d_olex has joined #glasgow
GNUmoon has quit [Ping timeout: 240 seconds]
jstein has joined #glasgow
<fest>
@esden: regarding the ram-pak design: for the differential clock, shouldn't there be a parallel resistor after the series resistors?
<fest>
or is the differential clock connection provided "just in case" and single ended clock is what is supposed to be used?
<fest>
also, the P/N for 1.27mm socket is probably incorrect, as it refers to a pin header. did you intend to use CLP-122-02-F-D-BE?
GNUmoon has joined #glasgow
FireFly has quit [Killed (grumble (My fellow staff so-called 'friends' are about to hand over account data to a non-staff member. If you care about your data, drop your NickServ account NOW before that happens.))]
FireFly has joined #glasgow
siriusfox_ has joined #glasgow
siriusfox has quit [Ping timeout: 240 seconds]
GNUmoon2 has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
emilazy has quit [Ping timeout: 260 seconds]
analprolapse has quit [Ping timeout: 260 seconds]
alanvgreen has quit [Read error: Connection reset by peer]
alanvgreen has joined #glasgow
emilazy has joined #glasgow
analprolapse has joined #glasgow
<electronic_eel>
fest: the socket of the ram pak is a tricky thing, because it is planned to fit into the closed aluminium case. height is really critical there. so esden plans to use a custom header he found at some asian manufacturer. iirc he plans to sell the bare connectors in his shop once the ram pak is available
<electronic_eel>
so i think he didn't really care about putting in a p/n which isn't properly selected yet
FireFly has joined #glasgow
FireFly has quit [Changing host]
umarcor has joined #glasgow
anuejn has quit [Remote host closed the connection]
<d1b2>
<icb> You would need to bypass the voltage regulator on the ram-pak board, but otherwise I think it should work. The 3.3v part is slower (100MHz instead of 166MHz)
<electronic_eel>
fest: 3v3 hyperram has a higher current consumption than 1v8. so the 3v3 rail will see more load and the ram might get hotter. but i don't know if that will become a problem, i don't think it was tested yet.
<d1b2>
<icb> Those antennae may cause some signal integrity problems, but worth a try since you already have everything
<electronic_eel>
oh, yeah, the signal lines will emit more emi at 3v3 than at 1v8
<d1b2>
<icb> Also be sure to feed 3.3v back to the Vref pin
<fest>
icb: good catch, I also realized it seconds ago
<d1b2>
<icb> Also, AFAIK only the hardware side has had any work so far. There's no support in the Glasgow software or gateware currently
<fest>
yeah, that I've already prepared myself for :)
<tnt>
In theory I should get a ram pak soon (I hope in time for the weekend) and I'll definitely try to push it to max freq, see how it works out.
pinoaffe has quit [Quit: Bridge terminating on SIGTERM]
pinoaffe has joined #glasgow
<electronic_eel>
whitequark: any plans to move the glasgow channel off freenode? I know you don't like sysadmin chores, but there seems to be a hostile takeover of freenode. and the new owner seems - sketchy at best. see for example marcans tweet here https://twitter.com/marcan42/status/1395053658182619137
veisenhart1[m] has joined #glasgow
eddyb has left #glasgow ["User left"]
egg|anbo|egg has joined #glasgow
<whitequark[m]>
electronic_eel hmm
<whitequark[m]>
at some point
<electronic_eel>
currently a lot is still in flux of course, but i think planning a bit ahead won't hurt
<whitequark[m]>
planning what exactly? once a clear successor network emerges we move there
<electronic_eel>
registering channels for example. when a clear successor network is established, #glasgow might already be gone there
<electronic_eel>
at libera.chat for example #glasgow already exists. op is "V". i don't know if it is someone from here who wants to cede control to you
<whitequark[m]>
ask them
<electronic_eel>
ok
<whitequark[m]>
if libera.chat wants to be a successor network they're going to have to respect existing project allocations from freenode
<whitequark[m]>
and not just have a free-for-all mess
<tnt>
note that, if it turns out they don't cooperate, single # are reserved for projects and so you can contact libera ...
<electronic_eel>
but their admin staff will currently probably be very busy. so going that route might take a lot of time
<tnt>
yes probably ... they sure have a lot of work ahead of them in the coming days.
<ebb>
from speaking to one libera staffer, handling requests like "can I have my channel back plz" are something they're expecting in the short term. registering as a project with libera, if that's chosen as the next place for Glasgow, would lodge that request nicely (and make sure it's not lost, since it's an email) IMO
<whitequark[m]>
alright
<whitequark[m]>
i'll see what i can do
<whitequark[m]>
does matrix have a libera bridge yet
<electronic_eel>
not sure about the matrix bridge. i hope they also remove the inactivity timeout requirement / policy when they create it.
<electronic_eel>
i have contacted the op V at libera, but haven't got an answer yet.
<whitequark>
anyone has opinions on logger domain?