azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
chris_99 has quit []
bvernoux has quit [Quit: Leaving]
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<d1b2> <Aleksorsist> Yup, and thanks! We're shooting to keep the price as low as possible while balancing the feature set (and also the fact that we're producing at low volumes) so it'll likely fall in the $700-800 range
<d1b2> <Aleksorsist> PCIe card version will be a good chunk less, probably ~$600
<d1b2> <azonenberg> @Aleksorsist what's the deal with the hypothesized-but-not-yet-promised 10GbE version?
<d1b2> <azonenberg> is that still on the roadmap as a potential offering? I can't promise who else will want them but i'd buy it
<d1b2> <Aleksorsist> We're keeping the option for it open through the m.2 daughterboard, but we're not having it as a separate SKU at launch
<d1b2> <Aleksorsist> That way if you get the PCIe version at launch you can add a 10GbE daughtercard later (or a thunderbolt one)
<d1b2> <azonenberg> Makes sense. How would you power the 10G version?
<d1b2> <azonenberg> since the pcie and thunderbolt versions have power available on that interface
<d1b2> <azonenberg> i'd be fine with either standard (non PD) USB or a barrel jack with 5/12V
<d1b2> <Darius> PoE 😄
<d1b2> <Aleksorsist> It'll need a DC barrel jack, which will live on the daughterboard and power the main board (just like the TB daughterboard)
<d1b2> <Aleksorsist> Isn't PoE kinda cursed lol
<d1b2> <azonenberg> well PoE is not an option for SFP+
<d1b2> <azonenberg> if you did 10GbaseT it'd be doable
<d1b2> <azonenberg> but if you did 10GbaseT i'd have to buy a media converter as all of my 10G is optics
<d1b2> <Darius> I barrel jack seems more sane 🙂
<d1b2> <azonenberg> (and you REALLY do not want to do 10GbaseT on a board)
<d1b2> <Aleksorsist> SFP+ seems to be the best option since there are 10GbaseT module IIRC
<d1b2> <azonenberg> Yes. So someone who wants to do baseT can do that
<d1b2> <azonenberg> and the rest of us can stay with optics
<d1b2> <azonenberg> it's much easier to host a sfp than drop down all the support components needed for a baseT PHY
<d1b2> <azonenberg> 10GbaseT is a power hog
<d1b2> <azonenberg> there's a laundry list of reasons why it's awful and sfp is the way to go
<d1b2> <azonenberg> Anyway, if you make a version that can run on standalone DC power and uses a SFP+ for backhaul I'll buy at least one
<d1b2> <azonenberg> And when you're ready, we should probably collaborate on my big scope project i have planned
<d1b2> <azonenberg> (the one with an AD9213 per channel instead of a HMCAD shared by all channels)
<_whitenotifier> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/glscopeclient/scopehal-docs/compare/da389ad5b255...3c468b3953b9
<_whitenotifier> [scopehal-docs] azonenberg 3c468b3 - Initial skeleton docs of envelope filter
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+2/-0/±3] https://github.com/glscopeclient/scopehal/compare/91aee034c159...d8badb39cf50
<_whitenotifier> [scopehal] azonenberg d8badb3 - Initial implementation of envelope filter
<_whitenotifier> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/glscopeclient/scopehal-apps/compare/5a30762a3f0e...e1fd5cb3efde
<_whitenotifier> [scopehal-apps] azonenberg e1fd5cb - Updated submodules with envelope filter
massi has joined #scopehal
sajattack[m] has quit [Quit: You have been kicked for being idle]
chris_99 has joined #scopehal
azonenberg has quit [Ping timeout: 260 seconds]
azonenberg has joined #scopehal
massi has quit [Remote host closed the connection]
massi has joined #scopehal
<_whitenotifier> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://github.com/glscopeclient/scopehal/compare/d8badb39cf50...02ce6ec3c9c3
<_whitenotifier> [scopehal] miek 3a16464 - USB2PacketDecoder: fix DecodeSetup behaviour when the ACK/NAK packet is missing Previously, when looking for a response to a setup packet, DecodeSetup would consume the subsequent packet whether it was an ACK/NACK or not. In cases where the device did not reply, the decoder would consume a packet from the next transaction and break the decoding. This commit makes sure that
<_whitenotifier> DecodeSetup only consumes the subsequent packet iff it is an ACK or NAK. fixes #723
<_whitenotifier> [scopehal] azonenberg 02ce6ec - Merge pull request #741 from miek/usb2_decodesetup_missing_ack USB2PacketDecoder: fix DecodeSetup behaviour when the ACK/NAK packet is missing
<_whitenotifier> [scopehal] azonenberg closed pull request #741: USB2PacketDecoder: fix DecodeSetup behaviour when the ACK/NAK packet is missing - https://github.com/glscopeclient/scopehal/pull/741
<_whitenotifier> [scopehal] azonenberg closed issue #723: Protocol Analyzer: doesn't list all USB SETUP transactions - https://github.com/glscopeclient/scopehal/issues/723
chris_99 has quit []
massi has quit [Remote host closed the connection]
<d1b2> <Aleksorsist> For sure! It'll be pretty sweet to have a >1GHz open source scope out there
bvernoux has joined #scopehal
chris_99 has joined #scopehal
<d1b2> <azonenberg> Yep. There's quite a bit of R&D involved and it won't be cheap. I'm expecting MSRP in the 5 digits USD
<d1b2> <azonenberg> it will probably have a xilinx 7 series or ultrascale/ultrascale+ FPGA on each of the four ADCs and possibly one more on the back end for triggering and marshalling all that data out to 10GbE and/or thunderbolt
<d1b2> <azonenberg> (we may or may not be able to fit that into one of the channel FPGAs)
<d1b2> <azonenberg> and probably dual channel DDR SODIMM per channel for buffer
<d1b2> <sierra (she/her)> sounds like a good time
bvernoux has quit [Quit: Leaving]
chris_99 has quit []