| |
In lugnet.robotics, Philippe Hurbain wrote:
> > http://www.convict.lu/Jeunes/RCXCam/RCXCam_Journal.htm
> >
> > Comments or suggestions?
>
> So it works... congratulations, Claude!
>
> Now longing for "real life" applications ;o)
>
> Philo
Thanks ! (Also, for your precious e-mail advice.) 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.
Suggestions?
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.
- Claude
|
|
| |
| |
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
“ACKr”then a message “CMUcam2 v1.01 c6r:”. However, every second package
doesn’t read the first two characters correctly. So, we get the ASCII series
after the ACKr :
3 255 85 99 97 ... instead of
67 77 85 99 97 ...
Probably the CMUCam2 introduces a pause after the ACKr.
|
Why could it be a problem?
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
|
|
| |
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
|
|
|
