Go Down

Topic: rsapi.dll with Excel VB, replace with arduino?? (Read 1 time) previous topic - next topic


Jun 01, 2018, 12:04 pm Last Edit: Jun 16, 2019, 11:27 pm by pissten

I'm very interessted in using my arduino to read serial data from my outboards PCU/ECU device. I have got a software to interface with the pcu using excel (VB and rsapi.dll)
Unfortunatly there's no communication protocol information from the PCU manufacturer, So I will need to reverse engineer the excel communication.

Are there anyone in this forum who knows how to go about this? Does anyone know how the rsapi driver works, source code, etc??

Any help would be truly appreciated.

Best regards


IIRC rsapi.dll is a library to handle serial comms so you could maybe hack a suitable serial cable to put a RS232 to TTL converter inline and connect this to an Arduino to log the serial data being sent/received.
Or you could use a logic analyser to do the same thing.
It would help if you supplied details of what make/model of outboard your talking about and/or the ECU it uses.
Don't PM me for help as I will ignore it.


Hi Riva,

Thanks for your reply.
I've now been in contact with the author of the raspi.dll, and got alot of help..
Will be trying to connect to my Brucato PCU using a Arduino rs232/ttl converter, as you suggested.



I did not look as I prefer not to run unknown macro coded excel but are the macros password protected or can you see them?
Being able to view them will go a long way to working out the protocol.
Don't PM me for help as I will ignore it.


Hi Riva,

Been a long time since i Worked on this topic. But I finally got around doing some more testing.
I'm a newbie in arduino/coding and have way to high ambitions :D So I would truly appreciate all the help and advise I can get along the way.

In the attachments above, I have copied out some of the excel macro, into a pure *.txt file. maybe you could have a look at that?
I have hooked up a arduino uno with RS232 to TTL converter and tried to capture some serial data, but I don't receive any data unless I frequently pull out the RX-pin and replaces it. Does that mean that the ECU needs to open connection, poll data, and then close connection for each call?

I got in contact with the author of the rsapi.dll file, hoping to get some help, and here is some of what he replied:

"To comunicate to your device only a few calls are used, as I see.
The corresponding arduino routines are millis(), Serial.close, Serial.begin, Timeout might be found at arduino.cc, Serial.write, Serial.read (see reference at adruino.cc)
So, I have only utilized serial.begin(38400) and Serial.read(). I get data, but only when toggling the rx pin.

Any suggestions would be truly appreciated! :D

Best regards


There is a tool called (Free) "Serial Port Monitor".
You can install it and bridge a Serial Port, to record all the communication data between the device and the Excel solution.

With that, I expect you to send the identical commands and receive what you need.

More or less exactly what you try to archive with the TTL converter, but without additional hardware.


Jun 17, 2019, 12:53 pm Last Edit: Jun 17, 2019, 02:26 pm by Hiddenvision
There is  many FREE basic tools for communicating via serial. "Putty" is one

My approach would be to

setup a computer with putty to MONITOR the serial comms,
Use the same or another machine to connect to the ECU as normal and just connect the RX line of the putty interface to either the RX or the TX line of the ECU.

With that type of setup you should be able to simply monitor the comms traffic over the standard interface. Connecting only the (putty) Serial RX line (pin 2 on pc 9way) will simply listen.

First thing will be to determine the correct Baud rate, taking note that it could change at any point.
Some devices will connect at a low known rate and then switch up to something faster.

If you have access to a scope it is easy to figure the approx. baud rate.
Or it maybe written somewhere.!

Oh... com1:38400,n,8,1. That saves looking too hard.
However, within the DLL it is clear to see that 9600,n,8,1 and 19200,n,8,1 is also mentioned.

Once you establish what the proper Baud rate is then you can log the traffic on the TX line and do the same for the RX line.

It is possible that the ECU will not transmit any data until it receives a valid instruction thus you need to see what the original interface is saying to the ECU to make it reply.

Once you can see the data flow you could then perhaps use an Arduino to monitor and listen, even perhaps using two serial ports, connecting the RX and TX pins of the original interface to the RX pins on the Arduino ports. Some Arduinos only have one hardware serial but you can use a software serial port to give a second one. But I would say using a PC will give an easier interface while working with the unknown.

I have not mentioned it but you know that the pins on the Arduino will be TTL and the pins on the ECU sound like they are RS232. Not only are the lines at the wrong voltage but I believe they are also inverted, I forget now. So connecting to the Arduino will require TTL-232 convertor like MAX232 or similar.

Then once you have nailed what the required Baud Rate and protocol is you can then use the Arduino in place of the original interface and talk to the ECU like a pro.

There does not seem like much work needed to reverse engineer the received packets as they are clearly defined in the excel macro you show.

Hope that helps, I do this a lot so if you need any further help SHOUT.



There is  many FREE basic tools for communicating via serial. "Putty" is one

My approach would be to

setup a computer with putty to MONITOR the serial comms,
Use the same or another machine to connect to the ECU as normal and just connect the RX line of the putty interface to either the RX or the TX line of the ECU.
Putty is not able to bridge a COM-Port connection.
The COM-Port can only be accessed by one device at once, so I prefer my approach with the Serial Port Monitor.
Then, after you got the information you need, you can easily use Putty and test the commands by sending them yourself.


Yes, agreed, bridging com ports is another thing.
But USB comports are ten a penny so to add an extra port seems easy.

But I guess many ways to skin the cat so whatever you find easiest is the best approach.


Thanks alot for the replies guys! I will try some of the tips you've given me, as soon as I get some spare time :D
And @Hiddenvision, I really appreciate the offer. I'm almost positive that I'm going to SHOUT out for some more assistant :D



Since I'm not able to attach images in a PM, i'm putting them here :)



Jun 26, 2019, 07:10 pm Last Edit: Jun 26, 2019, 07:41 pm by Hiddenvision
Sent you a reply via PM but drop up picture of the underside of the max232 board.



Ahh So that clears it up a little.

Guessing with good odds, but still a guess without touching things.

So the Dots on the board Run this way

POS, (6v to ??v)

Negative is Obvious.
Pos. There is a 5v regulator so would guess the Pos will be somewhere from 6 to 12v

The data to your controller box will be on the TOPCU Dot,
The data from your controller box will go to FROMPCU Dot,

But from looking at the extra stuff on the board to the left of the max232 it seems like the 5v level from the max232, that is normally connected to the TTL input of the processor is driving a pair of transistors so that the data line voltage will be closer to the supply voltage less 1 or 2 v for the diode and other drops.
Longer distance perhaps or stronger signal in a noisy environment.
Guessing they have a reason.
This may prevent 5v ttl units from working, I wonder, you can wonder too.

If this is the reason why things are not working then just think of it as a level-shifter board you may have seen, you would need two channels, one for each serial line connecting the Arduino.

And the only bit that escapes me is the lone 4571 resistor next to the 5v reg.
Either it's inline of pin 12 of the max or perhaps joining two of the PC plug pins.

So once you get the original module working you can connect your Arduino wires to some points.
Use common grounds for ease.

Pin 11 will be ttl level data FROM the PCU on its way to the computer
Pin 12 will be ttl level data TO the PCU (From computer to the controller)
Connect 11 or 12 to serial RX on an arduino to monitor the traffic in each direction.

pin 13 will be RS232 level data of Pin 12 (From computer to the controller)
pin 14 will be RS232 level data of Pin 11 (From controller to computer)
Connect 13 or 14 to pin 2 on a 9pin serial port to monitor the traffic in each direction.

Remember that you only want to monitor the traffic first, see what the software says, see how the PCU responds.

Then you can, with luck, send the same packets to get similar responses.

No doubt going to get an edit or two for clarity.!.

Go Up