translator question

I'm considering tackling the TW523 emulator translator.

Which of the controllers which might make use of this send for all three phases and which only send for a single phase? I know ADI only sends for one and think HAI is the same. I'm not sure this is critical but would like to know, just in case.

My thoughts are to make it with TTL input/output and with mutiple serial input/output ports. That way it could interface with any PLC (or other) system for which there is a serial interface and for which the translator knows the protocol.

If I do this it will be a DIY project and will probably use a ZX-24 processor so it won't be as cheap as a PIC based device. The ZX-24 has one hardware UART and can support up to four interrupt driven full-duplex software UARTs (9600 bps or less) so it could deal with multiple protocols/devices and be programmable from a PC serial port. It's code execution speed is 10x as fast as the original BX-24 and has a more efficient compiler so there should be ample EEPROM available for user instructions.

I'm willing to try to develop the code and to design a printed circuit board but I'm not willing to buy all of the various hardware needed to develop and test (and reverse engineer protocols) for the new PLC (and other) systems.

I envision it as a "monkey see, monkey do" system that listens for inputs on any port and translates it to whatever action on whatever port the user specifies. In essence, it would just be a multilingual switchboard.

I can probably do most of the development using a board I already have (BX24-AHT). That way the board design could come after the coding and list of devices supported is near completion or it might turn out that the existing board design will prove adequate with some simple surgery.

I think it could support...

TW523 CM11A CPU-XA, Ocelot, Leopard 2414S PowerLinc V2 Serial (if I can reverse engineer the protocol) UPB Powerline Interface Module LynX-10 PLC Other serial interfaces (if the protocol is available) X-10 RF (if all the above leave enough memory)

I need to keep this as simple as possible so as not to put too much pressure on my health so would probably take on one protocol at a time.

I've had some preliminary discussion with the ZX-24 developer about publishing this as an Application Note on the ZX-24 web site. I do not want to set up and maintain another web page.

Reply to
Dave Houston
Loading thread data ...

Sounds like an ambitious project well worth the effort. The TTL interface would, IMO, be far superior to translating PLC signals. I'd be willing to participate financially and otherwise. Let me know how I can help.

From:Dave Houston snipped-for-privacy@whocares.com

Reply to
BruceR

Actually, it's not that ambitious. I already have BX-24 code (which only requires minor changes for the ZX-24) for most of the X-10 stuff and the rest is just a matter of getting the serial protocols. It's basically just a few lookup tables. The BX24-AHT board is already setup for the PC link plus three 12V RS232 ports. A fourth can be added with a few jumpers in the location designed for the RS-485 driver (which won't be used otherwise).

When the time comes, you can loan me a 2414S and lamp module or two for testing. This one would be much simpler if they'd just change the terms of their license. ;)

I can also include X-10 RF (and Bobby G's housecode switcheroo) rather easily. My brain was locked into a particular path as I was writing the first post. Some lunch unlocked it.

I think the UPB and LynX-10 PLC protocols are published. Any other serial controller (9600 bps or less) for which I can get the protocol is a candidate. I'd rather not have to reverse engineer them.

The firmware can be changed via a PC serial c>Sounds like an ambitious project well worth the effort. The TTL

Reply to
Dave Houston

I should have clarified - it would be ambitious for ME ;). I'll be happy to loan you my 2414U and some modules. Note that I have the USB rather than the Serial version of the 2414. Hope that will still fit the bill. If not, I'll get you one.

From:Dave Houston snipped-for-privacy@whocares.com

Reply to
BruceR

Reply to
Dave Houston

Let me know how soon you'll be ready to tackle it and I'll get one ordered. I'll be placing another order next week anyway which will arrive the following week. If you could send me your address via email I'll send it out as soon as it arrives. I expect I can have it to you 2 weeks from today.

Reply to
BruceR

Oh Boy!!!!! :-) Put me on the "I want it now!" list, please!

-- Bobby G.

Reply to
Robert Green

This is looking like it could be a really versatile device so I'm trying to finalize the design details.

Besides the high speed hardware UART (PC), the TTL port and four 9600 bps ports there are 6 pins which can be used for 10-bit ADC or DIO. My thoughts at this point are to merely make them available through the user interface and to supply some brief app notes with schematics showing how to use them for things like temperature, humidity, pressure, etc. or with external switches, relays or LEDs.

I'm sure someone is going to suggest using them for a 1-wire network but that's not an option. It takes too long to get data from a 1-wire network. You can, however, use something like the serial 1-wire networks from Peter Anderson on one of the serial ports and relay the data out any of the other serial ports including the PC port.

While the processor has a software RTC it gets reset to Day 1 whenever the processor is reset so I'm leaning towards adding a battery backed RTC chip. This would use one or two of the unused pins. A reliable RTC can be used to schedule events via any of the serial ports.

I'm open to suggestions but bear in mind that I'm using the ZX-24 precisely because it will let me put something together quickly without a lot of detailed design and low level programming. My health isn't up to more strenuous efforts.

I will design a new circuit board as that will probably be easier than answering questions about modifying the BX24-AHT boards. As of now it will have a DB-9 for a PC connection, one 4x6P4C (RJ11) jack for the 9600 bps serial ports, one 1x6P4C for the TTL connection and a terminal strip for the other pins. I will design it to use a +5V *regulated* wall transformer. They cost about the same as unregulated ones and this simplifies the board design. There are switching power supplies that will work worldwide. I have to look into how many handshake lines the MR26 uses for power. If it's only one I'll provide power on all of the 9600 bps ports. Otherwise, it will need to connect via a terminal strip.

I'll design it so you can output ASCII strings or binary data via any of the four 9600 bps ports so it should work with any device for which you know the protocol.

I'll have to set priorities. I think support for the 2414S and UPB PIN are the highest priority so will try to implement those before taking on others.

Reply to
Dave Houston

It has become apparent that Rosetta needs 2 TTL ports. One connects to a controller (e.g. JDS, HAI, Ocelot) and another for an optional TW523 connected to the powerline.

While some of the PLC interfaces it will support have RTCs, others do not so there will be an optional hardware RTC backed up with a super capacitor. The ZX-24 software RTC gets reset to Day 1 whenever the processor is reset so the hardware RTC will be used to reset the ZX-24 RTC. There will also be an optional 10/100 Ethernet interface.

The additional TTL port and RTC chip use up all the surplus pins.

To summarize, Rosetta will have...

1 highspeed full duplex RS232 port (5V) for connecting to a PC 1 optional 10/100 auto-select Ethernet port 2 TTL ports (X-10 PLC protocol) 4 full duplex RS232 ports (12V, 9600 bps max)

and will have native support for...

Any controller that uses a TW523 TW523 CM11A 2414S UPB PIM MR26 Any ASCII device that is 9600 bps or less and doesn't require handshaking

A replacement PIC for the MR26 adds handling of X-10 security RF and CR14 camera positioning codes.

Since the serial ports are full duplex they can be used with touchscreens, etc. The firmware can be field updated via the highspeed serial port. It may also be possible to update it via TCP/IP but this still needs to be tested. User programs can be updated via the serial port or TCP/IP. The highspeed serial port and Ethernet interface cannot both be active at the same time so will be jumper-selected. (The serial port will only be needed if the firmware cannot be updated by TCP/IP.)

User programming will be very simple. Rosetta will just need to be told what devices are on each port and then instructed what to do when data comes in on any of the ports. Actions will be either to do nothing or to translate the command as needed and send it out a specified port (or ports). In effect, incoming data will trigger user defined macros directed to any of the outputs. It will be possible to operate with no PC connection and will include scheduling events by time of day, etc.

Thanks to Bruce Robin I should have a 2414S and UPB PIM along with a lamp module for each in a couple of weeks and will have a prototype circuit board a week or two after that. I was hoping I could avoid setting up and maintaining another web page but I think this will require one.

Once I have all the above working I'll entertain adding support for other devices depending on resources available.

Reply to
Dave Houston

How would you connect your device to a typical Ocelot setup? Through the cable that normally goes to the TW523 or would it connect to their 2 wire device bus?

Let me know if you need any prufereeding or there's any way I can help with the website or the documentation! I'm betting this is going to be very popular with people trying to shift their HA setups from X-10 to one of the newer, more robust protocols.

-- Bobby G.

Reply to
Robert Green

It will not connect to the ADI bus. The Ocelot can only deal with ADNET devices it knows about.

It depends on how you want to arrange things. You can connect the Ocelot's TW523 port to a Rosetta TTL port and connect the other TTL port to the TW523 and have Rosetta route some commands to the TW523 or translate them and send them out a serial port to other devices (e.g. 2414S, UPB PIM). The Ocelot will think it's talking to a TW523. You can tell Rosetta to send PLC to the Ocelot in response to inputs from any other connected device.

Or you can connect the Ocelot's serial port to one of Rosetta's serial ports and control everything the Ocelot is capable of doing with it's ASCII protocol.

Or you can do both.

Rosetta will understand the X-10 PLC (i.e. TW523) protocol, the CM11A protocol, the 2414S protocol, the ADI ASCII X-10 protocol, the UPB PIM protocol (and maybe a few more). For other ASCII protocols (including things like telling the Ocelot to send IR) the user can specify what to send to the appropriate port(s).

I used a simple ASCII protocol for the BX24-AHT X-10 functions. I'll try to adapt that so you can use the same ASCII command to send X-10 to any X10-capable device. I may be able to adapt it for UPB but I'm not so sure about the 2414S.

The circuit board will only require soldering if you want to add the xPort or the hardware RTC. There will be sockets for the ZX-24 and RTC chip, some SMT components will be preinstalled but the super capacitor, xPort and 3.3V power supply for the xPort will require soldering. The non-xPort part of the board is powered from a +5V *regulated* power supply using a 2.1mm plug but I'll also provide solder points in case you want to permanently attach the regulated wall transformer to avoid accidental use of a higher unregulated supply. I'm trying to use parts that are available from Mouser (except the ZX-24) to keep it as simple as possible.

Some HA devices have their own RTC (e.g. 2414S, Ocelot) and Rosetta can use those for backing up its native software RTC so the hardware RTC will not be needed by eveybody.

Adding the xPort web-enables everything connected to Rosetta. There's quite a bit of memory in the xPort for a web server and it is capable of sending email but I haven't gotten that far yet.

Lantronix has virtual serial port drivers for the xPort - similar to USB-to-serial adapters. This will mean that software written to talk to Rosetta over the PC serial port can use TCP/IP with no changes.

I chose not to add USB because that would add about $15 cost. Not everyone will need USB and those who do can buy USB-to-serial adapters for that amount. I will test and recommend a USB-to-serial adapter. Some are not fast enough to handle downloading new firmware to the ZX-24.

BTW, I also c>> It has become apparent that Rosetta needs 2 TTL ports. One connects to a

Reply to
Dave Houston

From:Dave Houston snipped-for-privacy@whocares.com

I like the both names but I think Rosetta is the better choice unless it can say "one ringy-dingy." ;)

Reply to
BruceR

It seemed like a logical way to "dial into" the Ocelot. Someone over in the ADI forum discussed using the IR IN and OUT ports to communicate very quickly with the Ocelot in a way that it could understand - parsing and acting upon unique data strings. In this case, I believe it was someone wanting to use an RF remote fan control via an Ocelot. The discussion soon veered way over my head when it got to using an RF receiver to feed the Ocelot IR IN after stripping the carrier frequency. (Very loose paraphrase by a non-techie -- may not resemble actual technical dialog in the least!!!) I can find the URL if you're remotely interested.

That sounds pretty interesting because it's a cinch to wire your device into the circuit that way. It's also the logical place to intercept and translate PLC traffic.

I wish I knew what that was. CMAX appears only to send ASCII strings. It's clear that CMAX can "talk" to the Ocelot through that DB9 port. Sorry to be dense on this but I want to understand it cold. I've seen references to bidirectional RS232 Bobcats in the work, but AFAIK the Ocelot can only send ASCII through DB9 port on the box, a serial Bobcat or to their modem for paging.

Ocelots *can* have programs loaded and variables in a programming tweaked by Cmax, so they obviously can receive data through that DB-9 connector. But there seems to be no way I know of to get the Ocelot to programmatically do anything based on received serial port ASCII commands.

I'm interested in this aspect of the Ocelot and just had a conversation with John Warner about how he sets his "guest" and "holiday" flags. Although I envisioned a secret Bat Cave with arrays of toggles labeled "Guest Mode" and "Holiday Mode" he assured me he just sets those flags via CMAX. But stopping the running program to tweak variables from the CMAX console is a long way from sending "A1 ON NOW" in ASCII to the Ocelot's serial port and having it do anything.

What about ZigBee and Z-Wave?

Any more languages and you'll have to change the name to the Babelizer. What's that Arthur Clarke story, "The Nine Billion Names of God?" Once you've included all the HA languages in your device, the world will end! This is a pretty unusual time in the HA world with so many new technologies appearing pretty much simultaneously. Well, except for poor old ZigBee. In any case, you have your work cut out for you.

To give you some idea of my lack of soldering skills - I'm having lots of trouble de-soldering and resoldering jumper wires in an RS-232 DB25 breakout box. Even with big, swing arm lighted magnified, a nice small soldering iron and an alligator clip "helper" to hold the work, I still can't make a go of it. Shaky hands, bad eyesight, bad hand-eye coordination or whatever, I just can't do precision work like that.

Now the IR circuits we talked about a few messages ago seem to be within my limited soldering skills, but it's really simple stuff with a low component and solder joint count. Give me nice big oak planks and I can make furniture and all sorts of stuff, but it's on a scale that I can work at. Modern electronics is awfully small compared to your basic woodworking project. It's why I am wary of anything that required much soldering expertise and have been questioning that part of the process very closely. I have a fairly big box of things I have soldered to death and I don't want to add to it!

I've noticed that the newer motherboards now have a single DB9 serial port instead of the long-standard two. If it works through an adapter, that's not a big deal - especially since there's no cost benefit to having it built in.

"We don't care, we don't have to: We're the phone company!"

Ah yes, the good old days.

-- Bobby G.

Reply to
Robert Green

I may have participated in that ADI forum thread. I sent ADI a prototype of an RF module for use with the IR input about two years ago. They lost it internally and never tested it. I didn't follow up as it wasn't that big of a deal to me - I was merely offering them a free design they could use if they wanted to do the necessary FCC tests.

ADI has an 8 character ASCII protocol for controlling the Ocelot via the DB9 RS232 port. It's on their website somewhere. It allows for X10 & IR control as well as a few other things. I really haven't worked with it for a few years so details are fuzzy. The BX24-AHT used it when interfacing with a Ocelot. I used their binary protocol with Commander-X. John M. Jones who mentioned the BX24-AHT in that other recent thread found and corrected an error in the documentation for the ASCII protocol. I can email you a corrected copy if you cannot find it on the ADI website.

Some examples...

send B 11 once +X011001 send B ON once +X011801 send B DIM 5 times +X012005

But C-Max is the only way to do more complex logic. You really should read Guy Lavoie's ladder logic tutorial for C-Max.

If someone releases a Zigbee based system that has a serial controller and it looks like it will become popular and someone will loan me the controller (and/or do the testing in case it's a simple ASCII protocol) I or users can implement it. I suspect there will be a myriad of Zigbee systems, each with its own high level protocol. As I said upfront I'm not willing to buy one of every controller in order to add support to Rosetta. This is a DIY non-profit project. The key to Rosetta is that it's really simple to do as long as you don't have to write dedicated code for dozens or hundreds of protocols. The memory in the ZX-24 is extremely limited.

The same goes for Z-Wave although I don't expect Z-Wave to be around for much longer. In 2-3 years about all we've seen here are posts from dealers, one of whom is so clueless that he thinks Intel incorporating it in their proprietary version of uPnP (along with a few million other devices) is a big deal. There has been a dearth of posts from Z-Wave users. I think its an IPO play. Any day now I'm expecting to read that it's a big success in Korea. ;)

Anything with an ASCII protocol that uses RS232 at 9600 bps or less and doesn't require handshaking is already supported by Rosetta. In other words, if you can control the device just by sending an ASCII string and there's no need for ACK/NAK, etc. Rosetta can handle that without having any native knowledge of the protocol. Examples are the ADI ASCII protocol and HAI's ASCII protocol. Since I expect there will be some ADI users who will be interested in Rosetta I will build in knowledge of the CPU-XA, Ocelot and Leopard for X-10. Users will still need to use the ASCII protocol for anything beyond basic X-10.

Think of Rosetta as a switchboard operator with a little less intelligence than Ernestine.

You may need to f>> It will not connect to the ADI bus. The Ocelot can only deal with ADNET

Reply to
Dave Houston

I have these on my site:

formatting link
Not sure if there is anything more up to date.

Reply to
Neil Cherry

There is an error in...

Change Variable Contents in CPUXA +Vnnxxxx

If John Jones is hanging about, maybe he can send you the correction.

Reply to
Dave Houston

There are several ways currently to communicate with the Ocelot in real time:

1) X10 is the most obvious. I have a 4 position Leviton Wall Mount controller (relaces a normal light switch) that I use to set the guest flag, over-ride "light security mode" etc. I also use Palmpad controllers to signal various things like camera selections, bed time etc. 2) IR is another way through my IR dongle or the built-in IR receiver on the Ocelot. I only use this for IR control but the Ocelot can be programmed to do any funtion you like based on an IR match. 3) SECU16 inputs are used to communicate PIR detects, Alarm Keypad set/reset, garge door positions etc. They could also be used with a home-brew control console like you were imagining. 4) By connecting to the Ocelot with a PC, flags and variables can be manually set. I use this method to set my holiday flag - something I only have to do a few times per year to tell the SpeakEasy not to wake us up at the usual time..

John W

Reply to
John W

Well, that's unfortunate considering they badly need some sort of RF capability!

Too bad it fell through the cracks at ADI.

Now that I know it exists I'll look a lot harder for it. Stuff seems to be pretty well scattered all over the site.

It's on the reading list. I'm currently slogging through the C-MAX overview. I've got Guy's document as well, although the version I have seems to have lost its embedded screen shots. What I find unsettling is that some things just don't seem to be explained. What happens to the currently executing C-MAX program when you hook up to the PC to change a variable from the computer. Is it still running? Is it paused? Does it need to be reloaded? I suppose the only way to learn this stuff is to keep hammering at it, day in and out.

There's a interesting article in today's NYT Science section about how the advent of digital photography has really been a boon to fakers. Microphotographs aren't quite right? Bring them into Photoshop to clean them up! As for ZigBee and Z-Wave I am really surprised that they've made so little penetration of the market compared to something like Insteon and even UPB.

That's great! I've posted just a little info about Rosetta in the ADI forum in response to someone there who wants to work with X-10 security RF devices. What concerns me the most about serial comms with the ADI devices are comments that I have read implying there's no command buffering and that if serial data comes in too quickly, it will be lost.

I'll bet there's a whole generation of young whippersnappers who have no idea who Lily Tomlin is! I haven't seen her on the tube in ages.

If push comes to shove, I'll get the kits parts and beg someone in newsgroup to solder it for a fee. It would still be cheaper than ruining the first one myself! :-) I live in an "old growth" neighborhood that's surprisingly free of teenage kids except for the crackhead kid who lives down the block and breaks into neighborhood cars and houses when he needs a fix. Fortunately, since I installed some very obvious CCTV cameras he's hit every house on the block *except* mine. The last time he (or someone like him) hit our block my neighbors came over asking for my surveillance video!

Thanks again for all the info, Dave! Very helpful, as always!

-- Bobby G.

Reply to
Robert Green
[snip, snip, snip]

I don't recall any problems. other than allowing for an X10 command to complete before sending another.

She's the president's secretary on "The West Wing". You probably just didn't recognize her in a (mostly) serious role. She also does a one-woman stage show with all of her characters from years past.

Reply to
Dave Houston

Guy Lavoie posted a program fragment that essentially spaced out the serial commands using a timer. I recall more than one thread where people complained that the serial ASCII output was getting "lost" - some commands would execute but others weren't. I'll try to find the thread again. I thought the preferred way to perform that sort of I/0 was with handshaking that said "ACK" thus confirming the receipt of a data packet.

That show's forbidden at this house. SWMBO actually worked at TWH for

*several* tours and finds it as utterly unbelievable as most cops find police shows, most doctors find medical shows, most lawyers find legal shows, etc. I might have sneaked out to watch it had I known Lily was acting!

I just saw someone talking about his kids seeing a dial phone for the first time and having no idea what to do with it! Ernestine and her ringy-dingy's were lampooning the days when human operators placed all calls which was probably comprehensible to our generation because our parents lived in that world. Now it's twice removed from reality. Can you imagine if operators still brokered all calls with phone plugs and jacks?

-- Bobby G.

Reply to
Robert Green

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.