Communication Issue - 8 Second Cycling Between "OK" and "Not Receiving Data"

[JoeT5589]

I have just set up Genmon on my home's Briggs and Stratton generator. Thank you so much for creating this amazing utility!! I am running Genmon on a PI-4B and I'm using Channel 1 on a Waveshare 2-Channel RS485 HAT. The PI is communicating via /dev/ttySC0. The PI and HAT are located indoors approximately 30 feet from the generator and they are connected via a twisted pair with a separate ground wire (connected at both the generator and the HAT). The PI is connected to my internet via WIFI. Email function is working as intended. With the generator in standby, the "Status Panel" correctly shows Utility, PI CPU, and WiFi information. The issue I'm having is the Monitor Health cycles between "OK" and "Not Receiving Data" about every 8 to 9 seconds, remaining in each state for approximately same amount of time. The status bar at the bottom of every page follows the same 8-9 second cycle, changing between Gray and Red. I have rebooted the PI multiple times, and each time it promptly connects to the generator, but monitor health still cycles as described above. It does not generate an email indicating monitor failure during the 8-9 second "Not Receiving Data" cycle. I have attached two screen shots of the Monitor page in each of the two states. Thank-you for any insight you can provide on how to resolve this issue.

[jgyates]

Hi @JoeT5589

Typically you would have zero comm errors so something is going on that is not quite right. I would do the following.

1. Make sure that both the controller and genmon have the exact same serial settings, specifically the baud rate and parity bit. By default genmon uses 9600,N,8,1 but data rate and parity can be changed on the advanced settings page.
2. Validate your cabling. With RS-485 you can run in 2 or 4 wire mode. If two wire mode, the HAT and the controller should be disabling the transmitter when they are not transmitting.
3. I have not used the waveshare HAT, but looking online it appears that this device uses SPI to RS-485 instead of the native serial port on the pi. I am not sure if this is the issue or not but it does open up the possibility of other software using the SPI bus or some other setting on the pi that would effect the SPI clock timing. Is any other software running on the pi? Was there a specific setup for the waveshare device? and does it support the data rate you are using
4. This page shows two different types of oscillators on the HAT: https://www.waveshare.com/wiki/RS485_CAN_HAT Which one do you have?

Posting photos of your cable setup may be helpful

[JoeT5589]

Thanks so much for the quick response!

1.Make sure that both the controller and genmon have the exact same serial settings, specifically the baud rate and parity bit. By default genmon uses 9600,N,8,1 but data rate and parity can be changed on the advanced settings page.

My B&S controller has the below settings:
Slave ID = 2
Baud rate = 9600
Parity = Even
Bits = 8
Stop Bits = 1

Below is how I have genmon configured.

2.Validate your cabling. With RS-485 you can run in 2 or 4 wire mode. If two wire mode, the HAT and the controller should be disabling the transmitter when they are not transmitting.

I am using a two wire system. There are DIP switches on the back of the HAT to select half-auto and full-auto. It came configured in Full-Auto. I tried half-auto and it would not communicate with the controller. Both channels are now configured in Full-Auto (A=1, B=0). The HAT's 120 ohm resistors are enabled.

Not sure if this is any use, but I monitored the TX/RX data LEDs for activity. The TX flashes about once/second 16 times and then both the TX and RX LED have a burst of activity. Then it starts over 16 / burst, repeat...

3.I have not used the Waveshare HAT, but looking online it appears that this device uses SPI to RS-485 instead of the native serial port on the pi. I am not sure if this is the issue or not but it does open up the possibility of other software using the SPI bus or some other setting on the pi that would effect the SPI clock timing. Is any other software running on the pi? Was there a specific setup for the Waveshare device? and does it support the data rate you are using

I went through the set up below from the Waveshare site. I did the setup on a clean install on the PI. Only after I set up the HAT and successfully performed the 2-channel loop back test they provide, did I load genmon. To my knowledge, I am not running any other applications, unless the Waveshare set up is doing something in the background.
Note that the below "dtoverlay" instructions mention int pin 24 should be changed as needed. Not knowing what this was referring to, I left it at "24".

I attempted to install the below libraries as directed by Waveshare, but I believe only the Python3 was successful.

4.This page shows two different types of oscillators on the HAT:
Mine is different than the RS854/CAN HATs, and doesn't have a readily identifiable oscillator. Here are links to mine.

https://www.waveshare.com/wiki/2-CH_RS485_HAT

https://www.waveshare.com/2-ch-rs485-hat.htm?srsltid=AfmBOorhUTbvQZi6Js2c_9NNpZWCURD95ZqZhdOkViy2vKZgXYmCP3K7

If there is a simpler/more predictable HAT to buy, I am all for it. I initially tried a USB based bridge, and then a W610, without success. I have very limited Raspberry Pi experience, and any suggestions would be greatly appreciated. Thanks again for your help!

[jgyates]

I know that some folks have used both of the RS-485 models listed in the Briggs and Stratton setup wiki with success. The big thing to avoid if using the network to serial device is, if possible, do not use WiFi, use wired Ethernet as it is much more reliable. You wifi has to be excellent to work without errors.

I am not exactly sure what they mean by Full Auto or Half auto. My first guess is full duplex auto TX enable and half duplex auto tx enabled, but if to run full duplex you need 4 wires and it looks like you only have 2, but you are in full mode, so I am not exactly sure what that is. I think the Briggs controllers uses 2 wire. If the brigns only only has A,B and Ground then it is two wire since RS-485 uses 2 wires to transmit and two wires to receive, each side taking turns to transmit (half duplex). It could be that the full auto move uses both ports, one to transmit (transmitter always on) on and one to receive on, but that is a guess. Typically in 2 wire mode you have both ends sharing the line. The primary (genmon) will ask for data to the secondary (controller) once it is finished transmitting then it will disable the transmitter and let the secondary node transmit. In this mode only one device can transmit at a given time. If the transmitting a receiving get out of sync between the two notes then garbae is on the line and nothing gets thru or partial data get thru.

Question: do you have the ground wire connected between the HAT and the B&S controller? I think you mentioned that above but just want to be sure.

Trying one of the two RS-485 devices on the wiki may help, but it is not 100% known that your issues is not in the cables or the controller.

Another thing to try is to play around with the parameter "Additional Modbus Timeout (sec)" on the Advanced status page. If the controller is delaying a response this could cause your behavior. Try a value of 3 first, then try 5. If that does not help then we can move on to other things.

[JoeT5589]

Thank-you. I set the "Additional Modbus Timeout (sec)" to 3 and it had no noticeable effect. When I tried 5 seconds, the communication failure rate dropped significantly, but still present. I tried 10 seconds, and over a 10 minute period there were only 6 failures, each lasting only about 8 seconds. When I tried 15 seconds, there were no comm failures in a 10 minute span. Is there an upper limit on where you would suggest setting "Additional Modbus Timeout (sec)"? Is 15 seconds okay or will it adversely impact genmons's operation in some other way? Thanks again for your help!

[jgyates]

There is not upper limit. If you are getting not errors with a very large timeout then you may have an issue with your card or the controller. What is your packets per second (and other serial stats). I use RS-485 (4 wire) on my setup and convert it back to RS-232 to overcome the distance and keep the data rate high. Here is my stats, note the packets per second vs yours:

Grated, this is a complete different controller with different response times.

Are you still getting discarded bytes or other errors?

[JoeT5589]

After running for about 8 hours overnight, Genmon lost communication 8 times for a duration long enough that a "Communication WARNING" email was sent. In each case a "Communication Restored" email was sent between 20 to 60 seconds later. The most recent pairs of emails are below showing the errors and a Packet Per Second count which is about 10% of what yours shows.

I tried the other channel on the card, but the results were the same. Would you suggest trying a different card. This is the one referenced in the links you provided to the B&S pages above.

https://www.amazon.com/Isolated-Expansion-Raspberry-SC16IS752-921600bps/dp/B09VFLQQFK

[JoeT5589]

I checked on the chipset used on the HAT referenced in the Genmon-Briggs link below. It uses the same UART (SC16IS752) and same RS485 Transceiver (SP3485), so I am wondering if my results would be any different from the dual channel board I am currently having issues with.

https://www.amazon.com/Isolated-Expansion-Raspberry-SC16IS752-921600bps/dp/B09VFLQQFK

[jgyates]

The transceiver chip type is one thing, how they use the transmitter enable on the transceiver chip is probably the more relevant question. The board you are using has two modes (full and half) and according to the schematic this effects how the transmit enable is used. If the two nodes are sharing the line and both are trying to drive it at the same time then you will get communication errors. Another thing that matters in RS-485 design is how does the board bias the line when neither node is driving it. If the two lines (A and B) are just floating inputs when the line is idle then it can produce errors. This is more likely in a differential mode of communication like RS-485 where the difference in the voltage between A and B determine if the output is a 1 or zero. Having the same UART and transceiver is a good start but if the transmit enable is handed in an incompatible way then the comms will have issues.

I looked back at some of the logs that have been submitted that are using Briggs and Stratton. The once that use TCP over serial get between 15 and 21 packets per second. the ones that use serial get about 62 packets per second.

[JoeT5589]

Here a a video of the TX/RX LEDs on the HAT. This is the typical cycle which it repeats. Is there any way to tell if this looks a like a normal/expected comm sequence?

Rs485.Comm.Leds.mp4

Do you think getting a single channel version of my board, having the same UART and transceiver ICs, is a logical next step? Thanks!

[jgyates]

Is there any documentation on what Full Auto vs Half Auto does? I have looked at the schematic and it is not obvious to me what these switches do other than it controls the tx / rx enable on the transceivers.

[JoeT5589]

All I could find is the below. The HAT would not communicate when I set the DIP switches for Half-Auto (A=0, B=1).

[jgyates]

ok. that makes sense, but the schematic looks like txd is enabling the transmitter. I should look at the data sheet for the transceiver.

[jgyates]

I looked at the schematic again and I am not sure about the orientation of the DIP switch

https://files.waveshare.com/upload/f/fb/2-CH_RS485_HAT_SchDoc.pdf

The switch labeling implies that of the switch is open it selects half vs full. In Half mode one channel transmits and the other receives is what it looks like. In full mode it uses a GPIO on the pi to control the Tx/Rx enabled. The transistor S1 and S2 look likwe it could be doing an auto enable when transmitting, but I am making some guesses about the switch position (I don't have one in my hands to ring it out and the switch appears to be on the bottom of the card)

Another thought would be to try to reboot the controller. The slow response may be on the controller side.

[JoeT5589]

I will reboot the controller in the morning. Would you suggest rebooting the controller while genmon is running, or should I bring the generator controller up first and then start genmon? Thanks!