I have Bridge 1046 disconnecting from USB (Using latest Phidget22 from 7 Mar 2018 and c#). I can't pin why is it disconnecting, I suspect it gets flooded with events and just decide to reset itself.

When it reset itself it goes to gain 128x (I use 1x gain) and reports " OutOfRange Overrange condition detected on input, try lowering the gain." I tried lowering gain in code (ie in the OnError event) the code appears to be doing what it should but then the gain goes back to 128x (and the OnError kicks in again, and the code, etc etc). So it goes into a form of infinite loop.

The error is telling you that the ratio you're trying to measure is larger than what it can measure at that gain (128x is pretty high), so you're right, you want to use a lower gain, just set it in the attach handler (like i mentioned in your other post) .

However the real problem is the detaches you're seeing. Can you share some of the code? Are you doing anything in particular with the attached stepper motors/DCmotor?

What I think happens is:0) Bridge is attached to a linear encoder which works fine and values are within range that is usual (ie there are no spikes or out-of-range values)

1) The software is reading the encoder using VoltageRatio property of Bridge every e.g. 15-30ms (from memory I think it's 30 or even 50ms).

2) The Bridge gets overwhelmed by number of requests to read a VoltageRatio (eg every 15ms but continuously and possibly from multiple threads so likely to be far less than 15ms datarate on Bride).

3) The Bridge decides to disconnect itself. I can connect it straight back on (ie I catch an error and then try re-connect). However, when I reconnect it is at 128x gain and I can't instruct it to set gain to 1x.

So the worrying bit is not only the detach but the fact I can't set it to 1x gain after I re-attach it. If the Bridge gets overwhelmed with read requests I would expect it either ignores some requests or raises an "Please increase your DataRate error, I'm struggling".

Unfortunately the software is family complex multi-threaded app so I can't easily share code it would have to be written specifically to for the purpose of replicating this issue.

Hm, well there are no EMI changes in the setup. The entire environment is comprised of several Phidgets boards (few stepper boards and a bridge) in metal casing so I guess external interference would be minimal even if there was something to interfere.

Same for power, there are no changes in other boards etc that would warrant changes in power supply. Unless Bridge starts drawing more then the usb can provide??

What would you see as power or EMI changes that would make bridge disconnect given it has no external power source and is in metal enclosure?

I can see from your log the unexpected detaches / USB errors. These are most likely EMI. Especially with motors, this isn't that surprising. You Can help by using shorter USB cables. Make sure any USB hubs are powered. Make sure USB cables have ferrites. Could also be a grounding issue related to motor power. Have a look here as well: https://www.phidgets.com/docs/Addressin ... h_Phidgets

Try measuring the voltage on the 5V / Ground for your load cell. Use a different USB Cable, or particularly a shorter USB Cable. There is a chance that USB Voltage is low - and when the 1046 turns on the load cell, voltage drops a little lower, and the 1046 will hit it's internal Low Voltage Reset.

@fraser: I set the gain but it just does nothing, ie it reverts immediately back and disconnects etc. The calls to bridge are based on event call-backs (p22 API) so the minimal polling intervals are obeyed.

Only one stepper is relatively close to usb cables (approx 20cm distance). Others are far away and separated by aluminium and steel.

I have in the past suspected the usb hub and did voltage measuring, it used to produce what is required. It may be that in this specific case EMI is stronger and causes issues and otherwise all is fine (?).