<d1b2>
<azonenberg> This is a quick and dirty console test application that opens up a bunch of shared memory regions and a socket
<d1b2>
<azonenberg> using the FastWavePort feature on the scope
<d1b2>
<azonenberg> and spits out waveform data every trigger just like our pico, dslabs, etc. bridges do
<d1b2>
<azonenberg> So far i'm sending to netcat /dev/null clientside, there's no scopehal driver to actually crunch the data
<d1b2>
<azonenberg> but i'm sustaining 800-900 Mbps of throughput - likely saturating the 1G uplink on the switch the scope is plugged into since i have other stuff running on that network
<d1b2>
<azonenberg> compare this to the 200-400 sporadic rate i get using SCPI to download waveforms
<electronic_eel>
does your revamped scope now have a 10gbe port (or a free pcie-socket you could use to plug a nic into)?
<electronic_eel>
or maybe a free m.2 slot or the like that could be repurposed for this?
<azonenberg>
It does not have a 10G interface but it has plenty of pcie
<azonenberg>
i would need to shut the scope down, unrack it, and take off the top panel
<d1b2>
<david.rysk> I think that would be worth doing
<azonenberg>
This is on my list of things to explore at some point in the future, but not immediately as any time this scope powers up from cold it blows GFCIs on adjacent circuits
<azonenberg>
so i have to plan a maintenance outage for the entire lab around it
<electronic_eel>
if you are able to performance tune this fastwave interface to get more than 1gbit data out, i think it could make sense to sometime do this
<azonenberg>
yes
<azonenberg>
absolutely
<electronic_eel>
also i'm wondering why the psu in it blows your gfcis. that doesn't sound like a well engineered solution to me
<electronic_eel>
i mean at the price point of this scope i would expect them to care for such things, and adding 100 bucks more bom costs for a slow-start circuit in the psu wouldn't matter much in the whole picture
<azonenberg>
Sooo i'm suspecting it has something to do with being on my double conversion UPS with a transformer on the output
<azonenberg>
UPS is L1/L2 only no neutral
<azonenberg>
the bypass module (eaton 9PXPPDM2) has a 1:1 center tapped transformer to derive a new neutral
<azonenberg>
i am NOT treating this as a separately derived service and bonding neutral to ground in the subpanel because i called eaton apps engineering twice and both times was told this was not necessary
<electronic_eel>
is this new neutral tied to your ground or not? i understand it as it is not
<monochroma>
azonenberg: does the scope support 240VAC? just run a dedicated 240 circuit to it :P
<azonenberg>
there is no connection between neutral and bond in the breaker panel on the UPS output, i explicitly isolated them
<d1b2>
<david.rysk> oh yeah if equipment runs on 240 then you're generally better off doing that anyway as power supplies are usually more efficient 😛
<azonenberg>
neutral and ground*
<azonenberg>
the simplified circuit diagram of the PPDM in the manual does not show a connection internally either
<electronic_eel>
hmm, yes, then this could cause the gfci issue
<azonenberg>
so next outage i'm very tempted to add a connection there
<azonenberg>
and see what happens
<electronic_eel>
the question is are there any downsides to doing this? i don't immediately see them
<azonenberg>
Yes. I dont either
<electronic_eel>
but i'm not familiar with us regulations in this detail
<azonenberg>
you could hypothetically create a really short ground loop between the PPDM and the panel
<azonenberg>
but its a couple of feet of cable and i doubt there'd be any significant current flow
<d1b2>
<david.rysk> you might find that there's some voltage between ground and "neutral"
<azonenberg>
yes
<azonenberg>
That is kinda my suspicion
<azonenberg>
due to uneven load on the two legs
<d1b2>
<j4cbo> 120/240 split-phase is such a pain
<electronic_eel>
yeah, true 3 phase is much better
<d1b2>
<david.rysk> true 3 phase has its own set of challenges
<d1b2>
<david.rysk> wye vs. delta etc
<electronic_eel>
i recently saw some links to a induction cooking field that included a bunch of liion batteries. just that it can be used fully with just 2 phases. crazy.
<azonenberg>
wait waht
<d1b2>
<j4cbo> blows GFCIs on adjacent circuits?
<azonenberg>
j4cbo: yes
<azonenberg>
three of the eight breakers in the panel blew, with LED codes indicating a ground fault, when i powered the scope up
<azonenberg>
(the scope wont boot at all if *it* is on a gfci, it insta-blows)
<azonenberg>
once the scope comes up you can reset the other breakers, so its not a continuous leak
<azonenberg>
its only the surge at powerup
<azonenberg>
everything seems to point to neutral drifting above 0V
<azonenberg>
that reminds me of how some phones/laptops require a battery installed even if plugged into a charger
<azonenberg>
because their peak power demand exceeds what the charger can supply
<azonenberg>
and they use the battery to cover the shortfall
<electronic_eel>
yeah, that is common
<electronic_eel>
they also need the battery to boot and configure the charge control ic
<electronic_eel>
so if the charge runs below that minimum, you have to pull out the battery and charge it externally
<azonenberg>
(I wish they could just power-OR properly, ideally allowing battery hotswap. a lot of older laptops supported that which was really handy if you were on the go but could steal mains for a minute or two at a time in the middle)
<electronic_eel>
oh, wait, you can't pull out the battery in modern phones anymore
<azonenberg>
lol
<miek>
has anyone tried out these vertical launch SMA connectors with a spring contact (e.g Bel Fuse 141-0701-231 or SV Microwave SF2921-61345-1S)? they look interesting, it'd be nice to have a good reusable connector that doesn't need any soldering, for test boards
<azonenberg>
miek: that looks exactly like what LeoBodnar's SMA output pulse generator uses
<azonenberg>
the sv part in particular
<azonenberg>
the problem i ran into there is that the connector from the factory was overtightened, which had pushed the center pin too far forward as measured on my connector gage
<azonenberg>
so i remove it, it didnt make great contact
<azonenberg>
apparently in an effort to improve yield they had added a bit of solder to the center pad which caused the push-out problem
<azonenberg>
but if you didn't do that it tended to fail open
<azonenberg>
(i tried using some braid to remove the solder)
<azonenberg>
i think part of the problem is that they were doing via-in-pad on the center pin but not actually using a dedicated ViP process
<azonenberg>
and so there were planarity issues where the via was plated thicker than the rest of the PCB or something?
<azonenberg>
i'm not sure but i dont use that pulse gen very much as i found it difficult to get reliable contact
<azonenberg>
so i use the BNC one instead
<d1b2>
<j4cbo> the old titanium powerbooks had a backup battery for DRAM refresh, so you could sleep the machine and swap the main battery without having to be plugged in at all
<azonenberg>
yeah several $dayjob laptops ago it had IIRC two batteries
<azonenberg>
a fixed internal and a hotswappable external
<azonenberg>
it would draw from the external preferentially
<azonenberg>
So you could use the internal to cover a swap of the external battery with no grid power
<azonenberg>
just tinned over the hole on the connector side
<miek>
ah right, yeah that does sound like it could cause some issues
<miek>
the ones i linked to are the microstrip variants, where they've got a little channel for the trace to exit on the same side
<azonenberg>
ah ok i havent used that style
<d1b2>
<20goto10> Who's responsible for msys2 packaging for scopehal-apps?
<azonenberg>
i dont think anyone is actively maintaining it right now. This state is likely to continue, because we are moving towards a native windows build free of GTK and mingw dependencies in the future
<azonenberg>
so at some point we'll just ask msys2 folks to stop distributing the obsolete package
<d1b2>
<20goto10> Ah fair enough!
<azonenberg>
this is one of the big benefits of ngscopeclient
<azonenberg>
it will let us leave all of that horribly complex build system in the trash
<azonenberg>
and instead just use cmake to generate a visual studio project
<azonenberg>
and compile natively
<d1b2>
<20goto10> What's the rough timeline on ng ooi?
<azonenberg>
ng is usable for most work that is temporary and does not require saving and loading session files today
<azonenberg>
session file load/save has been on ice since december because we had planned to contract it out to lain (so i wasn't doing it) and administrative/paperwork issues delayed that
<d1b2>
<zyp> I had a Dell laptop where you could swap the optical drive with a second battery
<azonenberg>
ultrabay? no, that was the lenovo name
<azonenberg>
anyway, other than that there's a few random other odds and ends needed for ng
<azonenberg>
spectrogram / waterfall / histogram rendering shaders have to get ported
<d1b2>
<zyp> and I had two batteries of each kind, so I could switch either while running on the other
<azonenberg>
multiscope sync wizard and export wizards have to be ported
<azonenberg>
horizontal cursors i think are still pending, as are statistics
<azonenberg>
lots of random little stuff
<azonenberg>
i've been super busy and not spending a lot of time on it myself, partly because my big scope that i do a lot of my dev on was gone
<azonenberg>
and just came back
<azonenberg>
and now i'm working on the fastwaveport lecroy driver rather than ng core
<azonenberg>
but hopefully that will only take another few days