I, too, have too few time this month to deal much with the problems of Pyrpl.
To your question: I did not implement this scheme because so far. I only see 1/2 argument against it: One of the biggest advantages of digital demodulation is getting rid of offsets, as one typically has with analog electronics. I was always afraid that sending the demodulation signal to the other input would cross-talk slightly to the demodulated channel and lead to an effective offset (I never characterized that type of crosstalk). That being said, there is an offset anyways, coming from the crosstalk of analog outputs to analog inputs. Therefore, your scheme works probably not much worse than existing ones.
For the implementation: Long-term idea is to modify the DSP layout such that the implementation consists of a bunch of simple and flexibly interconnectable basic building blocks: multipliers, filters, biquads, adders, and pure inputs and outputs.
That would easily solve your problem, but unless you implement it that option has to wait a little
Next option is to make a small modification, for example modify the dsp schematic to allow for your proposal. Probably less than 30 minutes of work.
If you want I can propose an implementation for you.
Otherwise, I had a similar problem a while ago and my approach was to synchronize the redpitaya clocks.
For the clock synchronization, there are a number of better and worse options:
1) Use 1 redpitaya as master and draw cables from its 125 MHz clock to other redpitayas external clock input, as described somewhere in the official RedPitaya documentation and forum.
2) Use a nice external 125 MHz clock, properly do the electronics to send the clock signal to all redpitayas external clock pins.
(the external clock pins are hidden under the radiator and one must unsolder 2 small resistors from the board to activate them - basically disconnecting the existing quartz clock from the fpga)
3) My favourite option was to use the 10 MHz clock source from a Spectrum analyzer or other clock source in order to have all electronics in an experiment depend on the same master clock.
I got as far as sending a 10 MHz signal from a function generator to digital input pins on the extension connector (no unsoldering so far), routing that signal inside the FPGA to a PLL block which generated a 125 MHz clock signal from there. I was able to run the FPGA logic on that clock signal, except for the ADC part which would however have been straightforward (need to route an analog clock output to the ADC chip - all well described in the official documentatoin). My biggest problem was a parasite of the 10 MHz signal on the mass plane, which can probably be removed by doing proper impedance matching on the digital input pins. By the time I got there I did not have the need any more and abandoned the approach (also as I was not sure to what extent phase jitter would limit the performance later on).
I'd say: If you can implement a 125 MHz master clock and send it to all redpitayas, thats the best option. Otherwise a little FPGA modification will do the job for you.
Hi Leo, Thanks a lot for your detailed suggestions. I'll have to think about what you're saying more carefully and discuss it with more competent people (my dear colleagues Xueshi and Ruben) before I can make a call on what would make most sense.
It's an interesting idea to synchronize the clocks like this. We talked about doing this previously, but I think we gave up the thought because we believed it would be too difficult.
I'll get back to you on this later!
in case you're interested, I can send you the FPGA code for the PLL
all you really need to figure out is how to get the clock onto two digital input-output pins with proper impedance matching
(in case you were talking about 10 MHz clocks)
in case you want to use a 125 MHz master clock, I can send you a device suggestion from our colleage Pierre Clade