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.