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
Degi has quit [Ping timeout: 276 seconds]
Degi has joined #scopehal
<d1b2> <altracer> Hello. Why would you limit this device to 100 kHz modest bandwidth? 2ch 1Msa sounds doable on a standalone MCU, but you will not move 2000 KiB/s out of it through Full-Speed USB (1216 KiB/s practical, not 1500), so either you do 500kSa or single-shot to SPI PSRAM
<d1b2> <altracer> How does that compete with Scoppy (rp2040) and Martin Loren's HS10x/HS402 (stm32f1/f4)? More than oscilloscope functions (power supply and signal generator) and actual SCPI UART compatibility? https://www.martinloren.com/hs40x-diy-oscilloscopes/
<d1b2> <altracer> MCU-wise I recommend either FT2232H as a dual 12Mbaud UART-USB HS bridge with FTDI drivers and anything stm32f411 grade or faster to feed those uarts. Or some really new SoC with HS USBPHYC built-in (STM32U59x/U5Ax, but not F723 nor H7R/S) so that you can roll your own composite gadget.
<d1b2> <altracer> If you have competent PCB designers, then stm32h7a3 + external ulpi phy is possible, some octospi psram if sheer 1.4 MiB of internal SRAM is not enough for single-shot capture. sdram is last decade, don't waste the pins unless you use preassembled chinese boards.
<d1b2> <altracer> Finally, there are at32f490 and gd32eprt which contain 4-8 megabytes of psram in same package
<d1b2> <azonenberg> That might be a GUI side bug let me look into that
<d1b2> <azonenberg> Hmmmm
<d1b2> <azonenberg> @rapzak_ what instrument classes are you advertising support for?
<d1b2> <azonenberg> oh wait i think i see the problem
<_whitenotifier-4> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal-apps/compare/d7b3bd598742...23b253e97e12
<_whitenotifier-4> [scopehal-apps] azonenberg 23b253e - ChannelPropertiesDialog: push ID before doing stream specific settings to avoid conflicts
<d1b2> <azonenberg> @rapzak_ see if that fixes it
<d1b2> <rapzak_> let me try that, i tried fix it by this: ImGui::SetNextItemWidth(width); if(UnitInputWithExplicitApply("Offset##"+ std::to_string(i), m_offset[i], m_committedOffset[i], unit)) ochan->SetOffset(m_committedOffset[i], i); //Same for range auto range = ochan->GetVoltageRange(i); auto srange = unit.PrettyPrint(m_committedRange[i]);
<d1b2> if( (m_committedRange[i] != range) && (srange == m_range[i]) ) { m_range[i] = unit.PrettyPrint(range); m_committedRange[i] = range; } ImGui::SetNextItemWidth(width); if(UnitInputWithExplicitApply("Range##"+ std::to_string(i), m_range[i], m_committedRange[i], unit)) ochan->SetVoltageRange(m_committedRange[i], i);
<d1b2> <rapzak_> Added an ID to the string... but honestly i have no clue what i am doing - just exploring my logic...
<d1b2> <rapzak_> It removes the problem, but the values in the 2 fields is still linked on update
<d1b2> <azonenberg> Yeah did you try my version
<d1b2> <azonenberg> the unit input functions have a bunch of different widgets inside them
<d1b2> <azonenberg> you cant just assign IDs like that
<d1b2> <azonenberg> you have to use PushID / PopID like in my fix
<d1b2> <rapzak_> im just trying
<d1b2> <rapzak_> it fixes the UI bug, but the behavoir is still the same as with my fix... the 2 values is linked
<d1b2> <rapzak_> also if i scroll the y axis in the graph, both values is updated
<d1b2> <rapzak_> is there some event handler on these, there updates the values other places?
<d1b2> <rapzak_> where it does not check for the streams
<d1b2> <rapzak_> it is NOT linked across channels, only streams
<d1b2> <rapzak_> my version btw:
<d1b2> <rapzak_> is this also inverted, or do i not understand the message? :
<d1b2> <azonenberg> So the idea is, if you adjust the plot settings
<d1b2> <azonenberg> you'll be changing the channel to 3.3V full scale
<d1b2> <azonenberg> which might e.g. remove an attenuator from the instrument input
<d1b2> <azonenberg> and if there's currently a 5V signal applied it might overload it
<d1b2> <azonenberg> If you have ideas on how to phrase this more clearly i'm all ears
<d1b2> <chille0417> This might be a bit off topic, but I'm trying to figure out what the heck those EMC pre-compliance testing softwares really do. If we skip the immunity and focus on emissions it looks like softwares like Tekbox EMCview don't do much. It's basically just getting the data from the spectrum analyzer, applying some calibration of the LISN/TEM/whatever and showing the data with a limit level pulled from a standard. If it's nothing more advanced
<d1b2> than that I can't see why I should pay €695 for some software. Or am I missing something? Or should I start coding?
<d1b2> <chille0417> I would rather spend a few weeks writing some open source software than paying €695 for a software that does not even run on the operating system I use 99.9% of the time.