Go Down

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


Jul 06, 2019, 08:02 pm Last Edit: Jul 08, 2019, 08:37 pm by Hiddenvision
Hi C,

Last edit for now,
I also include the renamed xls sheet.
the XLS is mostly the same but with a few edits and a bit of formatting

In this Ino I edit the RPM and opmode so you can see them change on the screen.
RPM increments per packet requested,
opmode increments once every 100 packets.

I was going to simply use the EE as a place to store the data.
Some of the replies are got from the EE, so you can see the various efforts working.
But the address's it sends out on progword or progbyte is not easy to use instantly. I had a go but it was not right.
The programming feature is responding correctly though not actually saving the received data.

To find how each number is stored, encoded and presented you will need to step thru the vbs code.
RPM for example 4 bytes {x1,x2,x3,x4}
x1x2 =  16 bit value
x3 = multiplier
x4 unused mostly

As I think you mentioned the Pot values are simply in Text from 99 to -99 with a comma at the start.

Oh with the XLS sheet,
I added a central opencom function.
Just easier to set the port details and tweek that delay if needed,
ALL the original OPENCOM's now call the "openthecoms" sub.
I mention that cos I had it set to com3, you may need to change that.



Jul 08, 2019, 08:32 pm Last Edit: Jul 09, 2019, 07:33 pm by Hiddenvision
Trying to upload another version but it is failing.
Urgh, something to do with the ino file.
So I zipped it.

Nothing much has changed, a few edits to make it read better perhaps.



Hi H,

I am so incredibly impressed with your work! Seems that you have figured out the entire VBA? :O

The only thing that is not read correctly on my computer, is the Serial Number, which seems to expect 7 bytes and not a string. I can see that the serial number is spit out as a whole number from the PCU, but I can't find any calculations in the macro for it? When editing the PCU emulator.ino to print a string the Calibration Sheet stops with a VBA error message :/

And the program version is not registered in the calbration sheet, but only in the Real Time Display sheet. So It parses the data in different ways on each seperate sheet? :/

Since you have figured out how the data is expected to be received in the excel macro, would you already know how to parse the data directly from the PCU?

I thought that I had sent you a PM, but I can't seems to find it as a sent message. So It may never been sent :/ just wanted to tell you that I would like to make a donation for your time and help! Do you use paypal?

I'm just so greatfull, because this is such a important mission for me, but don't have enough skills to poll it off by my self.

Best regards


Hi C,
You did send a PM but I can't access them on this browser.
I saw your offer but that is fine. I thank you for the offer though.

Yes the VB stuff is my native language, easy to follow what is happening there.
Terrible code, if I were to comment, but hey it works for them so even terrible code is worthwhile.

Oh Re some numbers not showing,
Un-comment the  Write_EEDATA(); bit in the setup for the first run on a new device.
Just program, let it run and re-comment the line again compile and program
The empty eeprom will throw up some errors in the xls due to the default 255 of the received data.
make sure to comment it back out after to save on reset time.

Most of the formatting of the numbers is pretty clear.
RPM, BVolts and those similar fields all use the 4 byte packets.
First two bytes is just a 16bit value, the third byte is used as a multiplier or divisor.
The fourth byte is collected but appears unused in the Macros.
Then sometimes the value is manipulated to present a final value on screen.

There was a couple of SET functions in the Ino code showing a blunt method of creating the packets from regular numbers.

Parsing the data directly from the PCU should be easy, you just have to get to know the values and reference the VB stuff to see any formulas.
but very simple as long as the Arduino does not take too long to do any calculations
I will have a breeze thru later and see if anything is tricky.

So Onwards....
It would not take a moment to spin up some new code to just
open a "soft serial" port on the Arduino and spit out a 144 request
You should then get the serial number back each time.
If you have used a softserial port (and it works) you can simply echo debug stuff back to the terminal via the normal serial.print.

If you find that the PCU is still not responding to the Arduino code then it could be that Higher voltage on the max232 thing biting you. We can go there when/if you have the problem.

In theory you should be able to hook the PCU wires to the pins of the Arduino/Atmel chip.
They are both serial at TTL logic but with different voltage.

I would use a level shifter to comfort the HIGH VOLTS you see on the lines, that is what the bits on that original Max232 board are doing. Or you could jig it with some resistors to protect the Arduino a little.

The little level converter boards on ebay are so cheep it is worth trying one of those first.
Or get that original dongle/max232 board working again and you could simply drive that with another max232 connected to the Arduino softserial pins.

Once you have the PCU responding to the Arduino code then simply expand it to be a bridge for any serial traffic to and FROM the PC/xls sheet.

Listening for data from the PC and echo it to the PCU
Listen for data from the PCU and echo it to the PC
Doing that you can intercept and decode/encode any of the data passing thru.
still using the XLS as the method of testing if your decoding of the numbers match.

Once that is nailed you're set.!!

What are you doing with the data you read from the PCU,?
are you putting it on a display or transmitting it somewhere else.?
You may have already mentioned that.! I'll check.


Jul 09, 2019, 07:31 pm Last Edit: Jul 11, 2019, 01:32 pm by Hiddenvision
So time for another edit.??

I added in some softserial bits to use pins 10 and 11
I also added a timeout for nodata  reception on the softserial port.
You may need to adjust that for real world use.

the idea is that it will open the port, send out a request for serial number and if it gets one it will write the first 6 bytes received to the EEProm.
then it will do everything it was doing before but using the new serial number received.

Obviously I do not have a PCU to test but I guess I could just program another Arduino to pretend to be one to see if it actually works.

Let me add those files.



Oh there you go,
I read a bit more and figure the addressing offset.
Now the Write function actually works.


Thanks again for the great job done.

I tried to hook up another arduino as PCU emulator on the softserial pins, put I don't seem to get this properly working. I get unknown in response on the serial number request.

And for your last post, what write functions were you referencing?

I've been a little busy the last couple of days, using my boat in a local fjordrace etc.. So haven't been able to hook the PCU up to the arduino yet. just tried like you suggested, to use another arduino to emulate.

Just to clearify the end goal with this "project", it's my wish/dream to poll live RPM and Battery voltage from the PCU and use it with my Android Gauge app. It will be a nice comlpement to the existing gauges already implemented.

As for the fuel curve data, I'm now also very eager to visualize it in the app as well :D

Thanks for all your great work so far, I'm so incredably thankfull!


Hi C,
No worries on being busy "playing" with the boat.
That is after all what they are for, No?
Guessing Norway, TVEDESTRAND

The Write function was in the Excel prog.

The Emulator code now reads and writes the data from the EE so that you can edit the curves, program, and the changes are saved and should verify. Not claiming it is perfect, but it seems to work for the experiment.

I have not tried the softserial at all myself, not even programmed up another Arduino to test.
Sort of threw it in last moment but it felt working ish.!!
I shall program one later and see what happens.

Right so the end idea is to spit the displayable data out to something else.
Pretty easy on face value, just plain old serial, Bluetooth or WiFi.??

I would be tempted to make all this using a wifi module.(esp8266 for example)
Not strictly Arduino, but it seems fully supported in the IDE and would handle doing this task on it's head giving you an accessible interface that you can view/edit on a browser or extract data into existing gauge apps perhaps.

A positive stepping stone will be getting the Adruino to talk to the PCU.
I still wonder if it is going to need that line driver stuff on the comms or if it will be comfortable resting at 5v and not the reported 8 ish V.

Remember you have several options on how you connect the Arduino to the PCU.
1: Using a level shifter board on the two data lines.
2: Fitting a Max232 chip on the Arduino soft serial port and driving the original PCU Max board from that.
3: Direct connection perhaps with some resistors and other trickery to tolerate the voltage differences.

But just be cautious of hooking those 8v data lines direct to Arduino pins.


Jul 17, 2019, 08:37 pm Last Edit: Jul 17, 2019, 10:27 pm by pissten
Hi H,

That's correct. I'll have to use the boat also, not just interact with it over serial ;)

You're correct about the location of the Fjordrace, I live here and for me it's like the biggest event of the year..hehe
How have you heard of this "little" local event?

I can verify that the write function now works flawlessly:D That's awseome!!

I've been trying to set up a second arduino to try to spit out the serial number on request from the PCU emulator. But haven't had any luck so far..

Would this be the proper code for it?:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3); // RX, TX
byte serial_number[]  {'2','1','0','8','4',' '};

void setup() {
  // initialize both serial ports:


 void loop() {
  // read from port 1, send to port 0:
  if (mySerial.available()) {
    int inByte = mySerial.read();
    //Serial.write(serial_number, 7);
  // read from port 0, send to port 1:
  if (Serial.available()) {
    int inByte = Serial.read();
    mySerial.write(serial_number, 7);

best regards

Go Up