electronic_eel has quit [Ping timeout: 272 seconds]
_whitelogger has joined #scopehal
electronic_eel_ is now known as electronic_eel
<electronic_eel>
azonenberg: I think splitting the decoder and the velocity filter is the better solution. because the velocity filter can be reused for other things where speed / rate of change is interesting, like monitoring process temperature or similar
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±6] https://git.io/JUEYw
<azonenberg>
Right now there's no reset pulse support, and there are four config settings for the filter: pulses per revolution, interpolation mode (linear or none, to produce a smooth or blocky curve)
<azonenberg>
then wrapping mode (single rev = wrap phase to +/- 180 deg, multi rev = phase keeps integrating forever)
<azonenberg>
and a timer value for debounce
<electronic_eel>
nice
<electronic_eel>
hmm, I finally should get around to buy a new gpu so that I can use glscopeclient...
<azonenberg>
what do you have now?
<electronic_eel>
some older integrated intel thing, I think haswell. I checked the opengl parameters you mentioned here and it was missing one feature
<azonenberg>
Hmmm
<azonenberg>
what opengl version do you have?
<azonenberg>
as of now i require GL 4.3 and GL_ARB_gpu_shader_int64
<electronic_eel>
it has GL 4.5, but it is missing the int64 shader, just has a fp64 shader
<azonenberg>
hmm, interesting. yeah int64 isa a hard requirement now
<azonenberg>
pretty sure haswell integrated is literally the only platform with recentish GL that doesn't do it
<azonenberg>
So you got the short straw lol
<azonenberg>
any post haswell integrated gpu or <10 year old discrete card should do it
<azonenberg>
btw, did you get the AKL-PT1 i sent you yet?
<electronic_eel>
I didn't get the probe yet, landed in Germany, but is still in customs
<electronic_eel>
the older discrete gpus either don't have 3 digital monitor outputs or require blob drivers
<electronic_eel>
so I'll buy a new amd
<electronic_eel>
the workstation at home is getting a bit old, so no problem
<azonenberg>
Sounds like a plan
_whitelogger has joined #scopehal
<noopwafel>
:o
<electronic_eel>
this configures the scope to trigger on any uart data, right? or did you enter some characters it should trigger on? I didn't see them
<azonenberg>
electronic_eel: see the "pattern"
<azonenberg>
it's triggering on "lol"
<azonenberg>
note the position of the pink arrrow on the timeline
<electronic_eel>
ah, I missed that
<azonenberg>
the scope supports up to i think a 12-byte trigger pattern
<azonenberg>
(right now i don't enforce a limit, so if you type something too long it will probably derp out somehow)
<electronic_eel>
I should check what my rigol supports for the uart trigger
<azonenberg>
Right now all of the advanced (i.e. not edge) trigger types are only implemented for LeCroy
<azonenberg>
but it should be straightforward to do them in other drivers
<azonenberg>
Trigger classes allow you to disable some features if the scope doesn't support them
<electronic_eel>
straightforward as in figuring out what the quirks in the scpi for this scope model are...
<azonenberg>
Lol
<azonenberg>
well did you see the hoops i had to jump through doing lecroy trigger support?
<azonenberg>
they have different enums for different kinds of pattern matching
<azonenberg>
so "LessThan" vs "Smaller"
<azonenberg>
or "Greater" vs "GreaterThan"
<electronic_eel>
you posted some stuff here, yeah. that was why I was mentioning it
<electronic_eel>
the uart decode in your screenshot is done in scopehal, not on the scope, right?
<azonenberg>
Correct
<azonenberg>
I detect the UART software option during boot but only use the trigger feature, not the decode
<azonenberg>
If you don't have the option installed I hide the trigger type from the dropdown in glscopeclient to avoid confusing the user
<electronic_eel>
can you do advanced stuff like guessing baudrate and parity?
<azonenberg>
At the moment my uart decode requires you to configure baud rate and only supports 8N1 mode
<azonenberg>
the trigger actually is more advanced and supports parity and 1.5/2 stop bits, since that's done scope side
<electronic_eel>
ok, but I guess if someone wants that feature, they can add it to the code
<azonenberg>
Yes
<azonenberg>
I think there's an open ticket for it
<azonenberg>
but i've had no reason to work on it as i haven't seen anything but 8N1 in use in forever
<azonenberg>
i think once in my career i saw even parity on a link
<azonenberg>
and was like "wow people actually use uart parity?"
<electronic_eel>
some older industrial gear likes different modes, like 9 bits for rs485
<azonenberg>
>8 bit mode is on the todo as well. the lecroy trigger can do i think 4-9 bits but i havent implemented the UI side for that
<azonenberg>
I actually have a rs485 pmod that came in the same digilent order
<azonenberg>
havent tried using it yet
<electronic_eel>
I think I once fiddeled with an older printer which had parity or different stop bits
<electronic_eel>
don't remember the details
<azonenberg>
Yeah they exist. they're just suuuper rare
<azonenberg>
Ok so, what next? i've finished up the stuff i'm actively working on
<azonenberg>
can easily add more trigger types (i2c and spi are pending)
<azonenberg>
the peak hold filter would be pretty easy
<azonenberg>
persistence is still broken on the new renderer, i havent lookd at how much work it would be t oadd yet
<azonenberg>
to re-add*
<electronic_eel>
just browsed through the manual (downloaded pdf), it still mentiones haswell as supported and doesn't mention GL_ARB_gpu_shader_int64
<azonenberg>
let me updat ethat
<electronic_eel>
I suggest adding "glxinfo | grep GL_ARB_gpu_shader_int64" as a way to find out if it is supported or not
<azonenberg>
I was just going to say known hardware
<electronic_eel>
hmm, I prefer some rough guidelines regarding the known hardware and then commands for the details
<electronic_eel>
because you can't know all niche hardware details
<electronic_eel>
also often people don't know what hardware they have
<azonenberg>
true
<electronic_eel>
glxinfo | grep "core profile version" is for finding the opengl version
<azonenberg>
actually right now i think i'm using a compat profile because that's what GTK requests by default
<_whitenotifier-f>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JUEOF
<_whitenotifier-f>
[scopehal-docs] azonenberg a87078f - Updates to new decodes and system requirements
<electronic_eel>
for compat version I get: Max compat profile version: 3.0
<azonenberg>
interesting. maybe i'm not then
<azonenberg>
i know i request 4.3 at startup
<electronic_eel>
pdf looking good now
<electronic_eel>
so how many days left do you have on your sonnet trial?
<azonenberg>
-9
<azonenberg>
I'm back to L2 Basic now
<azonenberg>
but it was well worth the effort and i'm already in talks with my sales rep to upgrade to gold or silver, depending on budget, in december
<azonenberg>
Between now and then i want to write a kicad .son exporter
<azonenberg>
kicad's dxf export is broken and importing multiple DXFs into sonnet was annoying anyway, kicad has no way to export drill outlines as dxf at all
<azonenberg>
so i feel like a native exporter is the way to go
<azonenberg>
the other option is to pay $1.1K or so for the GDS2 import option in sonnet
<noopwafel>
oof
<azonenberg>
Which works well. Kicad can't export GDS natively but it can export gerbers, and klayout can translate gerber to GDS2
<electronic_eel>
it should make the native gerber import of sonnet unnecessary, because you could import most gerbers into kicad
<azonenberg>
that is the path i used to get kicad designs into sonnet during the trial
<azonenberg>
electronic_eel: the native gerber import for sonnet has a five digit price tag and is windows-only
<azonenberg>
it's a third party component they license
<azonenberg>
It's never been on the table for me
<azonenberg>
my options for interchange between kicad and sonnet are native .son, dxf, or gds2 if i'm willing to pay for it
<azonenberg>
even if the not-closed-polygon bugs were fixed the dxf export would need a ton of work and doesn't output the style sonnet wants (kicad does one dxf per layer, sonnet wants one file with one pen type per layer)
<azonenberg>
and the .son format is a well documented plain text format
<azonenberg>
So i think it would be the best route
<electronic_eel>
yeah, that is what I meant. when you write the kicad exporter and other customers find out, the third party component isn't needed anymore
<azonenberg>
That is a possibility, lol. But i suspect most big customers wont want to do that
<azonenberg>
They didn't sound hostile to the idea, their support happily gave me the spec when i told them i was trying to develop a converter
<azonenberg>
and the sales rep even told me the gerber options is normally not something people use, and just go through dxf
<electronic_eel>
if it is a third party thing they license, I guess they don't get rich on selling this module
<azonenberg>
it sounds like they licensed a third party module just to say they could read gerbers
<azonenberg>
i doubt they make much profit on it
<azonenberg>
when the sales guy tells you not to waste your money on something there's usually a reason for it
<azonenberg>
anyway, depending on how busy i am this year i may or may not have time to write the converter soon
<azonenberg>
i may buy the gds option just as a temporary hold-over
<electronic_eel>
maybe it is just a gerber to dxf thing which then goes into the regular dxf import?
<azonenberg>
quite possible, i'm not sure. it's a windows only binary component i know that much
<azonenberg>
also the gds export leaves a ton of junk in /tmp it doens't clean up
<azonenberg>
:p
<azonenberg>
import*
<azonenberg>
so native .son seems to be the cleanest route
<azonenberg>
It just might take me a while as i havent touched that part of the kicad code in years, since i fixed the broken microvia export in v4.x
<azonenberg>
and it's now Q4, which is historically the busiest time of year at $dayjob
<azonenberg>
And we've had some folks quit recently, and if that wasn't enough almost all of our seattle based embedded work is going to me because i have a lab at home and none of the other seattle folks do
<azonenberg>
i'm already booked on projects through the end of the calendar year
<electronic_eel>
hmm, why doesn't someone skilled in embedded work have not at least basic equipment at home?
<electronic_eel>
now a lab like yours might be not everyones thing and budget, but at least some debug adapters and a cheap scope?
<azonenberg>
Some folks are working on building out home labs. a lot of them are pretty junior and just getting into embedded
<azonenberg>
i know at least one guy has a bunch of mcu devkits etc but no scope yet
<azonenberg>
another one does a lot of SDR stuff
<azonenberg>
But there's a certain critical mass of tooling you need to be able to be thrown into an embedded system you've never seen before and reverse it
<azonenberg>
using a chipset you may have never seen before
<azonenberg>
you need to be able to solder probe wires to weird headers you don't have a mating part for, desolder and dump flash chips, etc
<monochroma>
microscope :3
<azonenberg>
Having enough gear to do basic development doesnt mean you can throw yourself into a completely new ecosystem and work on it
<electronic_eel>
ok, but do they really have the skills to do this kind of stuff and are just lacking the gear?
<electronic_eel>
I often see that people that acquired the skills over the years also keep some equipment around
<azonenberg>
Yeah. We have a lot of junior folks we're training up
<azonenberg>
there was a big brain drain and we're rebuilding
<azonenberg>
Which also means more work for me
<azonenberg>
a bunch of new folks got hired right before covid hit and didnt get enough time in the lab under supervision of more experienced people to be comfortable working on hardware stuff solo
<azonenberg>
so for the most part they're stuck doing software stuff until we can reopen the lab. Which is likely next summer at the earliest
<azonenberg>
electronic_eel: anyway, as far as dev priorities go... any specific targets?
<noopwafel>
my soldering/etc skills only became acceptable after I left $securitylab and no longer had access to people who could do it for me :)
<monochroma>
noopwafel: XD
<noopwafel>
(waste time and potentially break customer board vs ask someone in lab support to desolder, never a difficult choice..)
<monochroma>
they always give you spares to break! ;)
<electronic_eel>
azonenberg: finish MAXWELL, MEAD and CONWAY?
<electronic_eel>
re scopehal and glscopeclient I think I need to have it running on my workstation first to get a feeling which feature I'm missing most
<azonenberg>
electronic_eel: MEAD is designed and at manufacture now. No action requred
<azonenberg>
CONWAY is on hold until i've got MEAD running with MAXWELL i think. It's not a priority for me and if I see any shortcomings in MEAD during actual use, i want to fix those before doing a second design with the same mistakes
<azonenberg>
as far as finishing MAXWELL, that's on hold due to budget until probably end of month. Most of my income this month is going to the construction
<azonenberg>
My board house takes paypal credit cards for lower valued orders but for larger amounts (more than 1k USD or so) they prefer wire transfers as the conversion fee is much lower. But that means having it in my account, not just ready before the credit card bill comes
<electronic_eel>
so did you finish the board design and it is just waiting on the boards to be manufactured?
<azonenberg>
I have to do a few little tweaks like adding more vias to some high current power rail layer changes
<azonenberg>
and a final signoff review on the layout
<azonenberg>
it's been stuck in that state for the past month or so while i do less expensive projects
<electronic_eel>
hmm, I never developed a project that was that expensive
<azonenberg>
probably the weekend of the 26th or 3rd i'll try to finish the layout then do review during the week
<azonenberg>
Exactly. So it's going slowly. The MEAD pods for one system are $2054 in populated PCBs, estimated $513 in import duty, $140 in LCDs, $155 in cabling, and about $850 in enclosures
<azonenberg>
MAXWELL will be (at qty 2) about $1500 in parts and $800 in PCB, plus assembly costs and machining of the enclosure
<azonenberg>
So one full system is going to be $5K or more
<azonenberg>
And i'm paying for two until the university reimburses me for the one i'm making for them, so my short-term expense out of pocket will be closer to $10K
<electronic_eel>
that is quite a lot. but peanuts if you compare it to buying similar things from keysight or lecroy
<azonenberg>
Yeah
<azonenberg>
But that is the pace of budget/pricing to expect for my longer term projects
<azonenberg>
the AD9213 based scopes will be $2-4K per ADC alone
<azonenberg>
even doing a single channel dev platform will probably be a >$5K project when you add in the pcb and frontend
<azonenberg>
and thats for the acquisition board, not counting the fpga subsystem
<azonenberg>
But the good news is, these projects are so massive from an engineering perspective that the amortized cost per month won't be that high
<azonenberg>
i expect probably 6+ months to get maxwell and glscopeclient working together pushing >1 Gbps of waveform data end to end
<azonenberg>
(sustained, not peak)
<azonenberg>
and then when you add in the months of schematic and PCB time, say in the end it costs me $6K over 8 months is less than $1K/mo
<azonenberg>
Also, next rev probe is coming back from fab to oshpark eta Thursday, probably gonna get to me by next weekend
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #10: Add UI for selecting external trigger - https://git.io/JUEG1
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #33: Cursor text label should show signal amplitude for voltage/frequency traces - https://git.io/JUEGH
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #33: Cursor text label should show signal amplitude for voltage/frequency traces - https://git.io/JUEGQ
<azonenberg>
So i'm looking at lecroy's active probes. Interesting observations
<azonenberg>
DX20-QC-ND
<azonenberg>
Can anyone identify that coax connector?
<azonenberg>
It appears this very expensive probe tip is just a bunch of precision 56 ohm carbon resistors, a 2-pin 100 mil header, possibly some kind of SMT resistor, then a flex PCB that bridges the two signals out to coax connectors
<azonenberg>
which then mates to an external differential amplifier
<azonenberg>
And you pay $620 for that lol
<azonenberg>
I think building something conceptually similar but for a fraction of the price should be very doable
<azonenberg>
i'd likely use my proven SMT resistor attenuator though
<miek>
keysight's got a very similar product line (the infiniimax probes & heads). i'm pretty sure they use SMP connectors on theirs, they look kinda similar to the lecroy one but maybe not quite
<azonenberg>
looking more at a manual it seems like they have the 56 ohm carbon resistors you solder to the DUT as an attachment point, then the probe tip contains two more unknown value resistors in series with them
<azonenberg>
and then a parallel differential terminator
<azonenberg>
I'm looking at probably getting a 4 GHz active diff probe for my scope at some point. One.
<azonenberg>
and then i want to build a bunch more of my own and compare performance :p
<azonenberg>
ideally i'd like to get a VNA on the output of the lecroy probe and compare end to end flatness
<azonenberg>
Connectors lecroy is known to use are BNC for probus, some kind of upgraded BNC for probus2, and BMA for prolink
<miek>
but yeah, i'm very interested in some diff probe heads. i've been looking very closely at keysights ones for a while, wanting to build something similar with that 7GHz amp
<miek>
i was planning to do some work on it before the TDR quit on me :<
<azonenberg>
well first priority remains pushing the passive probe to at least 4 GHz
<azonenberg>
i think i've got it with this round
<azonenberg>
i'll know in a week or so
<miek>
interestingly lecroy's one seems more like i was expecting, keysight's seems to be dual gcpw rather than edge-coupled diff pair
<azonenberg>
If i were to build one, I might actually go dual gcpw
<azonenberg>
But it depends in part on what connector i pick and what gives the best launch
bvernoux has joined #scopehal
<bvernoux>
hi
<bvernoux>
azonenberg, do you remember the reference of Vishay 100ohms/50ohms resistor you bought ?
<bvernoux>
the RF microwave version up to 40Ghz
<bvernoux>
I want to check those ones FC0402E1000BTT0,
<bvernoux>
FC0402E50R0BST1,
<bvernoux>
FC0402E50R0BTBS
<azonenberg>
BTT0 is what i'm using
<azonenberg>
It looks like the last 2 characters are just distributor packaging code: T0 = tape and reel qty 100, T1 = tape and reel qty 1k, BS = bulk pack
<azonenberg>
then the first B is 0.1% tolerance
<azonenberg>
so the difference is just T vs S. T = NiAu flip chip
<azonenberg>
S = wraparound SAC305 plated
<azonenberg>
So FC0402E50R0BST1 is not flip chip package
Nero_ has quit [Quit: Leaving]
<bvernoux>
yes I want to test both to see the effect from 30kHz to 6GHz
<bvernoux>
so all is good
<bvernoux>
thanks
<bvernoux>
I was checking if there is not other similar part at other manufacturer but I have found notihing
<bvernoux>
nothing
<bvernoux>
azonenberg, do you have seen the new Tek 6-Serie B MSO ?
<bvernoux>
It is even more amazing than previous version with 50GSPS ...
<azonenberg>
Several hours of work on a layout algorithm later
<azonenberg>
miek: how's this look?
<miek>
very nice!
<bvernoux>
those fft peaks with text are very nice !!
<bvernoux>
really like how it is clear
<azonenberg>
I now use a simple repulsion model to keep them from overlapping
<azonenberg>
seems to be working well
<bvernoux>
so you have found a solution to have those boxes and avoid text are spaced correctly ?
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+1/-0/±2] https://git.io/JUEBe
<_whitenotifier-f>
[scopehal-apps] azonenberg debd5f7 - Major improvements to appearance of FFT peaks
<bvernoux>
azonenberg, does it work fine in realtime too ?
<bvernoux>
with smooth display and text box ?
<azonenberg>
They bounce around just a little bit as peaks move, i may do some stability improvements, but i don't find it distracting
<azonenberg>
longer term plan is going to be saving the last location of the box then using that as the start for this frame's position calculation if the peak is within X Hz of the last one
<bvernoux>
azonenberg, do you have news with your latest compensation on your passive probes ?
<bvernoux>
It seems you can reach >5GHz
<bvernoux>
which will be very amazing for the price to be checked if you can reproduce that on multiple probes without too much variations
<bvernoux>
my KC908 can be used as accurate sig gen up to 14GHz ;)
<bvernoux>
I need to test it for that
<bvernoux>
they have released a GNU Radio driver/mod too
<bvernoux>
now I can use it with Gnu Radio to receive or transmit like a SDR
<azonenberg>
bvernoux: as of early this month, i had ~5 GHz bandwidth with a big resonant peak
<azonenberg>
i added the filter, the v1.2 board is at fab, and it should ship to me thursday
<azonenberg>
expecting it by the weekend
<azonenberg>
Expecting closer to 4-4.5 GHz usable bandwidth after the compensation, but a lot flatter
<azonenberg>
We'll see
<azonenberg>
My simulations are still imperfect
<azonenberg>
I dont like the tek approach because i dont want to lose analog channels when i do digital stuff
<bvernoux>
yes the only good things on Tek stuff is it seems they can mix trigger on Digital or Analog channel
<azonenberg>
Yeah that's something i dont like about lecroy. i don't think any of their instruments can do that
<azonenberg>
i dont know how the waverunner digital board connects internally, but the HDA125 high-speed logic module is actually usb3 for the data portion, plus clock and some sync pulses
<azonenberg>
I'm ~99% certain i even know which fpga is inside the thing without opening it up :p
<bvernoux>
woo very interesting research => A laser pulse channelled through a curved 'snail' target can generate magnetic fields of thousands of Tesla, thanks to a 'Whispering Gallery' effect
<bvernoux>
azonenberg, Lecroy are quite old compared to latest Tek / Keysight scope
<bvernoux>
all new ones have nice big touch screen with 12bits ADC with lot of GSPS
<azonenberg>
i mean the new lecroy stuff has that too
<bvernoux>
I'm not sure touch screen is always a must have for a scope anyway ;)
<azonenberg>
The stuff i have is four years old
<azonenberg>
miek: hey, ping re the status of the usb decodes
<miek>
no updates, though some of the current discussion is relevant
<miek>
i was waiting to look at segmented capture first, so can get a good capture of lots of packets in a row and verify things like pid toggle
<azonenberg>
ah ok. with lecroy segmented capture works, i just don't have a UI (or API) for configuring it yet
<azonenberg>
if you set it up on the scope, glscopeclient will accept it fine
<azonenberg>
i dont know the status of segment support for whatever scope you're using
<miek>
i'll need to write it :p
<azonenberg>
Lol, fair enough. Start out by writing support for segmented waveform download but set it up on the scope manually
<azonenberg>
I'll need to think a bit about the APIs for setting up segment mode
<miek>
yeah, that's what i was thinking
<azonenberg>
but this should be good enough for you to get data for testing
<miek>
the scpi protocol for mine is kinda annoying. i was hoping i could just request all of the memory, then split it on the host side
<miek>
but it works the other way, gotta query for every segment
<azonenberg>
Oh lovely
<azonenberg>
that sounds like a pain in the butt
<azonenberg>
BTW, does your scope have a LA probe?
<miek>
yup
<azonenberg>
and is it supported?
<miek>
nope, not yet :p
<azonenberg>
ah ok
<azonenberg>
i was gonna say, when you add support, try and do deduplication. That makes a huge difference in capture size and decode speed for large waveforms
<azonenberg>
i.e. only store a sample object for each toggle
<azonenberg>
rather than splatting the raw waveform data out naively
<azonenberg>
I did that in the lecroy driver and i'm seeing 2-3 OOM reductions in memory usage for big LA captures
<azonenberg>
and it's only a few lines of code so totally worth it
<azonenberg>
So is there any particular holdup or just you're busy on non-scopehal stuff? anything you need from me?
<miek>
cool, i'll look at the dedup code
<miek>
nah, just busy on other stuff. i think everything i need is there
<azonenberg>
Bird|otherbox: any updates on your end? last i heard you had the new GPU, glscopeclient was compiling and running, but you hadn't touched the code at all
<azonenberg>
Degi: what about you, working on anything lately?
<azonenberg>
bvernoux: my requirements for an official release are to have some semblance of a proper install process and a more complete manual, as well as more extensive testing especially on windows
<azonenberg>
That's a draft, it's not an official release
<azonenberg>
hence being in temp/
<bvernoux>
yes an installer is a must have
<bvernoux>
to avoid to do all by hand
<azonenberg>
also some stuff like making sure all config settings are persisted to save files
<azonenberg>
fixing some invalid YAML in th ecurrent save files
<bvernoux>
especially as lot of guys with scope are not developer but more electronic engineer ;)
<bvernoux>
do you have an estimated date for the first release ?
<azonenberg>
Exactly. It needs to be to the point that an average engineer can just set it up and use it
<azonenberg>
No. There's still quite a few things left
<bvernoux>
you can always tag it v0.1 ;)
<azonenberg>
i havent even made a formal roadmap as to what it will take to be a release
<azonenberg>
i just know it's not there yet
<bvernoux>
but yes I understand you want to polish it with lot of stuff before to release first version
<bvernoux>
but it is a very good news you plan a windows release
<azonenberg>
It builds on windows now. or it did a few months ago at least
<bvernoux>
I was thinking you was planning only linux version which is clearly very limited for lot of users
<azonenberg>
but it's not well tested
<azonenberg>
katharina was the main windows port dev and she did super awesome work for a couple of weeks then got covid
<azonenberg>
she was in the hospital for quite some time and is now recovering at home but trying to get back in shape to return to work, so scopehal stuff isn't gonna happen for a while
<Bird|otherbox>
azonenberg: at the stage of "resolve merge conflicts with pulling master into gui-dev" atm
<Bird|otherbox>
(sorry about the delayed reply, was scrolled up)
<azonenberg>
Bird|otherbox: Great. How bad is it? a zillion of them or just a few?
<Bird|otherbox>
handful of contents conflicts, mostly a matter of mergetool setup I think
<azonenberg>
bvernoux: speak of the devil, Bird|otherbox is trying to pick up katharina's other project besides the windows port - a bunch of UI improvements including a proper preferences system
<azonenberg>
That, plus actually creating preferences for a whole bunch of settings, is another major blocker to a release
<bvernoux>
ha nice
<azonenberg>
we have a lot of hard coded configs for colors, fonts, etc that i want to make configurable
<bvernoux>
anyway we must live with the devil windoz ;)
<bvernoux>
until it is fully replaced one day by a good linux distribution ;)
<azonenberg>
I also want to start thinking about i18n at some point in the long term but that isn't happening any time soon
<bvernoux>
I can say win10 is very evil with such a mess and spyware ...
<bvernoux>
how it is possible to release such a crap like win10 with telemetry and all that cheaty apps you cannot remove ...
<bvernoux>
I feel it is worse than Google sometimes ;)
<bvernoux>
azonenberg, just one things please do not do a cloud version ;)
<bvernoux>
It is a shame all those software which are now in cloud and user does not have any control on what they bought ...
<bvernoux>
For that open source will win more and more users
<azonenberg>
Yep
<bvernoux>
Fusion360 or Altium or anything now like Adobe
<bvernoux>
you shall pay every year else you cannot use their stuff ...
<bvernoux>
and the worse is they update and add bugs and can totally destroy months of works and you cannot use an older version as all is in cloud and you can use only latest version ;)
<bvernoux>
This cloud stuff shall be stopped
<azonenberg>
It's a great business strategy if you're an abusive monopoly who wants to milk your users for every penny you can, because they have no choice
<azonenberg>
but it's also a risky one, because as soon as a viable alternative arises, they'll all leave :p
<bvernoux>
yes
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #177: Protocol analyzer window keeps reference open to attached decoder even when hidden - https://git.io/JUEul
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #177: Protocol analyzer window keeps reference open to attached decoder even when hidden - https://git.io/JUEul
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JUEu4
<_whitenotifier-f>
[scopehal-apps] azonenberg 51685ff - Protocol analyzer window can now be reopened from the Window menu once closed. Fixes #44.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #44: Protocol analyzer window is permanently lost when closed - https://git.io/JeHyg
<bvernoux>
azonenberg, the manual is already very nice
<bvernoux>
I'm trying the MSYS2 MinGW64 build
<bvernoux>
what is annoying is the format for the commands
<bvernoux>
we cannot just copy and paste
<bvernoux>
as there is line number 1, 2 ...
azonenberg_work has quit [Ping timeout: 272 seconds]
<azonenberg>
hmm i normally like line numbers in code listings but yeah for shell commands you're supposed to just run i guess it's a bad idea
<azonenberg>
file a ticket against scopehal-docs and i'll work on that when i get a chance
<azonenberg>
BTW nobody has attempted a windows build in the past ~month
<azonenberg>
to my knowledge
<azonenberg>
very likely there are regressions where i used some posix api out of habit or something
azonenberg_work has joined #scopehal
<bvernoux>
and also copy paste is totally destroyed ;)
<bvernoux>
with some space in lot of place
<bvernoux>
I'm doing it from scratch step by step and writing the correct command lines in a txt file
<bvernoux>
the git clone is always problematic
<bvernoux>
without an account on github ...
<azonenberg>
Yes there is an open ticket for that and i've been too busy to sit down and properly test the proposed fix
<bvernoux>
and there is also error with some local path
<azonenberg>
Maybe i'll do that later today
<bvernoux>
ha no it is because of the path right
<bvernoux>
Please make sure you have the correct access rights
<bvernoux>
I do not see the open ticket related to that
<bvernoux>
IIRC I have already reported it months ago as it is annoying
<bvernoux>
and anyone without a github account shall have a way to clone the repo ...
<azonenberg>
Yeah. basically it wasnt a priority because at the current level of mature
<azonenberg>
maturity*
<azonenberg>
i assumed anyone cloning the code was probably intending to push updates too :p
<bvernoux>
yes it is just annoying ;)
<bvernoux>
nothing blocker
<bvernoux>
build fail
<bvernoux>
\home\Ben\scopehal-apps\lib\xptools\UART.cpp:75:9: error: invalid conversion from 'int' to 'FILE_DESCRIPTOR' {aka 'void*'} [-fpermissive]
<bvernoux>
| ^~
<bvernoux>
75 | , m_fd(-1)
<bvernoux>
| int
<bvernoux>
| |
<azonenberg>
Looks like xptools is not actually as xp as it was supposed to be
<azonenberg>
i thoguht we had hit that already and fixed it but i guess not
<bvernoux>
yes strange it build on your side
<bvernoux>
I'm using GCC 10.2.0
<azonenberg>
the uart code wasn't there last time i tried building on windows :p
<bvernoux>
ha ok ;)
<bvernoux>
a good fix seems to be
<bvernoux>
m_fd(INVALID_HANDLE_VALUE)
<bvernoux>
instead of
<bvernoux>
md_fd(-1)
<bvernoux>
more errors after that
<bvernoux>
\home\Ben\scopehal-apps\lib\scopehal\UartTrigger.h:51:3: error: expected identifier before '(' token
<bvernoux>
51 | PARITY_NONE,
<bvernoux>
| ^~~~~~~~~~~
<bvernoux>
maybe it is because the header is .h instead of hpp
<bvernoux>
as C++ like hpp IIRC ;)
<azonenberg>
no that shouldnt matter
<bvernoux>
or it is something mandatory in GCC 10.2.0
<azonenberg>
first guess: PARITY_NONE is defined in some windows header
<bvernoux>
which was allowed in older
<bvernoux>
ha yes maybe ;)
<bvernoux>
a conflict
<azonenberg>
I'll look into it at some point. File tickets against scopehal or xptools as appropriate for each build error you have and include as much info as possible