<_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 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