azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi has joined #scopehal
bvernoux has joined #scopehal
massi has joined #scopehal
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #scopehal
<azonenberg> So bvernoux just pointed me at https://www.ti.com/product/BUF802
<azonenberg> I ordered ten of them. Looks like it has potential to be a fun 1-3 GHz active fet probe frontend
<bvernoux> yes clearly
<bvernoux> Just a warning I see they are not really protected against ESD
<bvernoux> to have max performance I think else that will add something like 0.2pF ...
massi has quit [Remote host closed the connection]
<azonenberg> Yeah i'll figrue that out when the time is right
someone-else has joined #scopehal
<someone-else> azonenberg: 2.4pf input capacitance combined with tip inductance would do quite terrible things to response flatness I think
<someone-else> and with 50ohm series resistance -3dB bandwidth is already only 700MHz
<someone-else> TI made these primarily for 1meg frontends where 2.4pf input capacitance might be ok, I suppose
<azonenberg> someone-else: well, only one way to find out. I think I can get pretty low tip L based on my experience with the AKL-PT1 etc
<someone-else> azonenberg: perhaps a small/short solder-in probe would fit the bill..
<someone-else> I wonder if anybody makes a better (lower input capacitance) discrete fet for similar application
<someone-else> there are ce3512/ce3520s (which aren't JFETs but from what I gather gate leakage is low enough), but they seem rather unstable in simulation
<azonenberg> someone-else: yeah i just figured it was worth a few bucks to grab a couple of the thing to play with
<azonenberg> if it's not useful oh well
<azonenberg> $50 is a drop in the bucket of my lab R&D budget
<azonenberg> i just spent $1700 on resistors for the AKL-PT5 work lol
<azonenberg> and half of them are going to go unused
<azonenberg> i just don't know which half yet :p
<someone-else> azonenberg: yep, looks like a decent bet, plus it will very likely work at lower frequencies and still be useful as an active probe even if not at >>1GHz
<azonenberg> Yeah
<someone-else> anyway buf802 looks like a go-to device for a true fet active probe now
<someone-else> I made a 1ghz-ish probe from lmh6559 a while ago - worked fine (except of course it's not 50GOhm but 200kOhm input resistance plus there's a substantial input bias current), but buf802 seems better
<electronic_eel> azonenberg: i already thought the buf802 could be interesting for you back in january https://libera.irclog.whitequark.org/scopehal/2022-01-28#31651332;
<azonenberg> oh oops i must have forgot
<azonenberg> anyway i have some on the way now
<d1b2> <dannas> Me and git and submodules. Not a match made in heaven. I've fetched the latest changes in scopehal-apps and the lib folders and I get this compile error: /src/glscopeclient/FilterDialog.cpp:596:17: error: ‘class Filter’ has no member named ‘HasParameter’; did you mean ‘GetParameter’?
<d1b2> <dannas> I've made a habit of updating the lib folder to have the latest scopehal changes. Maybe I should switch back to using the version in the gitmodules folder
<azonenberg> no
<azonenberg> hold on a minute i might have not pushed changes to scopehal
<azonenberg> i got pinged about a CI error last night and didnt have time to look at it
<_whitenotifier-e> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/azonenberg/scopehal/compare/cedfe805719b...bd4dfd9790b5
<_whitenotifier-e> [scopehal] azonenberg bd4dfd9 - Added FlowGraphNode::HasParameter()
<_whitenotifier-e> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/azonenberg/scopehal-apps/compare/bb6a27bf5a75...9f7cc9b5c0b4
<_whitenotifier-e> [scopehal-apps] azonenberg 9f7cc9b - Updated submodules
<azonenberg> dannas: ok pull latest
<azonenberg> that was a derp on my part, i pushed changes on the apps side and not the corresponding lib change
<d1b2> <dannas> Back from putting my kids to bed. Fetched and now it builds. Thank you!
<d1b2> <dannas> I'm still seeing those weird lockups. Where the scope freezes for 10s. Seems to happen about once per 1-2 minutes. @mubes Have you seen any such stalls?
<d1b2> <dannas> You do have a different generation and model of Siglent scope. Maybe they're designed completely different.
<d1b2> <dannas> mandl: Have you witnessed any stalls when using glscopeclient to retrieve data from your Siglent SDS1104x-e?
<d1b2> <dannas> It happens even when I set memory depth to the lowest setting (7K)
<d1b2> <dannas> If only I had kept notes when I investigated this the last time for like a month ago. I think I checked with Wireshark, to try and verify if there was some other network activity during the stalls...
<d1b2> <dannas> fires up wireshar
<d1b2> <dannas> My router says that the arp entry for my laptop goes stale like every minute. So the stalls I'm seeing are not related to the scope or glscopeclient.
<d1b2> <dannas> goes to read up on dhcp leases and arp tables
<d1b2> <mubes> @dannas yes, it generally means the scope and scopehal have gotten out of step with each other...scopehal has sent a request and hasn't got back what it expects...so eventually it times out.
<d1b2> <mubes> Switch on trace logging for the scpi interface and you should see where it's sending something and not getting a response.
<azonenberg> (the command for that is --debug --trace SCPISocketTransport (or SCPILXITransport or whatever you're using)
<d1b2> <mubes> The actual sample collection bypasses the logging (for historic reasons, I'll look to fix it) so if it's hanging in the sample collection you won't see it too obviously, but you should see everything else.
<azonenberg> mubes: just be aware that logging does take time even if disabled. so you might want to add a #define or something for ultra verbose dev logging
<d1b2> <mubes> Yeah, but we've got scopes that do 2 captures/sec....it's not the biggest bottleneck :-)
<d1b2> <mubes> (in other news, been hacking at Linux usbtmc to get it working with siglent...nearly, but not quite there)
<azonenberg> Nice, let me know how that goes
<d1b2> <mubes> The issue is that siglent fragment the TMC flow into usb sized packets rather than one urb for the whole message. That needs to be fixed, but we can fix things on the Linux side too.
<d1b2> <mubes> Currently at the point where all the command messaging works fine, but the wavedesc screws things up...I suspect because they send an extra newline after the packet, but I'm not at the bottom of that yet.
<d1b2> <zyp> what do you mean? on the device side?
<d1b2> <mubes> Yes, each packet is 64 bytes
<d1b2> <zyp> URBs are a host side thing
<d1b2> <mubes> Rather than a whole message across multiple packets.
<d1b2> <mubes> Plus a TMC message can be up to 2048 bytes iirc.
<d1b2> <zyp> but yeah, they're sending 64B packets on a USB-HS pipe?
<d1b2> <mubes> Yes, but the urbs represent complete messages.
<d1b2> <mubes> Yep
<d1b2> <mubes> They've defined the endpoint to be 64 bytes.
<d1b2> <mubes> There's a lot of performance locked up at the moment.
<d1b2> <zyp> are you sure? HS bulk endpoints are only allowed to be 512B
<d1b2> <zyp> in which case sending 64B packets will always be one full transfer each
<d1b2> <mubes> TMC is its own class. It's a few weeks since I looked at this, but cehckout the usb TMC spec.
<d1b2> <zyp> I thought it was bulk based, but I'm gonna double check
<d1b2> <mubes> Section 5.6.2; The format of the Bulk-OUT endpoint descriptor is specified in the USB 2.0 specification, section 9.6.6. For USBTMC interfaces, wMaxPacketSize Bits 10…0 (maximum packet size in bytes) must be a multiple of 4.
<d1b2> <zyp> that's pretty redundant, all possible legal values across all speeds are multiples of 4
<d1b2> <mubes> Well, irrespective of the packet size, it seems to me that the issue is the test for packet continuation when there's one on the way.
<d1b2> <mubes> If the received block is less than the size of the receive buffer then it's assumed to be a complete message...even if the header indicates there is more message to be received.
<d1b2> <zyp> yes, that's how it works
<d1b2> <mubes> By changing the test to if there is more data outstanding then everything behaves much better.
<d1b2> <mubes> The receive buffer in usbtmc.c is set to be 4096 bytes.
<d1b2> <zyp> endpoint must be 512B, but the device is free to send you smaller packets, and reception of any non-512B packet will make the host controller signal completion of the scheduled URB
<d1b2> <zyp> I'm not sure how much the driver can do in that case, I believe it still has to schedule a new URB for every single 64B packet
<d1b2> <mubes> Each TMC message has a 12 byte header that tells you how much message remains. By changing the driver to use the remaining length to identify a continuation then things start to work.
<d1b2> <mubes> I think/thought an urb was an arbitrary length and it's split into usb packets in the driver.
<d1b2> <mubes> ...is that not correct?
<d1b2> <mubes> I.e. checkout transfer_buffer or the transfer_dma variable (as only one can be used for a urb). If this is 0, neither transfer buffers are used by the USB core. For an OUT endpoint, if the endpoint maximum size is smaller than the value specified in this variable, the transfer to the USB device is broken up into smaller chunks in order to properly transfer the data. This large transfer occurs in consecutive USB frames. It is much faster to
<d1b2> submit a large block of data in one urb, and have the USB host controller split it up into smaller pieces, than it is to send smaller buffers in consecutive order
<d1b2> <zyp> I haven't worked much on the host side of things, but my understanding is that an URB is scheduled for a given number of bytes and terminated either by receiving the requested number of bytes or a short packet, where a short packet is a packet smaller than the configured max for the endpoint
<d1b2> <zyp> which implies that for a HS bulk endpoint, the only way to put more than one packet in the same URB is to make them 512B
<d1b2> <mubes> The size of an urb is set by transfer_buffer_length which can be divvied up into multiple packets.
<d1b2> <zyp> yeah, full packets
<d1b2> <mubes> Indeed
<d1b2> <mubes> But siglent defined the endpoint size to be 64 bytes.
<d1b2> <zyp> well, is it HS USB?
<d1b2> <zyp> 64 is valid for FS but not for HS
<d1b2> <mubes> So it's consecutive 64 byte packets. Yes, it's usb2-hs.
<d1b2> <mubes> It's valid, just unusual.
<d1b2> <zyp> no, it's not
<d1b2> <mubes> ? You can make a hs endpoint less than 512 bytes
<d1b2> <zyp> nope
<d1b2> <mubes> Now things get interesting....one sec, I'll go to the pc
<d1b2> <zyp> not sure what linux will do if you try it, but macos will ignore the descriptor and use 512 anyway, and log a warning that it did
<d1b2> <mubes> Gotta send this as multiple messages;
<d1b2> <mubes> us 001 Device 044: ID f4ec:1011 Atten Electronics / Siglent Technologies SDS2504XPlus Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0xf4ec Atten Electronics / Siglent Technologies idProduct 0x1011 bcdDevice 99.99 iManufacturer
<d1b2> 1 Siglent iProduct 2 SDS2504XPlus iSerial 3 SDS2PDDQ4R0769 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0027 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 2mA Interface
<d1b2> Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 254 Application Specific Interface bInterfaceSubClass 3 Test and Measurement bInterfaceProtocol 1 TMC iInterface 0
<d1b2> <mubes> Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7
<d1b2> bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN
<d1b2> bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered)
<d1b2> <zyp> use a pastebin? 🙂
<d1b2> <mubes> done now 😁
<tnt> that's unreadable in IRC for sure :/
<d1b2> <zyp> can you double check that it's actually HS too?
<d1b2> <zyp> this looks like a FS config descriptor, and is not spec compliant for HS, hence issues are to be expected
<d1b2> <zyp> check if dmesg logged any interesting warnings
<d1b2> <mubes> BulkHS must be 512Bytes? I swear I've configured them smaller
<d1b2> <zyp> I'm absolutely certain, and I already posted the relevant part from the spec
<d1b2> <mubes> It was more of a rhetorical question
<d1b2> <mubes> [2039001.473305] usb 1-10.2: new high-speed USB device number 45 using xhci_hcd [2039001.578390] usb 1-10.2: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 64 [2039001.578403] usb 1-10.2: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [2039001.578408] usb 1-10.2: config 1 interface 0 altsetting 0 endpoint 0x82 has an invalid bInterval 0, changing to 7 [2039001.586379] usb 1-10.2: New USB
<d1b2> device found, idVendor=f4ec, idProduct=1011, bcdDevice=99.99 [2039001.586391] usb 1-10.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [2039001.586397] usb 1-10.2: Product: SDS2504XPlus [2039001.586400] usb 1-10.2: Manufacturer: Siglent [2039001.586404] usb 1-10.2: SerialNumber:
<d1b2> <zyp> yep
<d1b2> <mubes> So yep, it's barfing, but allowing it
<d1b2> <zyp> so if the host controller expects 512B packets and the device intends to send a transfer of a series of 64B packets, it makes sense that it breaks
<d1b2> <zyp> it'd probably work as is if you forced it to enumerate as FS
<d1b2> <mubes> Not with the code in usbtmc.c I doubt
<d1b2> <zyp> why not? I expect that in FS mode the host controller would correctly join the 64B packets to a transfer
<d1b2> <zyp> assuming everything else is well behaved on both sides
<d1b2> <mubes> So...to summise; A urb can span more than one packet (i.e. it's arbitary size), but the packet size is wrong for a HS device.
<d1b2> <zyp> yes
<d1b2> <zyp> this is totally a device side issue and I believe the best thing you can do on the host side is to submit multiple URBs and manually join them as a workaround
<d1b2> <zyp> but if you already have the vendor's ear, I'd bring it up with them before even bothering with the workaround
<d1b2> <mubes> Linux seems pretty good about bolting together 64byte Bulk packets..that bit is working, provided that I change the test for packet continuation in the driver.
<d1b2> <mubes> TBH I'm pretty sure the protocol is getting corrupted through extra newlines in the flow
<d1b2> <zyp> one mistake rarely comes alone? 🙂
<d1b2> <mubes> true enough
_florent_ has quit [Ping timeout: 245 seconds]
sorear has quit [Read error: Connection reset by peer]
elms has quit [Read error: Connection reset by peer]
mxshift has quit [Read error: Connection reset by peer]
esden has quit [Read error: Connection reset by peer]
mxshift has joined #scopehal
elms has joined #scopehal
_florent_ has joined #scopehal
esden has joined #scopehal
sorear has joined #scopehal