azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-cmake, https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal | Logs: https://freenode.irclog.whitequark.org/scopehal
Pretzel4Ever has quit [Quit: Leaving...]
tverbeure has joined #scopehal
tverbeure has quit [Read error: Connection reset by peer]
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #scopehal
tverbeure has joined #scopehal
tverbeure has quit [Client Quit]
<_whitenotifier-c> [scopehal] azonenberg closed pull request #127: Fix Siglent SDS2000X acquired data voltage calculation - https://git.io/JfwD6
<_whitenotifier-c> [scopehal] azonenberg pushed 5 commits to master [+0/-0/±5] https://git.io/JfrIt
<_whitenotifier-c> [scopehal] tomverbeure 30e5ce6 - Fix acquired data voltage calculation
<_whitenotifier-c> [scopehal] tomverbeure 37696e4 - Use GetHwname() when selecting channel
<_whitenotifier-c> [scopehal] tomverbeure 3186fa0 - Merge branch 'master' of github.com:azonenberg/scopehal
<_whitenotifier-c> [scopehal] ... and 2 more commits.
<azonenberg> MEAD schematic is coming along nicely
<azonenberg> Hopefully will have something ready for review by the end of the night
<azonenberg> need to finish two power rails and... i think that might actually be it
tverbeure2 has quit [Remote host closed the connection]
awygle_ has joined #scopehal
awygle has quit [*.net *.split]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
juli965 has joined #scopehal
<azonenberg> If anybody wants to take a look at what i have so far (Degi, lain, electronic_eel)?
<_whitenotifier-c> [starshipraider] azonenberg pushed 1 commit to master [+10/-0/±0] https://git.io/Jfrsv
<_whitenotifier-c> [starshipraider] azonenberg 7442f34 - Initial version of MEAD LA pod schematic
<azonenberg> i need to add some test points and run through the signoff checklist, but i think it's ready for folks to start looking at it
<Degi> Hmm sure to not use a inductor based converter for the negative rail?
<azonenberg> That charge pump is a part i've used in the past with good results, it can do up to 200 mA and we need less than 100
<Degi> Hmm ok
<azonenberg> it's small and fairly efficient
<azonenberg> already have a board proven sch symbol for it etc
<azonenberg> i used the same TI part for the positive rails other than the 3.3 which is an LDO off the 5
<azonenberg> however for the 5V rail i used the fixed voltage 5V variant since that eliminated the need for reference resistors
<Degi> Is J3 the input?
<azonenberg> Yes
<Degi> Hmm not sure but I think that R33-R64 need to be on the other side of the cabe
<azonenberg> That's a samtec board-to-board connector that will then adapt to either one of Pretzel4Ever's custom probe fixtures or one of our adapters to SMA or MMCX
<azonenberg> No. These are not terminators, they're ECL load resistors
<azonenberg> they need to be at the source side to provide a DC current path. You then get LVDS compatible levels over the bus
<azonenberg> and you can terminate w/ 100R between the pairs
<Degi> Hmm ok
<Degi> Hmh maybe add a LC decoupler on the VREF0-7's
<Degi> Like on the AFE board
<azonenberg> See page 24 of the datasheet for the LMH7322
<azonenberg> i dont think that will be necessary, they only go to one load
<azonenberg> and it pulls almost no current
<Degi> Hm okay, in this case I guess there will be little RF there, compared to the scope where they got a bunch of RF
<Degi> I have an idea for the FPGA mainboard, on the input directly after the DC jack we could use coupled inductors to a) DC isolate input from output and b) provide dual rails
<azonenberg> we'll worry about the mainboard later. Much later
<Degi> oki
<Degi> Well providing +12 and -12 to the AFE boards would be neat. Or +7 and -7.
<Degi> Hmh R72/3 diont have values
<azonenberg> on the charge pump? i thought i reuploaded after calculating those
<Degi> Ag
<azonenberg> refresh?
<Degi> Yes I see
<azonenberg> and yes we can figure out power to the afe boards later
<azonenberg> but einthecorgi has to work out our power delivery to the probes first
<Degi> Hm maybe we can integrate the USB C port or whatever we use on the acquisition boards.
<azonenberg> that was always the plan
<azonenberg> that's why i havent done that board yet
<Degi> Oh okay
<azonenberg> basically i need to do a little more fine tuning and testing on the afe but mostly we have to work out the probe interface
<azonenberg> but the LA side has no dependencies on that in either direction
<azonenberg> so it can be done in parallel
<azonenberg> Degi: anyway, looking good in general?
<azonenberg> i need to do some work for a customer in a bit but when i'm done with that i plan to do the full schematic review
<Degi> Hm yeah I didn calculate all the component values though
<azonenberg> hope to get that done today but probably won't get to layout until after work
<_whitenotifier-c> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfrnB
<_whitenotifier-c> [scopehal-apps] azonenberg b674507 - OscilloscopeWindow: fixed fullscreen behavior by not actually telling the window manager to make us fullscreen. Fixes #99.
<_whitenotifier-c> [scopehal-apps] azonenberg closed issue #99: In fullscreen mode, when a popup dialog is focused the others disappear - https://git.io/JfE2b
futarisIRCcloud has joined #scopehal
bvernoux has joined #scopehal
awygle_ is now known as awygle
Pretzel4Ever has joined #scopehal
<electronic_eel> azonenberg: I'm currently having a look at your la pod schematics
<electronic_eel> I recommend to move the UART on the STM32F031 to PA9 and PA10. these are the "natural" and preferred pins on the STM32F series for UART, meaning you can use them for example with the serial bootloader
<electronic_eel> we could also use a trick I used on one of my boards: use small 74 logic gate to detect that the uart rx is low for longer than a second (=does not
<electronic_eel> happen in normal use)
<electronic_eel> then trigger a reset and set the boot0 to trigger the bootloader
<electronic_eel> this way you never have to care about writing your own bootloader, care about flashing and so on, you just need to plug it into a uart under your control and you can always get it back to life
<electronic_eel> I can post a excerpt of my schematics if you are interested
<Kliment> wonderful trick
<electronic_eel> the device I'm using this on is glued shut and I only have 4 wires, uart+power, so I had to think of something...
<electronic_eel> next point: does the SFF8087 have leading gnd contacts that are guaranteed by design to connect first?
<electronic_eel> if not, we should add a bunch of tvs diodes on the SFF8087, because it will be plugged off under power
<electronic_eel> and contact ringing and so on can lead to voltage spikes, killing the contacts
<electronic_eel> heard some reports about badly designed poe gear being killed this way, rj45 does not have leading gnd
<electronic_eel> even if this is not the case, the user will touch the SFF8087 and might kill it with esd
<electronic_eel> next point: while I don't have a general problem with cap switched converters, they tend to be noisy
<electronic_eel> so how about adding a rc or lc filter with a bigger cap (22µF or similar) after it?
<monochroma> my molex SFF8087 cable and socket are all same height looks like
<electronic_eel> thanks for looking
<electronic_eel> so I suggest tvs diodes for all data and power pins
<monochroma> heh, looks like SFF8643 might have a provision for that though
<electronic_eel> hmm, haven't seen those in use yet
<electronic_eel> the SFF8087 and SFF8088 seem much more common to me
<electronic_eel> the 8088 is unfortunately out because of missing sideband
<monochroma> i have seen them on some SAS backplanes and the like
<electronic_eel> ok, I don't do SAS/SATA backplane stuff all day and also mostly with HPE gear, so I don't claim I have seen everything in that regard
<electronic_eel> but we should still pick something that will be around for a few years, the more common the better for this
<electronic_eel> this market segment will see big changes in the next years due to the change to nvme
<electronic_eel> about the RCLAMP0542T input protection: these are designed like classic tvs diodes, which break down at 8 V typical. that is above the limit for the comparator
<electronic_eel> so for positive pulses we rely on the pulse having the right shape for the tvs diode to catch it (before the internal diodes of the comparator get damaged)
<electronic_eel> for negative we have the 1v5n rail of the comparator, giving us enough headroom
<electronic_eel> so how about this: use a tvs diode that is built like a classic diode instead and put them against the 5v0 rail
<electronic_eel> you know that I love the NUP1301U for this, but they have 0.6pf typical
<electronic_eel> how about the SP4010-02HTG instead: 0.48pf typical (RCLAMP0542T has 0.45pf typical)
<electronic_eel> the SP4010-02HTG is also much sturdier, 30kV esd, 23A surge 8/20µs
bvernoux has quit [Quit: Leaving]
<electronic_eel> <rant>I still can't read pullups being drawn down (the power rail below the resistor), this confuses me all the time. azonenberg seems to love doing this though</rant>
<electronic_eel> maybe add some status leds? like power, mcu comms to scope ok, triggered (this would be controlled via uart commands from the scope). may be handy when you have your eyes not on the scope screen but on the pod because you need your hands there to hold something
<electronic_eel> when thinking about this we could also add a button there. it's use can be configured of course, but sometimes I'd like something near the DUT to either arm the single shot capture or manually trigger
<electronic_eel> for the cases when you have to hold your probes, have to look at the dut for this and can't reach to the scope screen
<electronic_eel> when using a pc this can be solved by adding a foot pedal of course (I have one for cases like this), but maybe someone prefers having this on the la pod or the active probes
<electronic_eel> (the passive one could also get this when we add a small mcu for id and color led)
<electronic_eel> oh, we should also think about indexing the la pods. so how does the user easily see which pod is which if they have like 10 of them on the bench?
<electronic_eel> the user sticking labels on them and then remembering where to plug which pod is a bit oldschool and error prone
<electronic_eel> we could put small displays on the pods showing a number or letter, could be oled or eink
<monochroma> just put those rotary decimal switches on em
<electronic_eel> oh, they look really oldschool. or these mechanical id switches with the small + and - buttons and the window showing the id
<electronic_eel> like they were on old gpib gear or in the first days of scsi
<monochroma> love those
<electronic_eel> they were really neat, but i think they were pricey even back then
<monochroma> thats what i was actually thinking of
<monochroma> i love thumbwheel/button ID selector switches, but they are huge and yeah spendy :P
<electronic_eel> how about a small oled display? they are small and cheap, interface is i2c
<monochroma> sounds like feature creep unless there is a solid use case for them on each pod
<electronic_eel> hmm, so you would not select the pod id by the slot it is plugged into and show it on the pod, but dial in the pod id on each pod itself
<electronic_eel> and when there is a id conflict, show it to the user?
<lain> could do a cute little 7seg
<electronic_eel> selecting the id by the slot prevents the user from having to dial something in
<electronic_eel> yeah, a 7seg would work too
<monochroma> yeah either or
<lain> wait what am I saying
<lain> just provide color-coded collars for both ends (scope side and probe side)
<lain> OR
<lain> color-code the ports on the scope, and put an RGB LED in the probe
<lain> I always wanted to do that for my scope designs
<electronic_eel> that is what makes sense for the scope probes, that is already planned for the active ones
<lain> if you put RGB LEDs on both (the port and the probe), then it can match a user-configurable trace color
<electronic_eel> but I think color coding the la pods too will create color conflicts between the scope probes and la pods
<electronic_eel> you can't have that many colors and still expect people to tell them apart, with different screens, colorblind people and so on
<electronic_eel> so I think for the la pods a letter/number scheme makes more sense
<electronic_eel> like A3 would be pin 3 of pod A
<electronic_eel> the "3" would be printed on the case of the pod, the A is what we have to show or dial in somehow
<electronic_eel> if busses get more complicated, the users will begin to confuse the assignments, like "was MOSI C7 or D3"?
<electronic_eel> if we put a small screen on the pod, we could show user-assigned labels for each pin
<electronic_eel> user-assigned labels are a must for any logic analyzer with lot's of pins
<electronic_eel> I think showing them on the pins would make day-to-day usage more easy
<electronic_eel> I'm currently evaluating these oled modules for a project of mine: https://lcsc.com/product-detail/OLED-Displays-Modules_QG-2864KLBLG01_C90547.html
<electronic_eel> about 3$ in small quantities, controlled over i2c
<monochroma> so now you need user input to scroll through all of the labels per pin?
<electronic_eel> ? they come preassigned to be "A1, A2, A3,...", the user can rename them if they want
<electronic_eel> the display could be mounted next to the pin entries, so that they line up with the text
<monochroma> the labels can get longer than the screen, i guess you could scroll it
<electronic_eel> ah, you mean for really complicated bus names?
<monochroma> yes
<electronic_eel> yeah, they could be slowly scrolled
<electronic_eel> I think this is much better than needing to have a big spreadsheet open with all the assignments
<electronic_eel> btw, here is a screenshot how I did the uart booloader trigger I wrote about above: https://imgur.com/a/NTEmwGo
tverbeure has joined #scopehal
juli965 has quit [Quit: Nettalk6 - www.ntalk.de]
<azonenberg> electronic_eel: i thought sff8087 was hotswappable
<azonenberg> if it's not we can make use of the presence detect signal
<azonenberg> and apply power say 1 sec after we see the initial mate?
<azonenberg> re PA9/PA10 i need to also avoid conflicts with the I2C peripheral
<azonenberg> suggest an alternate pinout and i'll take a look
<azonenberg> TVSes on the data lines is a good call, i was mostly worried about protecting the scope but i guess the comparator outputs should get some too. the ECL loading resistors will definitely help dissipate any transients though
<azonenberg> re status LEDs i have a few spare I/Os on the MCU and was planning on putting in some LEDs but i havent decided on exactly what yet
<azonenberg> rgb led for pod ID sounds like a good idea
<azonenberg> But hmm tiny oled might work
<azonenberg> let me think about that
<azonenberg> something ssd1306 based?
<azonenberg> and slow scrolling of stuff could work
<azonenberg> SP4010-02HTG looks good
<azonenberg> the display you linked is interesting, we can use 12V for the display power natively which is convenient
<azonenberg> and its cheap
Pretzel4Ever has quit [Ping timeout: 240 seconds]