CME8000BUS

(last updated: 2006/11/04)

Purpose: Notes taken during the evaluation of the C-MAX CME8000BUS-LP01 time code receiver module. A time code receiver is a desired component in my home monitoring and control system.

Notes

    • The module was ordered from Digi-Key in Feb. 2006. The price paid was roughly $26USD
    • Visual description: Appears to be the module shown in the CME8000-BUS-B8.pdf document except that it is “encased” in a heat shrink tube. It has one label that shows the part number “CME8000BUS-LP01”.
    • The interface to the CME8000BUS-LP01 will be via the DLP-2232M – a USB to dual RS232/IO module. It is set up for RS232 on side A. FTDI's “Mprog” software application was used to set up the device (used the default setup file). The virtual COM port (VCP) drivers are used. COM15 and COM16 were installed on my computer (side A = COM15, side B (not used here) = COM16).
    • Power to the CME8000BUS-LP01 was obtained from the USB bus (the DLP-2232M is wired in the bus powered setup). This is 5V.
    • The C-MAX demo application is used during this evaluation. It requires a COM port connection to the TCR module.
    • At first, the connection between the DLP-2232 and the CME8000BUS-LP01 module was simply a cross connected Tx and Rx. The C-MAX demo reported timeout errors. It did not appear to talk to the module.
    • Questions were emailed to C-MAX, but no response was received, so I decided to “try one more thing”.
    • The data sheet (CME8000-BUS-B8.pdf) gave some hints that there is some sort of multiple serial device connection going on (section 4 and the fact that it uses an address in the protocol). The system block diagram (Figure 1) is also another hint, but it has no supporting text that tells the user what it is for. Another hint is the “CME8000-BUS RS232 regulator circuit.pdf” document. I decided to take all these hints and assume that the CME8000BUS-LP01 is set up such that it requires aditional external circuitry so that it exists on a shared serial connection.
    • See the attachments for a schematic of the circuit I came up with (based on the schematic in “CME8000-BUS RS232 regulator circuit.pdf”).
    • The circuit was connected on a solderless breadboard.
    • With this hardware connection the C-MAX demo application DOES communicate with the CME8000BUS-LP01 module. The interface is not a simple UART connection. I would recommend that C-MAX add a bit more text to the data sheet to explain the interface.
    • Now that the communications interface has been set up correctly, I can evaluation the functionality.
    • From the C-MAX demo appliation, I selected “Read the CME8000BUS” with the “1 sec” checkmarked. The time displayed starts at 0:0:0, 01/01/2005 and counts up every second. This must show the real-time clock feature. But what I'm really interested in is the reception of the time code.
    • After quite a bit of playing with the application, I finally figured out that I had to first start with the “reading” off (uncheck the “1sec” box), then select “WWVB” and then “Start Receiving”. Then check the “1sec” box and select “Read from CME8000BUS” and watch for a while. The graphical bar on the left of the black area should fill in (signal strength bar), “WWVB” is displayed, and “Busy” is also lit up. The time display again shows X:X:X, 01/01/2005, so the time code still hasn't been received yet.
    • After I waited several minutes (3?), a new time appeared in the time display. “Busy” was no longer lit, rather “Off” was. The signal strength bar was no longer filled in. It appears that the “receiving” had ended. The new time displayed did not correspond to my local time – but of course it shouldn't. I figured out what my offset was from GMT and sure enough the time displayed was the GMT (UTC) time. So I have successfully received the time code signal.
    • I noticed that when I had my flourescent desk lamp on, the signal strength bar would not fill, so apparently it was creating noise.
    • I have decided not to create my own PC application at this time. It would be helpful to get code working that correctly uses the prototcol, but higher priority projects are waiting. This projects was supposed to be a quick eval.
    • Positives: it correctly gets the time code, internal real-time clock, no RF tools or experience needed
    • Negative: price, external hardware is needed for a simple connection, having to wait 3 minutes to receive the time code (the atomic clock clock I have seems to get the time code in well under a minute), real-time clock is not battery backed.

This completes the evaluation.

Downloads (see Attachments)

CME8000BUSEvalSchematic.jpg - schematic

Terms of Use

Home

Copyright Steven R. Nickels, 2008. All rights reserved