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
<azonenberg> new SMA test board shipped
<azonenberg> also BTW digikey cart is $136.07 for one MEAD board right now, not including the parts for the SMA/MMCX input board or a few passives i have in stock
<azonenberg> and including overages of a few things
<azonenberg> actually it includes the mating LSHM connector for the input board. Just not the MMCX's, which i think i have enough of in stock
<azonenberg> Just ordered a SFF-8087 cable for testing
<azonenberg> electronic_eel: BTW the LM27761 is not just an inverting charge pump, so i suspect the extra filter will be unnecessary
<azonenberg> it's a two stage design consisting of a charge pump followed by an LDO
<azonenberg> but i'll stick it there just to be safe
<azonenberg> Continuing the design review checklist, we do have the 100 uF cap at the input but i am not planning to add inrush limiting
<azonenberg> since the plan is to "semi-cold" mate the pod with power gated host side, then turn on power after the connection mates
<azonenberg> we can do soft-start on the host side switch if needed
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #scopehal
juli965 has quit [Quit: Nettalk6 - www.ntalk.de]
tverbeure has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
<azonenberg> Looks like the sma-test-v0p2 boards are arriving Monday
<azonenberg> Anybody else have a chance to look at the LA pod schematic? other comments?
<Degi> Maybe we can have a RGB LED for the whole pod
<azonenberg> what's the point if we have the LCD too? As an alternate mode for a no-LCD build?
<Degi> Hmh idk just to identify pods at a quick glance if you have more than 1
<Degi> But yeah for that too
<azonenberg> (I remain skeptical of the need for it, and it's about 10% of the BOM for the entire pod right now)
<Degi> Can the pod run doom
<azonenberg> if you can run a doom stm32f031 i'll be seriously impressed.Lol
<Degi> Maybe the FPGA can run doon
<Degi> *doom
<Degi> Hmm I bet the pod can run pacman
<Degi> Read your brain waves with the scope inputs
<azonenberg> lol
<azonenberg> ok so, added a bunch of test points
<azonenberg> and i think i'm good
<_whitenotifier-c> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±8] https://git.io/JfKTC
<_whitenotifier-c> [starshipraider] azonenberg 7952c98 - MEAD: finished schematic review, added more test points
<azonenberg> New schematic uploaded after review
juli965 has joined #scopehal
<azonenberg> Tweaking the layout floorplan a bit. New concept is SFF connector north center
<azonenberg> MCU northwest corner, power supply northeast
<azonenberg> DAC and LCD connector in the center
<azonenberg> then two pairs of comparators east and west of center
<Degi> Hmh dont forget to length match traces
<azonenberg> Yeah i'll skew match everything as tight as i can
<Degi> Hm yeah, input as well as output so that signals rising at the same time wont yield different results
<azonenberg> Yeah
<azonenberg> (keep in mind that we do have the option of doing skew matching on the FPGA to some extent too)
<azonenberg> But yes i am going to try to length match as much as i can
<Degi> Well velocity can change with temperature, humidity etc so if skew matched, that effect would be way reduced
<azonenberg> Here's what i've got now
<azonenberg> i'm putting shield rings around each of the major subsystems. not expecting EMI to be a problem but this provides some futureproofing if a can ends up being needed
juli965 has quit [Quit: Nettalk6 - www.ntalk.de]
<_whitenotifier-c> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JfKL7
<_whitenotifier-c> [starshipraider] azonenberg d67e112 - Continued MEAD layout
<_whitenotifier-c> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JfK38
<_whitenotifier-c> [starshipraider] azonenberg 28da679 - Continued MEAD layout. Right side is almost done.
<azonenberg> lain/monochroma: ^^
<lain> nice :3
<azonenberg> i wonder how much a machined aluminum case would be compared to a plastic one?
<azonenberg> or even 3d printed SLS/SLM aluminum
<lain> SLS/SLM printing is $$$$$$
<lain> unless it has come down recently
<azonenberg> SLS nylon is quite affordable. That's what i plan to use unless I go with a metal enclosure
<lain> machined cases will be significantly more (order of magnitude or two) per enclosure compared to plastic, but setup costs should be <<$1k, whereas plastic injection molding setup costs will be between $2k and $20k depending on whether you go china or US
<lain> and then there's the existing housings from like Hammond on digikey/mouser that they will custom CNC cutouts for you, for relatively cheap
<lain> a *small* machined alu enclosure probably wouldn't be too cost-prohibitive if the device itself is expected to be >$100
<azonenberg> Right now the board is looking like it will be around 80x100 mm give or take a bit, plus however much space the MMCX fan-in board takes
<azonenberg> the digikey bom is $143, plus passives in my existing inventory and the MMCX connectors
<azonenberg> and the pcb itself
<azonenberg> but thats at qty 1, i think sub $100 component cost is viable in higher volume
<lain> alright, then yeah, sounds like retail is going to be above $100 so a machined alu housing should be a small fraction of the total cost
<lain> and since this will be low volume, injection molding's setup fees probably outweigh the per-part benefits
<lain> machined alu looks and feels great, and doubles as an electrical shield and a heatsink too :P
<azonenberg> Yeah. I'm thinking I'll go SLS nylon for initial prototypes, SLM aluminum to sanity check performance on a metal case, then think about CNC if/when we're ready to ramp up
<lain> though that can backfire and you wind up with cavity resonance :D
<azonenberg> Sonnet can model that. If your design fits in the available ram limits of course
<azonenberg> as a first order estimate, say 80x100 mm, we could get resonances starting at ~20 GHz if i'm doing this right?
<azonenberg> (half wavelength is when you'd get that, i think?)
<azonenberg> no wait i missed a zero
<azonenberg> we could actually have cavity resonances at 1.5 - 2 GHz
<azonenberg> which is well within the potential operating range
juli965 has joined #scopehal
<azonenberg> that would go up to 5+ GHz if we split up the cavity over each part of the board though
<lain> it's expensive but you can always add RF absorbant mats if you run into a problem
<azonenberg> Yeah its more that i think 3d printed plastic will be good enough for the time being
<azonenberg> and wont have any resonance problems
<lain> fair
<azonenberg> oshpark probe with the new SMA is back from fab, should ship today and arrive early next week
<Degi> Hmh you could probaly add metal walls to prevent resonances, but yeah foam probably works too
<azonenberg> My plan is to start with plastic then do a test run in SLM aluminum with the internal partitions between blocks
<azonenberg> that should make each cavity small enough to shift the resonances out of band
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
<Kliment> azonenberg: have you seen those reflowable foam gaskets?
<Kliment> azonenberg: check out Würth 3029040030030
electronic_eel_ has joined #scopehal
electronic_eel has quit [Ping timeout: 264 seconds]
miek has quit [Quit: miek]
<electronic_eel_> azonenberg: I'm having a look at your current MEAD schematics again
<electronic_eel_> how about adding a pin header for easy access to the uart rx/tx to the mcu?
<electronic_eel_> this might come in handy during development when you don't have the other side of the SFF8087 connector finished
<electronic_eel_> maybe also for debugging
<electronic_eel_> I've seen that you changed uart to PA9/10 on the STM32, so we could use the integrated bootloader when we have a way to activate it
<electronic_eel_> have you seen the schematics I posted to do this?
<electronic_eel_> or did you consider it too complicated?
<electronic_eel_> I think about not having to implement a custom bootloader, saves time and also space in flash
<electronic_eel_> the main point is that it makes it foolproof. you can resurrect the mcu from any state with this from the host, without opening the case or a SWD probe
<electronic_eel_> if you don't want the extra components and space for them - how about adding a pin header for the boot0 pin and 3v3, but keep the 10k pulldown
<electronic_eel_> this way a user with a misflashed mcu can just plug in a jumper to enable the bootloader
<electronic_eel_> I'm a bit confused by the lcd datasheet - how do you power the led backlight?
<electronic_eel_> is that just through the vdd/vss pins?
<electronic_eel_> but how are you supposed to control the current through it? on page 12 of the ds they say you have to limit the current with higher ambient temperatures
<electronic_eel_> for a display this is quite a good datasheet, but displays generally tend to have horrible datasheets
<electronic_eel_> if the leds are really driven with vdd, then we might have to lower the voltage for it. on page 12 they give 3.1v as typical
<electronic_eel_> idea about the lcd vdd: put a 0R resistor from 3v3 in series to the lcd-vdd and a 0.47µF cap to gnd after it
<electronic_eel_> this way we can measure current draw and also lower the voltage with the resistor
<electronic_eel_> the lcd allows vdd+0.5 on the data pins, so we have lot's of headroom there
<electronic_eel_> I'm having a look at the dac now
<electronic_eel_> we want 0 to 5v out of it right? so internal ref *2 as max output
<electronic_eel_> the dac needs some headroom from it's vdd to the max possible output value
<electronic_eel_> it is no wonder that they were doing all the graphs in the datasheet with vdd 5.5v
<electronic_eel_> so we should raise the input a bit, I think 5.1 or 5.2 v should be enough
<electronic_eel_> so we don't need another power rail for it
<electronic_eel_> but the psrr of the dac is not stellar, so I think we should add some basic filtering on the vdd input of the dac
<electronic_eel_> since the 5v0 rail is the input of the cap switcher I think there is quite some ripple on it
<electronic_eel_> so maybe another ferrite bead + cap after it?
<electronic_eel_> about the LSHM input connector:
<electronic_eel_> how about esd protection for PROBE_I2C?
<electronic_eel_> are all probes that connect there expected to have a i2c eeprom for id?
<electronic_eel_> or do we want some more simple presence detector?
<electronic_eel_> you could route for example pin 38 to the mcu and use it a simple presence detector
<electronic_eel_> the connector is then expected to connect a resistor to 3v3 or gnd for a very basic presence detect