[argyllcms] Re: Calibrating the DTP94

Oliver Schulz wrote:
> Hi all,
>
>   
>>> The bit rate of 390 bits/s (i.e. 1 / 2.56ms) is rather unusual, and the
>>> framing (3 start bits low followed by one start bit high in front of the
>>> data) is rather unusual too.
>>>       
>> You got me :(
>>
>>     
>>>  I'm not sure, whether the UART of a PC's
>>> RS232 interface can be programmed to handle these frames directly (the
>>> frames could be basically treated as if they were standard async frames
>>> wih 1 start bit, 11 data bits, no parity and 2 stop bits, if the upper
>>>       
>
> Had a quick look at the manual - seems to a synchronous serial link.
>   

Basically each transmitted byte has a particular frame format with start
bits, etc. (though very unusual), such that it could be decoded as async
frame as well (11N2 should basically fit), granted that the instrument
obeys the documented timing. Of course making use of SCK helps anyway to
sample the data bits in the center, and to deal with a timing which
deviates from the documented one.

> A UART will in all probability not be able to handle this, the
> date rate might not even be guaranteed (which isn't necessary on a
> synchronous bus). However, since the data-rate is quite low, it should
> be possible to use the RS-232 handshake and status signals for
> clock-monitoring and bit-wise data transfer.
> Also, you will need some pull-up resistors and maybe a level-translator
> (MAX232 like) for the physical interface to a PC's serial port (depending
> on the voltage levels of Busy, SCK and Measurement Request).
> It's a bit stange that the data output is open-collector, but SCK
> and Busy don't seem to be.Hello Oliver,
>   

This was eventually my thought too. Just interface SCK and Data to two
of the incoming RS232 modem signal lines with a MAX232 and to interface
two outgoing modem control lines to "Measurement Request" and "Busy",
and don't use the UART otherwise, but do everything else in software
(390 bits/s is not really so fast, that it would require hardware support).

Hopefully, pin 12 provides enough current to power a MAX232 (but I'm
afraid that 10mA may be not sufficient), and hopefully the voltage at
pin 12 doesn't drop below 4.5V under load, (due to the diode, assuming
that possibly Va = 5V, and not the voltage at pin 12), otherwise we're
outside the required supply voltage range for the MAX232 (4.5...5.5V).
If pin 12 can't power the RS232 converter, then a separate power supply
(e.g. 9V battery plus 5V regulator (e.g. LM7805)) may be required as well.

Alternatively, it may be possible to interface the four signals to the
parallel port (standard parallel port, not ECP or EPP) without needing
any active components, but possibly just a pull-up resistor for "Data".

Another issue to consider is the availability of software interfaces
provided by the OS to access the RS232 modem control lines or to access
the parallel port at register level. If such interfaces are not
available, then it may be necessary to implement a driver for the OS
kernel. In Linux there seem to be at least ioctl() calls for the RS232
modem status lines available. I haven't checked whether low-level
user-level access to the parallel port is available. And I don't know
the Windows interfaces.

(But these approaches assume, that SCK, Busy and Measurement Request are
basically TTL level signals, which needs to be clarified first)

Regards,
Gerhard

Other related posts: