azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
_whitenotifier has joined #scopehal
<_whitenotifier> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal-docs/compare/32aa18b0b511...45621ae66bac
<_whitenotifier> [scopehal-docs] azonenberg 45621ae - Initial skeleton documentation for J1939TransportDecoder
<_whitenotifier> [scopehal] azonenberg pushed 2 commits to master [+3/-0/±55] https://github.com/ngscopeclient/scopehal/compare/28c0d75c62d7...191fffbb61fe
<_whitenotifier> [scopehal] azonenberg fdc2f8f - Initial WIP work on J1939TransportDecoder. Works, but doesn't also pass through non-TP packets yet.
<_whitenotifier> [scopehal] azonenberg 191fffb - Merge branch 'master' of github.com:ngscopeclient/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal/compare/191fffbb61fe...811aa28c5f35
<_whitenotifier> [scopehal] azonenberg 811aa28 - Updated to latest logtools
<_whitenotifier> [scopehal-apps] azonenberg pushed 1 commit to master [+2/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/19bc636a007c...705888818aa5
<_whitenotifier> [scopehal-apps] azonenberg 7058888 - Initial doxygen integration. Probably needs a bunch of work.
<_whitenotifier> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±7] https://github.com/ngscopeclient/scopehal/compare/811aa28c5f35...e7d96e30fc8a
<_whitenotifier> [scopehal] azonenberg b295532 - Started work on improving Doxygen coverage
<_whitenotifier> [scopehal] azonenberg e7d96e3 - The doxygen rampage continues
<azonenberg> Welp, i guess i'm on an api documentation kick now lol
<azonenberg> gonna be a bit before i end up putting all of this on the website but if you set "BUILD_DEVDOCS=ON" in the cmake script then "make devdocs" you should get doxygen
<azonenberg> there's a lot more content to write, i'm aiming to at least get full coverage of all the core apis in libscopehal soon
<_whitenotifier> [scopehal-apps] azonenberg closed issue #28: Improve state of developer documentation - https://github.com/ngscopeclient/scopehal-apps/issues/28
<_whitenotifier> [scopehal-apps] azonenberg commented on issue #28: Improve state of developer documentation - https://github.com/ngscopeclient/scopehal-apps/issues/28#issuecomment-2362884291
azonenberg has quit [Ping timeout: 248 seconds]
azonenberg has joined #scopehal
sgstair_ has joined #scopehal
sgstair has quit [Ping timeout: 260 seconds]
<d1b2> <azonenberg> https://www.ngscopeclient.org/devdocs/ Initial Doxygen is now up on the website
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://github.com/ngscopeclient/scopehal/compare/e7d96e30fc8a...da194c9bbec7
<_whitenotifier> [scopehal] azonenberg da194c9 - Doxygen pass over ComplexChannel and ComputePipeline
<_whitenotifier> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://github.com/ngscopeclient/scopehal-apps/compare/705888818aa5...dc267838e677
<_whitenotifier> [scopehal-apps] azonenberg dc26783 - Updated to latest scopehal and scopehal-docs, updated developer docs intro
<Fridtjof> hmm. I want to add support to scopehal for my RD6006P PSU. It communicates using modbus over UART, and now i'm thinking about the least painful way to implement this. The driver/transport/bridge model seems to assume I want to use a scope in quite a few places... Implementing this in a bridge server a la Picoscope seems the most viable so far to me
<Fridtjof> (doing it directly in scopehal seems like i'd also end up having to abstract away SCPITransport as well...
<azonenberg> Fridtjof: There is absolutely no assumption you are using a scope
<azonenberg> we support plenty of power supplies etc
<azonenberg> We have native uart support for linux, i dont know about other platforms
<azonenberg> The SCPITransport class is protocol agnostic despite the name, we might rename it
<azonenberg> The base instrument classes kinda assume you are using SCPI but is a weak assumption
<azonenberg> there is an argument you can send to the constructor to say 'don't send *IDN?" during startup
<azonenberg> in which case you can simply use the SCPITransport as a raw byte transport and run modbus or whatever over it
<azonenberg> If you want to make a scpi to modbus bridge thats not a completely ridiculous option given that this would also allow network transparency of the thing
<azonenberg> but is absolutely not required to make it work
<d1b2> <fridtjof> Oh okay, that is very surprising yeah :D
<azonenberg> Basically there are some apis in SCPITransport that provide convenience wrappers for sending line oriented text data with mutexing and stuff
<azonenberg> but if you dont mind more legwork you can just call ReadRawData and SendRawData, iirc, to access the underlying file handle / socket / whatever
<d1b2> <fridtjof> I see
<azonenberg> You just have to manage locking yourself so different threads don't step on each other. the transport has a mutex for this purpose but you're responsible for locking so transactions are atomic
<azonenberg> i.e. lock, send command, wait for reply, unlock
<azonenberg> (otherwise you risk sending a command in the gui thread stepping on stuff the background polling thread is doing)
<d1b2> <fridtjof> Still leaning towards the bridge approach because i'd like to skip implementing modbus with a library And i feel it's not worth adding to scopehal unless there'll be more instruments that would need it
<d1b2> <fridtjof> also yeah network transparency is probably nice
<azonenberg> (From a general perspective, if you find an instrument that doesn't fit our object model well i'd love to hear about it and figure out how we can make it work)
<azonenberg> Idea (not necessarily the best)
<azonenberg> Generic modbus to scpi network bridge
<azonenberg> then implement the device specific driver stuff in scopehal
<azonenberg> this would allow future integration with other modbus peripherals
<azonenberg> using the same bridge
<azonenberg> Maybe make the bridge generic enough it can work with modbus over IP as well as rs232/rs485 etc
<d1b2> <fridtjof> So just pipe modbus register r/w through scpi?
<azonenberg> Yep
<azonenberg> just a simple 1:1 protocol translation
<d1b2> <fridtjof> hmm
<azonenberg> implement *IDN? to identify the bridge and then MODBUS? 0x4141
<azonenberg> MODBUS 0x4141 = 0xdeadbeef
<azonenberg> or something like that
<azonenberg> again not saying its the best optoin but it came ot mind
<d1b2> <fridtjof> is there anything standard i can rely on with modbus to identify stuff? From my first glance it seemed to be just bare registers but i might not have looked into this enough
<d1b2> <fridtjof> Ah function code 0x43 supposedly
<d1b2> <fridtjof> *43 decimal
<azonenberg> if you can translate that to *IDN? usefully great. if not, maybe add a bridge argument to specify what is hanging off the bridge
<azonenberg> so at least scopehal has some way to get ID information
bvernoux has joined #scopehal
<d1b2> <fredzo_72653> LA support for Siglent SDS complete !
<d1b2> <fredzo_72653> @azonenberg let me know if you prefer reviewing the PR for paginated mode before I create this one.
<d1b2> <azonenberg> Awesome 😄 You can squash it all into one PR if you want
<d1b2> <azonenberg> I've been busy but should be able to review this weekend
<_whitenotifier> [scopehal] fredzo synchronize pull request #891: Better Siglent SDS HD support - https://github.com/ngscopeclient/scopehal/pull/891
<_whitenotifier> [scopehal] fredzo synchronize pull request #891: Better Siglent SDS HD support - https://github.com/ngscopeclient/scopehal/pull/891
bvernoux has quit [Quit: Leaving]
Bird|ghosted has quit [Quit: Leaving]
Bird|otherbox has joined #scopehal