Nixie x MEGA-BAS (v4) RS-485 communication issue

[craywm]

*I realized I posted this on rstrouse's dashboard page earlier, so I moved to here.

Hello all! I've been researching Pool automation the past few seasons, and late this season decided to pull the trigger on the Nixie standalone controller. I decided to begin late in the season instead of in off season due to my pump beginning to overheat, and replacement seems immanent. I started slow with a proof of concept, and ordered my panel BOM to begin building my outdoor station. Here's my pool info:

Body Specs:
Location: Lexington, KY (May - Sept season)
Capacity: 16,500 gal
Automation: None
Pump: Hayward Superpump 3/4 HP
Filter: Hayward 300lb Cap. sand filter
Sanitation: Pentair IC40 with PC100 power station

Nixie Standalone Pool Controller specs:
Processor: RPi 4 model B (8GB)
DAQ/COMM: Sequent MEGA-BAS (must be V.4)
Power control: Sequent 8-RELAYS (v.5)

Peripheral
Temperature: 10k Pool temp sensor (for testing - will add more in future)

Issue back ground:
I setup the raspberry Pi, and installed REM, Dashpanel, and pool controller to the RPi. Everything fired up and was straight forward. The last step before I pulled the trigger on the full panel was to test the RS-485 communication to the salt cell. The interface I initially used was communication through the MEGA-BAS RS-485 pass through. This was not successful (not setup in chemistry) so I ordered a physical USB RS-485 adapter. I wired the USB adapter onto a bus with the MEGA-BAS RS-485 connections. This is where things got... weird.

Nixie is using the dev/ttyS0 for RS-485 communication. Since I wired the USB adapter on the bus, I set dev/ttyUSB0 as the Aux port, and adjusted the chlorinator port in chemistry for testing. After attaching the USB adapter, communication began immediately through the ttyS0 port, and worked very well. After confirming that the ttyUSB0 port was unnecessary, I removed it and restarted everything. There was no communication when I restarted with the chlorinator. Thinking it was a wiring issue, I replaced wires, reseated them and restriped many times to no avail. I decided to re-create the original setup and it fired right up. This time, I decided to manipulate the communication from the COMMs side. I left only the ttyS0 as the primary, and installed the USB adapter to the pi, and wired into the RS-485 bus. The ttyUSB0 was not setup in dashpanel. I started everything up, and communication began to flow through the ttyS0 primary port.

This is where I thought I had success (maybe just a lose wire that was finally corrected), so I removed the female mating connector block from my USB RS485 adapter, and communication stopped. I then re-inserted it, and removed the USB from the RPi. Communication stopped again. Thinking maybe the Pi devices were mapped incorrectly, I decided to remove the female mating connector from the MEGA-BAS (disconnect RS-485 from MEGA-BAS), and again communication stopped. I was very confused by this. I setup a Aux Port for the USB adapter and setup an additional IC40 fired it up and both IC40 communications began to work.

It appears that the USB adapter must be plugged in for the RS-485 to work from the MEGA-BAS. I should have taken screenshots..
Anyway, I figured I had installed something incorrectly, so I performed a backup, reflash, and reload on the SD card, reinstalled everything (decided not to use the USB adapter), and I still cannot get the MEGA-BAS RS-485 pass through to work. I think some other members had similar issues (#581/#804).

I tried to troubleshoot on my own, but dont know where to start for the RS-485 communication. I've narrowed it down to a possible problem with these newer MEGA-BAS versions, or some silly error I made during setup. Here is a replay as well:
replay.zip

Has anyone else dealt with an issue like this, or know where I can start troubleshooting?

[craywm]

Also, here is a replay with the USB adapter installed and A+/B- connections attached to the bus. No changes were made to the communication configuration in dashboard.



replay (1).zip

When I plug the USB adapter in, like magic the RS-485 port on MEGA-BAS works. I would prefer not to run with a USB adapter. I assume if the MEGA-BAS RS-485 isn't working, that the 8-Relays RS-485 wont work either (Must be on Pi side).

Any help/direction would be greatly appreciated!

[rstrouse]

Why do you need 2 isolated RS485 ports? RS485 is a bus topology so if you have two (or more) devices this should all be ganged to the same port. For instance, I have 10 devices on the same bus running out of the MEGA-BAS. I am pretty sure that both of those pass through connections are mapped to the same UART on the Raspberry Pi so you cannot enable both but I may be wrong. If that were the case you would have a /dev/ttyS0 and a /dev/ttyS1 port listed.

The RS485 port on both of these boards are designed such that they can also be used to control the board using MODBUS. I suppose if you had them remote a two wire interface may be convenient but it doesn't really apply to this situation.

[craywm]

Exactly my thought! Why should I need both? I am only using a single port as shown above (Port 0: dev/ttyS0), and communication is flowing to Pool controller from that Port. My thought with testing the 8-Relays and MEGA-BAS at same time is exactly as you mentioned - there should be no change if I unplug one or the other. I may be wrong about this, but the MEGA-BAS is set to pass through, and the 8-Relays is basically doing the same this (transceiver). So should they both be mapped to the same UART (like a bus on the Pi side)?

However, When I unplug one or the other communication stops through port 0. I'm not too certain of whats going on. Is there a way I can check the Pi I/O mapping? In Dashpanel under comms menu, I have options for ttyS0 and ttyAMA0 (ttyUSB0 before I unplugged it). I'll take a few pictures of the controller setup when I get home. Is there any modified data capture I can do to trouble shoot the issue more thoroughly?

[rstrouse]

If you have jumpers installed on both then they are physically wired to the same uart pins and will pull the pins in the direction required to enable the uart. Serial uarts by definition are not a bus. The underlying protocol would be responsible for that but I suspect that the pass through physically sets the pull up/down to the uart.

[craywm]

MEGA-BAS Firmware was v2.00. I updated to v2.03.

Rebooted and same issue is occurring. I have data communication until I unplug one of the connections. I pulled a data capture from when I was unplugging each connection.
replay 2.zip
I unplugged the 8-RELAYS RS-485 connections first, watched communication fail, plugged back in, watched communication start again, then unplugged the connection on MEGA-BAS board, watched communication fail, reinserted, and watched comms start up again.

Is there some way I can check I/O mapping on the Pi?

[craywm]

I've narrowed the communication error to some "unrecoverable collision" causing the incoming bytes to be "tossed":

I am receiving bytes from the Ichlor40, but they're being thrown away. I must be missing some handshake, or something is hijacking my UART. I disabled bluetooth at startup, and am now using PL011 (/dev/ttyAMA0). I removed the 8-RELAYS HAT to isolate the MEGA-BAS communication.

[craywm]

This is my current mapping.

[rstrouse]

Please perform the following steps.

1. Power down the pi

2. Remove the RS485 jumpers from the 8-Relay hat. We do not want the RS485 chip on that board to be communicating with the serial UART.

3. Ensure the two jumpers are installed on the MEGA-BAS.
   

4. Power on the pi.

5. Run the following commands

cd ~/megabas-rpi
megabas 0 rs485wr 0 9600 1 0 1

6. Ensure the wires are connected to the RS485 port on the MEGA-BAS then check for successful communication
7. If there is not successful communication switch the A/B wires then check again. Pull the plug and do the change on the plug before plugging it back in. We do not want to short between the A and B wires.

[craywm]

Thanks! I actually removed the 8-Relays HAT entirely to isolate the MEGA-BAS. I will try to swap the wires, but when I did previously, I was not receiving any data.
This is what I receive with how its currently setup:

I'll go out to the pad this evening and take a few pics / swap wires.

Just curious, what are the effects of shorting the A/B wires?

Thank you!

[craywm]

Alright, first try without swapping wires:
SWC configuration:

Pi/megabas:

rs485 config:

Communication:

I powered down and swapped A/B positions:

started up and confirmed rs-config:

and this is the result:

Also confirmed RS-485 pass through:

Did not change port or SWG setup:

[CodeSlinger69]

Looks similar to my setup here, I can't see anything obviously wrong.

This may be stupid, but in your pictures, it looks like you have some larger gauge wire going into the RS485 block on the Megabas Hat. Are you sure those wires are contacting the set screws in that block? I used 22 gauge speaker wire for that connection fwiw.

[craywm]

Yes they are making contact. I checked continuity. Will change to appropriate size, this was just temporary without digging around.

I actually read through most of your thread code slinger! Very helpful, ended up with some of the same gear:

that enclosure is well built, but I got a super deal on a bud industries NEMA enclosure that will replace the temporary test enclosure pictured. The Qilpsu will become my project prototyping/POC enclosure for future projects.

[craywm]

I think something running onboard is pulling the mini-UART away (disabled bt). I tried to use the PL011 UART, but did not have luck there either. Still, I’m receiving bytes, but they’re being corrupted by some other signals (no idea what)

[craywm]

Just to better visualize the issue, I plugged the USB back in and wired it into the RS-485 BUS:

I did not setup any additional devices, or change the port to USB:

The communication fired up immediately through ttyS0.

Devices:

[rstrouse]

That is really bizarre. Do you have any device tree overlays loaded in /boot/config.txt. These will be listed as dtoverlay=....

[craywm]

When I took the above screenshot, there were two overlays (circled). I disabled Bluetooth thinking that could have been impacting some comms. The VC4 overlay has always been present.

I moved my UART assignments around today to utilize a PL011. Still only worked with USB connected. I did connect my computer to the mega-bas via the adapter and echo Hello from the pi to my computer which went fine. So the Mega-bas is connected through the pi.

[rstrouse]

Why are you loading the uart overlays? Comment out the last two lines.

EDIT: And add enable_uart=1 to the all section.

[craywm]

The PL011 UART is more capable. I was attempting to isolate UART0 by disabling Bluetooth. Probably don’t need the last two overlays (they weren’t present in the above test with usb, I added after the fact). Reference RPi manual:
https://www.raspberrypi.com/documentation/computers/configuration.html#configuring-uarts:~:text=might%20help%3A%20usbhid.mousepoll%3D0.-,configuring%20uarts,-Edit%20this%20on

also, enable UART is the first overlay (covered by red circle).

[CodeSlinger69]

I'm completely puzzled @craywm. Can I suggest to start clean? Format/reload the RPi and start from scratch? Follow the wiki guides, or my #801 thread and if it still doesn't work, then maybe there is something wrong with either your RPi or the Building Automation Hat.

[craywm]

This is actually my second setup attempt, but I may wipe and restart again. I was able to get comms to my windows laptop through the Mega-bas HAT rs485 port, so I know it works. Something is corrupting the data packets on the mega-bas/pi side. It’s clear from byte receiving in screenshots above, and replays.

I thought I ruled out the pi by isolating UART/AMA0 device (comms work with that device) with no USB), but it’s only recognizing the data when USB is connected (packet collision referenced above) I’m receiving bytes on both USB and mega-bas devices though.

[rstrouse]

I’m receiving bytes on both USB and mega-bas devices though.

This is the part that has me scratching my head. Because it reads the data only when the usb has a device in it. Almost as if the serial port is disabled until the usb is plugged in. Was there a driver for the usb device that could be hijacking the serial port interface. Btw there is no gain with the PL011 UART for this implementation.

[craywm]

I did not install any drivers for the usb. I tried the mega-bad first before I even bought the adapter. So no drivers for the usb were installed (beyond what Rasbian is loaded with). I’m using the raspberry pi imager to flash the OS. I also started default without any Sequent directories cloned onto the RPi.

Thank you all for taking a look! I’ll try and start from scratch documenting the setup (maybe my mistake can be found!) If all else fails, USB for the win! Something does have me thinking I should just plop the 8-Relays on there without the Mega-bas and test the RS-485 pass through there (before I reflash).

[rstrouse]

Yes

…

Sent from my iPhone

On Aug 27, 2023, at 5:52 PM, craywm ***@***.***> wrote:  I did not install any drivers for the usb. I tried the mega-bad first before I even bought the adapter. So no drivers for the usb were installed (beyond what Rasbian is loaded with). I’m using the raspberry pi imager to flash the OS. I also started default without any Sequent directories cloned onto the RPi. Thank you all for taking a look! I’ll try and start from scratch documenting the setup (maybe my mistake can be found!) If all else fails, USB for the win! Something does have me thinking I should just plop the 8-Relays on there without the Mega-bas and test the RS-485 pass through there (before I reflash). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[craywm]

I started a new discussion for the third setup attempt/issue. Please reference #844 for additional troubleshooting of this communication issue.