Configuring Phidget dataInterval in the Attach Handler

Problem Details

You open the Phidget Control Panel, select a bridge / VoltageRatioInput channel, drag the data interval slider to the sampling rate your application needs, and take readings. Close the window, re-open the channel, and the value is back to the factory default. There is no "Save", no "Apply as default", and no configuration file exposed in the panel that survives the session.

A second, related observation: the data interval slider in the Control Panel can be dragged past 1000 ms. This is a user-interface defect that has been logged with the vendor for correction. The slider position beyond that point does not represent a supported, characterized configuration state that you should design around.

Symptoms that map to this root cause

Root Cause

In the Phidget object model, dataInterval is a property of an open channel object, not a property stored in the device's non-volatile memory. The lifecycle is:

1. Your process (Control Panel, or your own program) creates a channel object.
2. The channel is opened and matched to a physical device — the attach event fires.
3. On attach, the channel comes up with library/device defaults.
4. Any dataInterval you write applies to that channel object only, in that process, until detach or close.
5. On close or detach, the state is discarded.

Because the Control Panel closes its channel when you close the window, there is nothing left to persist. Two applications can hold different intervals for what appears to be the same sensor because each holds its own channel state.

So the correct engineering answer is not "find the hidden save button." It is: own the configuration in your application code and re-apply it on every attach.

Solution: Set dataInterval in the Attach Handler

The attach handler is the only reliable place to apply channel configuration. It runs after the device is matched and ready to accept property writes, and it runs again automatically on every re-attach — which means USB replug, host sleep/wake, hub power cycle, and cable knocks all self-heal without operator intervention.

Recommended pattern

The vendor ships a C# example for the VoltageRatioInput channel class that is functionally identical to what the Control Panel runs. That example is the fastest starting point: open it in Visual Studio, locate the attach handler, and change the interval assignment there.

// Pseudocode / C# shape - verify exact member names against the
// Phidget22 .NET API reference for your library version.

VoltageRatioInput ch = new VoltageRatioInput();

ch.Attach  += OnAttach;
ch.Detach  += OnDetach;
ch.Error   += OnError;
ch.VoltageRatioChange += OnVoltageRatioChange;

// Optional: pin the channel to a specific device so you do not
// grab whichever bridge happens to enumerate first.
// ch.DeviceSerialNumber = 123456;
// ch.Channel = 0;

ch.Open(5000);   // open with timeout, ms


void OnAttach(object sender, Phidget22.Events.AttachEventArgs e)
{
    VoltageRatioInput c = (VoltageRatioInput)sender;

    // Apply YOUR defaults here - every attach, every time.
    c.DataInterval  = 100;      // ms between samples
    c.VoltageRatioChangeTrigger = 0.0;   // 0 = report every interval

    Log($"Attached S/N {c.DeviceSerialNumber} ch {c.Channel} " +
        $"interval={c.DataInterval} ms");
}

Why the change trigger matters alongside the interval

Setting DataInterval alone does not guarantee you receive an event at that rate. Change-event delivery is gated by the change trigger: if the measured value moves less than the trigger threshold, no event is emitted even though the device sampled. For a fixed-cadence acquisition loop — logging, PID feed, timestamped CSV — set the change trigger to 0 so every interval produces an event. Leave a non-zero trigger only when you deliberately want event suppression on a quiet signal.

Where to put the setting so it is maintainable

Implementation Procedure

1. Bring up in the Control Panel first. Confirm the bridge enumerates, note the serial number and channel index, and confirm the sensor reads a plausible voltage ratio under load. Treat the interval slider here as a temporary experiment only.
2. Choose your interval empirically. Use the panel to sweep the interval and watch noise versus responsiveness on your actual load cell / sensor. Record the value you want; you are going to hard-set it in code.
3. Download the C# VoltageRatioInput example from the vendor and open it in Visual Studio. Confirm it builds and runs against your device unmodified before you change anything — that isolates toolchain problems from code problems.
4. Locate the attach handler in the example (the method subscribed to the channel's Attach event).
5. Insert your interval and change-trigger assignments in that handler, after the sender cast.
6. Add a log line inside the handler that prints the interval read back from the channel, not the value you intended to write. Reading back is your proof that the write was accepted and not clamped.
7. Add a detach handler that logs the detach and, if applicable, marks the acquisition as stale so downstream logic does not consume frozen values.
8. Add an error handler. Silent property-write failures are the main reason "I set it and it did nothing" reports occur.
9. Rebuild and deploy. Do not run the Control Panel and your application against the same channel simultaneously during validation — you will not be able to tell which process owns which state.

Verification

Verify at three levels. Do not accept the configuration on the basis of the assignment statement alone.

Interpreting a failed read-back

If the read-back does not match what you wrote, the requested interval is outside what the channel accepts. Query the channel's minimum and maximum data interval properties and log them at attach; clamp your configured value into that window in software rather than assuming any arbitrary number is legal. This is also the safe way to sidestep the Control Panel slider defect entirely — your code enforces the real device limits, the slider's UI range is irrelevant to you.

Regression guard

Once the rig is validated, keep the attach-time log line permanently. A single line per attach recording serial number, channel, interval, and change trigger turns "the data rate changed and nobody knows why" into a one-grep answer. This costs nothing at runtime and is the highest-value diagnostic you can leave in a Phidget-based acquisition application.

Design Notes for Production Rigs

• Pin the device. Set the serial number and channel index before Open() on any rig with more than one Phidget attached. Without it, channel-to-sensor mapping depends on enumeration order and will eventually swap.
• Use Open() with a timeout during startup so a missing device produces a clear, catchable failure instead of an indefinite wait.
• Treat the Control Panel as read-only in production. Opening a channel in the panel while your application runs creates a second independent channel object and muddies any timing investigation.
• Version-lock the Phidget library in your build and record the version in your startup log. Behavioral details of property clamping and event delivery are library-version dependent.
• Do not extrapolate the buggy slider range. The fact that the UI let you drag past 1000 ms is not evidence that the channel supports that interval. Confirm limits through the API's min/max properties.