The THVD8000 or THVD8010 are transceivers for RS485 links over DC or AC lines. TI has an app note (SLLA590) specifically for a COM link over an 120V AC outlet.
Another choice would be the TDA5051A, a powerline modem IC for home automation. All you need is an UART interface. The datasheet has a complete schematic for 230V AC power lines. It doesn't take much to mod it for 24V AC.

All three devices look very good. They appear to be quite compact and can operate with a simple microcontroller using UART, which is a great advantage since I want to keep this project as low-cost yet robust as possible. I would rather invest in slightly over-engineered filtering components than use a 32-bit microcontroller unnecessarily.

My question regarding the TI solutions is about the difference between those that mention RS-485 (such as the THVD8010) and those that specifically refer to a “modem,” like the TDA5051A or Microchip’s PL360. Would I be correct in understanding that devices described as “modems” handle retries, error correction, checksums, and similar functions internally? Whereas with the TI THVD8010, these features would need to be implemented in firmware?

Also, am I right in thinking that the PL360 modems conform to certain power-line communication standards or protocols, allowing devices to be compatible with existing PLC systems, similar to how Zigbee or Wi-Fi ensures interoperability? Since I’m developing a custom solution, I believe the THVD8000 might be an ideal choice.

 

Make some pictures like this. Label the blocks. Describe the functions of each piece.
View attachment 357400

Because 64 is a binary number and good for computers. Say the number of devices to needs to be 50 to 64. It might to be good to have some addresses reserved for special functions. Example address 0 and 51 to 64 are not used at this time.

Each remote device listens for its address. (1 through 51) Then follows some instructions. (0=off, 1=on, 2=?, 3=?)
What happens when the power first comes on? (turn off) or (remember what state you were at)
What happens when no communications happens for a long time?

I think it would be good if the remote devices did not care if the two wires get reversed.

What drives the main device? A normal sprinkler controller? Are you going to build a controller?

State how waterproof it must be.

Put this picture in your document.
View attachment 357401
It is very important to understand what you are wanting to build.
It is important to know who will do each piece of the project.
Who will use it? What is their ability?

Yes, each device will include a UID, typically a 48- to 64-bit identifier. There could also be an additional 16-bit address used for custom messages, such as communication with specific groups of devices or broadcasting to all devices. Once a device is connected to the wire, we can implement a sync or pairing process so that the user is aware of which device corresponds to which UID. Alternatively, I could read the UID directly from the device and print a sticker to apply to its enclosure. I also plan to add LEDs to serve as indicators for active devices.

When power is first applied, the device will remain in IDLE mode, waiting for instructions. I could save the status or other data to memory, but this will need to be explored further during firmware development.

If there is no communication for an extended period, I’ll need to implement a polling mechanism to check each device and its status every 5, 10, or whichever time interval is preferred.

Regarding a “don’t-care wire reserved” option, I’d like to understand how this would affect how messages are interpreted by the THVD8000, as there should be no interference with relays or solenoids powered by 24 VAC.

My main device is the IoT Controller, which controls relays and solenoids. This PLC module would be an additional component. The controller already has a port that uses RS-485, so I would replace the existing RS-485 circuitry with the THVD8000.

And yes, of course, I will make it waterproof.

 

Regarding a “don’t-care wire reserved” option, I’d like to understand how this would affect how messages are interpreted by the THVD8000, as there should be no interference with relays or solenoids powered by 24 VAC.

I made a system that ran on 24VDC from solar and batteries. Data was on the supply by pulling the voltage slightly down or up for data. It was not good for the wires to get reversed. (very simple circuit) This type of data cannot have the wires reversed.

I was thinking of using AM or FM modulation. A simple AM plan would send maybe 30 cycles of 120khz for a 1. There are some very simple AM circuits. FM is better but requires more parts.
Either way. the receiver will not care if the 30 cycles are reversed, or 28 or 33 or missing one cycle in the middle. This is more like how we sent data over the phone lines years ago.

 

And yes, of course, I will make it waterproof.

You talked about switches to set the address. Switches are not waterproof. The Hunter device is programmed by a command on the wires.
Maybe a new device is at address zero. There is a "here is your new address" command.
OR
There are serial numbers used as addresses. A 16 bit address/serial number will allow 64,000 unites before the numbers repeat. The chance of buying two unites with the same number is very small.

 

@ronsimpson Yes, it was an idea at the time, but then I thought about keeping it waterproofed, so I will use a UID

 

Have you thought about who will do the programming? Who will layout the Printed Circuit Boards. Where will the product be made? Have you looked at how big the market is? Advertising? Funding?

 

Yes, i will be designing and making the PCBs

 

Would I be correct in understanding that devices described as “modems” handle retries, error correction, checksums, and similar functions internally? Whereas with the TI THVD8010, these features would need to be implemented in firmware?

The TDA chip is an easy to apply, dumb ASK modem chip. The communication protocol, incl. data recovery method if needed, is up to you. I would classify the THVD80x0 devices, because of the OOK modulator/demodulator, also as (dumb) modem chips.

 

This is slightly off topic but:
Here is a board with 8 relays not 1, I got them from China. The board is powered from 24Vac.
The computer is in the top right corner. It talks WiFi not power line. There is a smaller version. It also talks I2C and SIP communication.
I put it in a waterproof box with clear lid.
Because I am not good at software, I used Tasmota. It does much of what I needed and much of what you need. I think with some programming the Tasmota software could talk on a slow modem.
Address is 192.168.12.27 I have a number of these scattered out over the farm.

The reason I bring this up is, here is its little brother. No power supply, no modem. Smaller CPU.

 

The TDA chip is an easy to apply, dumb ASK modem chip. The communication protocol, incl. data recovery method if needed, is up to you. I would classify the THVD80x0 devices, because of the OOK modulator/demodulator, also as (dumb) modem chips.

So is there an advantage using TDA with ASK over the THVD ic?

Normally I would create a process of retries and ack to grantee a message.

 

So is there an advantage using TDA with ASK over the THVD ic?

The TDA can demodulate signals having a large dynamic range due to AGC used in the receiver section. As the receiver has a separate input, you can put a preamp in front of it if neccessary.

 

The TDA can demodulate signals having a large dynamic range due to AGC used in the receiver section. As the receiver has a separate input, you can put a preamp in front of it if neccessary.

That makes sense as it the TI part share the pins for both input/output

 

The TDA can demodulate signals having a large dynamic range due to AGC used in the receiver section.

Here is a fun little circuit. It is an AM radio receiver in a tiny 3-pin IC. Has 30db of AGC. This could receive 120khz or 455khz. Common parts in place of the "coil" in the schematic. It could be used to decode data off the powerline. Last time we added an 8-pin IC to take the output to TTL levels, then into the CPU's serial input.

There are three companies that did make this, but I think it is not in productions anymore.