Earlier, the in-firmware (mst.. msp.. commands) OutputTrigger was used to drive trigger signals.

Nowadays we play wav from the PC, because many things can be tested that way. Config, trigger setup, output sequence selection, minimum amplitude to trigger (for VR), input threshold level (HALL) etc...

Soundcard, driver, and mixer settings

note We still need a set of standard test wav files, one for each trigger type, revving from 300rpm to 7000rpm. These should compress well with zip as the patterns are repetative.

For the real VR signal, polarity is important. Because of the edge positions, the polarity of the generated signal does not effect the relative time of the edges (for the primary trigger at least). This makes testing much easier. The polarity of the generated signal can be inverted (by using capital type-char like M,C,F instead of m,c,f - see below) but it shouldn't be needed.

The secondary trigger rising and falling edge is appr 5 crankdegrees apart. But camsync position can be specified anyway.

To generate a wav of 60-2 (58+2) multitooth wheel, at 1740 RPM, with a lenght of 200 seconds, max amplitude of 1000 and secondary trigger at 20 degrees, execute:

signalgen.exe m582 1740 200 20 1000 1000

The code supports

Primary trigger


To generate a wav which revs up from 140 to 3000 RPM in 6 steps, holding 200 RPM for a while, sweeping secondary trigger 20+-5 degree increasing amplitude with rpm:

signalgen m582 140-170-200-200-400-900-3000 300 15-25-20 700-1000  1000 

Particuarly useful for testing GenBoard/Manual/InputTriggerCamSync. See [shop round testlight] item that is also very useful.

Testing on the table can save hours or days of - sometimes frustrating - work. Small config or other errors can be very frustrating and difficult to find. If one knows that his config and ECM inputs and firmware are fine, she eliminated 70% of the problem-sources, and cut the number of possible problem-combinations to 1/10th.

The cost is unfairly small, a few simple and cheap HW, and some work in the warm room.


Hardware - direct connection

I simply connected the soundcard output to the ECM inputs, without any capacitor or resistor (the ECM has protection for the inputs anyway).

I listened via a headphone to both channels to tell crank from cam, before inserting the econoseal receptacles.

With VR, there is no doubt it should work.

With HALL input, maybe I was just lucky. The output level for the soundcard is 2V peak to peak, which is lower than the 0V/5V input that HALL is designed for. While it worked for me fine for first try, maybe I was lucky, and one needs to use 1..2 resistors to divide signal towards GND (1 resistor in the 10k range from input to GND should be enough to bias the input, the soundcard output is likely capacitively decoupled anyway). If in doubt, run mdf01mdkff menu-command, and in output watch for B.=.... benchstats. That should reveal if primary/secondary trigger pulses are detected with the right frequency.

I use [audacity] to play the wavs, but any program should do. It triggerred either HALL or VR. I used max soundcard volume, both PCM and master. If it does not trigger your HALL input, a pulldown resistor on the input with the right value (10..20k?) should help. This is because of the capacitor on the soundcard output can only pass AC, not DC.

Note on waveform

Feel free to tweak signalgen if you like, takes only a few lines.

See also