<Bird|otherbox>
azonenberg: thoughts on the USB-as-probe-control/power -- I wonder if the probe control could use vendor messages in the USB-PD protocol, since that runs over a CC line? it'd mean you wouldn't have to deal with being a USB device or host proper
<d1b2>
<david.lenfesty> Running the probe-control/power can also be done via SBUx lines
<d1b2>
<david.lenfesty> probably quite a bit easier to do with just UART than implementing the USB PD spec
<d1b2>
<david.lenfesty> given it's all vendor-specific it's not much different from what the PD solution would provide in terms of end functionality (as far as I can tell, I'm open to being swayed, but it seems to be adding a lot of protocol complexity for not really any benefit)
Degi_ has joined #scopehal
<d1b2>
<TiltMeSenpai> I'm not aware of any readily available PD controllers that let you send arbitrary messages over the PD CC lines, but if someone can find one, that's an option
<d1b2>
<david.lenfesty> IMO that's not super great either. You'll need to have PD controllers at both ends
<d1b2>
<david.lenfesty> vs. direct connections to the MCUs (or a mux at most)
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
<Bird|otherbox>
thre are PD chips out there that are basically just a PHY
<d1b2>
<david.lenfesty> especially since it manages CC lines
<d1b2>
<david.lenfesty> idk still though
<d1b2>
<david.lenfesty> it means the probes all have to support USB PD
<d1b2>
<david.lenfesty> without it, all the probes need is Rn or Rp resistors, and a UART interface
<d1b2>
<david.lenfesty> vs. a full USB PD PHY
<d1b2>
<david.lenfesty> I think the host is similar either way, but not using PD means the probe side can be much simpler
<esden>
azonenberg: I also would encourage you to price it "correctly", including your time spent on the project and a reasonable markup. If the finances are not set up correctly, you will sooner or later get bored and uninterested in the project, plus you will have no financial incentive to continue working on the product, surrounding ecosystem and support the users. There are too many "I made it for fun once and threw over the
<esden>
fence" open-source devices out there already that one can't buy, or get any support for.
<esden>
That includes devices that had a group buy, or crowd funding campaign but were not financially viable so that the original creator had an incentive to keep making and supporting the devices.
<esden>
In my opinion a good open-source product is not only priced reasonabely, as opposed to "this is how much we can squeeze out of the customer" but also have a reasonable revenue model to support the creators to keep making them, supporting them and continue to create new interesting and useful tools and devices.
<d1b2>
<Darius> also it will invariably cost more than you expect 🙂
<bgamari_>
azonenberg, is there a document somewhere that lays out the roadmap of all of your hardware designs?
<bgamari_>
azonenberg, it's quite hard to keep all of these names straight
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
<azonenberg>
bgamari_: there's a markdown file somewhere on the starshipraider github
ericonr has joined #scopehal
<azonenberg>
david.lenfesty: the reason i was leaning towards not doing PD is that PD only supplies a single rail on Vbus
<azonenberg>
i needed bipolar power
<azonenberg>
using the PD protocol to negotiate bipolar power would be a plausible hack but i dont see the point in using the PD protocol if we're not having the actual power be PD
<Bird|otherbox>
thing with PD in USB these days is the PD protocol is also how the alternate modes are negotiated
<Bird|otherbox>
which is why I suggested using PD as the overall comms transport
futarisIRCcloud has joined #scopehal
<azonenberg>
Yes
<azonenberg>
That was my original plan
<azonenberg>
but debug accessory mode might be a lot easier to do
<_whitenotifier>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JL8hX
<_whitenotifier>
[scopehal] azonenberg closed issue #275: External refclk/trigger sync support on Tek MSO5/6 - https://git.io/JUVO3
<azonenberg>
Still fighting with MSO6 SCPI stack
<azonenberg>
The current bug is that if you change channel enable status between the time of the trigger and reading the data, the scope lies to you
<azonenberg>
it says you have data ready to read
<azonenberg>
but if you try to read it, Bad Things (tm) happen
<azonenberg>
I think i'm going to have to manually maintain a dirty bit to keep track of this state
<azonenberg>
but the synchronization around that will be tricky given command queueing
<azonenberg>
and the fact that i don't actually know when the pending commands may have committed to the scope
<azonenberg>
it would be so nice if the instrument would either give you a nice error or at least let you simply ASK "was this channel enabled at the time of the trigger"
<azonenberg>
Which DAT:SOU:AVAIL? is *supposed* to do
<azonenberg>
but it lies
<azonenberg>
It actually just returns the set of enabled channels
<azonenberg>
Currently enabled, that is
<azonenberg>
Not "was enabled at trigger time"
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<d1b2>
<mubes> Do you have a path back into the Tek grown-ups for all of this bug finding you're doing? They need to know in order to be able to fix it I guess...
<azonenberg>
I've been emailing back and forth w/ @AlanAtTek
<azonenberg>
The LeCroy apps engineers also know me quite well. One time I reported three MAUI bugs in one week
<azonenberg>
Woo, looks like UPS resolved whatever their delay is and my A25 silicone is on the truck for delivery this evening
<azonenberg>
And finally after lots of hacking and tweaking the mso6 driver is somewhat stable
<azonenberg>
There are still random glitches in which i request a waveform and just get nothing back
<azonenberg>
I have not figured out the trigger or a full workaround, but at least i'm now able to time out and recover after a several-second freeze
<azonenberg>
And it looks like my next mold version and the first prototype of the clip should be shipping monday and arriving weds
<azonenberg>
So with any luck before xmas i will be able to do characterization on a full overmolded board
<azonenberg>
Very curious what the impact of the silicone on loss will be
futarisIRCcloud has joined #scopehal
<d1b2>
<david.lenfesty> azonenberg: yeah not going with PD isn't just easier but it results lower-cost probes as well.
<d1b2>
<david.lenfesty> Because w/ PD you need a full PD transceiver on the probe side
<d1b2>
<david.lenfesty> w/o it you can get away with two pullup resistors and directly attaching a UART to the cable
<d1b2>
<david.lenfesty> IMO keeping the probes simple is worth more than being vaguely closer to the spec (but we still end up violating it any way we go)
<azonenberg>
Yeah. and like i said logo compliance is not a design goal
<azonenberg>
there will be no usb trademarks in use and no intent of actually interoperating with anything else
<azonenberg>
I just want it compatible enough to not cause damage if cross-mated to real usb
bvernoux has joined #scopehal
<balrog>
azonenberg: USPS has been terrible lately