<d1b2>
<chille0417> And then I thought... why not at least make the scope work? There is software from OWON that can interface with the scope.
<d1b2>
<chille0417> Well, I just found out that even the AWG and the DMM does have proper SCPI interface. And they can all be used at the same time.
<d1b2>
<chille0417> But... OWON thought it will be a nice idea to require raw USB access to send SCPI commands, instead of something useful like a virtual serial port or USB TMC...
<d1b2>
<chille0417> Well, I can just: libusb_bulk_transfer(handle->dev_handle, ENDPOINT_OUT, "*IDN?", 7, &bytes_written, 0); And it works.
<d1b2>
<chille0417> So how do we implement this in scopehal? It is indeed a SCPI interface, just a bit weird way to communicate with it. Or is this done in other equipment as well?
<d1b2>
<josHua> speaking of such things, who uses usbtmc (SCPITMCTransport.cpp)? would there be an appetite for that to have an implementation that uses libusb, also? I notice that usbtmc does not work, for instance, on my Mac, and scopehal uses a very limited subset of what the Linux kernel offers for usbtmc, so having scopehal speak usbtmc directly might be the right thing for 3-plat TMC support
Degi_ has joined #scopehal
<d1b2>
<josHua> implementing this as a SCPIOwonUsbTransport seems plausible?
Degi has quit [Ping timeout: 248 seconds]
Degi_ is now known as Degi
<d1b2>
<chille0417> I was thinking about that as well. I tried to get the OWON to work with USBTMC to see if that was what it needed to work. It seems like USBTMC is not that complex. I would assume that the Linux driver is never going to have compatible Windows version. So it would probably be better to implement it via libusb or similar.
<d1b2>
<josHua> I was reading a python usbtmc implementation and the kernel usbtmc implementation before I posted my question about it, and usbtmc definitely has all the hallmarks of psychotic early USB class
<d1b2>
<chille0417> Yeah I guess so. I think we can assume that this OWON is a bit weird. If any other instrument in the future needs something similiar it might be worth making something like a SCPIRawUSBTransport that could then be used by the OWON driver.
<d1b2>
<josHua> so this the 'two bulk endpoints' story of SCPI probably does not necessarily mesh with usbtmc, and those things probably need to be separate
<d1b2>
<josHua> yes, I would spell that generic driver SCPIBulkUSBTransport but that is nitpicking
<d1b2>
<chille0417> Yeah, "SCPIBulkUSBTransport" is probably a better name. I'm mostly calling it "raw USB" because that what LabVIEW calls the USB bulk transfer.
<d1b2>
<azonenberg> Ok so
<d1b2>
<azonenberg> Relatives are gone, catching up on scrollback
<d1b2>
<azonenberg> SCPI over raw USB bulk transfers seems like something worthy of its own transport type
<d1b2>
<azonenberg> As far as USBTMC via libusb, i think we should use the linux kernel driver on platforms that support it (i.e. linux)
<d1b2>
<azonenberg> but i am absolutely not opposed to a libusb based flow for other platforms (most notably windows)
<d1b2>
<azonenberg> i know nothing about how to use libusb on windows
<d1b2>
<azonenberg> But usbtmc on windows is something i want to have eventually
<d1b2>
<azonenberg> anb libusb seems as good a way as any to get it
<d1b2>
<chille0417> @azonenberg I see there is no support for °F in lib/scopehal/Unit.h and lib/scopehal/Multimeter.cpp. Do you think we should stick to SI master race and always use °C, even if an instrument supports both °C and °F?
<d1b2>
<azonenberg> There is going to be a big overhaul of the units framework over time
<d1b2>
<azonenberg> When that happens, trivial conversions like F-to-C will be much easier to implement
<d1b2>
<azonenberg> so, for now table it
<d1b2>
<chille0417> Ok!
<d1b2>
<chille0417> @azonenberg The only DMM implemented today is the R&S HMC8012, which does only have one port for measuring current. A lot of DMM's have different ports for measuring A and mA. I need some way to configure which port to use. Any suggestion on how to handle this in scopehal?
<d1b2>
<azonenberg> The meter APIs are definitely far from all-inclusive
<d1b2>
<azonenberg> Is this exposed as two separate current settings?
<d1b2>
<azonenberg> like, AC volts, DC volts, DC amps high range, DC amps low range?
<d1b2>
<chille0417> I have two DMM's with USB. The OWON HDS200 series (HDS2102S). It does support SCPI and doesn't seem to have any way of selecting an input port or range in the current mode. It looks like you just ":DMM:CONF:CURR {AC, DC}". So I guess this one shouldn't be a problem.
<d1b2>
<azonenberg> Yeah
<d1b2>
<azonenberg> I'm all for adding a new meter mode for "low range current" to start
<d1b2>
<chille0417> The other one I have is a Hantek 365B, which have 8 different modes for measuring current. Two of the modes are for "A AC" and "A DC", the A input have no ranges. The other 6 are for the mA input. AC/DC in different ranges and auto range.
<d1b2>
<azonenberg> one of the points of the v0.x series not providing guarantees of API stability is that we can fool around and try to design things that fit hardware the best
<d1b2>
<azonenberg> as we encounter more esoteric hardware
<d1b2>
<azonenberg> for the mA input, can we start with auto range only and call it good for the near term?
<d1b2>
<azonenberg> the meter APIs actually do not currently support manual ranging right now at ll
<d1b2>
<azonenberg> i think there's an api to turn autorange on/off or at least query its status
<d1b2>
<azonenberg> but not to do anything with manual ranges
<d1b2>
<chille0417> That's probably a good idea. It seems to be million different instrument, which all have their own ways of doing things lol.
<d1b2>
<chille0417> I think auto range would be good for now.
<d1b2>
<azonenberg> Yeah. The intent is that by v1.0 we will have support for a high enough number of instruments across the industry that we can make more signfiicant API stability guarantees
<d1b2>
<azonenberg> i.e. we dont have to support every instrument out there, but we'll support enough that we'll have an idea of what the ones we don't support are like
<d1b2>
<azonenberg> and can add them in the v1.x series without breaking api changes
<d1b2>
<chille0417> Would it be a bad idea if i added a bunch of helper functions that can actually set and query the manual ranges? Then I can use it when doing automated testing with scopehal. The day when the ngscopeclient can make use of it i can just refactor it to be compatible with the API.
<d1b2>
<azonenberg> We only have two meter drivers right now. So if you want to work on defining APIs for manual ranging in the Multimeter class, I can implement the GUI and the HMC8012 side of them
<d1b2>
<azonenberg> And work out any impedance mismatches between the instruments at that stage
<d1b2>
<chille0417> Yeah, that would be great!
<d1b2>
<azonenberg> it might take me a bit but i'm slowly catching up on things now that i'm back to near 100% WFH again and have more time in my day
<d1b2>
<azonenberg> Also feel free to join the dev call tuesday and chat about this if you want
<d1b2>
<azonenberg> Although the primary focus is going to be making plans for the v0.1 release before the end of 2024 so that it's out there for when thunderscope developer units ship
<d1b2>
<azonenberg> (And at some point we're going to need to have a feature freeze and work entirely on bug fixes and stability to get something releasable out the door)
<d1b2>
<chille0417> What time is the dev call?
<d1b2>
<azonenberg> 14:00 Pacific (UTC-7) Tuesday
<d1b2>
<azonenberg> (Zoom link will be shared in the channel shortly before since i don't have everyone's email addresses to invite)
<d1b2>
<chille0417> Hmm... okay, so 23:00 in CET. I'm not sure how I work next week. It might be possible to join.
<d1b2>
<azonenberg> Yeah that was the time that was the least bad for everyone when i sent out the survey last week
<d1b2>
<azonenberg> There was no time that worked for everyone, every time in the next two weeks had at least one conflict
<d1b2>
<azonenberg> so i picked the least bad one :p
<d1b2>
<chille0417> Haha
<d1b2>
<azonenberg> accounting for the fact that myself as lead dev, and aleksa as thunderscope liason, had to be available
<d1b2>
<azonenberg> and then as many as possible of the other folks who responded
<d1b2>
<jescombe> @fredzo_72653 found my issue I think..
<d1b2>
<jescombe> It started with the 'Better Siglent SDS HD support' commit on 22/9, and m_requireSizeWorkaround being set to true for the 800
<d1b2>
<jescombe> With this set to false, then both 8 & 16 bit data widths seem to work as expected
<d1b2>
<fredzo_72653> Okay so we pointed in the right direction, good to know that you found the solution ! Thank you for the investigation 😉 I changed a lot of things with this PR, sorry it broke SDS800 support event though I tried not to do so... 😕 It's frustrating not to have the hardware to test everything when you do changes 😉 So I assumed all Siglent E11 models where behaving the same, aligned with their documentation, looks like it's not the
<d1b2>
case ! 😕
<d1b2>
<fredzo_72653> @jescombe is your SDS800X HD firmware up-to-date ?
<d1b2>
<azonenberg> aha, it's probably that
<d1b2>
<azonenberg> we did report that issue to siglent some time ago
<d1b2>
<azonenberg> so they probably fixed it in a firmware update. the problem being of course that this broke the workaround
<d1b2>
<jescombe> Yes, thank you - that got me looking in the right place 😉
<d1b2>
<jescombe> I probably should have noticed sooner, as I had to set it false when first working on my original patch - oops..
<d1b2>
<jescombe> @azonenberg Yep, firmware is up to date. Currently running v1.1.3.8, and was running v1.1.3.3 when I first used ngscopeclient earlier in the month.
ALTracer has joined #scopehal
<d1b2>
<fredzo_72653> OK great, what's strange is that Siglent seem to have done the other way around with SDS2000X HD, remember @azonenberg that with the preproduction unit you originally tested, workaround had to be set to false whils with my up-to-date firmware it had to be set to true ? Go figure.... Anyway @azonenberg I will add this fix to the current PR so that you can merge all together if you will.
<d1b2>
<fredzo_72653> @azonenberg while working on Modbus over UART I realized that the current behavior of UARTTransport may be problematic... AFAIU, this code blocks until the requested amount of byte has been read from the UART right ? int x = 0; while( (x = read(m_fd, (char*)data, len)) > 0) { len -= x; data += x; if(len == 0) break; }
<d1b2>
<fredzo_72653> I implemented it that way on Windows too, but I think we should exit this method after a timeout it no data is sent by the device to avoid blocking the thread in case of protocol error or if the device is not responding to a specific command. What do you think ?
<d1b2>
<chille0417> @azonenberg is there any preferred way to know what include directories, other compiler flags, etc to use when linking an application to scopehal? I see there is no *.pc files, so I guess I can't use pkg-config. Or maybe we should have a scopehal.pc?
<d1b2>
<chille0417> @fredzo_72653 Thats nice! I can test it with my RD6018 and see if it works. I do also have some other RS485/Modbus based products that I could see if I could get to work. I think I have a few I/O expanders laying around. Could be good to see that the ModbusInstrument class works as expected with other devices.