Re: Directly connecting a digital camera module to the RCX

In lugnet.robotics, Philippe Hurbain wrote:
>> Thanks ! (Also, for your precious e-mail advice.)
> You're welcome ;o)
>
>> I added another small program to send a GV (get version) to the CMUCam2. The
>> result is first an acknowledge "ACK\r"then a message "CMUcam2 v1.01 c6\r:".
>> However, every second package doesn't read the first two characters
>> correctly. So, we get the ASCII series after the ACK\r :
>>
>> 3 255 85 99 97 ... instead of
>> 67 77 85 99 97 ...
>>
>> Probably the CMUCam2 introduces a pause after the ACK\r.
> Why could it be a problem?
>
>>
>> Suggestions?
>
> I'm afraid no :-(
>>
>> After half an hour of work with the module, the RCX starts getting hot in
>> the area of the C- output connector. The 200mA are perhaps too a heavy load.
>
> According to my measurements:
> voltage drop at 200mA is about 1.5V, so pover dissipation in the driver IC is
> about 0.3W, well within the capability of the package. Moreover the driver
> includes a very effective thermal shutdown (I triggered it quite a few times
> while testing RC-motors on RCX).
>
> Philo

The Ultimate ROBOLAB serial driver programs are interrupt-based and work in
half-duplex mode:

1. RX :
      - RXI interrupt : change serial state to "RECEIVING"; store the current
received byte in a buffer; increment the buffer index; reset various flags
      - ERI interrupt (framing , overrun or parity errors) : currently no other
reaction than flag resetting
      - The end of a package is recognized via time-out --> serial state changes
to "RX_VALID"; the user application should now asynchronously read the data and
clear the serial state to "READY"; if the data is not read within a certain
watchdog-time, the "READY"-state is set and the package is lost

2. TX : back to back mode
      - a send_bytes function is called with 3 parameters : data-address, number
of bytes, time-out; the function first sets state "TRANSMITTING", then forces a
first TXI interrupt starting the back-to-back machine
      - the TX time-out only returns a time-out message, the serial state is not
affected; the time-out occurs, if the channel is occupied for too a long time
(state <>"READY") 
      - TXI interrupt : send one byte, post-increment a data-index and clear
various flags; if length is reached, disable the TXI-interrupt"
      - TEI interrupt : stop the device and clear the serial state to "READY"

..................

So, Philo, you are right -why a pause after ACK\r could it be a problem?

I took the oscilloscope to check the whole interface. No apparent problem ! (I
even thought, the RCX IR-receiver could send some spurious data through the
PNP-transistor, so I disconnected it from the circuit : no change either !)

I followed the repeated packages for a certain time : "every second package.."
is not right; wrong packages : about 1 wrong to 5 correct ones.

Erronous bytes always appear at the indicated place "\rCMU" between
ACK\rCMUCam... Erronous bytes never appear anywhere else.

I tested the baud-rates : 2400, 4800, 9600 and 19200. No change. (By the way,
all these rates work with complete running Ultimate ROBOLAB system.) According
to the H8 datasheet, we have a 0.16% baud-rate error for these values with the
RCX clock frequency of 16MHz. Could this be the origin of the troubles? Contra:
in that case, erronous bytes should appear anywhere in the packages.

Connecting the module to the PC --> no errors.

What do I miss here?


This is a real short-coming of the CMU module, because the designers didn't
include any byte or package error-verification like parity-check, checksum or
Hamming-method.

.....................

Thanks for your graphics. I conclude that the RCX should be able to power the
camera module.

- Claude