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 joined #scopehal
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
_whitenotifier-3 has joined #scopehal
<_whitenotifier-3> [stm32-cpp] azonenberg pushed 2 commits to master [+4/-0/±6] https://github.com/azonenberg/stm32-cpp/compare/2343022c3416...8be8022a7bff
<_whitenotifier-3> [stm32-cpp] azonenberg 1c6c44d - Refactored STM32 flash structs into their own header, initial STM32L431 flash support
<_whitenotifier-3> [stm32-cpp] azonenberg 8be8022 - Refactored STM32L431 linker script into base sciript with registers plus memory in separate sections, added base file for 32K bootloader
<_whitenotifier-3> [stm32-cpp] azonenberg pushed 1 commit to master [+3/-0/±5] https://github.com/azonenberg/stm32-cpp/compare/8be8022a7bff...c13b61ff9889
<_whitenotifier-3> [stm32-cpp] azonenberg c13b61f - Initial STM32L4 CRC support
<d1b2> <johnsel> @azonenberg are you familiar with SoapySDR?
<d1b2> <azonenberg> I know of it, and i've compiled various packages that use it indirectly
<d1b2> <azonenberg> never actually worked with their API
<d1b2> <azonenberg> Not against adding a soapy bridge at some point, UHD was the higher priority as that's what the unit i had handy used natively
<d1b2> <david.rysk> UHD is GPL and that's a problem for some people/projects
<d1b2> <johnsel> I would be more interested in a native drive
<d1b2> <azonenberg> This is why I have it as a bridge
<d1b2> <azonenberg> I dont know soapy's licensing
<d1b2> <david.rysk> Boost license, permissive
<d1b2> <johnsel> basically to put between litex
<d1b2> <johnsel> and ngscopeclient
<d1b2> <johnsel> and by way of that - enabling much more SDRs
<d1b2> <azonenberg> You want to use soapy as an interface layer for thunderscope?
<d1b2> <azonenberg> or litex based sdrs
<d1b2> <johnsel> initially, thunderscope, yes
<d1b2> <johnsel> a SDR is basically an oscilloscope
<d1b2> <azonenberg> Anyway, if soapy is permissively licensed i'm fine with adding it as a native driver. But i would honestly still like a bridge because so many SDRs are USB attached
<d1b2> <johnsel> with some peripherals
<d1b2> <azonenberg> and i want network transparency for them
<d1b2> <azonenberg> i'm not opposed to supporting both
<d1b2> <johnsel> I'll give it some thought, there is existing work already by Florent dealing with the LitePCIe side to SoapySDR
<d1b2> <johnsel> so it might be faster to set up initially and can then grow
<d1b2> <johnsel> though I dislike using it for oscilloscopes because it is named SoapySDR
<d1b2> <johnsel> even if it's perfectly suitable in principle
<d1b2> <johnsel> yeah that too makes sense
<d1b2> <johnsel> @aleksorsist we should build a LNA + mixer frontend for thunderscope and use it as a 2 channel SDR with 350MHz bandwidth
<d1b2> <johnsel> receive only
<d1b2> <johnsel> but still fairly impressive
<d1b2> <johnsel> I'd love to do that eventually with mine too
<d1b2> <johnsel> Just digitize DC-2GHz lol
<d1b2> <aleksorsist> I was actually thinking about dusting off my fmcw radar project to use to demo ThunderScope's direct downconversion RF capabilities
<d1b2> <johnsel> Yeah that'd be fun
<d1b2> <johnsel> Also see above
<d1b2> <johnsel> I'm in debate internally because the SoapySDR is simple but how many people would use it with the ThunderScope