<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 - https://git.io/Jf5fm
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #151: Add support for configuring channel bit depth on LeCroy HDO9000 series - https://git.io/Jf5fm
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #151: Add support for configuring channel bit depth on LeCroy HDO9000 series - https://git.io/Jf5fm
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] https://git.io/Jf5TW
<_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] https://git.io/Jf5kk
<_whitenotifier-f>
[starshipraider] azonenberg 10bcce1 - Left pods
<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] https://git.io/Jf5cX
<_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 8.6.3.3.7
<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
<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>
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
<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?