<d1b2>
<ebb> Touching on the (deserved) FTDI bashing earlier ...any coïncidence that this project shares a name with FTDI's HQ location?
<sorear>
no, there is no coincidence
<sorear>
the original scope of the project was a drop-in no-extra-functionality replacement for ftdi usb-jtag converters
Getorix has joined #glasgow
Getorix__ has joined #glasgow
Getorix_ has quit [Ping timeout: 256 seconds]
Getorix has quit [Ping timeout: 260 seconds]
Getorix has joined #glasgow
Getorix__ has quit [Ping timeout: 246 seconds]
_whitelogger has joined #glasgow
<whitequark>
yup
<whitequark>
honestly the name was a moment's inspiration. once the project got more popular than like 3 people i knew i was a bit worried that aliasing the name of a major city would cause issues
<whitequark>
but it doesn't seem like it does, i've talked with more than several Glasgow residents about it by now and none think it's objectionable in any way
Stormwind_mobile has joined #glasgow
PyroPeter_ has joined #glasgow
electronic_eel has quit [Ping timeout: 260 seconds]
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
electronic_eel has joined #glasgow
_whitelogger has joined #glasgow
Getorix_ has joined #glasgow
Getorix has quit [Ping timeout: 256 seconds]
Getorix has joined #glasgow
Getorix_ has quit [Ping timeout: 240 seconds]
<sorear>
it does have the Go problem of being impossible to search for casual conversations about
<d1b2>
<jones> > > Prototype order timeline is Mondayish... :) > @esden#0000 > Is there any option/process to jump on that order and get it shipped to germany without too much hassle for you?
<d1b2>
<ebb> whitequark: i wouldn't be worried personally either :) it kind of sounds like how products of research can end up with the name of where they were invented
evck_ has quit [Ping timeout: 244 seconds]
evck_ has joined #glasgow
carlomaragno has quit [Ping timeout: 244 seconds]
<sorear>
works great for red hat. *looks at map of US-MA: wayland, weston, plymouth, dracut, ...*
<gruetzkopf>
oh, $clients_product seems to have the module this is cloned off
<Ultrasauce>
and having an onboard isolated supply seems pretty advantageous
bvernoux has joined #glasgow
_whitelogger has joined #glasgow
<d1b2>
<esden> @jones this is a prototype run before we launch the CrowdSupply campaign. I will only make a few units for WQ, electronic_eel and a few others, so we can make sure the hardware and software support works as expected. If you want the hardware make sure to sign up to be notified when the campaign launches: https://www.crowdsupply.com/1bitsquared/glasgow
<ebb>
Verif team 💪
<d1b2>
<esden> The whole revC2 revolves mainly around DFM changes, and making it ready for the full size production run.
<electronic_eel>
ok, there is one more thing I found while reviewing revC2: we don't have a low pass filter for the vsense on the new adc
<electronic_eel>
ti doesn't show one in the datasheet for the ina233, so I guess for most applications you don't really need one
<electronic_eel>
but I haven't tested the ina233 in this regard yet (the samples I ordered from ti are still in transit to me)
<electronic_eel>
so it could be that we get some emi problems or similar and that could trigger the overvoltage protection
<electronic_eel>
whitequark: esden: what do you think? should we add a filter to revC2 or should we try if it works without and only add it if we see problems when testing the revC2 samples?
<whitequark>
electronic_eel: can we DNP it?
<whitequark>
well, probably needs a jumper. do we have any?
<whitequark>
*in the BOM?
<electronic_eel>
no, we'd need a pass resistor. you'd have to populate this
<whitequark>
yeah
<electronic_eel>
we don't have a 0 ohm jumper in the bom yet
<whitequark>
hm
<whitequark>
we have some low value resistors and i think there's no reason we can't just use the lowest value of all BOM lines
<whitequark>
since the problem is BOM lines not component counts
<whitequark>
is primarily*
<electronic_eel>
the impedance of the ina233 is 800k, so adding the lowest value we have, 4.7 ohms, wouldn't matter
<electronic_eel>
now I would calculate the filter so that we'd use 100nF as cap, so the filter probably wouldn't need another bom line
<electronic_eel>
it is mostly adding the footprints
<whitequark>
oh, yeah
<whitequark>
is it hard to do that?
<electronic_eel>
no, not really. it is an area where there are differences between the ports due to the rotation. so it won't be symmetric
<electronic_eel>
on the other hand the impedance of 800k suggests that there is some basic filtering inside the ina233
<electronic_eel>
hmm, I just re-read the datasheet of the ina233. they have a filtering section, but they just mention the current monitoring there, not the voltage monitoring
<electronic_eel>
we have the current filtering scheme they suggest already implemented in revC2
<electronic_eel>
but there is nothing in the whole ds about filtering of the vsense. either they didn't think that you would connect something with a jumper wire there, or filtering isn't necessary
<electronic_eel>
a reasonable filter combination without adding additional bom lines would be 4.7 ohms an 100nF, giving 338kHz 3db cutoff
<electronic_eel>
the 100nF would make vsense unsuitable to connect to any kind of data line
<electronic_eel>
is having vsense connected to a data line (and not some power supply) an application we want to support?
<electronic_eel>
then we'd have to use something like 2.2k and 470pf -> 153kHz, adding the 470pf to the bom
bvernoux1 has joined #glasgow
bvernoux1 has quit [Client Quit]
bvernoux has quit [Ping timeout: 265 seconds]
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to wip-revC2 [+0/-0/±3] https://git.io/JU4Ra