Hi all.

I have an exhaust valve controller project I am currently doing. I have the controller which came with the valves but I want to make my own controller from an ATmega328p (Custom Arduino) with extra options like geofencing and time-based functions.

What I am trying to do is replicate the PWM signal from the valve controller and write it to an Arduino. I have never used a scope before and not sure if I understand the measurements. From what I think I can understand is, the signal is at 2.4khz and at a duty cycle of 50% but the OFF and ON signals look slightly different.

Is there anyone who could understand the signals and educate me on them, please?

Here is a link to the Hantek WAF Files, If you have a Hantek or a scope that can open WAF files: https://drive.google.com/drive/folders/12d0EpRkXBP3IsG-vZXz2ClF0c1DnEWgl?usp=sharing

I have put the controller on the scope and have come up with the following.

When the OFF button on the remote is pressed the valve gets closed and the controller outputs this wave:



and when the ON button is pressed the valve opens and the controller outputs this wave:



Mike.

 

It does not look like a PWM signal. It looks like a few bytes of data. You will need to find out what protocol is being used on the data bus or just replicate the two data strings in software.

Les.

 

hi $200,
Do you have any details of the controller or a link.?
It does not look like PWM to me.
It appears to be 2400Baud serial data.
E

 

When the OFF button on the remote is pressed the valve gets closed and the controller outputs this wave:

Is this like a common IR remote control?
That signal could be one of the many IR codes.

 

The only info I have at the moment is that the chip is a NuvoTon N76E003AT20. The cable to the valve is just 3 pins +12v, Signal & GND. I think it runs from pin 6 of the chip. The signal is then inverted and boosted up to 12v.

Datasheet: http://www.nuvoton.com/resource-files/DS_N76E003_EN_Rev1.00.pdf

 

That is a general purpose microcontroller so the way it is programmed determines that on/off signal - could be anything the manufacturers wanted. So it is a case of carefully measuring the width of each pulse and replicating that. The microcontroller includes an asynchronous serial port so it could well be using that.

 

So if I understand that correctly the OFF waveform could look something like this: 11001010101111100110110101111 as a data signal.

 

hi,
Write a test program for those two Bit strings and check them on your scope, if OK, try them on the valves.
Post your scoped test strings and we can check them.
E

 

I will give it a go. I'm not too clued up on this so it will probably take me a while to get my head around it and come up with a program. I will get on to researching it now.

Mike.

 

I'm not having much luck at the moment. Trying to measure the timings on the scope are proving to be a royal pain in the butt. I am however going to purchase the Pico 2204a with a logic analyser which has a serial decoder built in, which can convert the signal to hex, binary, etc the scope I am using now is not mine and I need to give it back.

I have come across this web page about SPI and has a bit about the asynchronous serial port.https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi/all.

Fingers crossed it is an asynchronous serial signal.

Mike.

 

Don't you have cursors on your scope? Makes reading pulse widths a lot easier.

 

And if that is SPI, you are going to need a clock trace to make any sense of the data.

 

Instead of buying a scope / logic analyzer, consider buying a straight PC based logic analyzer. They are fairly cheap today and offer a whole range of protocols. I have the ZeroPlus
Logic Cube and it comes with almost every protocol you would ever want. Though, unless they have updated it recently, it is a bit dated. You might be able to find better buys.

 

SPI is synchronous, so unless you can find an accompanying clock, those waveforms are definitely not SPI data. SPI is also typically much much faster. The waveforms look very much like async serial, so a character will likely be 10 or 11 bits - start, probably 8 data bits, possibly a parity bit which might actually be parity or just the totally useless MARK or SPACE so often used in lamebrained serial communication and at least one stop bit. 8 data, no parity and one stop bit is a very common format. The final stop bit(s) will be indistinguishable from the idle state of the line.

[EDIT] - the string is 29 bits plus that stop bit mentioned, so it is almost certainly three 8 bit characters - one start bit, 8 data, 1 stop bit for each character

[EDIT 2] - Sorry, I missed where you reported that there is just power plus a single data line. It definitely is not SPI.

The processor has two serial ports, so it may be possible to trace the signal back. I would be exceedingly surprised if the signals to and from the board are direct to the processor and not via line drivers and receivers. The voltage levels suggest perhaps RS-422, 423 or 485 (RS-485 is generally used for "half duplex" where the same data path is use for transmission in both direction, with something acting as a "master" to manage who gets to talk at any time. If the connection between the board and the valve control is very short, it might just be signals via buffers or (cringe!) directly from the microcontroller.

 

OK, I'm confused - the scope images show about 3 V peak to peak amplitude (with slight negative swing??) but you mention inversion and boosting to 12 V.

Async serial normally holds the data line in a "MARK" state between characters ("idle" line). At the output of the transmitting processor or input to a processor at the receiving end this would correspond to a logic HIGH. The approximately 0 V for what I assume is idle line is consistent with your description of inversion, but the 3 V for "SPACE" is ... odd.

 

But why do you want to reverse-engineer that? It won't be easy at all, considering that there is a microcontroller there. Who knows what the source code looks like!

 

@ebp Just a quick post as it is nearly 3 am in the UK and I need bed.

Here is the picture of the 12v inverted signal.

 

Looking at that signal, I do not recognized it as standard UART signal, as @ebp alluded to.
The MARK between transmission is not there. Thus this could be an unconventional format.

 

Looking at that signal, I do not recognized it as standard UART signal, as @ebp alluded to.
The MARK between transmission is not there. Thus this could be an unconventional format.

I didn't look at it carefully enough to identify stop and start bits. If they don't happen when they are expected then it may well be some oddball thing. The most recent scope image certainly is inverted from normal async, but the string at #7 and the most recent image look like the stop and start bits are in the correct place. The closest standard rate is 9600 bps, which would make 10 bits 1041.7 µs. It looks to me like it may be a little bit faster than that, but it's hard to tell - it may be the digital scope coercing the transitions to match pixel positions (I always forget to allow for digital scopes mucking about with reality). At 9600 bps, 29 bits should be 6.04 scope major divisions at 500 µs/div.

The datasheet for the processor will presumably reveal if there is some convenient way of inverting the output from the UART. Perhaps the data is received by simple attenuation rather than re-inverting and level shifting.

 

I haven't opened the valve as it is ultrasonically welded together. I have found this picture on the manufactures site its not the best. Maybe another N76E003AT20 chip acting as a slave.