Closed tmjo closed 3 years ago
We appreciate the thanks! This isn't my repo either, but @ccutrer volunteered the wiki for us to document the protocol, so this is as good a place as any to ask.
As far a I know, the RS-485 protocol is only used on the BP series spa controllers. The 8-pin Molex and RJ connectors may use a completely different protocol. Since the voltages do not seem to match, this only confirms my suspicion. However, this does not mean those protocols cannot be discovered and decoded, but it will take some elbow grease. You will have to determine what pins are for power, and what pins are for data, then capture the waveforms of the data signals. Depending on the physical layer protocol, this may be possible with a microcontroller/RPi, but may require a transceiver. If you're able to do any of that, we may be able to provide some guidance. Good luck.
Thanks for your reply @bggardner! I'll see what I can do. If you guys don't mind, I'll leave the issue open for a while just in case someone happens to stumble over it with some further advice.
Actually, measuring a bit more, I found some 3V-ish pins there. So I just need some time to verify and then I'll give it a shot and see if there is something there. Would surprise me if the protocols are very different, dont't you agree? Is BP-series the current series by Balboa? I find the GL-series under legacy products, which makes sense since its a decade old, but then again they all seem very similar. If we assume that there is a Vcc, a 0V and a TX/RX whatever the protocol, what could there be on the other pins? If I'm really lucky, perhaps nothing.
BP series is the latest.
I just bought a BP7 pack which was just released. It has the 4pin micro molex connector.
I’m planning to use a spare Netduino controller I have laying around as an RS-485 to Ethernet interface and control it from my Crestron control system. (Since that’s what I do for a living)
Sent from my iPhone
On Aug 16, 2020, at 1:30 PM, tmjo notifications@github.com wrote:
Thanks for your reply @bggardnerhttps://github.com/bggardner! I'll see what I can do. If you guys don't mind, I'll leave the issue open for a while just in case someone happens to stumble over it with some further advice.
Actually, measuring a bit more, I found some 3V-ish pins there. So I just need some time to verify and then I'll give it a shot and see if there is something there. Would surprise me if the protocols are very different, dont't you agree? Is BP-series the current series by Balboa? I find the GL-series under legacy products, which makes sense since its a decade old, but then again they all seem very similar. If we assume that there is a Vcc, a 0V and a TX/RX whatever the protocol, what could there be on the other pins? If I'm really lucky, perhaps nothing.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/ccutrer/balboa_worldwide_app/issues/14#issuecomment-674567668, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AENNGSDPSKQRNDBWQBERQKLSBAXWPANCNFSM4QA2XORA.
On request from the other thread, I'll post some pictures of my case.
The circled ports are the 8-pin Molex J70, J71 and J72 which are labelled "Main panels". There are also some 6-pin for auxiliary panels.
Please disconnect power and probe if all molex ports have the same pinout (check for continuity). Also please take a look at the remote control panel if all cables appear to be used.
I'm suspecting a TTL serial bus on the 5v lines and balboa has had problems with far distance controlling so they switched to rs485. Maybe it's even only vcc, gnd, serial so 3 pins.
Do you happen to have a oscilloscope or access to one?
Hi cribskip! Thanks. I will try to do that. I do have access to oscilloscope at work, so I might try to check it out when I'm back from vacation.
Hi, Did some simple measurements with a multimeter, don't have a scope available right now. Not sure if it tells anyone anything?
MEASUREMENTS J71
=================
- Ports J70, J71, J72 seems to be parallel (continuity between pins)
- Not sure of pin numbers, so using this when watching into the Balboa controller (ref photo):
1 2
3 4
5 6
7 8
- Pin 7+8 seems to be same (0V/GND?)
- Pin 2+4 seems to be same
MEASUREMENTS J71
------------------
1-2 4V 2-1 -4V 3-1 -3V 4-1 -3,9V Same as other Same as other
1-3 3V 2-3 -0,95V 3-2 0,9V 4-2 0V 5-6 5V 6-7 -9,74V
1-4 4V 2-4 0V 3-4 0,9V 4-3 -0,9V 5-7 -4,7V 6-8 -9,74V
1-5 4V 2-5 0V 3-5 0,9V 4-5 0V 5-8 -4,7V
1-6 9V 2-6 5V 3-6 5,9V 4-6 5V
1-7 -0,7V 2-7 -4,7V 3-7 -3,7V 4-7 -4,7V
1-8 -0,7V 2-8 -4,7V 3-8 -3,7V 4-8 -4,7V
SUMMARY REFERENCED GND(7):
1 0,7V
2 4,7V
3 3,7V
4 4,7V
5 4,7V
6 9,74V
Did a quick test connecting my ESP to some combinations of pins 1-4 but didn't get anything useful.
I would probably guess that the power supply (9-10V) is pin 6, and the rest may be averages of single-ended time-varying signals (data/clock lines). Still not sure there could be differential signaling, or if the data/clock lines use 9V or 5V logic. An o-scope would verify this. It might also be useful to try to find the part numbers of some of the ICs, as one of them may be a transceiver, which would give you a big clue as to the physical layer protocol.
With the power off, can you verify that pins 7+8 and 2+4 are shorted to each other? Also, it would be good to verify 7+8 are actually digital ground by checking continuity (short or not) between them and a probable digital ground (pad of one of the yellow tantalum capacitors, away from the orange stripe - such as the pad pointed to by the white line coming from the R35 text, by J71).
I would probably guess that the power supply (9-10V) is pin 6, and the rest may be averages of single-ended time-varying signals (data/clock lines). Still not sure there could be differential signaling, or if the data/clock lines use 9V or 5V logic. An o-scope would verify this. It might also be useful to try to find the part numbers of some of the ICs, as one of them may be a transceiver, which would give you a big clue as to the physical layer protocol.
With the power off, can you verify that pins 7+8 and 2+4 are shorted to each other? Also, it would be good to verify 7+8 are actually digital ground by checking continuity (short or not) between them and a probable digital ground (pad of one of the yellow tantalum capacitors, away from the orange stripe - such as the pad pointed to by the white line coming from the R35 text, by J71).
Thanks! I also assumed pin 6 is the supply. Pins 7+8 and 2+4 showed less than 1ohm and gave a beep, so I believe they are shorted. Also did some more ohm measurements between pins but they didn't tell me much. But I'll check with the capacitor as you suggest. Will also connect a oscilloscope in a few weeks to see if I get something out of that. Good tip about the ICs, I'll google them, but do you have any idea which ones it could be? There are so many :)
The best way to determine the IC would be to follow the traces from J70-72, or search IC leads for shorts to the non-power pins. If they're driven by a transceiver, it's probably one of U3, U6, or U16. Otherwise, they may be driven directly by the microcontroller (square IC above J72).
Side note - I came across this repo, and he appears to have the RJ45 connector, for which the pinout appears much different.
Perfect, I'll try to verify this as soon as possible. I had a look at the repo you linked to and I remember I've seen it before when googling around, but I skipped it at the time since it's about making the whole spa controller more or less from scratch. Looking more closely with the current knowledge, it may give me very valuable info if it is the same "protocol" as mine. So thanks for that!!
Although the linked repo uses RJ45, it seems like the following 8 pins are used:
Gnd
VD+5V
CLOCK
DATA_IN
DATA_OUT
V_RAW (12-24 Volts)
LIGHT_SINK
Unused
If it is the same, I should be able to find the corresponding pins and the code could also help to decipher the communication since this guy interfaced an original Balboa display.
PS! Found several places online that the Balboa Wifi-module does certainly not work with the GL2000 models, so I guess that is due to the communication and connections being very different. Hopefully I'll be able to figure it out and get it working with guiding from you experts! :)
Hi again,
Did some more research, and the pins 7+8 are confirmed as digital ground (short to yellow cap C4). Also, I found that pin 1 is connected to IC U16:2 and ground (7) to U16:4. Couldn't fint any other pins though, also not at the other ICs. So I don't really get this.
Tried to read the partno of ICs, but there doesn't seem to be any text on the smaller ones, so no luck there.
I'll try again to do some measurements with an oscilloscope when I get hold of one.
I do wonder if the RJ45 and molex are different physical connectors for the same protocol? It's possible to find online RJ45 to 8 pin molex for spas.... Perhaps you might be able to find some guidance there?
I also came across this link which documents an RJ45 protocol that is very different from NickB's https://www.olivierhill.ca/archives/74-Cal-Spa-Connector.html
I'm just on my journey to see if I can figure out which version of the RJ45 my controller uses for the gs510z controller
I do wonder if the RJ45 and molex are different physical connectors for the same protocol? It's possible to find online RJ45 to 8 pin molex for spas.... Perhaps you might be able to find some guidance there?
I also came across this link which documents an RJ45 protocol that is very different from NickB's https://www.olivierhill.ca/archives/74-Cal-Spa-Connector.html
I'm just on my journey to see if I can figure out which version of the RJ45 my controller uses for the gs510z controller
I think the RJ45 protocol on that website is used on display which have 4 buttons More buttons means they don't have enough lines and it has to be serialised in the data stream. But that's just a guess, measuring will tell for sure.
I think the RJ45 protocol on that website is used on display which have 4 buttons More buttons means they don't have enough lines and it has to be serialised in the data stream. But that's just a guess, measuring will tell for sure.
Thanks, this makes a lot of sense to me, will take some measurements and experiment to find out (I do have a 4 button controller)
I would highly doubt this is the case.
Any controller with a screen or LED feedback of any kind is likely using serialized data. Contact closure for buttons in place of serialized data would require a whole new set of i/o inputs on the control board which would add expense when they already have a serial bus.
On Sep 8, 2020, at 3:56 AM, khcnz notifications@github.com wrote:
I think the RJ45 protocol on that website is used on display which have 4 buttons More buttons means they don't have enough lines and it has to be serialised in the data stream. But that's just a guess, measuring will tell for sure.
Thanks, this makes a lot of sense to me, will take some measurements and experiment to find out (I do have a 4 button controller)
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ccutrer/balboa_worldwide_app/issues/14#issuecomment-688759684, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AENNGSFDECRCAWZPANKADGLSEX5VVANCNFSM4QA2XORA.
I would highly doubt this is the case. Any controller with a screen or LED feedback of any kind is likely using serialized data. Contact closure for buttons in place of serialized data would require a whole new set of i/o inputs on the control board which would add expense when they already have a serial bus. On Sep 8, 2020, at 3:56 AM, khcnz notifications@github.com wrote: I think the RJ45 protocol on that website is used on display which have 4 buttons More buttons means they don't have enough lines and it has to be serialised in the data stream. But that's just a guess, measuring will tell for sure. Thanks, this makes a lot of sense to me, will take some measurements and experiment to find out (I do have a 4 button controller) — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#14 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AENNGSFDECRCAWZPANKADGLSEX5VVANCNFSM4QA2XORA.
You would indeed think so but I have come across other projects having the same findings on their Balboa controllers: Example: https://www.raspberrypi.org/forums/viewtopic.php?t=175399 On these controllers only the display/led data seems to be serialised, the buttons are connected directly.
Interesting! I stand corrected!
On Sep 8, 2020, at 9:43 AM, Nick B. notifications@github.com wrote:
I would highly doubt this is the case. Any controller with a screen or LED feedback of any kind is likely using serialized data. Contact closure for buttons in place of serialized data would require a whole new set of i/o inputs on the control board which would add expense when they already have a serial bus.
I would highly doubt this is the case. Any controller with a screen or LED feedback of any kind is likely using serialized data. Contact closure for buttons in place of serialized data would require a whole new set of i/o inputs on the control board which would add expense when they already have a serial bus. On Sep 8, 2020, at 3:56 AM, khcnz notifications@github.commailto:notifications@github.com wrote: I think the RJ45 protocol on that website is used on display which have 4 buttons More buttons means they don't have enough lines and it has to be serialised in the data stream. But that's just a guess, measuring will tell for sure. Thanks, this makes a lot of sense to me, will take some measurements and experiment to find out (I do have a 4 button controller) — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#14 (comment)https://github.com/ccutrer/balboa_worldwide_app/issues/14#issuecomment-688759684>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AENNGSFDECRCAWZPANKADGLSEX5VVANCNFSM4QA2XORA.
You would indeed think so but I have come across other projects having the same findings on their Balboa controllers: Example: https://www.raspberrypi.org/forums/viewtopic.php?t=175399 On these controllers only the display/led data seems to be serialised, the buttons are connected directly.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ccutrer/balboa_worldwide_app/issues/14#issuecomment-688964817, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AENNGSHETGLGGNK3NXGLCSLSEZGLRANCNFSM4QA2XORA.
Maybe a bit off topic but has anyone looked at the controller from Gecko, or know if similar development is in place?
Thanks!
Gil
On Tue, Sep 8, 2020, 08:45 Neil Dorin notifications@github.com wrote:
Interesting! I stand corrected!
On Sep 8, 2020, at 9:43 AM, Nick B. notifications@github.com wrote:
I would highly doubt this is the case. Any controller with a screen or LED feedback of any kind is likely using serialized data. Contact closure for buttons in place of serialized data would require a whole new set of i/o inputs on the control board which would add expense when they already have a serial bus.
I would highly doubt this is the case. Any controller with a screen or LED feedback of any kind is likely using serialized data. Contact closure for buttons in place of serialized data would require a whole new set of i/o inputs on the control board which would add expense when they already have a serial bus. On Sep 8, 2020, at 3:56 AM, khcnz notifications@github.com mailto:notifications@github.com wrote: I think the RJ45 protocol on that website is used on display which have 4 buttons More buttons means they don't have enough lines and it has to be serialised in the data stream. But that's just a guess, measuring will tell for sure. Thanks, this makes a lot of sense to me, will take some measurements and experiment to find out (I do have a 4 button controller) — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#14 (comment)< https://github.com/ccutrer/balboa_worldwide_app/issues/14#issuecomment-688759684>>, or unsubscribehttps:// github.com/notifications/unsubscribe-auth/AENNGSFDECRCAWZPANKADGLSEX5VVANCNFSM4QA2XORA.
You would indeed think so but I have come across other projects having the same findings on their Balboa controllers: Example: https://www.raspberrypi.org/forums/viewtopic.php?t=175399 On these controllers only the display/led data seems to be serialised, the buttons are connected directly.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub< https://github.com/ccutrer/balboa_worldwide_app/issues/14#issuecomment-688964817>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AENNGSHETGLGGNK3NXGLCSLSEZGLRANCNFSM4QA2XORA>.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ccutrer/balboa_worldwide_app/issues/14#issuecomment-688965705, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHOIW4IVZ6VARO7C5RWVBI3SEZGQZANCNFSM4QA2XORA .
@tmjo did you get any further with this?
Just acquired the same board/controller combo, and really want to develop remote control for it.
Thanks! Dave
Hi @davewatson91! No, I didn't get any further but I didn't give up just yet. Plan is to hook up an oscilloscope and see what is going on there, but I didn't find the time to study it yet. I did find some useful information here, there's a pdf with some measurements there, but I didn't get as far as to verify if it is the same as mine.
Please let me know if you find any useful information, I'm really interested in getting my tub online :)
@tmjo - Great - I don't have access to an oscilloscope, but can definitely help with the protocol analysis once you've got some data!
Will keep digging when I find some free time!
I also have a Balboa GL2000 so would be interested in getting to the bottom of this. I also own a USB oscilloscope, though sure I know how to use it yet ;)
Happy to follow specific instructions @tmjo
Hi @netmindz; unfortunately I didn't get time to investigate any further, but I would be really interested in getting a working solution for this too. Since you have a oscilloscope available, are you able to perform some measurements and see what is there? I'm sure some smart people would be able to help us out if we get that done. See here for some guidance. I had (still do actually) to measure myself, but I didn't find the time and mental energy to start the project yet.
Pin1
pin2
Pin 3
pin4
pin5
Tried without the top panel connected and outputs look very similar
Ok, so done a bit more testing, looks like if i use an RS485 between Pin1 and Pin3 we do get some data, though not in the same format.
If i use python tcp_serial_redirect.py --bytesize 8 /dev/ttyUSB0 115200
Then I get data that has bits like "USER PREFS Pú^T395C" in there
trying to swap the bytesize to 7 looks possibly a little less garbled, but not sure. Tried lowering the baud rate, but then get all random output.
As this is my first time trying to reverse engineer serial, i'm not sure what the next steps are bar just randomly playing with baud rate, wordsize etc till it looks like all the data forms a regular pattern
Still tying to guess what the delimiter char is. Using E gives me more consistent message lengths (64/71) but repeating vales per message, using Ctrl+B (start of text) then you get the following
^B^@^@^@^@^@^@^@^@^@^@^@^@î^M ^B^@^@^@^@^@^@^@^@^@^@^@^@Ãû^F^CE^N^@^@ÿt®^M ^B^@^@^@^@^@^@^@^@^@^@^@^@Ãú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,ú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,û^F^CE^N^@^@ÿtú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,®^M^C^@^@^@^@^@^@^@^@^@^@^@^@´®^M^C^@^@^@^@^@^@^@^@^@^@^@^@´û^F^CE^N^@^@ÿt®^M^C^@^@^@^@^@^@^@^@^@^@^@^@´ú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,ú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,û^F^CE^N^@^@ÿtú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,®^M^@^@^@^@^@^@^@^@^@^@^@^@^@-®^M^@^@^@^@^@^@^@^@^@^@^@^@^@-û^F^CE^N^@^@ÿt®^M^@^@^@^@^@^@^@^@^@^@^@^@^@-ú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,ú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,û^F^CE^N^@^@ÿtú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,®^M^A^@^@^@^@^@^@^@^@^@^@^@^@Z®^M^A^@^@^@^@^@^@^@^@^@^@^@^@Zû^F^CE^N^@^@ÿt®^M^A^@^@^@^@^@^@^@^@^@^@^@^@Zú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,ú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,û^F^CE^N^@^@ÿtú^T385C^@^@é^@^@^@<84> ^Bÿÿe^@^@^@^@^@,®^M
I don't think a lot of this will be in straight ASCII (would be very inefficient use of limited bandwidth) - can you give us the HEX dump of it?
Also, you may need to check parity and stop bits - I suspect it may be 8 bit length, and a stop bit (probably no parity) as a complete guess.
As it's now clear the GS series uses a different protocol, going to move over to a new repo
https://github.com/netmindz/balboa_GL_ML_spa_control
Also has some example dumps, some with attempts guessing the delimiter char @davewatson91
Thanks for the voltage info @tmjo - helped me find the RS485 line, hopefully you will join my project?
Wow, looks great @netmindz! I didn't read it all yet, but I will follow your project right away! Hope we can get this running!
First of all, a million thanks for this well documented project! I'm using cribskip's ESP project as basis and have it running. Was about to measure and connect it to my spa, but found out I have 8-pin Molex instead of 4-pin. Anyone that could share some insight of the 8-pin Molex? Tried to measure, but seemed to get 10V and didn't find any 12-15V. Also, got 5V "several places", and no 2-3V. So I got a bit reluctant to connect my spa before I figure out some more.
My spa is having a Balboa GL2000 HSEX2000 Mach3 system (part no 54503-01) and is connected to a ML400 panel on the J70 plug (8-pin molex). I also have J71 available for "main panel" it seems. It's a 2007/2008 model.
PS! I realize this is not an issue with this repo, please forgive me for opening this, but I couldn't find anywhere else to ask so I gave it a shot. If there is a more appropriate place to ask, kindly guide me to it.