[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: CM11A hangup: Any better products?



Hello Dan,

> | > The CM11a does employ a resonator for the PIC's clock, but it uses a
> | > separate free-running LC oscillator to generate the 120kHz carrier. ...
> |
> | Interesting. I wonder why they did that.
>
> My theory is that the implementors of the CM11a were familiar with the
> free-running oscillator design used in the TW523 and decided to adapt
> it.  It was a proven circuit used in other X10 products as well.

That could very well be but it would be pretty sad. Engineers are
supposed to embrace new concepts when something can be realized at less
cost.

> | They could have saved the cost
> | for the extra LC if they used a timer on the PIC to generate the 120kHz.
>
> Does the 16C58 have the capability to route a timer to an output pin?  When
> I wrote the enhanced version of my replacement firmware for the RR501 I used
> a timer, but I had to swap some pins around to I could send it out via the
> PWM block of the 16F628 (not doing actual PWM, of course).

Frankly, I don't know the PIC series much. But it would surprise me if
it wasn't possible. Pin swaps may be needed. Timer-based outputs are
pretty easy on most uC like the MSP430 series even though they often do
not have a dedicated PWM block.

> | Unless they ran out of timers but then there is still the chance to use
> | a SW timer.
>
> I used a software loop for my basic version of the replacement RR501 firmware
> and it requires a pretty short loop.  (I assume the real RR501 & TM751 code
> works the same way.)  I don't think you have a lot of flexibility for the CPU
> clock rate if you use this approach (or even if you use a timer).  The RR501
> (and, I assume, the TM751) uses a ~3.84MHz clock to make the carrier come out
> right.  The CM11a uses a 4MHz clock.  Perhaps there was a conflict between the
> clock needed to make the bit-banging serial easy and the clock needed to make
> the carrier generation come out right.  Or maybe they didn't want to tie up the
> CPU during burst generation.  But I still like my convenience-of-familiarity
> theory best...

It can be a challenge to perform proper RS232 timing and 120kHz.
However, since the amount of data exchange between uC and ActiveHome is
quite minimal they could have chosen a very slow speed. Then it would be
easier to fall into the tolerance range of even do it purely in SW.

Regards, Joerg

http://www.analogconsultants.com


comp.home.automation Main Index | comp.home.automation Thread Index | comp.home.automation Home | Archives Home