Vixen Varying Idle-Break Period

[lightman]

I did some scope measurements of a Vixen Generic Serial stream of data running at a 50 msec update rate. I found a varying Idle-Break period between bursts of data packets of up to 10 msec. Has anyone else seen this?

The standard serial stream sends a series of channels (start bit, 8 data bits, stop bit = 10 bits/channel) then breaks for a few msec before the next burst of data. The Idle-Break time gives the receiver time to reset and prepare for next transmission. My test sequence had 104 channels being broadcast, with only one channel having sequence data of 50 msec block on and 50 msec block off for 3 minutes. This way it forced Vixen to perform a data burst output every 50 msec.

The total expected update period is 50 msec (~27 ms of data and ~23ms of Idle-Break). I did see that on the scope, however every half second or so, I would see the Idle-Break period reduce to ~13 msec and then revert back to 23 msec. This implies that the update rate period kept changing from 50 msec to 40 msec and back again...etc.

Normally our dimmer boxes can handle the varying break time, since there is a fair amount of slop in the processing window. However, I am working on a project that relies on the full Idle-Break of 23 msec.

Curious if anyone else has seen this?

Regards,
Lightman

[P. Short]

It may be a function of the underlying operating system (Windows) and the many layers of software between the lowest level timer interrupts and the output from Vixen. Windows is not a real-time operating system, and I'm not surprised at what you're observing.

[lightman]

Thanks Phil.

I also ran it with older version VIXEN 2.1.4 and saw similar issues, though it was only a 5 msec reduction rather than 10 msec. Also I saw the Idle-Break increase by at least 10 msec for both versions (very approximate).

I will design around this variance and resolve my timing with new project another way.

Thanks for your help.

Regards,
Lightman

[dirknerkle]

Brian, I think there's an API call for a more accurate clock value -- sorry I can't recall what it is...