azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
<_whitenotifier-5> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-5> [scopehal] azonenberg ac25cee - Updated to latest xptools
<_whitenotifier-5> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-5> [scopehal] azonenberg ccc0981 - Removed all vestiges of Siglent code from the LeCroy driver
<azonenberg> mubes: you've got some merge conflicts now, please fix
<azonenberg> looks ready to merge otherwise
Tost has joined #scopehal
<_whitenotifier-5> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-5> [scopehal-apps] Codysseus 090559f - Improve the usbcsv example This program was originally created by azonenberg to assist in decoding USB snippets in a headless state. The main intent of this program is to export only packets sent from the client device to the host computer. It is a bit messy, but I tried to make it clear how the logic works. The output format is as follows: [starting line in csv]
<_whitenotifier-5> in the USB spec, so feel free to implement them. Another thing to note is that there is a `step` variable in the ProcessWaveform function that represents the number of femtoseconds between lines in the csv. This was done because my logic analyser does not sample at that high of a rate, and I wanted to translate from femtoseconds that the decoder used back into a format that fit my original CSV. So be warned that you
<_whitenotifier-5> [ending line in csv] [DATA 1/0] [hex bits] | [SETUP request code] This is supposed to make it easier to extract those client packets from the CSV. I briefly considered using CPython to transform it into a format that can easily be used in feature extraction libraries, but that is more work than is necessary. This is not a perfect example, as I only really capture the data packets and the NAK packets. There are others
<_whitenotifier-5> will need to change this! Big thank you to azonenberg for helping out with the original example.
<_whitenotifier-5> [scopehal-apps] azonenberg 5ff7cfd - Merge pull request #310 from Codysseus/master Improve the usbcsv example
<_whitenotifier-5> [scopehal-apps] azonenberg closed pull request #310: Improve the usbcsv example -
<_whitenotifier-5> [scopehal-apps] azonenberg closed issue #287: Rigol MSO5000 Waveform *.bin file import -
<_whitenotifier-5> [scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±6]
<_whitenotifier-5> [scopehal-apps] sam210723 fef1160 - Added BIN option to Import dialog
<_whitenotifier-5> [scopehal-apps] sam210723 37c22de - Load BIN from CLI
<_whitenotifier-5> [scopehal-apps] azonenberg cbb37dd - Merge pull request #307 from sam210723/master Add *.bin filter to Import dialog
<_whitenotifier-5> [scopehal-apps] azonenberg closed pull request #307: Add *.bin filter to Import dialog -
<_whitenotifier-5> [scopehal] azonenberg closed pull request #396: Add binary capture file parser -
<_whitenotifier-5> [scopehal] azonenberg pushed 17 commits to master [+0/-0/±22]
<_whitenotifier-5> [scopehal] sam210723 13d0b85 - Added BIN file parser Parser for Agilent/Keysight/Rigol binary capture files
<_whitenotifier-5> [scopehal] sam210723 0dadcf1 - Set vendor based on file signature
<_whitenotifier-5> [scopehal] sam210723 b8b496a - Rewrite BIN importer
<_whitenotifier-5> [scopehal] ... and 14 more commits.
<_whitenotifier-5> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-5> [scopehal-apps] azonenberg f703ada - WaveformArea: more validation of invalid grid scales
<_whitenotifier-5> [scopehal-apps] azonenberg 8d75cba - Updated to latest scopehal
<_whitenotifier-5> [scopehal-pico-bridge] azonenberg commented on issue #2: feature request: Support for 4423 -
m4ssi has joined #scopehal
<azonenberg> grr, merge screwup
<_whitenotifier-5> [scopehal] azonenberg pushed 7 commits to master [+0/-0/±34]
<_whitenotifier-5> [scopehal] mubes c2e2337 - Changes to support SDS2000X+ and SDS5000X.
<_whitenotifier-5> [scopehal] mubes 3091444 - Fix to allow building on Windows
<_whitenotifier-5> [scopehal] mubes d2dc3f6 - Fix gain error on sampled waveforms
<_whitenotifier-5> [scopehal] ... and 4 more commits.
<_whitenotifier-5> [scopehal] azonenberg closed pull request #402: Changes to support SDS2000+ scope -
<_whitenotifier-5> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-5> [scopehal-apps] azonenberg d9020dd - Updated to latest scopehal with merge fixes
<d1b2> <mubes> ? Did you fix the merge conflicts on newSiglent then?
<d1b2> <mubes> (Just went to look and the PR is gone 🙂 )
<azonenberg> Yes
<azonenberg> i accidentally merged some other changes that broke master
<azonenberg> (deletion of some of the old lecroy siglent code)
<azonenberg> and the easiest way to fix was to fix your changes and pull them in
<d1b2> <mubes> fair enough
<d1b2> <mubes> I would like to get triggering and the digital channels into that since it makes the thing reasonably complete. Pls ping your guy to see if we can get a temporary digitial licence. Without the licence the scope doesn't respond to the options for me.
<azonenberg> Do you have the probes? or no
<azonenberg> without the probes is the license really useful as you can't download waveforms to test?
<d1b2> <mubes> I can poke wires into the connector
<azonenberg> do you know what the connector is, though? its probably LVDS if rigol and lecroy LAs are any indication
<azonenberg> there is probably a differential comparator in the pod
<d1b2> <mubes> No, it's a PCI-e connector but repurposed. The pinout is known.
<d1b2> <mubes> I can just about get enough running to test
<azonenberg> ah ok
<azonenberg> in that case i will ask
<azonenberg> its the middle of the night right now but i'll give him a ring in the morning when he's in the office
<d1b2> <mubes> You might also ask him how amenable they are to protocol feature requests...if they're not just going to bounce off the side then I'll go to the trouble of writing a few up and you can poke them in.
<azonenberg> First on my list is ability to query installed options
<azonenberg> that should be straightforward to add
<d1b2> <mubes> yup!
<d1b2> <mubes> and knowing if there was a trigger since last time we were triggered
<d1b2> <mubes> Mission one is finally accomplished though...SWD decode from analog traces;
<azonenberg> :)
<d1b2> <mubes> If we could set the sample rate (we can already set depth) that would really start to make this thing flexible.
<azonenberg> yeah typically i find i have to set time/div or similar in order to configure sample rate and depth on most scopes
<azonenberg> there's not usually direct access
<azonenberg> libscopehal's api provides direct control of both as this is typically a much more useful configuration
<_whitenotifier-5> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±3]
bvernoux has joined #scopehal
<_whitenotifier-5> [scopehal] azonenberg b83d69d - Cleaned up some unused parameters in Siglent driver. UartTrigger now only enables mark/space parity types on Siglent scopes since most others don't support them.
maartenBE has quit [Ping timeout: 246 seconds]
maartenBE has joined #scopehal
Tost has quit [Ping timeout: 246 seconds]
Tost has joined #scopehal
<bvernoux> hello
<bvernoux> I have some good news for Rigol MSO5K owner ;)
<bvernoux> I have feedback from Rigol Dev Team and they are working to deliver a new version of the MSO5K firmware with faster SCPI commands/data
<bvernoux> "We are working on it currently, and our engineers will make an improvement in the middle of May."
<bvernoux> So cross fingers to have something in middle of May ;)
<d1b2> <zyp> nice
<bvernoux> I think they are maybe interested to improve that also for their future Rigol MSO8000/DS8000 which I think use the same Firmware ...
<bvernoux> Especially DS8000-R which is their first Oscilloscope in Rack without screen
<bvernoux> Does anyone here have bought a Thermal Camera HT-301 ?
<bvernoux> It clearly seems amazing(and hackable in SW at least) for the price
<bvernoux> It is 384 x 288 IR Resolution for less than 800USD
<bvernoux> and 25Hz framerate
<d1b2> <mubes> @azonenberg when you speak to Siglent you might want to mention to them that rigol are working on scpi improvements...would be nice to trigger an arms race in that area....also, given the improving quality of vnc implementationz, I'm surprised that headless implementations aren't more common.
<azonenberg> mubes: tried to call but apparently i misremembered what time zone their office is in
<azonenberg> they're closed for the day already
<d1b2> <mubes> No worries. Saw the parity changes you made in the uarttrigger btw...I understand now.
<azonenberg> yeah the parameters are used by the gui code to populate the dialog
<azonenberg> we dont want to show options that the hardware can't support
<d1b2> <mubes> Trouble is it 'smears' the configuration of a specific scope across multiple files, but I can't easily think of a better way to do it that doesn't simply reverse the problem.
<azonenberg> Yes exactly
<azonenberg> It's not perfect, but i havent found a way to do it better yet
<azonenberg> the object oriented trigger model does simplify a lot of stuff gui side though
<azonenberg> as now glscopeclient can just manipulate abstract trigger objects and not care what they're for
<d1b2> <mubes> Code never is, but there's an appropriate level of pragmatism to apply to get anything done, and that might be it.
<azonenberg> Yeah
<azonenberg> If we find a better model we can always think about refactoring
<d1b2> <mubes> It's always better to understand stuff before doing that, and I'm not at that point yet. I need to go attack Orb for a few days but will take another look at this after that.
<azonenberg> Yeah a lot of scopehal stuff was "I'm gonna build it this way because it seems to make sense now, we can fix it if needed"
<azonenberg> Sometimes i did fix it
<azonenberg> other times it was fine
<d1b2> <mubes> often good enough is good enough, but we shouldn't be afraid of re-factoring either because that gives you headroom for the future. In a couple of other projects I've seen a lot of reticence to refactoring with the end result that the project slowly rusts away....its pretty arrogant to think that we get things right the first time every time we do them, at least for me coding is a sequence of successive approximations! Coding by Tailor Expansion
<d1b2> or something.
<azonenberg> I consider version 0.x of my projects to be "no long term api stability, refactor any time you have a good reason"
<azonenberg> once we hit a 1.0 release some level of stability should be considered
<azonenberg> for 0.x api instability and redesign is expected
<d1b2> <mubes> yup
bvernoux has quit [Quit: Leaving]
<azonenberg> And so one of the things delaying a formal 1.0 release is that we've implemented enough different scope drivers, protocol decodes, etc to be reasonably happy with the object model and APIs
m4ssi has quit [Remote host closed the connection]