baudrate changes

[StefanSimis]

Although the documentation for the sensors is fairly clear on changing the baudrate, I haven't been able to succesfully test this with an IPS box involved. I've found that these only go up to 19,200 but don't know the proper command sequence. I've yet to test switching baudrates when sensors are connected on individual com ports. I suspect that will work as advertised.

[davidbenncsiro]

@StefanSimis, Gemma and I may be able to test this if it helps, time permitting! What scenarios in particular would help?

[StefanSimis]

Re-reading my very ancient issue notes, there may be a difference between having the sensors on an IPS box or not, with the IPS box imposing a limit on baudrate. But to be clear, I do not remember ever having been able to increase the communication speed with or without an IPS box involved. With USB to serial interface being quite affordable nowadays I think direct connections to the sensors (still sharing a power supply) should be seen as the common case, and it's worth testing this again. At the same time, the G2 sensors offer a different comms interface (modbus and ethernet) and I don't see support for higher speeds in the protocol for those, suggesting that we are at the limit already.

[davidbenncsiro]

That all seems very reasonable @StefanSimis. I suspect that in our particular case there's at least a fairly strong preference for use of the IPS box due to the physical scenario in which our research team finds themselves in. I'll run all this by Gemma to see what she thinks re: G1 with no IPS box.

[davidbenncsiro]

Gemma and I had a chat about this today @StefanSimis. Let us know if you want to pursue G1 testing. Gemma also said that while she's happy with G1 at the moment, they are likely to move to G2 in future. It seems there would need to be a change to TriosManager to pass baud rate for testing different G1 baud rates in any case.

[StefanSimis]

I do think it is useful, as there are still many G1 sensors around and communication speed appears to be a bottleneck. I'm uncertain about whether the time is mostly spent between the internal detector and communication interface, or between the comms interface (the instrument as a whole) and the host (PC). Only the latter would benefit from setting a higher baudrate. If you can figure out the command sequence to make this work we can add it into the library quite easily. In the past I managed to make the instrument non-responsive when passing these commands, but a power cycle restored them so I'd say there is no harm in trying.

[davidbenncsiro]

No worries Stefan. We may not be able to get to this in the short term given that we are integrating a number of instruments into our common framework, but let's keep this open and keep talking. Thanks!