Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 04 18:28

    michaelcroquette on master

    add the possibility to set a di… (compare)

  • Dec 04 18:28

    michaelcroquette on master

    add the possibility to set a di… (compare)

  • Dec 04 15:54
    SamuelDeleglise commented #389
  • Dec 04 15:54
    SamuelDeleglise commented #389
  • Dec 04 10:28

    michaelcroquette on develop-manip-zpm

    temporary bug fix for output di… asg and NA changes (compare)

  • Dec 04 10:28

    michaelcroquette on develop-manip-zpm

    temporary bug fix for output di… asg and NA changes (compare)

  • Dec 04 10:28
    michaelcroquette added as member
  • Dec 04 10:28
    michaelcroquette added as member
  • Nov 30 01:38
    ecdlguy opened #392
  • Nov 30 01:38
    ecdlguy opened #392
  • Nov 25 12:23

    lneuhaus on max_hold_no_iir

    ams.trigger_source bugfix (compare)

  • Nov 25 12:23

    lneuhaus on max_hold_no_iir

    ams.trigger_source bugfix (compare)

  • Nov 25 10:43

    lneuhaus on max_hold_no_iir

    comment out unusable parts of a… (compare)

  • Nov 25 10:43

    lneuhaus on max_hold_no_iir

    comment out unusable parts of a… (compare)

  • Nov 25 10:34

    lneuhaus on max_hold_no_iir

    typo corrected start implementing triggered xa… trigger_delay in trig module, t… (compare)

  • Nov 25 10:34

    lneuhaus on max_hold_no_iir

    typo corrected start implementing triggered xa… trigger_delay in trig module, t… (compare)

  • Nov 24 13:54
    lneuhaus commented #389
  • Nov 24 13:54
    lneuhaus commented #389
  • Nov 24 13:08
    lneuhaus commented #389
  • Nov 24 13:08
    lneuhaus commented #389
lneuhaus
@lneuhaus
I, too, have too few time this month to deal much with the problems of Pyrpl.
lneuhaus
@lneuhaus
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:
lneuhaus
@lneuhaus
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.
lneuhaus
@lneuhaus
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.
Jonas Neergaard-Nielsen
@jneer
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!
lneuhaus
@lneuhaus
ok cool
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
lneuhaus
@lneuhaus
Hey Jonas, maybe this interests you: http://forum.redpitaya.com/viewtopic.php?f=7&t=1673
Jonas Neergaard-Nielsen
@jneer
Ai, looks nice!
lneuhaus
@lneuhaus
The person behind that post has visited our lab once, so if you want to send him a message he's very nice and interested
Jonas Neergaard-Nielsen
@jneer
It's really good to know that it seems to be possible and maybe not too hard to sync. Will just have to decide which way to go.
Ok, great. Btw, one of my colleagues, Ulrich, will be visiting your lab very soon (don't remember when) - he's a friend of Samuel.
He's not involved in RedPitaya business at all, but he's very interested in your optomechanics and cryosetups ;)
lneuhaus
@lneuhaus
what's his last name?
Jonas Neergaard-Nielsen
@jneer
Hoff
lneuhaus
@lneuhaus
ok
he's worked in haroche's lab
i dont know him
Jonas Neergaard-Nielsen
@jneer
Right, I guessed so.
What's your status currently? Have you handed in your thesis by now?
lneuhaus
@lneuhaus
end of the month
defense is in early december
i didn't know you had authored optomechanics papers as well
Jonas Neergaard-Nielsen
@jneer
you must be rather busy right now :)
lneuhaus
@lneuhaus
yes :)
Jonas Neergaard-Nielsen
@jneer
well, yeah, just theory for now - hopefully experiment later
don't waste your time chatting then - go on, write!! :D
lneuhaus
@lneuhaus
yeah :)
i need a short break every 2h...
lneuhaus
@lneuhaus
just a quick poll to everyone
as you can see from issue #81 , samuel has started to change the register classes to merge the gui into the software at a deeper level
my question to those of you that are already using pyrpl is this: to what extend will this kind of code change compromise your existing work, i.e. is there a risk that our forks will diverge or not
one could rephrase my question as this: how do you use the pyrpl class, i.e. do you use the gui at all, and how do you interface your existing code with pyrpl?
that is, what objects do you access with your interface? modules, registers, or higher-level stuff?
and in case you use the scope or spec-an, what typical function calls do you make?