rsapi.dll with Excel VB, replace with arduino??

Hi,

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
Chris

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.

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.

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 :smiley: 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.
TIMEREAD, CLOSECOM, OPENCOM, TIMEOUT, SENDBYTE, READBYTE

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! :smiley:

Best regards
Christian

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.

Hi,
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.

Hv.

Hiddenvision:
Hi,
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 :smiley:
And @Hiddenvision, I really appreciate the offer. I'm almost positive that I'm going to SHOUT out for some more assistant :smiley:

Sent you a reply via PM but drop up picture of the underside of the max232 board.

Fig-4-MAX232-RS232-level-converter.png

Ahh So that clears it up a little.

REMEMBER I AM GUESSING AT MOST OF THIS>!
Guessing with good odds, but still a guess without touching things.

So the Dots on the board Run this way
RS-232
Module

NEG,
POS, (6v to ??v)
TOPCU,
FROMPCU.

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.!.

I still do not understand why to make this so complicated ::slight_smile:

You want to see what is exchanged between the Excel-Script and the Device.

  • Via hardware-hack (Like you are doing it).
  • Just install a piece of software, which can record the datastream in between.

Hey Trib,

100% agree, there is software to monitor the ports and would be the easiest option.

But I think there is also some hardware confusion as the original interface I believe has stopped working.

I was mostly trying to explain that part and also giving some options where to tag on if you wanted to listen to the traffic.

Also I suspect that the TTL levels (voltage) used into the PCU module are raised a little.
That may give issues when trying to use a normal TTL device that would normally rest at 5v.

Using a level shifter (eBay 142603531109) should limit and tolerate the possible higher voltage.
Presume you know where to stick it. (inline of the RX and TX wires for the Arduino or USB-TTL)
That ebay number was just the first in a search for "Level shifter", it was not a recommendation or suggestion, I simply looked at the picture. It is just one of thousands available from many global sellers at different prices. I also now see that most are sold as 3.3v - 5v. But I have a feeling you could use it slightly further up the range with 5v being the LV side.
Or if it comes to it then just mimic their circuit on the max board.

As always, it is worth remembering I have not touched this stuff so my guesswork may be way off, so always be prepared to adapt for your current environment.

Wow, you really know some things or two about electronics :smiley:
That's great, because I'm a newbie and fumbling a little in the dark here :wink:

I can confirm that the voltage level from PCU is a little higher than 5v. I measured 7.3V on pin 8, and I also saw 8v on rx or tx pin to gnd.
The pinout on the dongle adaptor is like this:

Pin 2 : rx or tx (green)
Pin 3: tx or rx (yellow)
Pin 5: gnd (black)
Pin 8: 7.3V pos (red)

Does it look like I've soldered the wires to the right connections on the PCB?

And for my confusion regarding the rs232 and ttl voltage levels:

Would the typical prolific usb to rs232 adaptor, still operate at serial voltage levels -13/+13v?
And the PCU/ecu side would be the TTL-side with RX/TX voltage levels at same voltage level as VCC(pin8)?
Also read that serial comm operates different from ttl, as it uses logic high at negative voltage levels, and logic low at positive voltage levels. But the Rs232 to ttl converter (max232) handles all that right?

I'm currently in contact with the ECU manufacturer , and hoping to get a new communication dongle. That way I will most likly get a connection to the PCU, and start monitoring the traffic with a serial monitor.
My current soldering job on this dongle, doesn't seem to work :confused: heh

Hiddenvision:
Ahh So that clears it up a little.

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.

When you talk about the pins above, do you refer to the connectors on the max232 chip, or the rs232 db9 pins?

Sorry for my newbie-ness :smiley:
Thank you so much for helping med out!

No believe me I fumble my way thru most things, nothing wrong with it.
"Knowing" is way too overrated... And you learn far more than just getting the correct answer first.!

Those pin numbers mostly talk about the Max232 chip.
Apart from where I say pin 2 on a 9way.

On a 9 way RS232 connection
Pin 2 is the data into PC
Pin 3 is data out to device

The only reason why the interface may not work is RX and TX being reversed, the MAX232 chip popped or one of those other doofers on there is broke.

I would normally say, it won't harm to try (switching Rx & Tx), but obviously take any perceived risks you can deal with.

To test the interface just open a terminal program.
You would prefer not to have the PCU connected during the echo tests so either
apply some power (5-8v) to the red/black leads or unsoldier the Rx & Tx wires .

Without Max board connected
Test1: Short out pins 2 and 3 on the serial socket, type something into the terminal and see the echo.

Plug in the max board
Test2: Short out pins 13 & 14 on the max. type and see echo.?
Test3: Short 11 & 12 to test the TTL side of things, ECHO.??
Depending how that went you could test the level switching part by
Test4: Shorting Rx & TX dots and trying the echo test once more.

Re the Prolific USB to 232. It is the Max chip that generates the boosted voltage all based on the series of caps you see. Some devices get to +13v -13v but it is not so strict. Even some laptops struggle to reach 8 or 9v+-. And you strictly do not need negative volts the PC will be happy to see data bounce between 0 and 5v. in the old days before serial was built in you would bitbang the stuff in and out without needing max232, just a couple of resistors and you invert the logic levels or ones and zeros. But yes the Max232's or simular do all that for you.

Also not 100% if the 5v TTL levels are flexible by altering the input volts. Do they make 3.3v devices or just run them at lower volts.? A quick read of the datasheet will give that game away. Well the answer is NO 6v is the upper limit so it is just a 5v or lower device.
That's where a suitable level-shifter steps in.

If by purchase a new dongle, are you talking about the Max232 board.
You would not want to be spending hundreds on such a thing.
They are dollar and cents parts.

Hi Hiddenvision,

I've been able to establish communication to the PCU, using a arduino uno as usb to ttl converter.
With the help of free serial monitoring tool, I've recorded some data received from the PCU.
I read from the Excel macro that the SENDBYTE's that was used were, (37) (77) and (114).
In the log file you'll see the data received for each of these trigger strings.

I feel that I can recognize the data received when sending (77) and (114),
but the data I'm most interessted in, I'm not able to make sense of. If I send (37) to the PCU I should
receive Real-Time Data, like RPM and battery voltage etc.. This Is what I receive in ASCII data:

.....,...,.ë.,...,.·þ,.E.,...,...,...,Ë..,Ë..,Ë..,½..,½..,Ç..,È..,È..,...,...,...,..., ..,.Ò.,...,...,

Hi C,

Great news on getting the communications going.
I had a quick read of the vbs macro code in the xls file.
I knew there was more than the macro original text file you posted.

Two ways to go from here.
Either write a bit of Arduino code to emulate the PCU actions.
Something simple to spit out the various response strings to the requests.
That way it will be easy to interact with the software on the bench rather than the boat.
In doing that you will also fully understand how the packets are constructed.

You may also perhaps take the really lazy but challenging task of converting the VB into Arduino/C.

From what I read there is 25 data packets for the (37) request.
Each packet is 4 bytes long mostly.

Are you getting back about 100 bytes.??
If so then they may just need converting to a value.
See the Sub GetValue(valul) or Sub Getnumber(parf1, parf2, parf3, vax)

But that would be my 1st approach, get an Arduino responding to the original software as if it were the PCU. then you can edit the response data packets and see if the results make sense on the proper software.

You will then also have an invaluable simulator tool.

With the original Max232,
Just check if the 5v regulator is still working.
Then try those loopback tests, if testing the TTL loopback fails and it has 5v then the max has failed.
Simple to replace.
It is a handy Max driver as it drives the line volts up a little but in reality none of that may matter.

Looking at the log I got a bit confused as to what was the response to what.

Oh you need to also perhaps view some of the data in hex rather than character.
You will need to know the values of the 4 byte blocks to check the math.

So the same in Hex would be like

SENDBYTE (37) = "
53 45 4E 44 42 59 54 45 20 28 33 37 29 20 3D 20 22


2E2E2E2E
2E2C2E2E
2E2C2EC3
AB2E2C2E
2E2E2C2E
C2B7C3BE
2C2E452E
2C2E2E2E
2C2E2E2E
2C2E2E2E
2CC38B2E
2E2CC38B
2E2E2CC3
8B2E2E2C
C2BD2E2E
2CC2BD2E
2E2CC387
2E2E2CC3
882E2E2C
C3882E2E
2C2E2E2E
2C2E2E2E
2C2E2E2E
2C2E2E2E
2C0D0A2E
2E2C2EC3
922E2C2E
2E2E2C2E
2E2E2C22

0D0A0D0A

There is more than 25 x 4 byte blocks.

I am sure you can set breakpoints in the macros and check data in real time following the calculations thru to the final result.

I will give it a try tomorrow :slight_smile: Although I've tried several sketches to receive data from PCU to arduino, without success. I've never really tried what you suggested, to make arduino emulate the pcu.

Do you have a *.ino file that would fit the task? Parsing the data packets to each variable etc.. (rpm, bvolt, map, )

Thanks
Christian