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

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

Hiddenvision:
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 put the response inside " "

It should be possible to cross-reference the data between the excel macro and the data packets in the log file. But I can't seem to make any usable of the response from the "Real-Time data" (SENDBYTE 37)

The Calibration Sheet in the Excel macro (SENDBYTE 77), will give all the values from the chart in a ASCII response though. Just copy the response from my log into a online ASCII to DEC converter and you will see that most values can be cross-referances to the Calibration sheet.

Hi C,
Looking at the Macro Sub ReadData(icou)

You will see that it first waits for a sync word of 2217
It will try 4 attempts from first peek.

then after that was received it scoots off to Flag3: and reads in those 25 sets of 4bytes.'

Sub ReadData(icou)
     Ltries = 0
Flag1:
     parms1 = READBYTE                    ' sync byte1 is 22
     Ltries = Ltries + 1
     If Ltries > 4 Then icou = 31567: GoTo Flag8
     If parms1 = 22 Then GoTo Flag2
     GoTo Flag1

Flag2:
    Ltries = 0
    parms2 = READBYTE                    '  sync byte is 17
    Ltries = Ltries + 1
    If Ltries > 4 Then icou = 21345: GoTo Flag8
    If parms2 = 17 Then GoTo Flag3
    GoTo Flag1
    
Flag3:
    Call GetValue(RPM)                                        ' field 1

    Call GetValue(ExhTemp)                                    ' field 2
    ExhTemp = ExhTemp * 2

    Call GetValue(Map)                                        ' field 3
    If Map < 0 Then Map = 65536 + Map

    Call GetValue(engtemp)                                    ' field 4

    Call GetValue(Bv3)                                        ' field 5
    Bvolt = Bvolt * 0.95 + Bv3 / 20
    
    Call GetValue(AirTemp)                                    ' field 6

    Call GetValue(Time1)                                      ' field 7
    Time1 = (Time1 / 1000.002)

    Call GetValue(Time2)                                      ' field 8
    Time2 = (Time2 / 1000.003)

    Call GetValue(Time3)                                      ' field 9
    Time3 = Time3 / 1000

    Call RFu(Fuel)                                            ' field 10
    Fuel = Fuel - 1

    Call RFu(Fuel2)                                           ' field 11

    Call RFu(Fuel3)                                           ' field 12

    Call RFu(FuelM)                                           ' field 13

    Call RFu(FuelA)                                           ' field 14

    Call RFu(FuelB)                                           ' field 15

    Call RFu(FuelC)                                           ' field 16

    Call RFu(FuelD)                                           ' field 17

    Call GetValue(PumpPower)                                  ' field 18
    PumpPower = PumpPower / 10

    Call GetValue(pump_current)                               ' field 19

    Call GetValue(Time20)                                     ' field 20

    Call GetValue(SteamWheel)                                 ' field 21

    Call GetValue(TimeSec)                                    ' field 22
    If TimeSec < 0 Then TimeSec = TimeSec + 65536

    Call GetValue(ProgramVersion)                             ' field 23

    Call GetValue(opMode)                                     ' field 24

    Call GetValue(PrimerSwitch)                               ' field 25
    
  '  end of data stream -----------------------------------------------

I did not see that 2217 sync word in the captured data.

It will be simple to provide the basics to start an emulator.
opencom, listen for bytes and send out the required data that the program is expecting.

I will wrap something up as a starting point.
But it will need on hand editing once you start to work out what is what, so best you do most of it.

Let me download the rsapi file then I can run it

Ok So this interacts with the software.
Just to note that rsapi seems to ignore bytes that are 0.

Terrible looking code example but it works.!
I needed to edit the macros a little to add a Delay(1500) when the comport is opened.
Remember the Arduino normally resets when the port is opened.
That reset may make it miss any SENDBYTE(X) that happen just after the port opens.

SEE LATER POSTS FOR LATEST FILE.

Hiddenvision:
Ok So this interacts with the software.
Just to note that rsapi seems to ignore bytes that are 0.

Terrible looking code example but it works.!
I needed to edit the macros a little to add a Delay(1500) when the comport is opened.
Remember the Arduino normally resets when the port is opened.
That reset may make it miss any SENDBYTE(X) that happen just after the port opens.

Hi H

THIS IS JUST AWESOME! :smiley:
If this code is terrible looking, that just tells me how bad I am with arduino coding. Because this looks really good to me! :smiley:

I also did the changes in the macro as you suggested, I and communication between Arduino and Excel seems to work! :slight_smile:

I can't thank you enough!
Now the testin begins :smiley:

Thanks
Christian

No Worries C,

Actually that first version was full of holes.
This one is a little better.

This pretty much simulates some parts of the softwares needs.
Remember that "OPENCOM" may actually restart an Arduino so if you get no or slow response you may want to add the line DELAY(1500) after any OPENCOM, not the best but it wont harm.

I was trying all sorts of things so the code may look messier but with luck it will point you in directions you never thought possible or worthwhile. Using some pots or switches you can start to simulate some of the controls/messages and visualise it on the regular software.

How you structure things or what variable types you use is not something I can directly advise on.
It's a personal thing I guess, there is always many ways to skin a cat but some ways can be conventionally or programmatically better. I know little about all 3.

Anyway, this one should replace the previous PCU_emulator.ino.

I have edited the XLS(vbs) stuff a little but have not included the file as I do not want to break how it works on your real device. If you find the Arduino is not responding shout I can send this edited xls file..

SEE LATER POSTS FOR LATEST FILE.

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.

SEE LATER POSTS FOR LATEST FILES.

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.

SEE LATER POSTS FOR LATEST FILES.

Hi H,

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

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 :confused:

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? :confused:

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 :confused: 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
Christian

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.

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.

SEE LATER POSTS FOR LATEST FILES.

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

SEE LATER POSTS FOR LATEST FILES

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

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.

Hi H,

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

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 mySerial(2, 3); // RX, TX
byte serial_number[] {'1','2','3','4','5',' '};

void setup() {
// initialize both serial ports:
Serial.begin(38400);
mySerial.begin(38400);

}

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
Chris

Hey C,

Umm,
I've been chasing my tail a little trying to get a second Arduino to respond.
Ahh, I see I was sending 144 not 114 for serial number request in the ino file.
I guess that was the next stepping stone hey !

Silly me,
Meanwhile I added some bits to set the line levels.
I think setting the softRX line with the INPUT_PULLUP helped when I disconnect the line.

You can use the same project to program the second Arduino.
Just uncomment the SWAPCOM define.

As before, on any serial number requests it will try to communicate with the actual PCU via the softserial pins. If it gets a positive response then the first 6 bytes are saved to EE and will be displayed in the Excel sheets. If it fails to get a response (due to timeout) it will write the number 6 to the first byte.

Seems a simple way to verify a connection while keeping everything else working as it was.

Just four wires between the two Arduinos.

Vin - Vin, (5v)
Gnd - Gnd,
10 - 11,
11 - 10.

I see you were selecting 2 and 3 for the softserial.
Not 100% sure but the notes mentioned that the RX had to be on one of the mentioned pins.

Anyway, just side tracked so will tidy things and paste an update later.

I found your 'little' boat event with the help of google magic.
I used to live on the Bridge to Bridge course in Australia.
Crazy people in super fast boats quite often dragging a water skier behind them.
I forget the distance now, Ahh 112kms.

Try these for size.

Connect your spare Arduino to be used as the boat simulator
Just uncomment the SWAPCOM and newarduino defines and program the boat simulator.
Then re-comment newarduino and program the same device again.
All done that unit should now respond to serial on pins 10 & 11

Connect the original Arduino you were playing with,
Now comment out SWAPCOM and program.
If you needed to default the EE to something known then uncomment the newarduino as before, program, let it run and then comment and program again.

If you read thru you will see that when the PC requests the serial number then the running code will send the request byte 114 out the softserial. If the second Arduino or the actual PCU responds then the received number is saved in EE, if not response then the first digit is replaced with a "-".

I have added a little extra code to the Macros to WRITE the serial number on the connected ARDUINO.
I have NO IDEA what this will do to a normal PCU so please do not use the edited macro on any real equipment or comment out the section of excel code in the WRITE_ECU function.

Also remember that if the Arduino gets a valid response from the softserial then the serial number will be replaced. Disconnect a softseral wire to witness the SerialNumber change.

SEE LATER POSTS FOR LATEST FILES
This file is kept as a milestone pre multiple edits.

Just some edits.
REMEMBER TO KEEP YOUR ORIGINAL Excel file.
I cannot confirm if the edits made to the Macros will be transparent to what your PCU is expecting.

PCU_Emulator.zip (7.68 KB)

Ahh some extra edits required.
A few variables not declared in the serial Number writing function.

REMEMBER TO KEEP YOUR ORIGINAL Excel file.
I cannot confirm if the edits made to the Macros will be transparent to what your PCU is expecting.

Excel Macros deleted by request.