<d1b2>
<chille0417> @azonenberg The OWON HDS200 scope does not allow the user to set the samplerate. It seems to be controlled automatically based in the timebase and memory depth. This means it will be problematic to do a correct implementation of Oscilloscope::GetSampleRatesNonInterleaved(). Will this cause a problem somewhere in the application?
<d1b2>
<azonenberg> This is how most scopes work
<d1b2>
<azonenberg> GetSampleRates* just returns the list of valid sample rates the scope provides
<d1b2>
<azonenberg> then SetSampleRate() will need to set time/div based on memory depth and the desired rate
<d1b2>
<azonenberg> and something like that
<d1b2>
<azonenberg> or sometimes its the opposite you contrl the rate and time/div controls depth
<d1b2>
<azonenberg> Pico is one of the few that actually gives you explicit control over both
<d1b2>
<chille0417> Oh noes! I just accidently bought yet another device device that will need a driver for ngscopeclient! Got two Alientek DP100 pocket PSU's in the mailbox today. https://en.alientek.com/Product_Details/45.html
<d1b2>
<chille0417> @fredzo_72653 It looks like the Alientek DP100 PSU's I got today is also using Modbus!
<d1b2>
<benny2366> that is false advertising i'm afraid
<d1b2>
<chille0417> What is false advertising? That DP100 used Modbus? It is not something that is advertised. I'm looking at the source code for a project called "webdp100" and drawing my own conclusions.
<d1b2>
<fredzo_72653> Lol I have one of them too 😉 I wanted to
<d1b2>
<fredzo_72653> I wanted to make a driver for it too, but it's Modbus over USB HID, not UART
<d1b2>
<chille0417> However, it turned out to not be Modbus. It has a frame that is identical to a Modbus RTU frame and the checksum is calculated via a function named "crc16modbus". However, the function codes does not look like Modbus.
<d1b2>
<fredzo_72653> So we would need to add a new dependency to hidapi
<d1b2>
<chille0417> Are you sure it is Modbus? I don't think it is actual Modbus, it just looks like Modbus.
<d1b2>
<fredzo_72653> Not sure @azonenberg would want that since I'm not sure that using USB HID is very common in test equipment...
<d1b2>
<chille0417> And the USB HID is not a problem. I already have a somewhat working gateway between USB bulk transfer and TCP sockets. I'm using it for my OWON HDS200, which is talking SCPI over raw USB.
<d1b2>
<chille0417> It's based on libusb.
<d1b2>
<david.rysk> hidapi is one of the nicer libraries
<d1b2>
<fredzo_72653> That looks like Modbus: const frameBuffer = new Uint8Array([ frame.deviceAddr, frame.functionType, frame.sequence, frame.dataLen, ...(frame.data as any), // TODO: fix types 0, 0, ]);
<d1b2>
<chille0417> Yes, it does. But take a look at what is sent on "frame.functionType". It does not match the functions codes used in Modbus.
<d1b2>
<fredzo_72653> RIght and there's no sequence in modbus either...
<d1b2>
<chille0417> The sequence could have been a part of the data. But the functionType does seem to conflict with regular Modbus. 😦
<d1b2>
<chille0417> But whatever, it should be fairly easy to implement a driver based on the reverse engineered projects like DP100-WebApp and webdp100.
<d1b2>
<fredzo_72653> Yep, the second project talks about modbus too : /** DP100 Modbus Function IDs */ And no sequence here: const report = new Uint8Array([ deviceAddr, functionId, content.length, content, 0, // checksum 0 // checksum ])
<d1b2>
<chille0417> Hmm...
<d1b2>
<fredzo_72653> I would say it's modbus with custom function type (allowed in modbus spec AFAIR)
<d1b2>
<chille0417> The problem is that the user defined codes are only in the range 65 to 72 and 100 to 110.
<d1b2>
<fredzo_72653> Yes like I said, it's custom functions... meaning the ModbusInstrument class is not of much help here except for the CRC part... It's a shame they did not use the read/right register mechanism 😕
<d1b2>
<chille0417> Well, at least it can act as a good reference on how to work with binary protocols in scopehal. 🙂
<d1b2>
<fredzo_72653> @azonenberg / @david.rysk let me know if you want me to look into hidapi use for that purpose (at least on Windows platform).
<d1b2>
<chille0417> I have three devices on my desktop right now. All of them communicate via USB HID. 🙃
<d1b2>
<fredzo_72653> What ? A mouse, a keyboard and a gamepad ?😂
<d1b2>
<chille0417> Haha, yes. And a scope, a DMM and a PSU. 🦄
<d1b2>
<fredzo_72653> Oh really? I wouldn't have thought so ! 😀 What are the scope and the dmm?
<d1b2>
<chille0417> Scope is a OWON HDS2102S. It's a handhels scope with DMM and AWG. It communicates via SCPI over USB HID.
<d1b2>
<chille0417> The DMM is a Hantek 365B. It has a proprietary protocol over USB HID.
<d1b2>
<fredzo_72653> Well maybe UsbHidTransport is going to make it's way to ngscopeclient... 🙂
<d1b2>
<chille0417> Yeah, otherwise I'll make my own scopehal, with blackjack, hookers and USB HID! Saying in Benders voice
<d1b2>
<azonenberg> Yeah we definitely need a way to support this kind of stuff
<pirate>
i might have decided to use a 1983 corolla as a model for the CAN icons
<d1b2>
<azonenberg> lol
<azonenberg>
pirate: also it seems folks are a fan of the shork icons so that was definitely a good idea lol
<dingwat>
life pro tip, it's faster to install john the ripper and crack password protected zip files than it is to message the vendor application engineers for the password to IBIS models