azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-cmake, https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal | Logs: https://freenode.irclog.whitequark.org/scopehal
<azonenberg> whitequark: it's on "linter notes" on the openfpga github wiki
<bluezinc_> azonenberg: any idea what my graphics card is missing now?
<azonenberg> Let me work on the antialiasing fallback
<azonenberg> gimme a few
<bluezinc_> k.
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/fjrov
<_whitenotifier-3> [scopehal-apps] azonenberg 4b9d6bb - WaveformArea: added non-multisample fallback
<_whitenotifier-3> [scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/fjrof
<_whitenotifier-3> [scopehal-cmake] azonenberg a4f4309 - Updated to latest scopehal-apps
<azonenberg> bluezinc_: try that
<bluezinc_> hang on, give me like 5 minutes to boot the desktop
<bluezinc_> azonenberg: well, I don't get the perpetual error 506 anymore
<bluezinc_> it's still all black and doesn't work, but it's progress
<bluezinc_> and whenever I resize I get an "resize 4, err = 502"
<bluezinc_> but no more render errors are printing. https://imgur.com/a/K15bj42
bluezinc_ has quit [Quit: Do not go gentle into that good night.]
bluezinc has joined #scopehal
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/fjroQ
<_whitenotifier-3> [scopehal-apps] azonenberg 8fafafc - More MSAA fallback fixes
<_whitenotifier-3> [scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/fjro7
<_whitenotifier-3> [scopehal-cmake] azonenberg e3c62bb - MSAA fixes to glscopeclient
<azonenberg> bluezinc: what about that?
<bluezinc> still "resize 4, err = 502" and toolbar is black
<azonenberg> hmmm
<azonenberg> That's GL_INVALID_OPERATION
<azonenberg> can you poke around a bit in WaveformArea_events.cpp:87-109
<azonenberg> add some extra glGetError() calls
<azonenberg> see if you can narrow down what's failing
<azonenberg> And see if the if statement on line 93 is triggering or not
<bluezinc> execution does enter the if
<bluezinc> "m_waveformTexture.AllocateMultisample(width, height, 4);" < there's your problem
<azonenberg> ... oh
<azonenberg> I didn't add a glGetError() in the if to ignore that error
<azonenberg> Which means the printed error is a false positive for a condition we gracefully recovered from
<azonenberg> and the toolbar error is unrelated
<bluezinc> so that's on loading.
<bluezinc> I also get error 502 from a bunch of stuff when resizing
<azonenberg> yeah that's the same code path
<azonenberg> resize is called during window creation
<bluezinc> I know. but it fails on different lines
<azonenberg> ... oh?
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/fjrKv
<_whitenotifier-3> [scopehal-apps] azonenberg 15fb2f6 - Suppress error message when we fall back from MSAA to non-AA
<azonenberg> where's the other failure
<bluezinc> m_waveformTexture.Bind(GL_TEXTURE_2D_MULTISAMPLE);
<bluezinc> m_waveformFramebuffer.SetTexture(m_waveformTexture, GL_TEXTURE_2D_MULTISAMPLE);
<bluezinc> those are the other two.
<azonenberg> Yeah
<azonenberg> So basically despite being GL 3.x your vmware gpu doesn't support MSA
<azonenberg> MSAA*
<azonenberg> in any case, though, we fall back to the if statement being taken
<azonenberg> and the other path should delete all of that invalid junk and recreate valid textures
<azonenberg> if you dont get errors in the actual render code path, it's working
<azonenberg> So i think this is a solved issue and the toolbars are a completely unrelated bug
<azonenberg> So, have you tried actually creating some waveforms to render?
<azonenberg> i.e. should we be expecting waveforms to show up?
<bluezinc> yeah. I think I've got all the code to do that.
<bluezinc> other than the part where the waveforms aren't appearing, of course.
<azonenberg> ok, let's see... just to sanity check, break on WaveformArea_rendering.cpp:379 and check if m_waveformLength is a sane value
<azonenberg> that should be some number of points
<bluezinc> so it looks like my code to send waveform data is never callled, so that number is zero
<bluezinc> so I'm assuming that I'm implementing the wrong function, then.
<bluezinc> I've got an AcquireData
<azonenberg> Did you check if that's ever called?
<azonenberg> or you're assumine zero because waveformlength is zero
<bluezinc> I threw a print in it. it doesn't print.
<azonenberg> What did you do for PollTrigger()?
<bluezinc> what am I supposed to do for that?
<bluezinc> I think it should return TRIGGER_MODE_RUN by default
<azonenberg> Not exactly
<azonenberg> TRIGGER_MODE_RUN means the trigger is armed, but the scope is waiting for a trigger event
<azonenberg> if you stay in that forever, that implies you have a trigger condition that isn't happening
<azonenberg> TRIGGER_MODE_TRIGGERED means a waveform is ready to be read out
* monochroma is triggered
<bluezinc> not quite the terminology I would have chosen, but OK. I'll try it.
<azonenberg> See Oscilloscope.h:215
<azonenberg> Did you not read that, or are the comments unclear?
<azonenberg> (this is good feedback, you're the first person to try adding significant features to scopehal - so you're the guinea pig to find all the spots the documentation needs improvement lol)
<bluezinc> I did read that.
<bluezinc> it's not really clear what PollTrigger was used for.
<azonenberg> Ah, OK
<bluezinc> I interpreted that as basically a setter/getter
<bluezinc> so normal-vs-auto-vs-stop
<bluezinc> not "Is data ready?"
<azonenberg> Basically, the acquisition thread sits in a loop checking if the scope has data ready to read
<azonenberg> So you can return "I'm not even trying to trigger, come back in a while"
<azonenberg> "I'm waiting for a trigger event"
<azonenberg> or "I have data for you"
<bluezinc> ok, I saw a sine wave flicker across the screen for a couple of ms.
<azonenberg> I thought the "poll" rather than "get" in the function name implied it was used that way, i guess it wasn't clear enough
<azonenberg> And then what?
<bluezinc> I'm pretty sure this one is on me.
<azonenberg> Well, keep us posted i guess :)
<bluezinc> actually, this might not be me.
<bluezinc> something's segfaulting
<azonenberg> backtrace?
<bluezinc> ok, let me remember how to do that.
<bluezinc> Thread 13 "glscopeclient" received signal SIGSEGV, Segmentation fault.
<bluezinc> [Switching to Thread 0x7fffb2ffd700 (LWP 16780)]
<bluezinc> 0x00005555555a1c08 in WaveformArea::_ZN12WaveformArea15PrepareGeometryEv._omp_fn.0(void) ()
<bluezinc> at /home/matt/scopehal-cmake/src/glscopeclient/WaveformArea_rendering.cpp:82
<bluezinc> 82 float xleft = data.GetSampleStart(j) * xscale;
<bluezinc> (gdb) backtrace
<bluezinc> #0 0x00005555555a1c08 in WaveformArea::_ZN12WaveformArea15PrepareGeometryEv._omp_fn.0(void) ()
<bluezinc> at /home/matt/scopehal-cmake/src/glscopeclient/WaveformArea_rendering.cpp:82
<bluezinc> #1 0x00007ffff7217ee6 in () at /lib/x86_64-linux-gnu/libgomp.so.1
<bluezinc> #2 0x00007ffff71cb182 in start_thread (arg=<optimized out>) at pthread_create.c:486
<bluezinc> #3 0x00007ffff70f4b1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
<azonenberg> And can you either pastebin your oscilloscope class or push to a github fork so i can see it?
<azonenberg> bluezinc: looking
<azonenberg> if you still have the gdb session up (or restart it) can you print *pdat?
<azonenberg> Comments so far... for GetInstrumentTypes() please use INST_OSCILLOSCOPE and not the magic number 1
<azonenberg> Why are you creating channels twice, once in the constructor and once in DetectAnalogChannels()?
<azonenberg> Also, the scopehal project uses Allman/ANSI-style braces, not K&R/Linux Kernel style like you used
<azonenberg> (just a formatting change but please fix before I merge)
<azonenberg> The protocol decoder stuff on 233-239 is unnecessary but used to be needed before some refactoring
<azonenberg> what class did you pull that out of? whatever you copied it from needs tobe fixed :p
<azonenberg> But it's redundant and shouldn't break anything
<azonenberg> You also aren't handling the toQueue argument correctly
<azonenberg> in AcquireData()
<azonenberg> if set (which glscopeclient always does, the only time it's not set is in custom apps using libscopehal for non pipelined ATE-type stuff), you should be storing the waveforms into m_pendingWaveforms
<azonenberg> See LeCroyOscilloscope.cpp:1038-1052
<azonenberg> Also GetExternalTrigger() should return null if you don't have an external trigger input, rather than nothing
<azonenberg> (right now you end up with whatever garbage value was in the return address register, which might confuse things)
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
anuejn has quit [Quit: No Ping reply in 180 seconds.]
anuejn has joined #scopehal
bvernoux has joined #scopehal
<bvernoux> hello
<azonenberg_work> o/ bvernoux
<azonenberg_work> Prototype enclosure for the v0.4 z0 probe is in, as are all passives and connectors
<azonenberg_work> pcb eta the 9th of july
<bvernoux> ha great
<bvernoux> could you share your qucs project/files for check ?
<bvernoux> like that I will avoid to do it from scratch from your screenshot in Tweeter
<bvernoux> I will add S-parameters simulation
<bvernoux> like that I could compare S-params simulated vs real one when I will receive it
<bvernoux> it will be interesting to do modelling with previous probe too
<azonenberg> sims/ on the starshipraider repo has it
<bvernoux> in order to compare simulation vs reality
<bvernoux> ok great
<bvernoux> do you have tried Qucs Studio ?
<bvernoux> as it is even more advanced than the old Qucs
<bvernoux> it is more recent and done by the core guy which developed Qucs
<azonenberg> no i have not
<bvernoux> ha nice you have even done some work with OpenEMS
<azonenberg> a tiny bit, but nothing successful
<azonenberg> The modeling for the compensation caps was done in Sonnet
<bvernoux> Sonnet seems very nice too way more intuitive/easy than OpenEMS ;)
<azonenberg> Yes, it does
<azonenberg> The only problem is the price
<bvernoux> OpenEMS=GRC ;)
<azonenberg> the lite version caps you to 32MB of ram, 2 ports, and some other pretty serious issues
<bvernoux> do you have used lite version for the simulation ?
<azonenberg> Yes
<bvernoux> as so it is enough for that simulation at least ?
<azonenberg> actually no you can use up to 4 ports, the limit of 2 is 2 conductor layers
<azonenberg> It was enough for one of the 500 fF caps
<azonenberg> i couldnt do the whole 1pF cap or the entire tip geometry
<bvernoux> ha ok
<azonenberg> sonnet level 2 basic still has a pretty severe 128 MB memory limit and 2 signal layers, but lets you do thick metal, unlimited ideal components within the design, up to six port circuits, and (with an additional option) gerber import/export
<azonenberg> And that's $4625
<bvernoux> maybe could be interesting to check with 30day evaluation version which maybe does not have those limits to fully evaluate the product
<azonenberg> You can get 30 day eval of the full system, yeah
<azonenberg> but if i cant afford it, i dont even see the point
<bvernoux> yes
<azonenberg> i cant do all of my work in 30 days
<azonenberg> What i want is a UI like sonnet has, backed by openems
<bvernoux> me too I prefer something free for the job even if the learning curve is harder with OpenEMS or other ...
<azonenberg> rather than having to write python to model something
<azonenberg> i dont like using black-box software either, but i can only shave so many yaks at a time :p
<monochroma> azonenberg: start paying people to shave yaks for you
<monochroma> :3
<azonenberg> Lol once the construction is done if i end up with spare cash that is an option
<bvernoux> I'm also quite interested for my future RF things ;)
<bvernoux> need to evaluate it
<azonenberg> in which, openems or sonnet?
<bvernoux> the must will be openems but I'm not fan of python things ;)
<azonenberg> me neither :p
<azonenberg> it looks like you also don't get the parallel solver in sonnet until you get the "professional" edition
<azonenberg> which is $CALL_FOR_PRICE
<bvernoux> also Qucs Studio allow to design complex filter
<bvernoux> with PCB traces
<azonenberg> level 3 gold is $12495
<bvernoux> but it shall be done by hand in KiCad at end ;)
<azonenberg> so i can only imagine professional is somewhere in the 15-20k range
<azonenberg> if not more
<bvernoux> ha yes it is why I have not seen the price ;)
<bvernoux> in order to buy that I will need to release some project to gain enough cash ;)
<azonenberg> Yeah i am a long ways from being able to afford that
<azonenberg> but on the flip side i dont think the current f/oss tools are at that level
<bvernoux> yes they are clearly not when I see spec of Sonnet
<azonenberg> and i dont have the skills to fix openems/make a proper gui for it
<azonenberg> I also dont have the time to wait for people to fix it
<azonenberg> or the cash to pay people to :p
<bvernoux> it seems the 1st interesting one is Sonnet Level 2 Basic => as it include Gerber Import/Export ;)
<azonenberg> i dont think it includes it in the price
<bvernoux> 4625USD ...
<azonenberg> it says "optional"
<azonenberg> meaning you have to pay extra
<bvernoux> ha yes there is a * ;)
<bvernoux> they have university discount ;)
<bvernoux> maube open source project could be similar
<azonenberg> Possible
<azonenberg> it cant hurt to ask
<monochroma> that would be cool
<bvernoux> also I have found a very nice way to tune antenna with MegiQ VNA App ;)
<bvernoux> as it can import s-parameters (which shall be in Hz else it does not work)
<bvernoux> then you can compute the required matching and it provide values for capacitor/inductor ...
<bvernoux> as before I was using some excel things to compute ....
bvernoux has quit [Quit: Leaving]
<bluezinc> azonenberg: so how exactly is toQueue supposed to work?
<azonenberg> bluezinc: m_pendingWaveforms is a list of waveforms that have been acquired, but not yet displayed
<azonenberg> each element is a SequenceSet, which is a map from channels to captured waveforms
<azonenberg> So each time you acquire data you should create a SequenceSet containing one waveform per channel, then add to m_pendingWaveforms
<azonenberg> locking m_pendingWaveformMutex around the push
<azonenberg> The reason i have it done this way is that some scopes batch waveforms and give you a bunch at once
<azonenberg> for example sequence-mode capture
<azonenberg> And this rpovided better decoupling between capturing and processing/display of waveforms in multithreaded systems
<azonenberg> If toQueue is not set, you instead write the captured waveform data directly to your channels using channel->SetData()
<bluezinc> so we have a sequenceset of channel->waveform
<bluezinc> the more I look at this, the less sense it makes.
<bluezinc> google is failing me now... What even is a SequenceSet?