Introduction of asymmetric pulseblaster clock ticks were not introduced in a backwards compatible fashion and has created bugs with long experiments

[philipstarkey]

Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

The introduction of asymmetric clock ticks (changeset: d58f57b53a03408668643743c76a3110a60aaae4) has introduced a bug with long delays. It was implemented in such a way that bypasses the check for adding a LONG_DELAY opcode.

It also defaults to a clock tick of 66ns, which is extremely fast and is likely the cause of random missed triggers we've experienced in the lab for the past year.

I think it would be good to set the default behaviour (pulse_width=None keyword argument at instantiation) to use the original 50/50 high/low clock tick behaviour (thus making the change backwards compatible)

The bug with long delays should also be fixed.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

• changed state from "new" to "resolved"

Restores previous symmetric clock pulses as the default behaviour for the PulseBlaster (fixes #16)

Also fixes issues with:

• long delay instructions (the number of reps must be at least 2)
• calculation of when to use a long delay instruction when using assymetric clock pulses
• assymetric clock pulses don't make sense if it isn't used as a pseudoclock (now raises LabscriptError)

→ \<\<cset 4093ed4213969fb3b196699ed4c74ba3cb452660>>