diverger has quit [Read error: Connection reset by peer]
bvernoux has quit [Quit: Leaving]
<d1b2>
<Attie> @WillC ... I've just done some testing with CANL on another board that uses the same transceiver... it doesn't seem to work at all
<d1b2>
<Attie> actually... let me take that back for a sec [more testing]
<d1b2>
<Attie> hmm... i'm sticking with my "it's not going to work"
<d1b2>
<Attie> leaving CANL floating on the receiving end, I can see it trying to ACK, but the other end doesn't recognise this... even putting the bus into "silent" mode (in the CAN controller too) doesn't help
<d1b2>
<Attie> tying CANL to 0v also doesn't help, as CANH ends up at ~2.5v, which (as I understand it) would make the transceiver see a dominant state all the time
<d1b2>
<WillC> You set up a single wire can network?
<d1b2>
<Attie> ohh, no sorry - i thought this was a "hacky way" to connect CAN with only one wire
<d1b2>
<WillC> Oh no sorry signal wire can is used on GM vehicles
<d1b2>
<Attie> do you think if I had the other node as single-wire, it would work out?
<d1b2>
<WillC> When I have connected to a signal wire network I just grounded can L it works but when you go back to a regular can network you need to remove that ground
<d1b2>
<Attie> i see, okay
<d1b2>
<Attie> because of the "patch panel" design, i'm going to remove the 2-pin jumper, in favour of patching it accordingly... i hope that works for you?
<d1b2>
<WillC> I talked to some car hacking friends about pins 3/5 vs 2/7. There was no clear concessions but one person brought up a great point Bosh created CAN they then made a company called Vector the tools used by Vector use 2/7.
<d1b2>
<Attie> interesting
<d1b2>
<Attie> i think we came up with three options the other day...
<d1b2>
<Attie> so perhaps i put a dotted line on the silk to indicate "the Bosch way" ... ?
<d1b2>
<WillC> Maybe or documentations (which I don't mind helping with)
<d1b2>
<WillC> My biggest worry with a bunch of options is losing new people in them
<d1b2>
<Attie> basic on-board documentation along with more detailed in the repo would be ideal
<d1b2>
<Attie> yeah, i get that
<d1b2>
<WillC> I also don't know who you are building this for
<d1b2>
<Attie> likely not people working with cars day-in day-out... other tools will be far cheaper and more robust
<d1b2>
<Attie> but if you're working with car components on the bench (e.g: inverter / bms), then this may be interesting...
<d1b2>
<Attie> and if you're producing a new product then this could be quite relevant
<d1b2>
<Attie> because we have control over the "CAN controller" (we're putting that in the gateware), we have control over much more than typical CAN controllers
<d1b2>
<WillC> Dont tell @esden I have not read up on the glasgow that much. I did a while back but have forgotten most of that. That being said it would be cool to put this onto a bench hooked up to a controller and then monitor the I/O of the controller with the glasgow
<d1b2>
<Attie> yeah, sounds within scope
<d1b2>
<WillC> like a TIPM you can control the windshield wipers by sending a diagnostic command. Seeing that line go high would mean it worked and I could move on to the next wire/command
<d1b2>
<Attie> oh i see - you want to monitor the "wiper power supply"? you'd need to interface that voltage to the glasgow carefully (max 5v)
<d1b2>
<Attie> ... and this add-on provides two CAN interfaces (on different types of connector), but will "consume" the 6x of the 8x I/O for each of the port A and B... leaving only 4x I/O available, which you'd need to connect up somehow
<d1b2>
<WillC> Yeah I would need to drop down the 12v to 5 that would still be enough I/O
Getorix has quit [Read error: Connection reset by peer]
Getorix has joined #glasgow
<d1b2>
<Hardkrash> I'm watching the CAN add on board stream thought bout the Komodo. It has five signals to the scree terminal block: GND, Shield, V+, CAN H and CAN L. If you have the V+ in then it can power the isolated side for the CAN transceiver.
<d1b2>
<Hardkrash> I also liked the jumper wire approach shown above.
Getorix_ has joined #glasgow
Getorix has quit [Ping timeout: 260 seconds]
Getorix has joined #glasgow
Getorix__ has joined #glasgow
Getorix_ has quit [Ping timeout: 256 seconds]
Getorix has quit [Ping timeout: 256 seconds]
Getorix__ has quit [Ping timeout: 256 seconds]
umarcor|2 has quit [Read error: Connection reset by peer]
umarcor|2 has joined #glasgow
Getorix has joined #glasgow
analprolapse has quit [Ping timeout: 264 seconds]
analprolapse has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 265 seconds]
<esden>
as electronic_eel said, I had to make adjustments that are related to mass production repeatability and reliability. This has to be possible. We don't have any way to indicate that with the versioning as is. It does not impact anyone except those that mass produce the boards. That is why I think it is ok to not bump revision number just because of a 0.1mm pad size change.
<whitequark>
yes, I reluctantly agree
<whitequark>
if doing this over I would pick a better versioning scheme
<whitequark>
but that's one thing I am not going to change by this point
<electronic_eel>
esden: did you have time to do the desoldering test of the usb-c connector? otherwise this could be something for the stream on tuesday?
<esden>
whitequark: I understand, sorry to cause versioning discomfort. :/
<whitequark>
it's not your fault
<whitequark>
like I said, it's a downside of the versioning scheme I picked, so just my inexperience
<esden>
electronic_eel: not yet, it is on my todo list.
<esden>
Including testing the correct Molex connectors for the sync interface.
<electronic_eel>
esden: one other thing i noted down while you were doing the assembly was the size of the holes for the alignment pins for the lvds connector
<esden>
Ahh right, thank you. I have to doublecheck the mechanical drawing and we have to decide if we want to tighten them up... they were indeed bit sloppy.
<electronic_eel>
I also want to inspect the solder joints on the esd protection diode arrays with a microscope. with bare eye some look non optimal. maybe we should lengthen the pads a bit.
<esden>
I created a todo list for myself on the merge PR...
<whitequark>
\o/
<esden>
electronic_eel: yeah I don't know... I think with a more optimal reflow profile (mine is not perfect) this should not be an issue. Just saying those fillets on other similar QFN I have on other products (several k produced so far) look like this too and I did not have issues.
<esden>
They only "look wonk" :)
<electronic_eel>
but would a pad lengthend about 0.1 or 0.2mm create any issues?
<esden>
Not sure what it would change to be honest...
<electronic_eel>
I think that should improve the look of the fillets even with non-optimal profiles
Stormwind_mobile has quit [Ping timeout: 256 seconds]
<esden>
I honestly doubt it ... but if you insist...
<electronic_eel>
I haven't taken a proper look on mine. so I'm not sure yet
<electronic_eel>
this was just something i noted down on my list
pie_ has quit [Ping timeout: 272 seconds]
pie_ has joined #glasgow
<esden>
electronic_eel: yeah sure. They just look the same as the ones on the Black Magic Probe level shifters. The problem there is that those parts have the pads only under the part. This results in the visible fillet looking strange. It seems like it is not connecting to the pad because there is plastic pushing it away. In a sense it would almost make more sense to make the pads actually even shorter. But then rework is hard.
<esden>
Because of that it is usually nicer to have QFN/DFN parts that have the pad exposed on the side of the package. Results in much prettier fillets.
<electronic_eel>
hmm. so where is the solder profile coming in there? how does it change this to make nicer fillets?
<esden>
That is related to how the surface tension changes and creates a more clearly visible bond to the pad under the part.
<esden>
My curve is in a sense still bit too sharp resulting in the flux not being as active as I wish it would be.
<esden>
It is clear when I add flux and reflow those parts with a heatgun. They look nicer then.
<esden>
At the end it is all nuance. :)
<electronic_eel>
if one of those pads is not properly soldered, we couldn't detect this with the selftest or jig. it is just that this pin is then unprotected...
<esden>
Yeah we would need to apply reverse voltage on the pins to test if the diodes are present.
<electronic_eel>
the level shifters have reverse diodes too, just that they are much more sensitive
<whitequark>
wondering if the capacity difference can be sensed
<electronic_eel>
so I think if you want to do anything that does not risk destroying anything, it should be a capacitance test. but since the tvs diodes just add a few pf, you'd need serious gear
<whitequark>
like the FPGA we have?
<whitequark>
i don't really know how sensitive it'll be but... since we already need it for selftest on revC...
<electronic_eel>
I thought more in the direction of a high end lcr meter or a vna going in the multi ghz range
<electronic_eel>
the fpga on the board itself has the downside that it is behind the level shifters, so it can't directly measure on the outside pins
<whitequark>
yes, but the pulls are connected there
<electronic_eel>
maybe we could hook up the lvds connector to the regular ports and then use the lvds comparators in the fpga
<electronic_eel>
this should give a better defined switch point than regular cmos inputs
<d1b2>
<0x53A> Is this the right place to ask questions about the usage of applets (sensor-scd30 specifically)?
<electronic_eel>
also we don't have a test for the lvds connector planned yet
<whitequark>
0x53A: sure. i wrote that one
<d1b2>
<0x53A> I'd like to connect glasgow to an SCD30. (First time using Glasgow, I have the glasgow but not the scd30 yet) From scanning the applet source and glasgow run sensor-scd30 --help I can use any arbitrary IO pins and do NOT need to solder to the two test pads (sda/scl) at the bottom. From the SCD30 datasheet, I need Vdd 3.3V-5.5V, and Vih (I2C) 1.75V-3V. If I understand that correctly, I'd need to set the IO bank to <= 3V and supply Vdd >= 3.3V from
<d1b2>
somewhere else (the other IO bank?)? So: Connect GND to any GND, Vdd to B-V, SCL to A-0 and SDA to A-1. (Leaving SEL floating) Then run these two commands glasgow voltage B 3.5 glasgow run sensor-scd30 --port A --pin-scl 0 --pin-sda 1 -b 100 -V 2.8 Should that work?
<whitequark>
yes, totallt
<whitequark>
though you can use -V 3.3 for the I2C port
<whitequark>
since that's what the MCU on board of SCD30 actually uses
<whitequark>
(it has an integrated 3.3V LDO)
<d1b2>
<0x53A> That makes it even easier, then I need just the one command. Thank you!
<whitequark>
yes, checking on my SCD30, it's connected to just one port
<whitequark>
but there are some other sensors (PMS7003) i have that require Vdd=5 with 3.3V I2C
<whitequark>
for those sensors your arrangement is exactly how it would be done
<electronic_eel>
0x53A: soldering stuff to the i2c test pads is not the right way for nearly everything except testing or debugging glasgow itself
<whitequark>
yup
<d1b2>
<0x53A> I'm glad about that because I haven't soldered anything in a long time. At first I thought I had to do that until I read the help output. Alright then I'll order the part. I've wanted to clone your logger thing after I saw it on twitter, just never had the hardware and/or motivation.
<electronic_eel>
you wouldn't even be able to connect to the device at all from the internal i2c, since we don't have a protocol for arbitrary devices on the internal i2c (wq: wink wink)
<whitequark>
yup
<whitequark>
i think i'll implement that once i get my revC2
<whitequark>
right now i'm stuck with verilog horrors
<electronic_eel>
verilog horrors to work around for nmigen?
<whitequark>
soooort of
<electronic_eel>
or yosys work?
<whitequark>
it's like three yak levels deep
<whitequark>
i'm implementing verilog $display format string semantics so i could have something sane in RTLIL so i could emit it from nmigen so i could have a Display() command that works in both pysim and cxxsim
<whitequark>
verilog format strings are incredibly hateful
<whitequark>
they are *wildly* underspecified until something like 2010, to the point of being unusable, and they're the regular kind of horribly underspecified after that
<whitequark>
you basically have to guess what sort of committee dysfunction led to the paragraphs that are in the standard, and then work backwards from that
<electronic_eel>
doesn't that lead to each vendor implementing it slightly different?
<whitequark>
no shit it does
<whitequark>
"when in doubt, check what synplify does"
<whitequark>
tbh i don't even know if iverilog and verilator agree
<electronic_eel>
i wouldn't be surprised if something like this is different between ise and vivado...