Nixie x MEGA-BAS RS-485 Communication (Intellichlor40)

[craywm]

*Continuation of a previous #841 discussion. Please reference back to that discussion for additional back ground information.

1. I re-imaged the RPi with fresh image utilizing this guide. I only utilized for RPi setup (basic)

2. I then enabled VNC and headless resolution (remote function):
   
   

3. I decided to utilize this guide to install the pre-requisites, REM, Poolcontroller and Dashboard. All the guides are pretty much the same, and I'm referencing here to simply point back to what was entered into the terminal for installation. I did also install pm2 and lograte and setup to start on boot.

4. Setup Nixie with this
   
   

5. Setup MEGA-BAS in REM using this guide.
   
   

just a note here, my 8-RELAYS HAT was not automatically identified:

6. Input Long/Lat into Nixie, setup body / filter data, setup pump Control from Google Home? #1 (Just because).

7. Setup RS-485 Comms (more detailed):
   Here is what my RPi config looks like:
   .
   Turned on Serial Port:
   

At this point, I'm fae enough along in setup to utilize the RS-485 comms and confirm communication. Navigating to Comms tab showed by default (I did not change anything):

I have not installed a USB device yet. Selected ttyS0 device:

Navigated to Chemistry and setup a chlorinator:

Plugged everything in outside:

I'm getting the same condition. I have not yet tried to plug in a USB to see if that will allow data to flow. It should be noted that I sent some data from the Mega-bas RS-485 port to my computer to confirm that communication was OK (and it was). I initially left the jumpers on the 8-RELAYS, but removed. I also tried to swap the wires with no success. The inbound bytes are being tossed due to some unrecoverable collision. It should also be noted that I am using no device overlays, and have not modified any config files.

I can remove the 8-relays HAT and configyre. Also, I can set up with USB to see if packet by packet is the same, or if collisions are occuring on the Mega-bas side and not the USB side. does anyone have suggestions to move forward trouble shooting, or identified errors in my above setup?

[rstrouse]

The collision detection works like this. The software is constantly monitoring the serial port for inbound data. If nothing is communicating then no bytes will be read from it. It should be silent. Then when bytes come in the software looks for preamble bytes indicating an incoming message frame. In your case this should be [16, 2]. If it does not find it in the max packet length then these bytes are determined to be noise and the buffered byte stream tosses those bytes waiting for a preamble.

Expand the pm2 monitor console and at the bottom in the metadata section you should see Node.js version. Which version are you seeing there?

[craywm]

node.js version: 18.17.1. I think previous build used version 20.

[rstrouse]

Stop njsPC on PM2 by running pm2 stop njsPC then try running it using the following commands and test.

cd ~/nodejs-poolController
npm start

Leave this console window open and test the port.

[craywm]

Is this different from pm2 monit? I’ll try that when I get home.

Is it possible that no ground reference is causing the IC40 rs-485 signal to be misinterpreted by the mega-bas?
I’ve thought about running a cable from ground on the surge protected to the ground on the mega-bas, but have read it’s unnecessary.

[craywm]

The communication in console is same as previously:

Port is also same condition:

These are the variations of the collision messages:
[8/29/2023, 6:55:27 PM] verbose: Tossed Inbound Bytes 25,223,249,252,183,95,221,255,25,223,249,248,183,95,221,255,25,223,249,252 due to an unrecoverable collision.
[8/29/2023, 6:55:33 PM] verbose: Tossed Inbound Bytes 59,223,249,252,183,95,255,255,59,223,249,252,183,95,221,255,25,223,249,252 due to an unrecoverable collision.
[8/29/2023, 6:55:30 PM] verbose: Tossed Inbound Bytes 183,95,255,255,59,223,249,248,183,95,255,255,59,223,249,252,183,95,255,255 due to an unrecoverable collision.
[8/29/2023, 6:55:17 PM] verbose: Tossed Inbound Bytes 183,95,221,255,25,223,249,252,183,95,221,255,25,223,249,252,183,95,255,255 due to an unrecoverable collision.
[8/29/2023, 6:55:05 PM] verbose: Tossed Inbound Bytes 25,223,249,248,183,95,221,255,25,223,249,252,183,95,255,255,59,223,249,248 due to an unrecoverable collision.

[CodeSlinger69]

Have you tried testing with a different RS485 device other than the chlorinator? Do you have a pump you can connect to the bus? Just trying to eliminate possibilities.

[craywm]

I tested the RS-485 communication to both the 8-Relays and Mega-bas to using the USB adapter plugged into my computer running Realterm. I was able to receive and send data through both boards, and simulate sending the status command to njsPC which did push status correctly to dashpanel. All is good on that side. Plugged it back up to surge protector at pad, and same story.

I’m thinking of plugging the SWC surge protected A/B wires to my usb adapter on my laptop and see what realterm comms look like. Only issue here is that the connection to the USB adapter has been successful previously.

To answer your question directly, I don’t have any other RS-485 devices, but feel that my confirmation above should suffice.

Is it possible to push the surge protector board into some other “mode”? It’s odd that all the bits are ignored. Could the baud rate on the SPB have been changed somehow?

[craywm]

As it turns out, my plans changed for this week and I now have access to another pool with a pentair inteliflo vs pump and an IC40.

I plan to try the IC40 first then the pentair pump with RS-485 comms.

At the original pool, I continued to receive tossed packets through the mega-bas. I plugged in the USB adapter and wired to the bus, and without setting up any device or chlorinator, data began to flow through port0 on device ttyS0 same as before. Communication was perfect. When I removed the USB, it immediately stopped.

Hopefully my testing here will be more successful and aid to narrow issue. Is there some driver for the Mega-bad that should be running? It’s odd that when I plug in the usb, all other devices seem to start working even with no data flowing through the adapter.

[craywm]

I had some time last night to attach reconfigure and hook up RS-485 from a different IC-40 to my pool controller:
The Power center is a newer style board than the previous one I tested with

Fired everything up hoping for the best:

Same issue as before. I'm going to try the communication on a Pentair Intelliflo VS pump today, but I expect the same result.
I guess its a good thing that its not my equipment, but this is becoming frustrating. Is it possible Sequent changed something on the Mega-bas board causing this issue?

[craywm]

hmm.. thats a good observation rstrouse. I'll check, but I do believe my I2C connection is good. I can hooked up a thermistor and did not see any irregularities. I will however double check!
I decided to verify that my GPIO were being pulled up/down and:

shouldn't GPIO 14 be pulled high/low?

Also checked dmesg for reference to serial and tty:

[craywm]

The I2C pins are OK (there is some solder on the underside of the board, could be better.
But your comment about the pins made me think to check the GPIO pins as well:



I'm wondering if it is shorting to ground right across (pin 9). This would make sense as to why the I require two input paths to the serial port (Transmitting/receiving on different devices).

I would expect the 8-Relays card to have the same issue since it is stacked on top of the Mega-bas, but the 8-relays card actually only has a jumper to connect the tx side of the board to the GPIO pins, the RX side is always connected (might have reversed that). Thus when I connected both board to the bus, communication was successful.

I'm going to run a GPIO diagnostic to make sure everything is OK on the pi side, then do some continuity tests on that pin. I'm not near my soldering equipment now, so I cant fix it today (if that is the issue), But I should be able to stack just the 8-relays card ontop of the pi to confirm that is the issue (again assuming the pi GPIO is OK).

[craywm]

GPIO pins checked out OK. Checked continuity on mega-bas board between pins 10 (GPIO 15) and 9 (GND) with no continuity. I’m going to check with the mega-bas card stacked as well (no power) and with power.

I went ahead and stacked the 8-Relays on the rpi, installed jumpers, and fired everything up.

And the verdict….

SUCCESS!! As I suspected, the Pi side was ruled out. I’m still thinking there’s a short on the Mega-bad board causing the 8-relays to also short when all stacked. To test I’ll follow this sequence:

1. Restock HAT pi->BAS->8RLY
2. No jumpers on BAS
3. Jumpers installed on 8-Relay
4. Test pin continuity to GND without power
5. If short exists, should identify at GPIO pins to 8relay level.
6. power on and check continuity to GND
7. If no short, then removed jumpers on BAS have isolated the anomaly
8. Test RS-485 pass through on 8-relays.
9. Reach out to Sequent to request support/replacement.

Has there been any history of defective Mega-BAS cards to your knowledge?

[rstrouse]

I have stacked up several BAS cards and never had a problem. The symptoms are so very odd.

[CodeSlinger69]

At this point I would just get a replacement from whatever vendor you bought this from. You've done far more work than I would have done in trying to track down the problem, especially after noticing that wonky soldering on the board.

[jamestalmage]

I am experiencing the identical symptoms. I'm receiving packets, but 100% transmit errors.

@craywm Did you find a resolution?

[jamestalmage]

I notice @craywm is using a version 4.0 board, same as me.

How old are the 3.X boards? Has anyone had success with the new 4.X boards yet? Wondering if there's something to the guess that something is wrong/changed with the new boards.

Is there a command that would let me just dump the received bits in a way that would make sense to post? At least verify the expected preamble is being received?

I tried the screen command... Just black characters... Guessing they don't translate to ASCI

[tagyoureit]

A good first step is to try and update the firmware. When you do this, make sure that none of the applications accessing the card (njsPC, REM, etc) are running).

Have you tried swapping the A/B cables?

You can dump the raw bits with od -x, but MessageManager in dashPanel is much more effective.

[jamestalmage]

@tagyoureit I'm on firmware 2.03, and yes. Definitely swapped A/B. I'll head out and reconnect and send the MessageManager info in a bit

[jamestalmage]

@tagyoureit I tried everything you suggested:

The comms page shows bytes are being received:

But Message Manager only shows outgoing messages:

ox -d /dev/ttyS0
0000000 0100 3f2d f1bd fdff 00a5 0100 3f2d f1bd
0000020 fdff 00a5 0100 3f2d f1bd fdff 00a5 0100
0000040 3f2d f7bd 01fd 35bf 0100 3f2d f7bd 01fd
0000060 35bf 0100 3f2d f3bd f7fd 9dfd 0000 2d01
0000100 bd3f fff1 a5fd 0000 2d01 bd3f fff1 a5fd
0000120 0000 2d01 bd3f fff1 a5fd 0000 2d01 bd3f
0000140 fdf7 bf01 0035 2d01 bd3f fdf7 bf01 0035
0000160 2d01 bd3f fdf3 fdf7 009d 0100 3f2d f3bd
0000200 f7fd 9dfd 0000 2d01 bd3f fff1 a5fd 0000
0000220 2d01 bd3f fff1 a5fd 0000 2d01 bd3f fff1
0000240 a5fd 0000 2d01 bd3f fdf7 bf01 0035 2d01
0000260 bd3f fdf7 bf01 0035 2d01 bd3f fdf3 fdf7
0000300 009d 0100 3f2d f3bd f7fd 9dfd 0000 2d01

The ox -d command shows nothing if the `nodejspoolcontroller is not running.

A USB adapter arrived today, going to use it to verify wiring tomorrow while the sun is shining

[craywm]

@jamestalmage i ended up going with the RS-485 on the 8-Relays. You should not have an issue with the USB adapter if it is the same issue as mine. I do think there’s some interference on the board causing the issue. I was able to send to my PC through the megabas, but not receive, data would come, but it was corrupted.

Change your log settings to debug and check PC2 monit for njsPC tossing data packets incoming. This should indicate that data is reaching the pi from through the megabas RS-485 transceiver, however it is corrupted.

Just FYI, if you go with the 8relays transceiver (assuming you have one), remove jumpers from the Mega-BAs RS-485 Tx/Rx pins (as mentioned above) to isolate the Megabas from the GPIO pins. This is where I spun my wheels for a bit, removed jumpers and smooth sailing with 8-Relays.

[jamestalmage]

@rstrouse @craywm Turns out my issue was miswiring on the pump end. Now to get the AquaCal heater working.

[mhmatttu]

I have experienced a similar issue with my mega-bas v4. I have an intelliflo vsf pump and ic40. when either are connected to the mega-bas rs485, they work fine with zero failure rate. However, when i connect both of them at the same time, i get 100% failure send rate. I swapped wires, ensured good connections, added enable_uart=1 to boot config, rs485 pass through enabled, verified correct rpi interface settings. I currently have the pump connected to the mega-bas and the ic40 connected to a USB adapter and all is working well. Any thoughts on why both will not work together on the mega-bas?

[rstrouse]

Actually the one difference with the port on the BAS is that it is wired for modbus support. Try disabling it with the cli. While I love the Sequent cards it is utterly frustrating that they don’t document register changes on the I2c and they make indiscriminate changes as if nobody uses the hardware for anything other than playing with it. Heck they don’t document the registers at all. You have to manually decrypt c enumerated to come up with the values.

[mhmatttu]

Thanks. Apologies for my ignorance but how do I disable it? Below are the settings I get with megabas 0 rs485rd

[craywm]

Actually the one difference with the port on the BAS is that it is wired for modbus support. Try disabling it with the cli. While I love the Sequent cards it is utterly frustrating that they don’t document register changes on the I2c and they make indiscriminate changes as if nobody uses the hardware for anything other than playing with it. Heck they don’t document the registers at all. You have to manually decrypt c enumerated to come up with the values.

Thanks @rstrouse. This is the condition I attempted to describe above. Hope this fixes your problem @mhmatttu!

[mhmatttu]

Based on the below statement from the sequent website, should I change the rs485 settings to
megabas [0] rs485wr 0 0 0 0 0?

[mhmatttu]

By way of follow-up, the above command did resolve my issue. I now have the intelliflo and IC40 connected to the Mega-bas RS485 port and working.