<whitequark[cis]>
since we don't really have any feedback on whether Vio is above or below some threshold (1V I suppose) there needs to be a delay in the firmware that's enforced before resetting the FPGA
<whitequark[cis]>
well, turn off Vio -> delay -> reset FPGA
<whitequark[cis]>
what should this delay be?
<tpw_rules>
do you want us to check the decay on our glasgows?
<whitequark[cis]>
yeah, and also try to calculate it theoretically if that's feasible
<whitequark[cis]>
I'm not completely sure what is it driven by
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<sorear>
at 1.1–1.4V the pca6408a enters a power-on reset state, which might be observable over i2c, might be useful information, and might also affect #283 (it would be a problem if the pulls didn't work at 1.2v?)
<whitequark[cis]>
interesting
<sorear>
counting the capacitors gives 14.7µF / 1.1kΩ on VIO -> 37ms for 5V to 1V with a 20% margin -> closed loop control won't make it noticably faster for humans
<whitequark[cis]>
oooh
<whitequark[cis]>
that's really exciting
<whitequark[cis]>
1.1k of ESR?
redstarcomrade has quit [Read error: Connection reset by peer]
<sorear>
R41 and R57
<sorear>
actually 5.7uF -> 15ms, misread "u1" as "1u"
<sorear>
rated ESR at 1kHz is 2Ω for the 4.7µF and 30Ω for the 10x0.1µF, negligible
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<whitequark[cis]>
so... the fix is that on revision C up until C4, the LDOs are turned off before flashing the firmware, and a 15ms (is that with margin?) delay added?
<Wanda[cis]>
you mean before resetting FPGAs?
<Wanda[cis]>
s/FPGAs/FPGA/
<whitequark[cis]>
yes
<whitequark[cis]>
sorear: can you check revisions C0 through C2 and also A0 and B0?
<gsuberland>
whitequark[cis]: "since we don't really have any feedback on whether Vio is above or below some threshold" could you use the INA223s for that? they read both voltage and current coming from the TPS73101 regulators
<gsuberland>
*INA233
<whitequark[cis]>
gsuberland: oh, right!
<gsuberland>
that also allows you to check if the user is providing their own VIO
<whitequark[cis]>
that's... not something we actually support
<whitequark[cis]>
but it could happen
<gsuberland>
ah actually hang on
<gsuberland>
I forgot that the INA233 Vbus line is connected to pin 1 on the connectors so it can be used as an arbitrary 0-30V ADC, it isn't necessarily bridged to VIO
<gsuberland>
so unfortunately the INA233 can't be used to measure VIO since we don't know that it'll actually be connected to VIO
<whitequark[cis]>
can it measure Vin+?
<gsuberland>
the INA233 Vbus pin (that does the voltage measurement) just goes to pin 1 (VSENSE) on each of the port connectors. by default it isn't connected to anything at all.
<whitequark[cis]>
yes, what I'm asking if INA233 can measure single-ended Vin+
<whitequark[cis]>
since it's measuring the current on the high side using a differential input on a shunt
<gsuberland>
oh, I don't believe so no
<gsuberland>
iirc the idea is Vbus does the voltage measurement, IN+/IN- do the differential current measurement, power separately comes in via VS
<gsuberland>
but there may be a workaround here. there are some known pulldown resistances on VIO so there's always some small current flowing when VIO is enabled. if the INA233's current measurement range can be scaled sufficiently low, it may be possible to detect VIO voltage with some confidence by proxy from that leakage current
<sorear>
15ms includes a 20% margin for off-nominal resistor and capacitor values, it does *not* include anything to allow for capacitance internal to the ICs or other factors not visible on the schematic. this applies to revC1, revC2, and revC3 (revC1 uses a 1k pulldown instead of two parallel 2k2 pulldowns)
<sorear>
#552 as written is inapplicable to revA/revB since FXMA108 does not have DIR. the output becomes high impedance if /OE is high, which seems to be connected to iobuf_enable()
<whitequark[cis]>
ah right
<whitequark[cis]>
so on revAB this can be fixed robustly (as much as anything related to FXMAs is robust), revC123 we can wait a bit, revC0... is kind of fucked
<sorear>
revC0 is the hard case since it doesn't have the 1k VIO drain, it has to drain through the regulator feedback resistors which gives 930ms with the same margin calculation. this can likely be improved by forcing one or more of the 10k pullups to be continuously used (if you don't want to touch the "user" pulls, it would have to be via the VIO I2C pulls, saturating the bus with requests to the I/O expander might do it)
<whitequark[cis]>
I think I'll just wait one second
<whitequark[cis]>
messing with I2C has a high chance of causing regret
<sorear>
it sounds like revAB will go directly to high impedance during reconfiguration while revC will continue to drive the port at gradually lowering voltage over ~10ms until the drivers cut off, I can imagine this still being surprising in some cases
<whitequark[cis]>
well, what do you expect to happen when you're reconfiguring the FPGA live?
<whitequark[cis]>
it's clearly "something weird" but it also can't be "too weird"
<whitequark[cis]>
turning inputs into outputs that drive high is definitely "too weird", but aside from that and "Vio gets higher than it was before" i'm not sure if anything is too weird.
_whitelogger has joined #glasgow
<gsuberland>
accounting for the resistor network formed by R28, R29, R41, R57, and assuming that both VDAC and the OUT pin of the voltreg are of infinite impedance during the measurement, I'm seeing 1.08k pulling VIO to GND per rail on C3. so the completely passive leakage visible to the INA233s when VIO is >1V should be 925uA nominal (so 890uA minimum if we say 5% tolerance on the resistor values)
<gsuberland>
so if you pull an INA233 current measurement and see more than a milliamp, that tells you VIO is on.
<whitequark[cis]>
so here's the thing. if something else is connected to the board, Vio could be high without INA233 seeing it
<gsuberland>
but the leakage would remain
<whitequark[cis]>
e.g. large amounts of bulk capacitance, or straight up power supply
<whitequark[cis]>
oh?
<gsuberland>
oh right but yes the current would be going not to the regulator, I see what you mean
<whitequark[cis]>
doesn't INA233 measure current flowing out of the LDO's output
<gsuberland>
yeah
<whitequark[cis]>
shutting down the LDO is the easy part
<sorear>
if I'm using this for noninvasive monitoring of a circuit, revAB will allow me to reconfigure while connected to the DUT, revC0123 pulls all of the pins I'm monitoring low for 15ms every time I reconfigure
<sorear>
probably an unavoidable limitation of revC0123 that needs to be documented
<whitequark[cis]>
how would it do that
<whitequark[cis]>
those 15ms lapse before the FPGA is reset
<whitequark[cis]>
so your pins are all configured as inputs that entire time
<whitequark[cis]>
the level shifters have this:
<whitequark[cis]>
> VCC isolation feature – if either VCC input is at GND, both ports are in the high-impedance state
<sorear>
so for an *unpowered* DUT the proposed fix will guarantee that inputs stay inputs
<whitequark[cis]>
I do not understand the first part of the clause
<whitequark[cis]>
if you are non-invasively monitoring a DUT, it doesn't matter whatsoever whether it's powered or not
<sorear>
if the DUT contains its own source of energy driving Vio, then the shifters will still be active after the 15ms grace period and they'll swap to outputs immediately when the fpga resents
<whitequark[cis]>
how did you conclude that driving Vio is acceptable?
<gsuberland>
ah dang. there's an internal 80k pulldown to ground inside the TPS73101 LDOs as part of the error amplifier feedback (figure 2 in the datasheet), so with it disabled it would be a leakage path back through the sense resistors, but the current measurement range is 546mA so 1LSB is 16.6uA... and the pulldown would be 12.5uA. so that won't cut it.
<sorear>
was that not what "large amounts of bulk capacitance, or straight up power supply" meant?
<whitequark[cis]>
if you are non-invasively monitoring the DUT you do not connect Vio at all
<whitequark[cis]>
you only connect Vsense. so by definition there's nothing like that connected to Vio
<whitequark[cis]>
it's quite invasive to power a DUT from the device you're testing it with!
<sorear>
that makes sense
<whitequark[cis]>
supplying power to Vio is unsupported for, at the very least, this reason (but will not damage the device provided it stays within the AMR), and connecting large amounts of bulk capacitance is sometimes unavoidable in which case we can't do anything about it
<sorear>
large amounts of capacitance is still an issue since it could extend the length of time required for vio to dischange
<whitequark[cis]>
yep
<whitequark[cis]>
I don't think there's anything we can do about it without regressing other things (e.g. the I2C shenanigans fall under that category)
<whitequark[cis]>
although... hm
<sorear>
the intent for revC4 is to switch to DIR=high=input shifters, so that Vio remains stable across a FPGA reconfiguration, there's no added delay, and the I/Os become inputs for the duration of the reconfigure?
<whitequark[cis]>
the intent for revC4 is to do something about it
<whitequark[cis]>
I dunno what and I don't care too much at this point since Piotr is going to be shipping thousands more of revC3's
<whitequark[cis]>
so, what i can probably do is to poll for S ADR|W NAK P and at the point where I start actually getting NAKs I know Vio is low enough
<gsuberland>
fwiw the 80k divider network inside the TPS73101 do give you enough back-flowing current into the IC that if you leave the INA233 in the same config you use for current measurement normally, you'll get a reading of at least -1 (the INA233 is bidirectional) when VIO is at 1.28V or higher
<whitequark[cis]>
oh, interesting
<gsuberland>
so if you put it in the longest integration mode (8.244ms) and still see any negative value, there's voltage on VIO
<whitequark[cis]>
we don't actually have any code that reads current from INA233 I think
<whitequark[cis]>
also this doesn't cover revC1
<gsuberland>
it's at least a nice safety check to have for cases where someone's stuck something heavily capacitive on VIO, I guess
<gsuberland>
and solves it for C3 which is the one most people have aiui
<whitequark[cis]>
the I2C polling also solves that and works on revC1 as well
<whitequark[cis]>
at similar voltage threshold even
<whitequark[cis]>
so revC0 is actually just, like, kind of fucked?
<whitequark[cis]>
IIRC you can't really use it due to the level shifter bug
<whitequark[cis]>
like, you can use one port out of two
<gsuberland>
I also think the 80k ohms is actually guaranteed to be pretty precise on the adjustable voltage variant of that LDO, since it's part of the feedback network. but it's late so don't quote me on that
<gsuberland>
on the fixed version it's only the divider ratio that matters but it looks like the fixed one actually needs it to be 80k fairly precisely for proper regulation
<gsuberland>
*it looks like the adjustable one
GNUmoon2 has quit [Remote host closed the connection]
<sorear>
remind me what the "level shifter bug" is?
GNUmoon2 has joined #glasgow
<whitequark[cis]>
it has two TCA9572's back to back
<whitequark[cis]>
you can't connect them with VCCB sides facing each other or they start to wildly oscillate breaking everything
<whitequark[cis]>
I think as long as you never actually use the pulls on revC0 you're fine
<gsuberland>
here's something interesting that might be worth testing. if you turn the VFB DAC up to its full 3.3V max voltage, you should be able to push ~18uA back through the TPS73101's output (U20 VDAC -> R33 -> VFB -> R34 -> VIO -> R49 -> R56 -> U32 OUT -> 80k to GND). if you test this with VIO off (i.e. VIO known to be fully at 0V), turning the DAC from 0V to 3.3V and measuring the INA223, you should
<gsuberland>
be able to tell if it can reliably detect that 1LSB of leakage (16.6uA)
<gsuberland>
if it can, then you can exploit the VFB DAC here to help. for example, assuming the INA233 is pretty reliable at detecting exactly -16.6uA of current as -1, you can turn the VFB DAC to something like 1.65V, so that it applies a "static" current flow of -9uA into the LDO output pin
<gsuberland>
wait actually no, I need to think about this more
<gsuberland>
tired me missed a step in the analysis
<gsuberland>
the initial test idea is valid though, with VIO known to be off, purely as a check to see if the INA233 can reliably detect -18uA back-flow into the regulator (and that 80k is actually the resistance to ground inside the LDO)
<whitequark[cis]>
so, wanna test that?
<whitequark[cis]>
(I don't have time to mess with it. I only have time to write 8051 C)
<gsuberland>
no guarantees (busy with EMF prep + also super ADHD lol) but I'll at least sleep on it and see if I can figure out whether there's merit to the VFB DAC ideas I've got bouncing around
<whitequark[cis]>
basically, I'm not going to be doing hardware testing for this issue, so any interested parties will do their own and then I can write a fix
_whitelogger has joined #glasgow
<gsuberland>
just looking at the firmware docs: "to develop the firmware on Windows, use WSL" - is that actually viable for loading the firmware onto the device, or just for building the binary firmware image?
<gsuberland>
(I don't currently have a Linux machine handy here)
<gsuberland>
or is there already some way to get the INA233 readings off a Glasgow so I don't need to touch the FX2 firmware?
<gsuberland>
hmm, I'm guessing not actually given that I'd need to also adjust the DAC while VIO is off
<whitequark[cis]>
gsuberland: yes, you can use usbip, there's instructions for that
<gsuberland>
ah neat
<gsuberland>
if the muses happen to take me tomorrow I shall investigate :)
<whitequark[cis]>
good luck
<whitequark[cis]>
actually
<gsuberland>
ah dangit I forgot about the two 2.2k resistors to ground on VIO
<gsuberland>
so nah the DAC trick won't work
<gsuberland>
I'll check through the schematic tomorrow to see if it's 100% safe to backfeed voltage onto VIO (I would be very sad if I killed my Glasgow!) then see if I can figure out getting the INA233 to pick up the reverse leakage current
notgull has joined #glasgow
<whitequark[cis]>
I can't imagine any reason it wouldn't be; the only potential problem would be the LDO and that has backfeed protection
galibert[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
that's odd
<josHua[m]>
it is odd in a great number of ways
<josHua[m]>
anyway, I think that there is a possible shenanigan for revC boards, looking at the schematic and layout and datasheet. it seems that, if you're willing to trade off some extra quiescent current (which does not seem to be a goal of Glasgow RevC), then one could produce a FPC with cutouts for each levelshifter that overlays the board and abuts pin 5 of each level shifter and adds a 1k PD (I call this 'ultraHDMI style' because that's the
<josHua[m]>
first place I saw it, but I'm sure there is a name for it), and would be relatively easy to solder because the cutouts would align it and the polyimide itself would act as a solder mask to avoid blobbing over pins 4 and 6
<josHua[m]>
you'd grab C92 with a corner of the FPC to get a ground reference, I guess
<josHua[m]>
even at the full 128 uA of PU current, 1k gets you Vdir = 0.1V, <<< Vil of anything sensible
<whitequark[cis]>
that seems impractical
<whitequark[cis]>
it creates a revC3.5 which cannot be identified via software
<josHua[m]>
that is correct
<whitequark[cis]>
what to do about all the boards esden already shipped? recall them and fix them one by one?
<whitequark[cis]>
that's just a bad idea
<josHua[m]>
this would be an optional user modification for individual users who care about not getting caught out by this
<whitequark[cis]>
this is not interesting to me as a maintainer
<whitequark[cis]>
the few people willing to go through the effort can just do some flywiring
<whitequark[cis]>
what I need is a fix that is readily deployable
<josHua[m]>
(it is possible to detect this in an extremely silly way -- by putting the DIR pin on a tristatable output and measuring the RC time to see if there is a pulldown -- but that sucks)
<whitequark[cis]>
the FPCs are a real pain to produce too
<whitequark[cis]>
they're expensive and they have weird DFM requirements that most people aren't intimately familiar with
<whitequark[cis]>
(they got less expensive but they're still expensive)
<whitequark[cis]>
the soldering is a pain as well because you have these chonky plastic connectors that are easy to melt
<josHua[m]>
hm that is not my experience with an analogous FPC I have produced. an analogous part that I made on PCBWay fairly reliably hit the cut marks for like $0.80 a pop, qty ~250
<whitequark[cis]>
ok, so now you've fixed your glasgow and you have 249 more of them
<josHua[m]>
exactly!
<whitequark[cis]>
now you are in the business of selling electronic components to people
<whitequark[cis]>
after spedning 200 bucks on shit you mostly don't need
<josHua[m]>
and making maintainer's lives more difficult by having weirdly modified glasgows in the wild too
<whitequark[cis]>
so you'll have to spend at least 200 more just to get the envelopes and mail them, and an untold amount of your time doing the mailing
<whitequark[cis]>
it's like, the first step is bad enough but each next one makes it worse!
<whitequark[cis]>
josHua[m]: this is actually largely not a problem because if your glasgow is not produced exactly according to the spec the amount of support you can expect is precisely zero
<josHua[m]>
it is not a high profit project. if it were to be commercialized as a real Glasgow addon, it would be the kind of thing that would, when Glasgow is in reasonable MP, would have like 500 of them sitting in the 1b2 store or something that could be thrown in the box with the rest of the Glasgow
<whitequark[cis]>
this is an existing policy to avoid cases like this
<whitequark[cis]>
it's simply not sustainable to run the project otherwise
<josHua[m]>
oh you know full well that people only disclose the stupid shit they have done to their systems long after you have wasted an hour before they say "... and by the way, does it matter that I bridged pins 5 and 6 when I installed the mod?" or whatever
<whitequark[cis]>
high profit? this is more like "how much of a loss can you eat here"
<whitequark[cis]>
you're actually better off eating the 199.20 loss on the other 249 boards than trying to sell them, lol
<whitequark[cis]>
because unless your time is very cheap you'll never even break even
<josHua[m]>
I think this is likely true. it only makes sense if you have infrastructure already associated with selling shit, which I do not
<whitequark[cis]>
people really underestimate how hard it is to produce even 20 of anything
<whitequark[cis]>
much less 250
<whitequark[cis]>
until they try it the first time and the extent of suffering really kicks in
<theorbtwo[m]>
Frankly, it's amazing that the project supports all the named and unmodified boards, even the ones that never had general availability.
<josHua[m]>
(this is, in part, why I almost certainly will not try to sell any of the littleprobe/mediumprobe/largeprobe, even if I hit my bom targets, even if they work well)
<whitequark[cis]>
theorbtwo[m]: yes, _even that_ is more than most commercial companies do
<whitequark[cis]>
but it seems necessary to avoid any boards becoming e-waste
<josHua[m]>
indeed, also this is why the Rebble Alliance has not manufactured new watches, despite having plenty of money kicking around to tool up even for molds if we wanted to
<whitequark[cis]>
josHua[m]: if this becomes a persistent problem we'll start banning people for that
<whitequark[cis]>
I don't want to do that and I really hope we don't have to
<josHua[m]>
that seems like a good policy
<whitequark[cis]>
it's a ... least bad policy in an environment where time is a limiting factor and people feel entitled
<whitequark[cis]>
it's not great, but it's least bad
<whitequark[cis]>
in a perfect world we'd be able to hand-hold everybody through their first electronics expereinces
<josHua[m]>
anyway, the reality is that without maintainer support for wanting to do this thing, I would not bother to even sketch the interposer FPC, much less fab it out
<whitequark[cis]>
in a real world I'm severely disabled
<whitequark[cis]>
josHua[m]: there's one condition where I would support it
<whitequark[cis]>
if we design and prototype revC4 and if this FPC makes a revC3 into a revC4, this may be done
<whitequark[cis]>
but it needs to be very well planned and coordinated with Piotr
<josHua[m]>
it is not out of the question that it could add an identifying pull somewhere else as well (or 2kohm between some pairs of DIR pins or something to be able to differentiate a revC3 from a revC3.5/revC4)
<whitequark[cis]>
there's no place to add a pull
<whitequark[cis]>
also, configuring the FPGA is not acceptable as a way to determine the revision, it completely breaks the design
<whitequark[cis]>
because the device enumerates with a serial number that includes the revision, yes?
<whitequark[cis]>
and there's not enough space to store a bitstream anywhere on the board
<whitequark[cis]>
(there's barely enough space for one bitstream; it actually overflows into FX2_MEM at the very tail end)
<theorbtwo[m]>
Last step in the install procedure would have to be rewriting the "factory" eeprom to mark C3.5?
<whitequark[cis]>
I don't plan on having .5 revisions
<whitequark[cis]>
and the format of the EEPROM doesn't support it
<josHua[m]>
or C4, yes
<whitequark[cis]>
hence "if it's equivalent to revC4"
<whitequark[cis]>
it's BCD for the second digit, so we can go up to revC15 if we need it
<josHua[m]>
I was assuming for a FPC mod then you would program the EEPROM in an identifying way (or overwrite the serial number in an identifying way that also indicates that the board is modified!)
<whitequark[cis]>
I don't want that to become a support burden
<whitequark[cis]>
it's not just the EEPROM format, by the way
<whitequark[cis]>
the code space on the FX2 is quite limited and since we only ship one firmware for every revision, it has to fit everything
<whitequark[cis]>
we have about 400 bytes left currently, iirc
<whitequark[cis]>
so "if (this random person's mod is installed)" isn't an ok thing to have in the firmware
<whitequark[cis]>
it's going to cost us probably at least 10% of the remaining code space
<whitequark[cis]>
it's not inconceivable that we'll switch to split firmwares at some point (INA233 current measurement may be the trigger for that, though I have more than one trick up my sleeve) but I'd like to not do that for as long as we can, because it'll land us straight in #ifdef hell
<josHua[m]>
ah I was just thinking that, as to whether the FX2 could grow a detect on a bus pin, but that is not worth the code space
<whitequark[cis]>
the FPGA bus is the least problematic place to put a pull resistor on, yes
<whitequark[cis]>
but where do you connect to it?
<whitequark[cis]>
you can't do it next to the FPGA because the FPGA is in a BGA package
<whitequark[cis]>
and you can't really do it next to the FX2 because now you're asking people to solder shit to the side of a QFN
<josHua[m]>
oh, QFN, not QFP. rough
<whitequark[cis]>
have you seen how good the average soldering skill is?
<whitequark[cis]>
honestly the QFP is basically as bad
<whitequark[cis]>
because if you get a bridge you're going to suffer even more
<whitequark[cis]>
this idea is only marginally more practical than "open up a bunch of the FPGAs and FIB away the pullup"
<whitequark[cis]>
principally because it's cheaper
<josHua[m]>
pull A2 on U2 and detect that. also not worth the code space, but a lot more doable with a well designed FPC
<whitequark[cis]>
A2?
<whitequark[cis]>
the ... what
fibmod has quit [Remote host closed the connection]
<whitequark[cis]>
that's not going to work because the FX2 is hardcoded to look for it on this exact address
<whitequark[cis]>
it's a silicon bootloader.
<whitequark[cis]>
oh wait
<whitequark[cis]>
ICE_MEM not FX2_MEM
<josHua[m]>
ICE_MEM? or FX2_MEM?
<josHua[m]>
yes
<josHua[m]>
I looked at FX2_MEM and thought 'no' for this reason
<josHua[m]>
back in a few
<whitequark[cis]>
ok sure, that would ... work i guess
<whitequark[cis]>
I hate it but I acknowledge that it's practical
* whitequark[cis]
sketches "in the next revision connect A2 hard to GND"
<theorbtwo[m]>
I see two open paths. 1: last step is to reflash fx2 eeprom to be rev C4, and we consider that rev used up. Next rev with a real board is C5. 2: last step is to reflash the fx2 eeprom to not be a 1b2 Glasgow anymore, and just acknowledge that by installing you void your 1b2 warranty.
<whitequark[cis]>
step 2 is something I'm perfectly happy for anyone to do
<whitequark[cis]>
actually it's not about 1b2 because 1b2 is not doing anything special
<whitequark[cis]>
it's just not a Glasgow anymore (it will enumerate as "Another Interface Explorer"
<whitequark[cis]>
* Interface Explorer")
<whitequark[cis]>
it also voids the 1b2 warranty the moment you solder it but that's not my personal concern
<whitequark[cis]>
there is an alternative to step 1, which is that we design and prototype revC4 and once we consider it finished we also make a mod that's a diff between C3 and C4
<whitequark[cis]>
I'm fine with that too
<whitequark[cis]>
I'm much less fine with step 1 as you present it because it causes more support burden in the end
notgull has quit [Ping timeout: 268 seconds]
fibmod has joined #glasgow
fibmod has quit [Ping timeout: 260 seconds]
notgull has joined #glasgow
fibmod has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
notgull has quit [Ping timeout: 255 seconds]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
jstein has joined #glasgow
bvernoux has joined #glasgow
fibmod has quit [Remote host closed the connection]
fibmod has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
esden[m] has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has joined #glasgow
JanIbrahim[m] has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
jstein has quit [Ping timeout: 256 seconds]
bvernoux has quit [Quit: Leaving]
dustinm` has quit [Quit: Leaving]
redstarcomrade has quit [Read error: Connection reset by peer]