[argyllcms] Re: Image Engineering EX1 Spectroradiometer
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 20 Feb 2020 12:40:41 +1100
Richard Kirk (Redacted sender richard for DMARC) wrote:
Hi,
Argyll will have to have somewhere where they would be
willing for this stuff to live. But first let’s just check what these things
do, in
case you don’t want it…
there are practical difficulties with having support for instruments
I can't test. I'd have to think about putting such drivers in
a category of "3rd party supported", and would need to have at
least one volunteer with such an instrument to test it and
verify that it works on each release.
Here, for example, is info message from the JETI tool ’specbos’
[ Note that the specbos is supported since the protocol is
documented, and JETI very kindly sent me an instrument. ]
I have mixed feelings about serial interfaces. One of the
big divisions in instrument drivers is not the port type
however, but whether the instrument has the smarts to
return "fully cooked" measurement values. Most serial
interfaces had to do this, as it would have been too
slow to send raw data and interact with the instrument
multiple times to do a measurement. USB facilitated
dumbing down the instrument and doing the raw to
cooked processing on the host computer. So most
serial interfaces need less processing, and it's
easier for the manufacturers to document the protocol.
(There's much less excuse for not putting the smarts
back in the instrument - low power embedded CPU's
with floating point support are readily available.
Updating the measurement processing software is harder
though.)
But often the serial interfaces are unreliable. They have
timing constraints, and races. A number of instruments seem
to have converted to USB by simply fitting a serial to USB
chip inside them. This means that have baud rate settings,
even though it has no relevance to the USB interface.
This often end up with an unreliable protocol.
For instance, the Klein K10-A has a "high speed" mode
which entails increasing the baud rate. But there is
a race condition while changing the baud rate that makes
the feature unusable as far as I could determine.
A well though out and implemented USB interface is much more
reliable, since it doesn't need various heuristic timing allowances,
and a good deal of the hand shaking is taken care of by USB.
So the ideal instrument interface from the point of view
of ease of support would be a well documented USB protocol
in which the instrument does the cooking of the measurements.
Cheers,
Graeme Gill.
Other related posts:
