azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
Bird|otherbox has joined #scopehal
juli967 has quit [Quit: Nettalk6 -]
<azonenberg> SFP-to-SMA boards are now at fab, ETA june 24th
<monochroma> :D
<_whitenotifier-f> [scopehal] azonenberg opened issue #151: Add support for configuring channel bit depth on LeCroy HDO9000 series -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #151: Add support for configuring channel bit depth on LeCroy HDO9000 series -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #151: Add support for configuring channel bit depth on LeCroy HDO9000 series -
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #scopehal
<azonenberg> so i think i can fit the MAXWELL mainboard on a single pcb that fits in my reflow oven
<azonenberg> barely
<azonenberg> i'll need to pack the pod connectors really close together
<azonenberg> but it'll work
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±10]
<_whitenotifier-f> [starshipraider] azonenberg a165559 - Continued initial schematic capture
<azonenberg> wooow 38 ICs in the schematic already
<azonenberg> and i still have a fair bit more to od
<azonenberg> do*
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±14]
<_whitenotifier-f> [starshipraider] azonenberg 10bcce1 - Left pods
<azonenberg> i think this is all of the input stage logic done
futarisIRCcloud has joined #scopehal
<azonenberg> soooo check out the PMK SKID eco
<azonenberg> Looks suspiciously like the pcbite holders
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±8]
<_whitenotifier-f> [starshipraider] azonenberg d5ca062 - FPGA support
<azonenberg> 768 ERC warnings woooo
juli967 has joined #scopehal
<_whitenotifier-f> [starshipraider] azonenberg pushed 3 commits to master [+6/-0/±17]
<_whitenotifier-f> [starshipraider] azonenberg 95b6800 - Initial vivado project for main MAXWELL FPGA gateware
<_whitenotifier-f> [starshipraider] azonenberg 9b53134 - Updated ignore properties for main-fpga
<_whitenotifier-f> [starshipraider] azonenberg 484ed51 - Initial DDR3 RAM schematic, no decoupling
<Degi> We could add an ina233 to the 12 V raik
<Degi> *rail
<azonenberg> Degi: i have room for four more on that bus before i run out of addresses
<azonenberg> but we have more than four other power rails
<azonenberg> so i'm probably going to put a second bus for core power rails
<azonenberg> we have plenty of i2c on the stm32 i think
<azonenberg> this is in addition to another i2c segment going to the fpga that only has a mac addr eeprom
<Degi> Hmh not sure if thats good for the 1V0 rail
<Degi> Maybe we can measure before regulators?
<Degi> that way we dont have Rdrop after regulators
<azonenberg> i was going to use a really low value shunt, like 5 milliohms maybe, and make sure the regulator feedback is on the far side of it
<Degi> Hmh so feedback after shunt? Yeah probably works
<azonenberg> but i still need to sit down and work on the psu design
<azonenberg> i've added a lot of things to the design since i did the original power budget
<azonenberg> so i need to recalculate total load per rail etc
<monochroma> hall effect current monitors !
<Degi> You can measure input voltage, current, output voltage, get output voltage by I_in*U_in/U_out
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±4]
<_whitenotifier-f> [starshipraider] azonenberg b89bc90 - More work on DRAM schematic
<azonenberg> BTW the digikey BOM is now $927 for one MAXWELL board
<azonenberg> this does not include the case, front panel LCD, PCB itself, the power supply, and some of the passives
<azonenberg> pretty much major ICs, the wallwart, expensive connectors, and a few of the larger capacitors
<Degi> oof
<Degi> Isnt the FPGA itself like 300 bucks or more heh
<azonenberg> The big fpga is $386
<azonenberg> there's $89 of sff8087 connectors
<azonenberg> $51 of fans, tentatively, but they're not a definite pick yet
<Degi> Heh fans. Didnt think of that
<Degi> Oh yeah
<azonenberg> $46 of SMAs, the 48-12V dc-dc module is $34
<azonenberg> the 10 MHz OCXO is $46
<azonenberg> the little FPGA is $14.70
<azonenberg> lots of little things that add up
<Degi> How many smas do we have
<Degi> OCXO? Ovened?
<azonenberg> Four, they're $11.73 each
<azonenberg> @ qty 1
<azonenberg> but i wanted ultra clean edges since i'm using them for sync
<azonenberg> and yes
<azonenberg> This is a *very* nice oscillator
<azonenberg> 535-12623-ND
<monochroma> rubidium or bust >:(
<azonenberg> 1W warmup power, 400 mW normal operation
<azonenberg> +/- 25 ppb from -40 to +85C
<Degi> Oh yes
<Degi> How long is the warmup
<azonenberg> +/- 3ppm stability over 20 years
<azonenberg> phase noise of -72 dBc/Hz at *1 Hz* offset
<Degi> huh
<azonenberg> down to -123 dBc/Hz @ 100 Hz and -150 at 100 kHz
<azonenberg> The warmup time is specced as 3 mins max, this is the time needed to stabilize to within 20ppb of the final value
<Degi> Neat
<Degi> Hmm can we put a hydrogen maser as a project somewhere down the line heh
<azonenberg> lol
<azonenberg> So it looks like I'm actually going to be using the majority of the outputs on the lmk04806
<Degi> It should be possible to make with no moving components...
<Degi> Neat
<azonenberg> tentatively 8 of 12 total, but some will be blocked out because they share dividers
<Degi> I once saw a paper about a handheld mass spectrometer using an ion pump... No turbos or anything
<azonenberg> i'm actually worried i might not have enough
<Degi> Add a second lmj
<Degi> lmk
<azonenberg> lol well i'm doing design on that subsystem right now
<azonenberg> so let me see where i end up in a few mins
<Degi> " Note: This is a point where the TX and RX may diverge into different LTSSM states." ummm WHAT
<Degi> PCIe spec huh
<azonenberg> Sooo it looks like i am going to need a second oscillator for the 10GbE
<Degi> ?
<Degi> Ran out of lmk?
<azonenberg> No, ran out of common factors
<azonenberg> lol
<Degi> Could use FPGA pll
<azonenberg> there doesn't seem to be any way to get 156.25 or 312.5 MHz out of the same VCO freq that does the rest of the freqs i need
<azonenberg> the 10G SERDES has its own PLL that takes signals directly from off chip and needs extremely low jitter
<azonenberg> the LMK would be fine
<azonenberg> Except i need to run the LMK at 2 GHz VCO, with the clock distribution path at 1 GHz, to divide all of the other frequencies i need
<azonenberg> (which also means changing from the lmk04806 to the lmk04803, the sister part with a different tuning range)
<Degi> Hmh I mean you could use a FPGA pll for that
<azonenberg> no i cant
<azonenberg> too much jitter
<Degi> Was it these digital oscillators?
<azonenberg> no, just the fpga clock tree itself is too jittery
<azonenberg> the serdes need super stable clocks
<Degi> For the lan? oof
<azonenberg> I was previously going to use the lmk04806, which has a 2.5 GHz VCO
<azonenberg> that would let me run the distribution path at 1.25 GHz
<Degi> Or just use some cheap-ish quartz
<azonenberg> which i could then divide down by 8 to get 156.25 MHz for the serdes
<azonenberg> the problem is, the clock tree for the RAM controller needs a multiple of 200 MHz to run DDR3 1600
<azonenberg> and 200 and 156.25 don't have enough common factors
<Degi> Could an fpga pll be used for taht?
<azonenberg> actually wait a minute
<azonenberg> i think i know how to do this
<azonenberg> maybe
<Degi> 156.25/25*32 would be 200 MHz
<azonenberg> No, they both have to come from off chip due to clock tree constraints
<azonenberg> and i really dont want to loop them around
<Degi> Oh
<azonenberg> Sooo i can use 500 for the ram pll
<Degi> Well then 2.5/5?
<azonenberg> no i want to try and do it all on the LMK still
<Degi> I mean yes the 2.5 GHz
<azonenberg> let me list out all of the possible freqs
<azonenberg> I'm actually going to do this in picosecond clock periods as the numbers come out rounder
<Degi> Can scopehal deal with a scope having a noninteger picoseconds per sample?
<azonenberg> Not exactly
<azonenberg> timestamps of samples are all integer picoseconds
<azonenberg> you could round the timestamp of each sample to the nearest ps and probably be fine
<azonenberg> also, just finished my analysis
<azonenberg> the GCD of all of the frequencies i need is 2.5 GHz
<azonenberg> The LMK04808 VCO runs up to 3072 MHz and that means a max distribution path of 1536 MHz
<azonenberg> so i believe using this series of PLLs, generating all clocks on a single pll is impossible
<Degi> What if you just dont do divide by2
<azonenberg> That's not possible
<Degi> Whats the VCO mux for then
<azonenberg> oh wait
<azonenberg> am i being stupid? :p
<azonenberg> let me look
<Degi> Figures 1-3 indicate something about 3 GHz output hehe
<azonenberg> So the max toggle rate of an LVDS output is 1536 MHz
<azonenberg> that might have been what confused me
<Degi> What did they to in fig1
<azonenberg> let's see...
<azonenberg> that's the guaranteed minimum
<azonenberg> before you lose amplitude i think
<Degi> Ahh I see, above that it goes down to as low as 150 mV
<azonenberg> ok so yeah VCO_MUX
<azonenberg> just confirmed with the clock design tool, 200 MHz is impossible but 100 is OK
<azonenberg> So ... each of the two FPGAs is getting 156.25 MHz as a main system clock
<azonenberg> the kintex gets 100 MHz going to the RAM
<azonenberg> another 100 MHz to the 10 Gsps GTX for input sampling
<azonenberg> then a low TBD frequency to the GTX and an LVDS input for synchronization
<azonenberg> 156.25 MHz to the 10GbE, and 25 MHz to the 1G PHY
<azonenberg> so it's all doable and we even have one divider off the VCO unused
<azonenberg> which i will probably use for refclk out
juli968 has joined #scopehal
juli967 has quit [Read error: Connection reset by peer]
futarisIRCcloud has quit [Ping timeout: 256 seconds]
lukego has quit [Ping timeout: 256 seconds]
futarisIRCcloud has joined #scopehal
lukego has joined #scopehal
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg> So for the input comparators what kind of power rails do we want to use?
<azonenberg> for ext refclk, trigger, etc
<azonenberg> the waverunner 8000 refclk out, just for reference, is 3.5 +/- 1 dBm
<azonenberg> so we certainly want to be able to handle at least 4.5 dBm
<azonenberg> which is ~1V p-p, AC coupled
<azonenberg> then LeoBodnar's GPSDO can put out +7.7 to +13.3 dBm depending on drive setting, which comes out to 2.85V p-p
<azonenberg> The LMH7322, which i plan to use as the input stage, has a differential input range of -1 to +1V so assuming we have IN- tied to ground, our max input power at the input is +10 dBm. It can survive higher but won't be well matched and might have high current draw
<azonenberg> Does that sound reasonable as is, without any attenuators?
<azonenberg> then on the low side, it looks like we can get reasonably good propagation delay etc with a 20 mV differential at the input which is -30 dBm
<azonenberg> We definitely will want a negative supply rail to provide some headroom for the input stage, what voltage do you think makes sense? +/- 5V supply would give us absolute max ratings of -5.2 to +5.2V which is around +24 dBm
<azonenberg> which is plenty of headroom for the level of power we'd expect to encounter from a trigger reference etc
<azonenberg> or a refclk
funkylab[m] has quit [Quit: Idle for 30+ days]
bvernoux has joined #scopehal
<azonenberg> MEAD boards are in seattle, eta on the post office website is thursday but i expect them tomorrow
<monochroma> :o
<azonenberg> stencil is actually lagging, lol
<azonenberg> it shipped and i have a tracking number but it's not updated yet
<azonenberg> oshstencils was closed for a few days, they were apparently moving their gear to a larger facility
<azonenberg> also RFQ submitted for the PMK parts for the production probe run
<azonenberg> also... do you think just an OCXO reference is good enough or should i allow timebase calibration with a VCOCXO + DAC?
<azonenberg> i feel like for a LA having ultra precise timing isn't as important as for a scope and even a TCXO would probably be fine
<electronic_eel> I think an OCXO is fine. you have a flexible refclk input, so if someone has a really nice clk distribution system, they can use it with the LA
<azonenberg> Yeah
<azonenberg> For the higher end scopes i want to allow timebase cal
<azonenberg> so you can actually hook it up to a freq counter and twiddle the dac to get the last few ppb of offset nulled out
<azonenberg> electronic_eel: so what are your thoughts on the refclk input range / power rails i mentioned earlier today?
maartenBE has quit [Ping timeout: 258 seconds]
maartenBE has joined #scopehal
<electronic_eel> 1 Vpp is a common thing for the 10 MHz refsclks. but maybe someone is using a 3.3V CMOS output, that should be usable too.
<electronic_eel> I don't think the low end with something like 20 mV is relevant for a refclk input, I haven't seen something outputting a refclk at such a low level yet
<azonenberg> So you think maybe adding a 3-6 dB attenuator is reasonable prior to the input stage?
<azonenberg> plus an ac coupling cap
<electronic_eel> yes, I think a small attenuator + ac coupling would make sense
<azonenberg> 6 dB would give us 1.65V p-p from a 3.3V CMOS input, which is within the +/- 1V range when AC coupled and biased to zero
<azonenberg> and that would give us sensitivity down to 40 mV or -24 dBm refclks/triggers which should be more than enough
<awygle> yo azonenberg does glscopeclient have a way to source logic analyzer values (digital values generally) from a TCP stream?
<azonenberg> awygle: There is no generic TCP input bridge yet, but it would be easy to write
<azonenberg> funkylab was talking about making one to bridge to gnuradio
<azonenberg> also to be clear the bridge would be to scopehal, glscopeclient just takes one or more Oscilloscope objects and presents you with a UI
<azonenberg> there is zero device specific code in the UI
<electronic_eel> azonenberg: I think 40 mV as a low end will work well
<awygle> azonenberg: is tcp bridge to scopehal on your todo list at all?
<azonenberg> And our damage threshold, ignoring thermal limiting on the 6 dB attenuator, would be roughly +30 dBm
<azonenberg> awygle: noopwafel was interested in making one for picoscope stuff
<azonenberg> what is likely going to happen is we're going to define a standard dual socket schema
<azonenberg> there will be one control plane socket for SCPI commands (easy to implement a default stub that just returns the current sample rate and list of channels and doesn't let you set anything)
<azonenberg> and one data plane socket that contains a tiny framing protocol to define timestamp of each waveform and what channels/how many samples are present, then raw sample data
<azonenberg> pub/sub based, you write to the data plane socket to say "I want to see channel 3" then any time a trigger happens you get channel 3's waveform sent to you with no polling required
<azonenberg> If you're interested in contributing to the spec and/or implementation, then that's great
<electronic_eel> azonenberg: this is 10 MHz, so you can easily add NUP1301U as protection diodes
<azonenberg> I dont think there is a ticket open yet but i can make one
<azonenberg> electronic_eel: yeah but not for RF overload. also for the most part this input stage will be shared with the trigger sync in which is much faster
<azonenberg> and the PPS which needs very sharp edges but is low frequency other than the edges
<electronic_eel> ah, ok, you want as few extra capacity on the trigger as possible
<azonenberg> Exactly. I'm actually going to be putting the trigger into a 1:2 fanout buffer
<electronic_eel> so smaller tvs diodes, just for esd, must be enough
<azonenberg> then sending one leg to an FPGA input and one leg to a GTX, so i can sample the trigger at 10 Gsps at the cost of losing one of the four fast LA inputs
<azonenberg> you'll have your choice via a mux
<azonenberg> all of the GTX inputs will have 2:1 muxes at the input
<electronic_eel> the mux design is nice
<azonenberg> one is either ext trig or channel
<azonenberg> one is either a sync signal during startup or a channel
<azonenberg> the others are always a channel and the mux is just there for delay matching across PTV
<azonenberg> electronic_eel: have you looked at the wip schematic at all?
<azonenberg> there's obviously still a ton more work to do but i think it's filling out nicely
<electronic_eel> just scrolled through it, not proper review
<_whitenotifier-f> [scopehal] azonenberg opened issue #152: Design generic dual socket streaming protocol -
<_whitenotifier-f> [scopehal] azonenberg labeled issue #152: Design generic dual socket streaming protocol -
<electronic_eel> was just thinking about the psu setup: external psu, isolated converter on the input. makes the whole setup a class II device
<azonenberg> well, i'm not sure i like having the thing isolated. I will probably provide a ground lug on the back
<azonenberg> to earth the chassis
<electronic_eel> yeah
<azonenberg> rather than risk having it go hot if you probe something wrong
<electronic_eel> if you connect the gnd to a dangerous voltage and the touch a sma, you can fry yourself
<azonenberg> Exactly
<azonenberg> So even though the wallwart will make it isolated, i intend to provide a means to earth it regardless for safety
<electronic_eel> traditionally scopes are all class I, you can fry the scope input, but it is safe
<azonenberg> So you think a ground lug on the back is a reasonable compromise?
<azonenberg> the alternative is moving a mains supply internally
<azonenberg> which gives us a ground connection that way
<electronic_eel> there are a few scopes with isolated inputs, but they usually have each input isolated from the others. so touching another one is safe too
<electronic_eel> the question is if the safety standards allow such a setup where you can provide a pe connection, but it would also work without
<electronic_eel> someone could forget to attach it, or it loosens itself or something like that
<electronic_eel> you want to be able to sell it without having to fear some lawsuits about such stuff
<azonenberg> look at the picoscopes for example
<electronic_eel> aren't they usb?
<electronic_eel> usb shield to a bench pc (not notebook) is usually pe
<azonenberg> They're usb data connected but not usb powered, and i doubt the usb shield is rated to carry enough current to qualify as a safety earth
<azonenberg> i'm pretty sure they have a wallwart
<azonenberg> at least the pico VNA i have does
<electronic_eel> ah, right, usb shield does not qualify
<electronic_eel> don't know how they handle this case
<electronic_eel> I haven't built stuff that is test equipment, so I don't know about the norms for them
<electronic_eel> I heared whitequark has a library with lot's of iec and similar texts
<electronic_eel> but reading through this stuff takes time
<electronic_eel> here is a declaration of conformity for a picoscope:
<electronic_eel> they list all the relevant ENs, you should be able to find most of them when you ask wq
<electronic_eel> I think the electrical safety stuff isn't too much different in the US from the EU
<electronic_eel> oh, and I guess you want the scopes use a similar psu concept. there you want to have a mains trigger
<electronic_eel> I like to use it if there are some unknown artifacts in my measurement and I want a quick check if it is mains hum
<electronic_eel> you can of course build an optcoupler adapter and plug it into the external trigger in, but having it integrated is much more conveniant
<azonenberg> I don't plan to implement mains trigger
<azonenberg> at least on the LA
<electronic_eel> no, not on the LA. I meant for the scopes
<electronic_eel> on the LA it doesn't make much sense
<electronic_eel> when you look at some oscilloscope teardowns on signal path or eevblog, you can see that they use COTS mains psus, but have a small winding around one of the mains cables
<electronic_eel> they use that to do the mains trigger
<azonenberg> Makes sense. I want to have DC operation capability on everything though
<electronic_eel> so you don't have to cut the mains traces or implement your own psu to get that
<azonenberg> since i expect to start migrating more of my lab towards 48V DC in the long term
<azonenberg> so i think a mains trigger will be an external device we provide that hooks to ext trig or something
<electronic_eel> hmm, what is the point of it? do you plan to get a big 48v ups?
<azonenberg> well thats one possibility, but also rather than having dozens of wallwarts
<azonenberg> i was going to just get one kW class DC PSU with a big bus and some breakers
<azonenberg> and run stuff out to each unit
<azonenberg> i've actually considered an optional screw terminal input instead of barrel jacks
<azonenberg> So i can rack mount everything and just have terminal blocks for power
<electronic_eel> hmm, I don't know if it is worth it. lot's of things to consider, lots of small adapters and stuff needed, and I don't see that much to gain other than beauty
<azonenberg> well the point is more, i want to avoid dealing with the hassles of building mains powered gear especially since the overall power levels are fairly low
bvernoux1 has joined #scopehal
<electronic_eel> I can understand that. having mains in your device also changes a lot for compliance testing
<azonenberg> exactly
<electronic_eel> so from this pov I think an external psu is the best choice
<azonenberg> Yes, which means no mains trigger
<electronic_eel> the only thing I'm not sure about is how to do the connection to pe, or what is in the fine print for test equipment not having it
<electronic_eel> the mains trigger could be an external device, there should just be a conveniant way to power it
<azonenberg> the mains trigger device would obviously be mains powered :p
<electronic_eel> and plug it, like a dedicated input on the scope for it, but we can think about that later
<azonenberg> No we'd plug it into ext trig
bvernoux has quit [Ping timeout: 256 seconds]
<azonenberg> it would be a 1V p-p or so squarewave output
<azonenberg> re grounding
<electronic_eel> hmm, I'm just not sure if it is really enough to just spec that in the manual and be done with it.
<azonenberg> i mean at this phase in the design it won't change anything
<electronic_eel> if you'd have to put a psu into the case, you'd need a case with enough space in it
<azonenberg> there has to be a way to make DC powered test equipment legally
<electronic_eel> the pcb design is strongly affected by the case and case design
<azonenberg> worst case i think we can just use a non isolated mains supply, right?
<azonenberg> i.e. one with the negative DC rail earthed
<azonenberg> as a wallwart
<azonenberg> or do those not exist
<electronic_eel> yes, that would be an option. they are available, but more rare than the isolated ones
<electronic_eel> also the wire has to be thick enough, but I think that should be possible to find
<azonenberg> i still think a back side screw terminal ground is the best option, we'd simply specify the minimum required gauge
<electronic_eel> ok, so external mains it is
<electronic_eel> the backside screw terminal is the easiest solution to implement and will work well, it could just be a problem with regulation bodies somewhere in the world
<azonenberg> Yeah
<azonenberg> So here's a thought, 48V DC is SELV right?
<azonenberg> That would make us class III
<azonenberg> if you take a class III device and probe live mains with it, that's on you
<azonenberg> actually no it would be PELV because it would have an earth connection
<electronic_eel> if you sell it with a mains adapter, or even just list a mains adapter in your store accessories, or list a specific one as compatible, you are a class II device
<azonenberg> even if the output of that adapter is ELV?
<electronic_eel> class III is very rare for anything that is not battery powered
<electronic_eel> just stuff like usb mice
<azonenberg> yes but the usb mouse gets power from the computer power supply
<azonenberg> which is ELV sourced from mains
<azonenberg> and the usb shield is earthed
<azonenberg> through the computer chassis which connects to PE
<electronic_eel> exactly, but they sell the mouse without telling anything about power except to plug it into your pc
<azonenberg> even though the PC is all but guaranteed to be a class 1 device?
<electronic_eel> these regulations are strange, you have to live with it
juli969 has joined #scopehal
juli968 has quit [Ping timeout: 256 seconds]
<electronic_eel> it takes some time to get your head around it, and it is work I do not like
<electronic_eel> and I also think I am not good at it
<azonenberg> so a class II power supply apparently can't put out more than 30V if i'm reading this right
<electronic_eel> so take my words with a big grain of salt
<azonenberg> which would mean 48V is off the table anyway
promach3 has quit [*.net *.split]
<azonenberg> I guess that goes back to the original plan of a DC powered class I device
promach3 has joined #scopehal
<electronic_eel> are you sure about the 30v thing? I thought there are lot's of 48v ones available
<azonenberg> yeah that was one source i may have misread
<azonenberg> a class II device relies on being fully floating and *cannot* be earthed
<azonenberg> if you earth in any way shape or form it's not class II afaik. Even if it would otherwise meet the class II requirements
<electronic_eel> often they have a pe connection, but don't use it for safety, but for filtering capacitors. that is called functional ground
<azonenberg> my understanding is that if the chassis, for example, is earthed
<azonenberg> you cannot be class II
<azonenberg> or if anything the user can touch is
<electronic_eel> if the chassis is earthed, it is class I
<azonenberg> so the way i see it is, the DUT is presumably earthed
<azonenberg> we connect dut ground through a probe to the scope
<azonenberg> now all smas are earthed
<azonenberg> if there's a fault and we touch a probe ground to something hot, we've energized the entire chassis unless we have a separate earth connection for the chassis
<electronic_eel> but maybe that is the trick picoscope et al use: they say it is class I and the user has to connect the earth plug himself before operating it
<electronic_eel> but if it is optional, so the user can decide if to connect earth or not, then it is class II
<azonenberg> sooo that's one thing we could easily solve with my proposed screw terminal input :p
<electronic_eel> yes
<azonenberg> the back of the equipment is a terminal block with +24 or +48, power ground, and PE
<azonenberg> if you don't connect PE you've connected the equipment improperly and any problems are on the user
<electronic_eel> so how does the casual user connect a common psu to the screw terminal? do you expect the user to cut off the dc jack?
<electronic_eel> I have no problems doing that myself (done it often enough)
<electronic_eel> but some more professional users may have a problem with that
<azonenberg> well see, i was envisioning use of a rack-wide PSU with a terminal block on the back
<azonenberg> going to a din rail distribution block...
<azonenberg> :p
<electronic_eel> or is that for the "professional" level on your scope kickstarter, where you cut the dc jack for them?
<azonenberg> So it looks like telecom supplies are normally -48V DC with the high side connected to earth
<electronic_eel> yes, they do that against corrosion of the phone cables in the earth
<azonenberg> That's an option although we'd need to invert the rail at the input
<azonenberg> And it's a standard, common power source that regulators are likely familiar with
<electronic_eel> but the telco supplies are usually not connected to earth themselves, this is something that the installer does on the output
<electronic_eel> because they connect it to their really beefy ground connectors, lightning rated and so on
<electronic_eel> also some industrial users want the - connected to earth
<azonenberg> Yeah
<azonenberg> Negative earth is simpler for us
<azonenberg> let me look around a bit
<electronic_eel> but that is just what I have seen from several manufacturers yet, probably there is some psu out there that does it differently
<electronic_eel> 48v is also common in some datacenters, cisco for example has lot's of gear with 48v inputs available as option
<azonenberg> what do they use as input connector
<electronic_eel> I think they are screw terminals
<electronic_eel> or something proprietary
<electronic_eel> I think in datacenters it is more common to connect - to gnd
<azonenberg> Yeah
<electronic_eel> or have it floating and connect pe separately
<azonenberg> Here we go
<azonenberg> VES180PS48
<azonenberg> 48V, 180W which is overkill, 8 position rectangular connector (molex mini fit jr)
<azonenberg> it's rated as class 1 and datasheet explicitly states output return is connected to input ground
<azonenberg> So if we ship this with our unit we're class 1 with an earth, problem solved?
<azonenberg> no need for an integrated mains supply, no need for an external grounding lug
Error_404 has quit [*.net *.split]
Pretzel4Ever has quit [*.net *.split]
deltab has quit [*.net *.split]
vup has quit [*.net *.split]
wbraun has quit [*.net *.split]
_franck_ has quit [*.net *.split]
Bird|otherbox has quit [*.net *.split]
bvernoux1 has quit [*.net *.split]
LeoBodnar has quit [*.net *.split]
anuejn has quit [*.net *.split]
electronic_eel has quit [*.net *.split]
lain has quit [*.net *.split]
yourfate has quit [*.net *.split]
Implant has quit [*.net *.split]
miek has quit [*.net *.split]
smkz has quit [*.net *.split]
Kliment has quit [*.net *.split]
elms has quit [*.net *.split]
juli969 has quit [*.net *.split]
kc8apf has quit [*.net *.split]
laintoo has quit [*.net *.split]
Ekho has quit [*.net *.split]
megal0maniac has quit [*.net *.split]
promach3 has quit [*.net *.split]
awygle has quit [*.net *.split]
maartenBE has quit [*.net *.split]
noopwafel has quit [*.net *.split]
agg has quit [*.net *.split]
lukego has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
Degi has quit [*.net *.split]
monochroma has quit [*.net *.split]
tnt has quit [*.net *.split]
alexhw has quit [*.net *.split]
funkylab has quit [*.net *.split]
balrog has quit [Excess Flood]
yourfate has joined #scopehal
alexhw has joined #scopehal
agg has joined #scopehal
Implant has joined #scopehal
lain has joined #scopehal
wbraun has joined #scopehal
Kliment has joined #scopehal
smkz has joined #scopehal
noopwafel has joined #scopehal
elms has joined #scopehal
miek has joined #scopehal
lukego has joined #scopehal
bvernoux1 has joined #scopehal
anuejn has joined #scopehal
electronic_eel has joined #scopehal
Bird|otherbox has joined #scopehal
LeoBodnar has joined #scopehal
gruetzkopf has joined #scopehal
funkylab has joined #scopehal
Error_404 has joined #scopehal
_franck_ has joined #scopehal
Pretzel4Ever has joined #scopehal
deltab has joined #scopehal
vup has joined #scopehal
_whitelogger has joined #scopehal
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #scopehal
<bvernoux> yes
<bvernoux> my HydraNFC v2 firmware beta is working !!
<bvernoux> It manage all types of NFC with anticoll and compliance ;)
maartenBE has quit [Read error: Connection timed out]
<azonenberg> electronic_eel: did you see my last link before the split?
maartenBE has joined #scopehal
bvernoux has quit [Quit: Leaving]
promach3 has joined #scopehal
juli969 has quit [Quit: Nettalk6 -]