Triggered data logger problem: Not finding trigger

Moku model: Moku Pro
Operating system Windows:
Software version: 3.2.1

Bug or support request description:
Hello, I am trying to set up an experiment for which I need a PID controller, a waveform generator and log 4 inputs. I use multi-instrument mode with 2 2-channel dataloggers for this.
I want all channels to be synchronised, so I use an external trigger to both generate the excitation waveforms and start the two dataloggers. However, I seem to have trouble with the triggered data logging recently.

The waveform generator always gets triggered, but for the dataloggers, sometimes one starts logging, and sometimes both keep waiting for a trigger indefinetely. The weird thing is that they all should use the same (external) trigger, so I would expect all to start logging and my waves to be generated, or nothing to happen at all.
To make things a bit simpler, I went out of Multi Instrument Mode and just used the datalogger instrument, and there I had the same problem. It would not trigger to start the recording and keeps saying that it is waiting for the trigger to start.
I have verified that my trigger signal goes above 700mV (I used 1V).
Is this a known issue, or something weird on my end?
I think it used to work, so if this is due to a firmware update I recently did, would there be a way to go back to a previous version for now?

Another question, on the waveform generator I generate a burst of ramp waves when triggered. This works perfectly, but if the logging does not work I don’t want to wait for the sequence to finish, but stop the waveform generation and try to launch the experiment again.
What would be the best way to do this? If I turn off the output and turn it back on, the signal just continues, but starting a different instrument and then coming back seems to work. However, I am guessing there would be a better solution for this.

With kind regards,
Ruben

Hi Ruben

I am sorry for the issue you are dealing with. We are aware of this issue and this external datalogging trigger issue has been resolved in an internal debug release. The expected date of the next release is September.

If you want to stop the waveform output, you can change the modulation to Off and change it back to your original modulation method, then the Waveform Generator should stop the waveform output. Hope this helps.

Thanks,
Hank

Hi Hank,

Thanks a lot for your answer!
For now, I borrowed a second Moku:Pro from a colleague. Maybe his firmware is not entirely up to date, since there the triggered data logging is still working. So I am using mine to generate the signals and his to do the logging, on the same trigger. It’s a bit overkill, but it works.

However, I’ll need to return his device eventually, so I’m glad to hear that you’ve already found a solution and that it will be made available with the next release. Being able to do everything on one device again will also make my cable management much easier :wink:

I will soon try your suggestion for turning off the waveform generator output by changing the modulation to see if that works!
Thanks again for your help!

Ruben

1 Like

Hi Hank,

I can confirm that the firmware update has solved this triggered datalogger problem!

However, I noticed another bug with the datalogger in Multi Instrument Mode.
When changing the input range in MiM, an attenuator is applied.
If the input signals are fed to the datalogger, depending on the range selected, the reported voltages could be 10 or 100X weaker than what is actually applied.

When just using the datalogger outside of MultiInstrument mode, this does not happen, and the measured voltage is compensated for the attenuation automatically.

Once you know this, it is easy to compensate for in my Python code, but I thought I’d let you know.

With kind regards,

Ruben

Hi Ruben,

Glad to hear the bug fix is working for you.

Regarding the Multi-Instrument mode observations you made, this is the expected behaviour of Multi-Instrument Mode and we know that it’s not the clearest explanation and we are working on a better explanation. In this case, what is happening is the analog input has a range of ±2V. The signal is then attenuated by 20dB (10x), so the signal seen by this instrument has a range of ±200mV. So yes you can absolutely account for this in your code.

I hope this is a helpful explanation, let me know if you have any further questions,
Indira