So, I'm attempting to use a waterproof shower controller to control something other than the mixer it was intended for. I was looking to use a wireless controller (see here) but that may be a little beyond this first attempt.

Instead I'm attempting to use a wired version instead.

So the controller I want to hack is the Vado Identity IDE-147A-C/P or now called the Vado SENSORIIdentity IDE-147C-C/P.So far I've passed a multi meter across all of the pins of the mixer to see what it's outputting and the attached is what I found.

Basically the controller is 5v DC and the power is on pins 3 (-ve) and 2 (+ve). I've connected 5v to it and, sure enough, it lights up and shows the default screen. It then displays E1 which is to be expected I guess as it's not connected to the mixer.

I'm thinking that pins 1 and 4 are likely to be tx / rx but I'm not sure which is which or what the next step would be to work that out.

I've tried to read digital values on pins 1 and 4 from the controller and they set to 1 as soon as I add power and stay there.I've also tried reading analog on pins 1 and 4 from the controller and not much happens there either other than they both go to a particular voltage and stay there.

So the next step is going to be reading the same from the mixer to see if it shows up anything.Then I'll start looking into serial reads from the mixer and try replaying that to controller to see what happens.

So, assuming it is serial then I need to work out which baud rate to use but I think that rather than attempt to work it out it may be quicker / easier to just try the standard rates and see if I can read anything.

I only have an uno at moment with a mega coming tomorrow so I'll hopefully be able to read from serial1 and write to the serial monitor then.

Nothing much to ask right now other than any advice on where to go next and I'll continue to update this thread with my findings...

and the line "25525525525525525502552552552552552550" repeats every 37 lines.

It looks to me as though the baud might be too slow for starters.Secondly, it looks as though "2552552552552552550" might be a heartbeat of sorts with 0 being the termination character.I also wonder if the data or stop bits are the wrong length as there is a line in there ending in 5 (assuming the 0 is the termination character) although I guess that could also be because of incorrect framing.

The arduino is connected to a laptop which is not connected to a power supply so how am I receiving any signal without a ground connected? Am I therefore just receiving interference?And when I do connect the ground between the mixer and the arduino I get no output at all.

Is this a step backwards? How can I shield from interference and be sure I'm only getting a signal from the mixer?Any help appreciated...

I've now set the internal pullup on the mega's rx pin and worked out that the cable that connects the mixer to the controller "crosses over" such that the pins on the mixer's connector are the same as the pins on the controller. I'm now bypassing the cable the connects the 2 which was causing me an issue with the + / - round the wrong way.

When looking at the connector face on with the notch at the bottom working in a clockwise direction from the bottom left:On the plugs, pin 2 is +ve, pin 3 is -ve On the cable, pin 3 is +ve, pin 2 is -ve

Pin 1 on the mixer connected to Serial2 on the Mega, pin 4 connected to Serial1.

I now only get a signal when power is applied to the mixer and the ground pin is connected. Thumbs up.

This pattern then repeats.I've changed the baud and config on the serials to 38400 / SERIAL_6E2 as 115200 / SERIAL_8N2 was only giving 0's.So I'm still not convinced this is the correct baud and config but at least I'm getting consistent results now.Next step is to try replaying the mixer's output to the controller and see what happens...

So, on to the controller...If I send nothing to the controller then the screen displays E1 and there is no output to the rx pin on the mega.

HOWEVER...I replayed "38" from the mega to the rx on the controller and it no longer goes into error. Rather it now displays "00" which is the normal "off" state. The backlight stays lit, however, which is not right but it's progress.

After putting this down for a little while, I did some further poking around with the controller and the transceiver chip uses RS-485 for its serial communications. So it's not quite as simple as a tx and an rx pin. This also necessitated the use of a couple of RS-485 modules for the arduino to convert the comms to something the arduino can use.

Furthermore, I'm still unsure of what the baud rate is as I seem to be able to retrieve apparently real data at a variety of bauds. I therefore thought it would be worth trying an oscilloscope to help detect the baud rate.

Using the instructions / code / app from here I managed to set up an oscilloscope using the arduino. It's certainly not perfect but it definitely appears to give some useful information.

From here it suggests measuring the shortest pulse and using a formula you can work out the baud.

I measured the shortest pulse at about 400 µs and that makes it really close to 2400 baud (allowing for errors in display and measurement).

I'm yet to test with this baud but, again, another step forwards perhaps...

Using the scope trace you should also be able to work out the number of data bits and stop bits used.

So I've done some measurements using the arduino oscilloscope and I'm not entirely sure it has suitable resolution to be completely confident about the individual bits.

Anyway, I've attached a screenshot with what it outputs and it shows the following:

The red line measurement shows a "packet" is 8 ms long.The 2 pink dots on the red line are 1.2 ms apart.The green line measurement shows the gap between spikes is about 0.4 ms.The 2 pink dots on the green line are 3.5 ms apart - probably not that useful.

I've tried listening on Serial1 (the mixer) on the Mega and replaying any input to Serial2 (the controller) and vice versa but it's not working.

I have a feeling that there might be timing issues in that you may need to wait between bytes or something...

As your measuring the differential signal you only need to measure either the A or B side (or the UART input to the chip) on a single channel and this should increase the scope resolution.Failing that then maybe invest in a cheap logic analyser like this that will be ideal for a job like this.

It's difficult to tell but looking at your image it looks like you will have only 7 bits per frame and assuming it includes one start and one stop bit that means only 5 data bits.

As your measuring the differential signal you only need to measure either the A or B side (or the UART input to the chip) on a single channel and this should increase the scope resolution.Failing that then maybe invest in a cheap logic analyser like this that will be ideal for a job like this.

It's difficult to tell but looking at your image it looks like you will have only 7 bits per frame and assuming it includes one start and one stop bit that means only 5 data bits.

Tried only reading one channel but it didn't seem to make any difference.Also tried increasing the baud on the Arduino and the oscilloscope program to 250000 but, again, no dice.

I've ordered a logic analyser and it should turn up today or tomorrow so I'll give that a go and see what happens...

OK, so, logic analyser here and this is what I've managed to find so far.

I'm using sigrok to interpret the data from the analyser.

The following is connecting the analyser solely to the mixer, i.e. without the controller in the picture...

The image attached (full data.png) is the full set of data captured from when I turned the mixer on to when I turned it off.

The gap between the final peak of one packet and the first peak of the next packet is 47.3 ms

All the "packets" shown are the same and a single packet can be seen in the attached image (single packet.png). Each packet is 7.9 ms long and consists of 7 peaks. Are there start and stop bits at either end that are not peaks?

The attached image (peak.png) shows that a peak is 1 ms long and a trough (trough.png) is 0.1 ms long.

Now I've connected the mixer and the controller to a breadboard and have the signal analyser effectively listening in to the conversation.

From the conversation, it appears that there's a lot more going on than the single "packet" from the previous post. Having seen the data in the conversation I've measured the smallest pulse and it's about 0.1 ms which (according to here) correlates with a baud of 9600.

So, with that in mind I added a UART protocol decoder (according to here, it's the only protocol decoder that mentions RS485) and set the settings in PulseView as shown in uart.png, started reading data and then turned on the mixer. After a period of time I turned off the mixer and stopped reading data.

The attached file (sample.png) shows the first 11 chunks of data.

A couple of things of note before getting to the data:

There is about 39.15 ms between the end of one chunk to the start of the next chunk.

PulseView seems to suggest there are a lot of Frame Errors but that may be because the protocol isn't really UART... perhaps

It looks like there are 7 bytes from the mixer (As there were 7 peaks in my last post) followed immediately by 7 bytes from the controller.Only the final byte from the mixer ever appears to contain any data but then I haven't pressed any buttons on the controller yet.

UART decoder is probably the one to use. RS485/RS422 describe the electrical differential signal to reduce/cancel noise induced in the cables so you can transmit signals further in electrically noisy environments.

Does the protocol decoder have an auto mode to determine the correct baud rate, start/stop bits, data bits and parity or did you select them manually.Assuming it is Serial data then it looks like it could be configured as 9600,6N1 is this what you was using?That's 1 start bit, 6 data bits and one stop bit. Other options could be 5N2, 5E1, 5O1

UART signals are normally high in an idle state so you might have the logic probe connected to the wrong leg of the RS485 A/B line as your captures show the signal as idle low. You might be able to invert the logic in the protocol decoder instead.