Source: Manic Merv, personal correspondence. Latest version at his site

This is a rewrite of the original software internal to the cm11a PIC chip. Download here. 50Hz version here.

I started this as I wanted to repair my broken unit, that ended up fixing itself, but continued on as a PIC programming exercise.

I made extensive use of the "Interface Communication Protocol Version DBS 1.6" specification. I found it to be accurate and invaluable in this exercise. I also used the "X-10 Technology Transmission Theory" from the X10 web site, and the software "Active home" to test the communication and write macros to download to the cm11a.

 

I also wrote my own diagnostic program to test the cm11a software as it was developing.

The code is written for a PIC16F84A, and emulates all functions of the original unit, a PIC16C58, plus a few extras. I've hopefully corrected the overheating lockup fault of the original, due to the read before write design of the PIC chips, time will tell.

The extras include an eeprom dump, a receive frequency display and a simple reset capability. It handles all original eeprom macro stored data exactly the same, well as far as I can tell right now.

You will need some sort of utility to take advantage of the three extra routines I've incorporated into this version. Sending a hex "7B" to the cm11a will initiate the eeprom dump routine. It will send out via the serial connection all 1024 bytes of data in the eeprom. This is good for seeing the exact format

of the macro data stored within the 24LC08 eeprom chip. One strange thing I did find is when a macro element has a delay value, it has a preceding byte of zero within the macro element. The macro initiator takes care of this by pointing it's address at the second byte of the element, the delay value, essentially ignoring the extra byte of zero.

Sending a hex "6B" to the cm11a will initiate a 255 byte dump of any X10 signal that is currently present. If no signal present a series of "01" is all that will be seen, but if you are transmitting via any other device this will display the raw X10 sequence. You can decipher the start, housecode, and function sequences quite easily. Each individual byte will be the frequency of the transmitter of the other device. My testing gave hex numbers in the 7b and 7c range, which would be 123Khz and 124Khz. I use a sort of adaptive receive routine that can accept any X10 data bit of a received signal within 300uS of the zero crossover point, as long as it's frequency is within tolerance. Then calculates how much longer to sample, so as to be checking for the required 1mS specified time. I used 300uS as the X10 signal can begin as late as 200uS and I need to sample for some period of time after that to determine if a frequency minimum threshold is met. It sounds grander than it is, it's really a short section of code and not that fancy, but very accurate. This routine will display regardless of the receive frequency, so you could in theory use it to tune up an errant transmitter.

The third routine is initiated by sending a hex "4B" to the cm11a. It will then perform an internal reset of the cm11a. Not losing any eeprom stored macros but resetting all delay timers and battery counters, just the same as if you unplugged it with no battery installed. Also in the listing is included, but commented out, a routine to handle repeated X10 transmissions, but space was limited and this wasn't essential at the time for me. You can certainly remove my extra featuresand restore the "frame_repeat_check" routine and it's associated points of call. Make sure you handle the early end of the cm11b.asm section, by any routine you remove, by putting the "goto begin" at the proper place.

If you have any comments or questions you can email me at mailto:manic_marv@yahoo.com but no guarantees of response, sorry. Thank you for your indulgence.