Well, I'm sitting here recovering from open heart surgery for the next two months, and I've always wanted to tackle this little problem. Seems a bit scary though with all the moving parts.
On Fri, Aug 12, 2022 at 2:21 PM Nick Foster <bistrom...@gmail.com> wrote: > David, > > OK, I see what you're after now. Gnuradio isn't a SPICE simulator, so > getting it to fully represent your Tayloe mixer isn't really feasible. > Maybe the easiest way to accomplish what you're looking to do would be to > quantify the performance of your LTSpice simulation in a model of a > quadrature mixer that incorporates error parameters corresponding to your > mixer's simulated performance. In other words, make a Gnuradio block which > performs the job of the mixer, while adding the noise and nonlinearities > observed in your model -- conversion loss, thermal noise, and IQ imbalance, > for example. What you'd be missing is the end-to-end loop closure that lets > you make changes to the SPICE model and evaluate them easily. > > You could also use GR to construct a synthetic transmission, like you > suggest, write it to disk, and convert it to a time series format that > LTSpice can ingest. I know that LTSpice's RAW data format is documented, > and it looks like there are a couple of Python packages which read and > write it. Because you can run LTSpice in batch mode, it's conceivable that > you could automate the whole process in Python -- generate a test signal, > write it to RAW, run it through LTSpice in batch mode, convert the > resulting RAW to a complex floating-point IQ signal Gnuradio can read, and > process it to extract performance parameters in Gnuradio again. Supposedly > there's also a Python LTSpice integration > <https://acidbourbon.wordpress.com/2019/11/26/seamless-integration-of-ltspice-in-python-numpy-signal-processing/> > that lets you do everything in Python, in which case you could make a > Python GR block that would just execute LTSpice from within the block > itself, in which case you could get really funky with parameter sweeps and > such. > > Sounds like a fun project! If you do write such an integration, please > consider releasing it to the community as well. > > Nick > > On Fri, Aug 12, 2022 at 12:14 PM david vanhorn <kc6...@gmail.com> wrote: > >> I have built the detector in ltspice, but i was hoping to use gr to do a >> "soup to nuts" sim with multiple transmitters and various noise sources, >> feed that into the Tayloe, and then see what I could do downline from there >> to recover my signals. >> >> On Fri, Aug 12, 2022, 12:43 PM Marcus D. Leech <patchvonbr...@gmail.com> >> wrote: >> >>> On 2022-08-12 13:38, david vanhorn wrote: >>> > Ive been wrestling with this for a while, and im not even seeing how >>> > to get started implementing a Taylor detector in gr. >>> > >>> > Is it even possible? >>> You mean a *Tayloe* Quadrature Sampling Detector? >>> >>> This is ordinarily a *hardware component* of certain types of HF >>> direct-conversion receivers. >>> >>> Gnu Radio isn't, primarily, a hardware simulation environment, although >>> it is the case that many DSP transforms >>> have hardware analogues, it's not really a hardware simulator. >>> >>> It's probably best to tell us what you actually want to achieve, because >>> unless it's really "simulate a Tayloe QSD", >>> it's unlikely that building a Tayloe QSD in Gnu Radio is really going >>> to be that useful... >>> >>> >>> >>> -- K1FZY (WA4TPW) SK 9/29/37-4/13/15
