<azonenberg>
in the 8M point example the waverunner is doing 50M points/sec or ~403 Mbps plus protocol overhead of waveform throughput
<azonenberg>
meanwhile in the 500K*4 example the MSO64 is doing 8.6M points/sec or 68.8 Mbps
<azonenberg>
Meaning the lecroy is almost six times faster
Ekho has joined #scopehal
<d1b2>
<mubes> Wow, that's a scary speed difference. By way of comparison, what is the price range of the lecroy (seems relatively difficult to get pricing for it from the web)
<azonenberg>
The WaveRunner 8K series is discontinued, 9K is current
<azonenberg>
But it's still supported for quite a few years, they offer support for at least 7 years after last sale date
<azonenberg>
Generally lecroy factory refurbs are around 50-70% of MSRP. My 8404M-MS was $20K asking price, so probably high 30s to low 40s MSRP
<azonenberg>
(that's before software options, which they were nice enough to transfer over from my old 1 GHz waverunner but would have easily added $5-10K to the price tag otherwise)
<azonenberg>
I actually paid $13K plus trade-in of my 1 GHz WaveRunner 8104-MS
<azonenberg>
I'm amazed at how slow other scopes are over LAN vs the LeCroy stuff. I'm spoiled i guess :p
<azonenberg>
And here i am not satisfied with performance of the LeCroy gear and wanting to build stuff that will hit 60+ FPS on multimillion point waveforms
<azonenberg>
it seems like any time i attempt to do the slightest bit of optimization on the Tek driver i have to undo it
<azonenberg>
because i get 410 Query INTERRUPTED errors
<azonenberg>
in which the instrument basically freezes up
<azonenberg>
it seems like it has zero buffering
<azonenberg>
you can't send a command before it's fully executed the last one
<azonenberg>
WTF
<azonenberg>
this is a linux based platform apparently running ubuntu LTS internally
<azonenberg>
It seems like adding *OPC? after every single write command to provide synchronization fixes (so far) all of the stability problems
<azonenberg>
at the cost of an unbelievable performance impact
<azonenberg>
1.79 WFM/s on 10k points 4 channels
<azonenberg>
I really wanna get my hands on some keysight gear
<azonenberg>
from what i've seen they seem to be more interested in supporting daq-type use cases than tek
<azonenberg>
and hislip looks interesting
<azonenberg>
liblxi allegedly supports it
<azonenberg>
and it lets you do async commands and other cool stuff
<azonenberg>
meanwhile this tek is still stuck in the 1980s requiring lock-step single commands with a *OPC? top ensure you don't send one before the last has finished executing. Because apparently the thing doesn't understand the concept of a FIFO
<azonenberg>
This isn't GPIB anymore...
<azonenberg>
There's also a race condition of sorts: If you enable a channel after the trigger took place but before reading waveform data
<azonenberg>
the scope will display a blank channel on the screen with no data (as expected)))))))
<azonenberg>
But the instrument lies: DAT:SOU:AVAIL? returns the channel
<azonenberg>
since it's turned on
<azonenberg>
but there's no data, so CURV? will just hang with no response
<_whitenotifier>
[scopehal] azonenberg opened issue #386: SCPITMCTransport: reading a reply via multiple ReadRawData() calls fails - https://git.io/JLWJj
<_whitenotifier>
[scopehal] azonenberg labeled issue #386: SCPITMCTransport: reading a reply via multiple ReadRawData() calls fails - https://git.io/JLWJj
<_whitenotifier>
[scopehal] azonenberg labeled issue #386: SCPITMCTransport: reading a reply via multiple ReadRawData() calls fails - https://git.io/JLWJj
<_whitenotifier>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±16] https://git.io/JLWIV
<_whitenotifier>
[scopehal] azonenberg 4fd83b8 - SCPITransport: added some queueing helpers
<_whitenotifier>
[scopehal] azonenberg closed issue #185: Expose actual number of bytes transferred in ReadRawData and possibly other commands - https://git.io/JJ4uf
<azonenberg>
With some improvements to timeout handilng the OPC? hack is no longer needed
<azonenberg>
you still get a several second hang when the bug hits, which isn't ideal
<_whitenotifier>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLWqd
<_whitenotifier>
[scopehal-docs] azonenberg 540c85c - Updated docs for Tek MSO6
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLWme
<_whitenotifier>
[scopehal] azonenberg 8dee702 - TektronixOscilloscope: initial support for command queueing (see #179), take two. Also added better timeout handling and a bunch of other fixes.
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JLWwz
<d1b2>
<atx> azonenberg: Ideally, there should be some way to toggle "preview" mode and "repeated single shot mode"
<azonenberg>
Yes
<azonenberg>
I'm actually hitting that on MSO6 as well
<d1b2>
<atx> Because using the UI with 0.1WFM/s is just extremely frustrating
<azonenberg>
it has a "fast acquisition" mode which i believe decimates
<azonenberg>
Write queueing will definitely improve that
<azonenberg>
I am doing dev on that now and the Tek driver supports it
<azonenberg>
it needs to be tested more before i'm ready to roll it out to more drivers though
<azonenberg>
(There is currently no nonblocking read support)
<d1b2>
<atx> miek: Right, the fact that two separate read commands might come from different display frames is indeed something that could easily happen
<azonenberg>
Yeah and I really want to avoid breaking analysis
<azonenberg>
I want performance but not at the cost of inaccurate results
<d1b2>
<TiltMeSenpai> what decoders are broken by the downsampling and on which ones are live results important anyways?
<d1b2>
<TiltMeSenpai> I assume FFT would be the worst contender here?
<azonenberg>
Any kind of protocol decode
<azonenberg>
i routinely do multimillion point decodes of say ethernet or pcie
<azonenberg>
And i'm only sampling at say 4x the data rate
<d1b2>
<TiltMeSenpai> mmm, I see
<azonenberg>
obviously you have to zoom in to see it all, but it also livestreams to the protocol analyzer view etc
<d1b2>
<TiltMeSenpai> yeah, that would be a problem
<azonenberg>
eye patterns need as much sample rate as they can get
<azonenberg>
again, the end goal of glscopeclient is to be able to handle *tens of Gbps* of streaming waveform data
<azonenberg>
cutting corners to get faster update rates on a 1K point waveform seems exactly the opposite of what we should be aiming for
<azonenberg>
especially if it breaks any kind of decoding on that data
<d1b2>
<TiltMeSenpai> it's not glscopeclient here though, the Rigol scopes just won't shovel data off themselves fast enough
<azonenberg>
Yeah i know
<azonenberg>
my point is more, glscopeclient is oriented around complex analysis and decoding
<azonenberg>
if you just want to see the waveform use the scope front panel
<azonenberg>
i'm just struggling to find a situation in which downsampling the streaming data is beneficial
<azonenberg>
sure it looks cool to have high framerate data but if it's not useful, what's the point
<azonenberg>
especially if you risk losing sync between channels
<azonenberg>
Optimizing the UI to handle high latency instruments is important, i agree
<d1b2>
<TiltMeSenpai> yeah, I think I see your point. It feels like prioritizing decoupling UI from waiting on the scope is the priority for lower performance scopes in that case, right
<d1b2>
<atx> Being able to display partial waveforms would really help in this case
<d1b2>
<atx> Though, I do not know if the scope takes ages to format the data and then sends it instantly or if it gets sent at slow pace continuously
<azonenberg>
That's 800K points on 2 channels, sampling 5 Gbps data at 40 Gsps
<azonenberg>
So 8x oversampling. you need a min of 3-4x to do clock recovery reliably. Downsample any more than that and it's useless
<azonenberg>
And for jitter analysis you really need as much sample rate as you can get
<d1b2>
<TiltMeSenpai> this is likely the wrong way to solve the problem, but would it help if the scope driver could report different sample rates for single shot and continuous mode?
<d1b2>
<atx> This is already a part of the preambule
<azonenberg>
I mean you *have* to do that in order to get the downsampled waveform displayed correctly
<azonenberg>
But that won't make the missing data magically appear
<d1b2>
<TiltMeSenpai> lol, I feel I don't know enough about the architecture of glscopeclient here to help. Maybe I should just be quiet
<azonenberg>
Everything works in real time/voltage units. There's no "divisions"
<azonenberg>
Memory record length, sample rate, and display zoom are completely independent and you can adjust them arbitrarily
<azonenberg>
you can have arbitrarily many views of the same waveform each showing a different region of it at a different scale
<azonenberg>
And this is done by storing a scaling factor in fs/Hz/other X axis units to pixels for each viewport independently
<azonenberg>
the actual scaling is done in a shader
<d1b2>
<atx> azonenberg: Have you looked into running a custom data acquisition software on the lecroys?
<azonenberg>
i mean you can run glscopeclient on it :p
<azonenberg>
But i wanted to make it even faster
<azonenberg>
I had a friend who worked there and had written a C# module that wrapped the lecroy COM APIs
<d1b2>
<atx> Yes, but I mean bypassing the standard communication stack entirely
<azonenberg>
and went straight to their driver module bypassing the SCPI and VICP layers
<d1b2>
<atx> Oh wait, they even provide official way to do that?
<d1b2>
<atx> "who worked there" - I guess not
<azonenberg>
Kinda-sorta. It's COM so there's an OO interface internally, but it wasnt really documented
<azonenberg>
he had all the contact with developers in order to figure out the details
<azonenberg>
He was in the final stages of polishing it up for release
<azonenberg>
Then covid hit and there were a bunch of layoffs
<azonenberg>
Him included
<azonenberg>
That said, I can get to a pretty good fraction of the theoretical limit already. So it's not top priority
<azonenberg>
with deeper waveforms especially (there seems to be some overhead per trigger)
<azonenberg>
But i've been able to push 400+ Mbps of waveform data to glscopeclient
<azonenberg>
Silly me assuming that this level of performance was universal, lol. I actually assumed this would be bare minimum and tek/keysight would be able to saturate gig
<azonenberg>
So i'm quite disappointed at this $$$$ Tek that is getting single digit framerates
<azonenberg>
Good news is i didn't actually *buy* it it's on loan from a friend :p
<d1b2>
<atx> I honestly still don't get why is everything this slow
<azonenberg>
Me neither
<_whitenotifier>
[scopehal] tomverbeure commented on issue #386: SCPITMCTransport: reading a reply via multiple ReadRawData() calls fails - https://git.io/JLloQ
<d1b2>
<atx> The firmware format for the Rigols has been reverse engineered
<d1b2>
<atx> So I might be able to stare at the binary and see
<miek>
i think that they either didn't consider this use case, or didn't care about it
<_whitenotifier>
[scopehal] azonenberg commented on issue #386: SCPITMCTransport: reading a reply via multiple ReadRawData() calls fails - https://git.io/JLloA
<d1b2>
<TiltMeSenpai> do scope manufacturers not expect you to try to do real-time interaction on a separate machine?
<d1b2>
<atx> Apparently not
<azonenberg>
honestly, i dont think they do
<azonenberg>
LeCroy at least sells a headless version of the WaveRunner 8000 series
<azonenberg>
in a 2U rackmount
<azonenberg>
targeting ATE and factory production etc
<d1b2>
<TiltMeSenpai> why would you leave the walled garden, look at all the pretty plants we're giving you
<azonenberg>
So it is a consideration for them to some extent
<azonenberg>
Yeah. Pretty plants that cost thousands of dollars each :p
<azonenberg>
When you can just go out on github and pick some wild ones :p
<azonenberg>
Anyway, this whole disaster is why building our own open-hardware scope has always been the endgame
<azonenberg>
And if anybody is interested in contributing i have one main blocker in the engineering phase stopping BLONDEL from being ready to go to schematic/layout
<d1b2>
<TiltMeSenpai> definitely interested but I doubt I'm capable
<azonenberg>
(100 MHz 1 Gsps 8-channel 8/12 bit scope in 1U headless form factor)
<azonenberg>
So, I consider 1M ohm high-Z probes deprecated
<azonenberg>
Transmission line probes are lower loading at surprisingly low frequencies (tens of MHz)
<azonenberg>
and it's fairly easy to build an active probe for when you truly need high Z at low frequencies
<azonenberg>
an active 10 MHz probe is easy :p
<azonenberg>
As a result, all of my hardware will be 50 ohm inputs, most likely SMA because it makes it more obvious that these are 50 ohm RF inputs and not 1M which is what people assume BNCs on a scope are
<azonenberg>
by deliberately not using BNC i make it less likely some idiot will complain their cheap 1M ohm probe doesn't work with it :p
<azonenberg>
Anyway, I do want to support active probes eventually, which means having a power/data interface to go alongside the SMA
<azonenberg>
The decision has been made that we are using USB-C
<azonenberg>
It's a readily available connector with plenty of pins for data and power
<azonenberg>
The plan is to develop a custom alt mode which uses SSTX for +7VDC and SSRX for -7VDC power to run the probe head (so no need for SMPSes in the probe, less noise)
<azonenberg>
Just LDOs off these bipolar rails
<azonenberg>
Then +5V Vbus and the USB 2.x D+/D- lines will be used for running the MCU and communicating settings like gain/offset from the probe head to the scope
<azonenberg>
I need someone to design this system
<azonenberg>
Host side interface: supply +/- 7VDC and +5VDC. SPI interface that lets me send messages to the probe, query descriptor/presence state of the probe, and probably forcibly power cycle it
<azonenberg>
then some GPIO outputs to external load switches to gate the Vbus and analog power rails
<azonenberg>
Probe side interface: +/- 7VDC power and i2c/spi plus some GPIOs for talking to DACs etc
<d1b2>
<david.lenfesty> Is there somewhere this is being tracked? i.e. GH or something
<d1b2>
<david.lenfesty> I can see myself being interested but it depends on how my semester starts
<d1b2>
<TiltMeSenpai> will the scope side have the chance to handshake before enabling the +/- 7vdc
<azonenberg>
The starshipraider github is the location for the project
<azonenberg>
But there arent many tickets on the hardware side
<azonenberg>
i've been too busy to do any of that
<azonenberg>
i want a working prototype of the whole system. A key requirement is that it be compatible enough with actual USB devices that no damage will occur if cross-mated
<azonenberg>
This means
<azonenberg>
1) using the same pinout as real USB
<azonenberg>
2) Having Vbus be actual 5V and enumerating via actual USB on the D+/D- lines
<azonenberg>
3) Not being damaged if USB 3.0 signaling is applied to the analog power rails
<azonenberg>
4) Not enabling +/- 7VDC until you've confirmed you are talking to an actual probe via a straight through (not e-marked) cable with no intervening hubs
<azonenberg>
5) Immediately removing +/-7VDC once the probe is unmated
<azonenberg>
The actual negotiation may be via USB PD (the official alt function API) or a custom protocol over USB 2.0
<azonenberg>
I dont care
<_whitenotifier>
[scopehal] tomverbeure commented on issue #386: SCPITMCTransport: reading a reply via multiple ReadRawData() calls fails - https://git.io/JLlif
<azonenberg>
USB-IF logo certification is not a design requirement. I will not be advertising USB compliance or using USB trademarks/logos
<azonenberg>
Just using USB-C as a commonly available cable
<azonenberg>
So the probes will probably use a testing/reserved VID/PID because IDGAF
<azonenberg>
but i might try and get one from openmoko or something just because
<azonenberg>
The deliverables for this are two dev boards. One pretends to be the scope and takes in +12V on a barrel jack, the other pretends to be the probe and has some GPIO LEDs or something plus a big power resistor pretending to be the analog circuitry
<azonenberg>
(so we can measure voltage drop across the cable etc)
<d1b2>
<TiltMeSenpai> do you want the device to enumerate if plugged into a computer?
<azonenberg>
And all required firmware to at least be confident it will work
<azonenberg>
It does not need to be production ready firmware. It needs to be complete enough that i can spin a board with that schematic on it
<azonenberg>
and be confident we can finish the firmware later
<azonenberg>
There are no currently existing active probe designs
<azonenberg>
I just dont want to make BLONDEL until i know it will be compatible with them once built
<d1b2>
<TiltMeSenpai> the simplest option seems to be have the pod present as a debug accessory, handshake over SBU, then enable the +/-7VDC
<azonenberg>
That is not critical. But it would be nice if we could do USB DFU or something
<azonenberg>
There does need to be a data channel between probe and scope for setting various parameters and querying the type of probe
<azonenberg>
uart over SBU or something might work, and could potentially be lower noise than having USB data signaling with keepalives going all the time (no traffic unlkess you twiddle a knob)
<azonenberg>
heck, 3.3V UART over D+/D- would work :p
<azonenberg>
I don't care about the specifics
<d1b2>
<TiltMeSenpai> I2C over SBU? We would have the option of choosing all the involved mcu's so I2C weirdness doesn't need to be as big of a concern
<azonenberg>
The requirement is it needs to not fry the probe, scope, or whatever else you might cross mate it to
<azonenberg>
If i plug my phone or heaven forbid a usb-c laptop charger into the scope it needs to not die
<azonenberg>
so as a minimum backfeed of +5V into Vbus needs to be survivable
<azonenberg>
Again, I'm not picky
<azonenberg>
I just want it to be idiotproof if somebody crosses cables
<azonenberg>
Think of all combinations of usb-c endpoints and make sure nothing will fry
<azonenberg>
Functionality is not required
<d1b2>
<david.lenfesty> do you have any sort of timelines you're looking for? I'm absolutely interested but I won't be able to start or even know if I have time until like mid-to-late january
<d1b2>
<david.lenfesty> unless I do that thing where I start 5 new projects when I get a tiny amount of free time
<azonenberg>
This has been on ice since the BLONDEL analog front end and ADC characterization boards were tested and developed in March
<d1b2>
<david.lenfesty> I see
<azonenberg>
basically the next move for BLONDEL is to design an acquisition board containing four copies of the frontend with the identified bugs from the prototype fixed
<azonenberg>
one copy of the ADC circuit
<azonenberg>
and four copies of this probe control circuit
<azonenberg>
Then design an FPGA board that mates with two of them
<azonenberg>
and we can start doing firmware
<azonenberg>
I intend for BLONDEL to be scalable to one or two acq boards so you can reduce the cost of the scope during inital purchasing
<azonenberg>
then buy/make another acq board if you want the other four channels
<azonenberg>
or swap out boards if one fries
<azonenberg>
individual channels will not be LRUs but will obviously be repairable via hand SMT rework if you blow something
<azonenberg>
although i think i did a decent job on the input protection
<azonenberg>
All of the higher end scopes will have individual channels on separate boards , possibly linked to the ADC as well
<d1b2>
<david.lenfesty> hrm I would really want to just spec deliberately out-of-spec values for CC1 & CC2 resistors but I don't know how much I trust vendors to stay in spec
<d1b2>
<TiltMeSenpai> I think the debug accessory mode is the "most correct" way to do this
<d1b2>
<david.lenfesty> ah yes, that looks like the ticket
<d1b2>
<TiltMeSenpai> there's a simple resistor-based debug mode that lets you use 7 pins (14 if you do orientation detection) for "vendor defined purposes"
<d1b2>
<TiltMeSenpai> I think you're supposed to keep signals between 0 and 5v but as long as we gate the 7VDC power behind some type of handshake, I don't see us accidentally frying anything
<d1b2>
<david.lenfesty> lol instead of DFU just embed a CMSIS DAP adaptor inside our host controller and bridge SWD over the debug mode
<d1b2>
<david.lenfesty> yeah debug accessory mode looks basically purpose designed for what we'd need
<d1b2>
<david.lenfesty> and was pretty much what I was looking for
<d1b2>
<TiltMeSenpai> I say we use SBU for the low speed link, since that's essentially what it was designed for and should be spec-compatible even if we don't detect as a debug adapter successfully
<d1b2>
<TiltMeSenpai> if we keep D+/D- as USB, we will need a DFU board or jumpers to overwrite the debug adapter CC values with legacy USB ones, but that's no big deal
<d1b2>
<david.lenfesty> makes sense yeah
<azonenberg>
I'd say connect pins such that we could run USB over D+/D- if we desired
<azonenberg>
but also provide a low speed SBU based interface. I think uart is better than i2c because cable capacitance on potentially several feet of cable
<azonenberg>
But ideally pick pins usable for both :P
<d1b2>
<david.lenfesty> Yeah I think we'd have to do orientation detection
<azonenberg>
For sure
<d1b2>
<david.lenfesty> SBU is UART, D+/- is optional USB
<d1b2>
<TiltMeSenpai> oh, I only said I2C because that would let us stick additional "things" on the bus other than the power management MCU
<d1b2>
<TiltMeSenpai> but UART is also ok
<azonenberg>
tiltmesenpai: i was assuming there was a MCU on the probe
<azonenberg>
which would then bridge to whatever
<d1b2>
<david.lenfesty> Yeah I assumed this was a 1-1 link
<azonenberg>
i wanted one common interface from the scope that i could bridge to whatever the particular probe needed
<azonenberg>
Yes this is 1:1
<d1b2>
<TiltMeSenpai> yeah, in that case UART might be better
<d1b2>
<david.lenfesty> And then do we want to just bridge everything else as GPIO?
<d1b2>
<david.lenfesty> at least for the first draft
<azonenberg>
For the prototype sure. long term i will probably just not use them
<d1b2>
<david.lenfesty> yeah I don't see a real use for them
<azonenberg>
LeCroy ProBus is +/- 12V and I2C
<d1b2>
<david.lenfesty> but I don't see a reason not to for a prototype
<azonenberg>
then a resistor based presence detection flag shared with the probe boundary ring
<azonenberg>
and ground
<d1b2>
<TiltMeSenpai> do we just use all SS+ as +7v and all SS- as -7v then? I don't think we have enough pins needed to justify bothering with orientation detection
<azonenberg>
Yes that is my plan
<azonenberg>
more current handling capacity too
<d1b2>
<TiltMeSenpai> yeah
<azonenberg>
Also 7V is not 100% the final voltage. might go up to 8 or something TBD
<azonenberg>
but that should just be a BOM change on the scope
<azonenberg>
basically "bipolar rail derived from +12V with sufficient headroom to LDO to +/-5ish for an active probe"
<d1b2>
<david.lenfesty> I mean there's only two SBU pins
<d1b2>
<TiltMeSenpai> any plans for voltage negotiation? out of curiosity, I don't think it'll change anything for this phase
<d1b2>
<david.lenfesty> we need to do orientation detection there
<azonenberg>
We cooould cheat
<azonenberg>
arent there four D+/D- pins to allow inversion?
<azonenberg>
symmetric?
<azonenberg>
we could just put TX on D+ and RX on D-
<azonenberg>
Lol
<d1b2>
<TiltMeSenpai> "orientation detection" as in not at the PD level 😛
<d1b2>
<david.lenfesty> oh yeah no PD
<d1b2>
<david.lenfesty> that's too much
<d1b2>
<david.lenfesty> I can see it being useful to add a bit in the protocol for requesting different voltages
<d1b2>
<david.lenfesty> I.e. during enumeration the probe specifies the voltage it needs
<azonenberg>
Yes. The MCU will be powered by Vbus
<d1b2>
<TiltMeSenpai> upon power up, the pod sends a hello on SBU1, scope uses that to set TX/RX, then acks the hello on SBU2
<azonenberg>
there's room for it to negotiate what it wants to see on SS+/SS-
<azonenberg>
That would work. So orientation detection managed entirely host side. If we're not doing real USB what about using a small FPGA instead of MCU for the host?
<azonenberg>
that would let us use one for all four
<azonenberg>
and easily swap uart tx/rx dynamically
<azonenberg>
then a stm32 on the probe side
<d1b2>
<TiltMeSenpai> ah, that would work
<azonenberg>
then have pullups/downs on D+/D- in order to detect probe insertion/removal?
<azonenberg>
Since we need to kill the 7V if the probe is pulled out
<d1b2>
<david.lenfesty> CCx could be used for detection as well
<azonenberg>
anyway it sounds like you've got a good plan
<azonenberg>
Do you think you can have some semblance of progress by the end of january?
<d1b2>
<TiltMeSenpai> let me check if it'll detect an unplug event
<azonenberg>
I want the prototype to be as close as possible to the final system configuration
<azonenberg>
the idea is to just re-layout the same schematic on the actual board
<azonenberg>
to minimize risk of respinning a relatively expensive board with a $100+ ADC and a bunch of analog frontend components on it
<azonenberg>
If we have to do a few iterations of prototyping that's fine
<d1b2>
<david.lenfesty> I would say spinning schematic/layout could be pretty easily done in a weekend
<d1b2>
<david.lenfesty> code would take longer
<d1b2>
<TiltMeSenpai> mouser has them for $1.36@100, it'll probably be easier than trying to figure out all the USB PD possibilities ourselves
<d1b2>
<david.lenfesty> especially fi we collabed
<azonenberg>
Great. If you've got time this weekend want to do it as part of the hackathon? it's officially just for glscopeclient but hardware is totally in scope
<azonenberg>
If not, whenever you do have time
<azonenberg>
Maybe also ping @einthecorgi2
<azonenberg>
They indicated interest back in april-ish then kinda ghosted me
<azonenberg>
So no idea if any progress was made or not
<d1b2>
<david.lenfesty> this weekend is a hard no, it would be over christmas break or once the next semester starts mid-to-late Jan.
<azonenberg>
But probably worth attempting to sync up
<azonenberg>
Sure, not a rush
<azonenberg>
It's waited since March, another few weeks is no problem
<azonenberg>
My big two priorities on hardware are getting MAXWELL done (on hold for budgetary reasons right now) and getting the probes fine tuned to the point that I can start offering them for sale
<azonenberg>
If i can get a few bucks from selling assembled probes i can then spend that on BLONDEL R&D
<d1b2>
<TiltMeSenpai> I can probably do an initial prototype of the scope side that takes +5, +/-7v, just to check all the controllers and handshake process
<d1b2>
<TiltMeSenpai> and we can deal with the scope side regulation after we get the probes handshaking properly
<azonenberg>
(my hope is to subsidize development of each new instrument/accessory from sales of assembled units of the previous instrument)
<azonenberg>
TiltMeSenpai: Yeah make it take in +/- 7V from a bench supply then LDO +5 off the +7 or something?
<azonenberg>
(three rails is a bit much for one board since common bench supplies are 2 output)
<azonenberg>
And do you mean this weekend?
<azonenberg>
Or are you busy until later too
<d1b2>
<TiltMeSenpai> I'll try. I had some personal shit happen this week, so I'm still trying to get back into a productive mindset, but getting there
<d1b2>
<TiltMeSenpai> I'm at a point where I can give it a shot, but I don't want to promise anything
<azonenberg>
OK
<azonenberg>
Again not a rush, just want to keep expectations clear
<azonenberg>
Re the AKL-PT2 UPS apparently has decided to have a delay. So my Shore A25 silicone isn't coming until Monday, oh well
<azonenberg>
It's going to be inexpensive enough I don't plan on doing a kickstarter. I'll just start offering assembled units via lain's store and make an announcement on twitter when that happens
<azonenberg>
I'm thinking the PCBs will probably be single digit USD in moderate volume, then about $6 of resistors and $10 of SMA means about $20 plus silicone per unit. I can probably afford to sell assembled units (without full characterization data) for like $40-50
<azonenberg>
That should be cheap enough to be very accessible to hobbyists while still being enough that I'm not losing money on it
<azonenberg>
What do you folks think, is that fair?
<azonenberg>
obviously somebody could also just oshpark their own boards with no overmolding if they want to be cheap
<azonenberg>
But the startup costs of printing the mold, buying a big jar of silicone, and getting the process right are such that if you want a nice polished result you're better off getting one premade
<azonenberg>
unless you're making a lot
<d1b2>
<TiltMeSenpai> this is the passive, solder on probe right?
<azonenberg>
Yes
<azonenberg>
4 GHz bandwidth
<azonenberg>
I could easily sell it for triple digits and they'd probably still sell like hotcakes :P but i want to be accessible to low budget shops
<d1b2>
<TiltMeSenpai> works for me
<azonenberg>
And i'm not going to be like the big players and charge up the nose because i can
<azonenberg>
This is something i do for fun not to make a living on
<azonenberg>
As long as i'm not making a net loss i'm happy
<d1b2>
<david.lenfesty> seems reasonable to me, a broke student 😛
<noopwafel>
underpricing your labor runs the risk of making it not fun
<azonenberg>
noopwafel: Once i finish the R&D I'd be outsourcing assembly to my lab tech :p
<azonenberg>
A broke pizza delivery driver who does maintenance, cleanup, soldering, and random odd jobs around my lab for $25/hr
<azonenberg>
It's more than she gets from pizza hut and a hell of a lot cheaper than somebody with formal IPC training etc
<azonenberg>
At $25/hr the cost of soldering a SMA and three resistors is probably a buck or two, then mixing up some silicone and encapsulating a bunch of them in a ganged mold won't be that expensive either
<azonenberg>
I'm not attempting to price them to cover a fair rate for my R&D, that would put them in the same ballpark as commercial probes
<azonenberg>
I just want to not take a loss on the production
<noopwafel>
agree that $40-50 sounds very reasonable then
vitalmixofnutrie has joined #scopehal
vitalmixofnutrie has left #scopehal [#scopehal]
m4ssi has joined #scopehal
m4ssi has quit [Quit: Leaving]
<d1b2>
<mubes> I really woudn't make it too cheap. By all means offer some kind of discount to those who are close enough to be able to find it, but a realistic market price for those who would be buying in the open market anyway. That way, you might have enough income eventually to rescue a second person from the pizza house, and you generate a bit of 'loyalty' from those who got the discount.