Re: Suggestions for X10/Automation Widgets

[nobody@xxxxxxxxxxxx (Dave Houston)]

"Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote:

>Dan Lanciani and Robert Green wrote:

>> A quick hack might be to get the remote to send IR
>> format X10 as RF.  Then you could tweak my IR input code
>> to handle the RF as well.
>
>:-)  Sure I could, after a brain and hand transplant!!!!!!  I can wire
>telephones, assemble PC's and maybe replace a blown capacitor on a
>motherboard, but that's where my technical abilities stop.  I was hoping to
>entice Jeff into adding this feature to his Widget design.

It's a simple matter to have the universal remotes send RF at the same time
as they send *any* IR. It just takes removing a diode. Batteries won't last
quite as long.

The IR and RF protocols are totally different. A better idea might be to
assign some AV unit that uses the NEC IR protocol to one of the device keys
and then, choosing codes that don't conflict with existing X-10 RF codes,
use them to add preambles. They typically send IR codes with most if not all
key presses. You could use the NEC IR codes to switch housecodes and then
use the X-10 buttons as you do now. The protocols are identical except for
the shortcut repeat methods used by some but not all IR devices.  The
µPD6121 datasheet - X-10 used it in the old rectangular keychain remote -
explains the protocol.

     www.cpcares.com/pdf/UPD6121G-001.PDF

But the fatal drawback to all of these schemes are that they pretty much
have to be in the firmware of the target receiver or transceiver.

I don't want to speak for Jeff but my CM15X design that he's looking at
taking over can use a bootloader which means users can download new firmware
via the serial or USB port. It would be possible to supply multiple sets of
firmware with various features and let users pick the one that suits them.
But this adds to the support burden which is why I don't want to lock Jeff
into anything.

He could also sell assembled boards with the main µC just programmed with a
bootloader. Users could then get PIC16F88 firmware from anyone who wished to
supply it.

While the PIC12F683 in the design can be reprogrammed, it requires a PIC
programmer and adapter to reprogram it in circuit which will be beyond the
typical user. As I envisioned it, the PIC12F683 would handle RF I/O and
manage the RS485 network but would have minimal logic, passing data to the
PIC16F88 for decision making. I had planned to store the schedule for
reading RS485 modules in the PIC12F683 but everything else would be under
the control of the main µC.