# Moku pro data logger indefinitely wait for trigger

**URL:** <https://forum.liquidinstruments.com/t/moku-pro-data-logger-indefinitely-wait-for-trigger/1287>\
**Category:** Software & APIs\
**Created:** [July 6, 2026, 11:32pm UTC](https://forum.liquidinstruments.com/t/moku-pro-data-logger-indefinitely-wait-for-trigger/1287 "2026-07-06T23:32:08Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tina](https://avatars.discourse-cdn.com/v4/letter/t/48db29/32.png) [@Tina](https://forum.liquidinstruments.com/u/Tina)\
**Post date:** [July 6, 2026, 11:32pm UTC](https://forum.liquidinstruments.com/t/moku-pro-data-logger-indefinitely-wait-for-trigger/1287/1 "2026-07-06T23:32:08Z")

</div>

Moku Pro

MokuOS: 4.2.2

Hardware version: 3.0

Firmware: 644.0

Python: 3.11.15

I have a Moku pro and I tried to write a python API to repetitively trigger the data logger for automated measurement. Within multi-instrument mode, I set up a trigger source using a signal generator. I then route that signal to the data logger, and use a loop to rearm the session after each trigger has been received.

But sometimes I run into errors where the data logger freezes and indefinitely stays in the waiting for trigger stage. I confirmed that the trigger signal is firing correctly when this happens. I was wondering if there is a problem with my python control code, or perhaps I’m running into a software bug.

A screenshot of the multi-instrument set up is shown below, and I have attached the python script that I was using. Any help would be appreciated, thanks in advance!

 ![image](https://canada1.discourse-cdn.com/flex035/uploads/liquidinstruments/original/1X/d2473238acad22015f20a52f49d698df6f492c35.png)

“”"

Setup, 3 MIM slots:

Slot 1 – Waveform Generator (WFG)

OutB: periodic square-wave trigger (Internal burst mode),

also routed out to physical Output 1

Slot 2 – Lock-in Amplifier (LIA)

InputA ← physical Input 1 ← [loop cable] ← physical Output 1

(kept in the chain in case its own internal

clock/processing contributes to the bug)

OutA → Slot3InA (demodulated output, recorded)

Slot 3 – Datalogger (DL)

InputA ← Slot2OutA (recorded data)

InputB ← Slot1OutB (hardware trigger source, internal)

Routing:

Slot1OutB → Slot3InB (trigger, internal)

Slot1OutB → Output1 (trigger, physical monitor/loopback)

Input1 → Slot2InA (physical Input 1 → LIA in)

Slot2OutA → Slot3InA (data)

Goal: WFG OutB fires a trigger pulse every BURST\_PERIOD seconds via its

‘Internal’ burst mode. Each loop iteration arms the Datalogger and waits

for logging\_progress()[‘complete’] to go True. l connection.

“”"

import time

from moku.instruments import (

WaveformGenerator,

LockInAmp,

Datalogger,

MultiInstrument,

)

# ─── Configuration ──────────────────────────────────────────────────────────

IP\_ADDRESS = ‘…’

# Datalogger

SAMPLE\_RATE = 100 # Sa/s

DURATION = 0.2 # seconds per triggered session

NUM\_SESSIONS = None # None = run until Ctrl-C (recommended for bug hunting)

# Waveform Generator

WFG\_TRIGGER\_FREQUENCY = 1000 # Hz — shape of the pulse itself

WFG\_TRIGGER\_AMPLITUDE = 2.0 # Vpp (swings -1V to +1V)

WFG\_TRIGGER\_OFFSET = 0.0 # V

WFG\_TRIGGER\_DUTY = 50 # %

WFG\_TRIGGER\_BURST\_CYCLES = 1

BURST\_PERIOD = 3 # seconds between trigger events

# Lock-in Amplifier

LIA\_FREQUENCY = 1e6 # Hz — internal demod reference (no live input signal)

LIA\_CORNER\_FREQ = 100e3

LIA\_FILTER\_SLOPE = ‘Slope6dB’

LIA\_MAIN\_OUTPUT = ‘R’

# Datalogger trigger — comfortably within the -1V..+1V swing of the WFG

# trigger signal, not a marginal/near-peak value.

TRIGGER\_LEVEL = 0.5

# ─── Connect and configure ───────────────────────────────────────────────────

print(‘Connecting to Moku Pro …’)

moku = MultiInstrument(IP\_ADDRESS, platform\_id=4, force\_connect=True)

wfg = moku.set\_instrument(1, WaveformGenerator)

lia = moku.set\_instrument(2, LockInAmp)

dl = moku.set\_instrument(3, Datalogger)

moku.set\_connections(connections=[

dict(source=‘Slot1OutB’, destination=‘Slot3InB’), # trigger → DL (internal)

dict(source=‘Slot1OutB’, destination=‘Output1’), # trigger → physical Output 1

dict(source=‘Input1’, destination=‘Slot2InA’), # physical Input 1 → LIA in

dict(source=‘Slot2OutA’, destination=‘Slot3InA’), # LIA out → DL data channel

])

print(‘Instruments deployed and connected.’)

# ── Front-end configuration ─────────────────────────────────────────────────

moku.set\_frontend(channel=1, impedance=‘1MOhm’, coupling=‘DC’, bandwidth=‘300MHz’, attenuation=‘0dB’)

moku.set\_output(channel=1, output\_gain=‘0dB’) # 2 Vpp — trigger monitor out

print(‘Front-end (AFE) settings applied.’)

# OutA not used — off.

wfg.generate\_waveform(channel=1, type=‘Off’)

wfg.generate\_waveform(

channel=2,

type=‘Square’,

frequency=WFG\_TRIGGER\_FREQUENCY,

amplitude=WFG\_TRIGGER\_AMPLITUDE,

offset=WFG\_TRIGGER\_OFFSET,

duty=WFG\_TRIGGER\_DUTY,

)

wfg.set\_burst\_mode(

channel=2,

source=‘Internal’,

mode=‘NCycle’,

burst\_cycles=WFG\_TRIGGER\_BURST\_CYCLES,

burst\_period=BURST\_PERIOD,

)

print(f’WFG: OutA = off | OutB = burst trigger, period {BURST\_PERIOD}s’)

lia.set\_demodulation(mode=‘Internal’, frequency=LIA\_FREQUENCY)

lia.set\_filter(corner\_frequency=LIA\_CORNER\_FREQ, slope=LIA\_FILTER\_SLOPE)

lia.set\_outputs(main=LIA\_MAIN\_OUTPUT, aux=‘None’)

print(f’LIA: {LIA\_FREQUENCY:.0f} Hz demod, corner {LIA\_CORNER\_FREQ:.0f} Hz ({LIA\_FILTER\_SLOPE})')

dl.set\_acquisition\_mode(mode=‘Precision’)

dl.enable\_input(channel=1, enable=True) # InputA — recorded LIA data

dl.enable\_input(channel=2, enable=True) # InputB — hardware trigger source

print(‘Datalogger configured.\n’)

# ─── Triggered logging loop ───────────────────────────────────────────────────

try:

dl.stop\_logging()

except Exception:

pass

def arm():

return dl.start\_logging(

duration=DURATION,

sample\_rate=SAMPLE\_RATE,

trigger\_source=‘InputB’,

trigger\_level=TRIGGER\_LEVEL,

)

session = 0

try:

log\_info = arm()

session = 1

print(f’[{session:04d}] Armed — {log\_info[“file\_name”]}')

while NUM\_SESSIONS is None or session \< NUM\_SESSIONS:

start\_wait = time.time()

while True:

progress = dl.logging\_progress()

if progress.get(‘complete’):

break

elapsed = time.time() - start\_wait

print(f’\r[{session:04d}] Waiting for trigger … {elapsed:5.1f}s’, end=‘’, flush=True)

time.sleep(0.05)

print(f’\r[{session:04d}] Done — {progress[“file\_name”]} ’

f’({progress[“samples\_logged”]} samples) ')

session += 1

log\_info = arm()

print(f’[{session:04d}] Armed — {log\_info[“file\_name”]}')

except KeyboardInterrupt:

print(f’\nStopped by user after {session} attempted sessions.')

finally:

try:

moku.relinquish\_ownership()

except Exception:

pass

print(‘Disconnected.’)

---

<div class="post-metadata">

**Author:** ![Dylan](https://avatars.discourse-cdn.com/v4/letter/d/e95f7d/32.png) [@Dylan](https://forum.liquidinstruments.com/u/Dylan)\
**Post date:** [July 7, 2026, 8:53pm UTC](https://forum.liquidinstruments.com/t/moku-pro-data-logger-indefinitely-wait-for-trigger/1287/2 "2026-07-07T20:53:23Z")

</div>

Hello @Tina ,

Thank you for reaching out to Liquid Instruments! I tested your Python script and saw the same behavior you had reported. It seems that the data logger freezes after a number of iterations, and the only way to recover it is to stop the log and rearm. I was able to modify your script (attached as a .m file) and added a timeout check. If the data logger doesn’t receive a trigger within a certain amount of time (8 seconds in the modified script) then the data logger is stopped and rearmed which will allow data to be collected again. I have reported this issue to my development team and will update this thread when a fix is released. I hope this helps!

-Dylan

[datalogger\_rearm\_fix.m](https://forum.liquidinstruments.com/uploads/short-url/8p342EARWQ9Pdd5hZbXZnSdE7OE.m) (3.9 KB)

---

<div class="post-metadata">

**Author:** ![Tina](https://avatars.discourse-cdn.com/v4/letter/t/48db29/32.png) [@Tina](https://forum.liquidinstruments.com/u/Tina)\
**Post date:** [July 7, 2026, 10:47pm UTC](https://forum.liquidinstruments.com/t/moku-pro-data-logger-indefinitely-wait-for-trigger/1287/3 "2026-07-07T22:47:54Z")

</div>

Hi Dylan,

Thanks for looking into this! Please let me know once a fixed is released.