Go Down

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

pissten

Jun 01, 2018, 12:04 pm Last Edit: Jul 28, 2019, 03:22 pm by pissten
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

Riva

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.

Riva

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.

pissten

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

Best regards
Christian

TriB

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.

Hiddenvision

#5
Jun 17, 2019, 12:53 pm Last Edit: Jun 17, 2019, 02:26 pm by 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.

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.

TriB

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.

Hiddenvision

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.


pissten

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

Hiddenvision

#9
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.



Hiddenvision

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

TriB

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

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.

Hiddenvision

#12
Jun 27, 2019, 03:11 pm Last Edit: Jun 27, 2019, 03:43 pm by Hiddenvision
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.


pissten

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

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 :/ heh

pissten

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 :D
Thank you so much for helping med out!

Go Up