<eightdot>
yeah i did not understand the if(rmode == MODE_MULTI_REV) , it is one of the reasons i think a 'discussion' is better then a 'silent' pr/bugreport
<eightdot>
the multi_rev mode realy helped me get a clear picture (no phase jumps), but i guess i could also just have increased to steps/rev
<azonenberg>
Yeah its more a question of avoiding unnecessary duplication of functionality
<azonenberg>
because for example VNAs etc report phases as modulo +/- 180
<azonenberg>
so if you want unwrapped phase to calculate e.g. phase nonlinearity or something
<azonenberg>
you have to do that in post anyawy
<eightdot>
in my case its an encoder on a motor (with a geabox) that drives a meganism by rack and pinion, so degrees did not really make sense, i could have adjested the steps/rev so 1* would be 1 mm but was to lazy for that (i trying to tune the pid controller on that motor, and was mostly concerned with how the step responce looked, not the absulte measuments
<azonenberg>
makes sense
<azonenberg>
anyway, i havent touched that code in a long time
<azonenberg>
and it was pretty quick and dirty, i forget what the sensor i was reading was
<azonenberg>
i think it was whatever digilent's pmod encoder was
<eightdot>
i will try and figure out how to create a (set of) PR('s)
<azonenberg>
one for docs would be good too
<azonenberg>
i dont think it's documented yet
RedMoss has joined #scopehal
<RedMoss>
Hello, can someone share his build of skopehal-sigrok-bridge for Windows? I can't find build instructions for libsigrok4DSL. Eager to see what a 256 megapoint FFT looks like.
<RedMoss>
<RedMoss>
I also found 2 possible errors, after installing dependencies from build instructions I couldn't compile the app, it was solved by installing a bunch more. Probably some of the packages are missing, I can do it again from the start and provide a list of missing packages if someone's willing to make a pull request. Also, the app crashes if lanuched directly, not through CodeBlocks. I think it depends on some UCRT-specific DLLs. Dependency walker
<RedMoss>
and hresult suggested that it imports 32-bit DLLs instead of 64-bit ones. After copying all of them in the app folder it starts working, I can narrow it down and also provide a list. I'm using Windows 7 though, maybe that's the cause.
<RedMoss>
Whoops, that was supposed to be 1 message
<azonenberg>
Louis i think was working on scopehal-sigrok-bridge, i'm not sure what the state is. I've heard rumors it's bitrotted but I don't have any dslabs hardware to test with
<azonenberg>
Any windows build issues are good to know about
<d1b2>
<azonenberg> @meownik ^
<RedMoss>
Okay, thanks for the info. I took a brief look over the code, it seems to be fine, but libsigrok4DSL is a part of DSView, I'd need to find out how to compile it separately. Now that I think of it, maybe just using it as separate files and not a package could work, I'll test it
<RedMoss>
I'll get a proper description for those problems and get back in a few days or a week, a bit busy right now
<azonenberg>
and yes, its assumed that you have that installed somehow but i dont know if it was really well documented yet
<azonenberg>
that was louis's project as i said
<azonenberg>
there was some interest in converting it to a broader bridge with support for more sigrok-supported instruments
<azonenberg>
but i dont know any details about if anyone ever did any work on that
<RedMoss>
Yeah, there's no install instructions on that at all. Even for Linux there's only an openSUSE package. I'll take a deeper look at it then. A broader bridge would be nice, it would be easier to make the program into the one you can use for all lab equipment
<RedMoss>
I'm working on making a Qt client for Nordic PPK2(they use electron) and another client for Miniware power supplies with wireless control(MDP-P906, MDP-L1060), guess I could redirect my efforts to implement the sigrok support
<azonenberg>
Yeah we've generally tried to avoid using third party abstraction libraries like sigrok for a bunch of reasons
<azonenberg>
like their object model being less powerful than ours
<azonenberg>
there's a lot of things theyj ust cant represent well
<azonenberg>
and of course the whole need for an external bridge as a license boundary between GPL and non-GPL code which is a huge hassiel
<azonenberg>
hassle8
<azonenberg>
gaah
<azonenberg>
cant type today lol
<azonenberg>
Native scopehal drivers for those instruments all sound useful
<RedMoss>
Yeah, I thought of interface robustness, too, not about the licenses. Okay, I'll try to implement it directly for scopehal, not sure how long it will take me though. I'll start with PPK I guess, for Miniware you'd need a NRF24L01 dongle with your own USB converter board and protocol to interface it
<azonenberg>
So once you start getting to weird APIs and SDKs and stuff is where we start thinking about bridges regardless of license boundary concer
<azonenberg>
concerns*
<azonenberg>
e.g. for picoscopes
<azonenberg>
because we want to avoid a) a proliferation of dozens of scopehal builds with different config options on different OSes and linux distros or b) forcing people to install a huge number of SDKs to run ngscopeclient at all even if they don't have any reason to use a specific driver
<azonenberg>
this is a nice way to modularize things and make the bridge an opt-in component you pull if you want to use that device
<RedMoss>
Picoscope is a bit weird, yeah, with its own SDK. Was looking at one of the models in favor of DSLogic U3P100 but they've also had a client written in electron I think. Then I saw Thundescope and thought, gonna get that one if it's gonna work on Windows 7, but for now U3P100 is enough if I use it with the client
<RedMoss>
PPK has a very simple protocol, there's a python implementation somewhere on github, I think I'll spend more time getting to know the codebase than actually writing a driver
<azonenberg>
Makes sense
<azonenberg>
also just as a heads up we're currently in a soft freeze type state trying to get ready for an upcoming release that we hoped to have done end of 2024
<azonenberg>
but people were busy
<d1b2>
<meownik> RedMoss: I don't know that I ever even tried to build it on windows 💀
<d1b2>
<meownik> I haven't touched that in quite a long time
<azonenberg>
so we probably won't be merging new drivers in the near future
<azonenberg>
the focus is on fixing bugs and especially packaging/build issues on various OSes so we can get a release out the door
<azonenberg>
Feel free to write a driver and PR it, just dont expect a quick merge
<azonenberg>
since i want to avoid adding new potential for failure just before a release
<RedMoss>
Sure, I don't think I'll be that quick anyway
<RedMoss>
meownik: *And so the quest begins. Led by a faint promise of finding quick answers, the hero now must dive deep into thousand-year-old texts and recipies in search for knowledge lost many ages ago.*
<RedMoss>
Well, I keep makefile support for llama.cpp in my local repository, can't be much harder than that