Capturing data from CAN-View

OK I want to get this thing working this year. I tried to give it another go but failed to get any results. It is my understanding that with the RAW capture mode of the can-view I should be able to get about one line of data per second after converting the RAW data to a CVS right? Well I continue to only get a few lines of data after running the test for about 30 seconds. I will give you some screen shots of my settings and give you as much detail as possible. I did figure out how to get rid of the error light flashing. I had to set the parity to even.

Here is the RAW data captured from the latest version of realtem program.

This is with the direct capture setting set with capture as hex setting set. This produced a 0k cvs file when ran with the candecoder.exe
http://stuff.jaygroh.com/priuschat/cvdc/directhex.bin

This is the direct capture setting set with capture as hex unchecked. This produced a 1k cvs file with 2 lines of data.
http://stuff.jaygroh.com/priuschat/cvdc/directnohex.bin

This is with the direct capture unchecked. This produced a 1k cvs file with 3 lines of data.
http://stuff.jaygroh.com/priuschat/cvdc/nodirect.bin


Here are some pictures of the settings I had. I will have descriptions above each picture.

What I don't have is a pic of my OS port settings under device manager. I have it set to 115200, data bits 8, Parity Even, stop bits 1, no flow control.

Here is the display screen. I have HEX set as display type. I dont think this really matters much on the capture side of things but I could be wrong.



Port set at 115200, Parity even, data bit 8, stop bit 1, flow none.


Capture screen set for direct capture. As you can see the display is displaying HEX.



Here you can see that I unchecked direct capture so I could see what it was capturing. As you can see its a bunch of garbage compared to what i was getting before without capturing.





I would like to note the receive light on realterm was flashing about once a second. From my understanding this one second burst contains one line of data when converted. Am I right on this? I have not bugged Norm in a while so I might send him this information to see what he thinks.

 

OK so I have been talking with Norm and from the looks of it I'm capturing all the data correctly except for about 4 lines of data which I let Norm know about. The canview decoder program will need to be rewritten or just updated. Thats something I can't do at the moment because its been a few years since I have programmed anything and I don't really understand whats going on in the program to make the necessary changes. I was in touch with Gary who wrote the program and he said he would be on vacation so it might be a while until this gets fixed. Unless someone else knows how to program and can make the necessary changes.

 

I have some good news now. I imported the source code of the Can Decoder into Visual Studio 2008 and only had to make a few changes to get it to process my data correctly.

First change I had to make was with message ID 0529. In the source it was listed as having 6 bytes of information. My output said it was 7. Having this set at 6 was causing the EV mode message not to be recognized and thrown out.

The next change I made was with where the packet ended. The original source said to end at message ID 0602 but since my packets don't include those last few messages I had to change it to 056D which is the last message in my packet. This is what cause the whole thing to bomb at converting my captured data. Since I had no 0602 message the program would keep looking for 0602 until it just gave up and searched for the start of a new packet. This means it skipped about 11 packets trying to search for the 0602 message. I will be testing if my V4 Can-View can use the V4+ code to see if I can get those extra messages back.

[edit]
My V4 Can-View is missing the following messages.
057F - Lights - could be useful information
05A4 - Gas Gauge - Could be really useful if used to compare MPG Vs how much gas is in the tank over a whole tank worth of driving.
05B6 - Doors - Could be useful if you need to measure MPG you get with the doors open at 55mph.
05C8 - Cruse - Could be very useful if you want to compare MPG with and without cruse control.

Norm said it could be my serial buffer but I think its the Can-View because I tried capturing from my in car PC and my laptop and both are missing the same messages. In fact the packets captured are exactly the same.

The next thing I had to change was the rounding of the speed and temperature information when converted from metric to US. I had to remove it because it required the use of lround and Visual Studio does not include that option in the math operator thing or what ever you call it. It should be in an #include <math.h> I think but VS does not include the lround in that. Its been about 5 years since I have even touched C++ so my knowledge is lacking. Since I don't know that much about programming I could not find a replacement for the round command. I know there is one but just don't remember and cant find it at the moment. So I just modified it to give the whole number plus the decimal place. This will work for now as I do not need my US speed and temp rounded at the moment.

I'm sure I may have broken something in the code so I will be doing some more testing before I release the modified executable and source. Unless of course someone that knows how to program wants to clean up my mess.

 

I just found a round.h file to include in the source. I ran a few tests with the data I captured today and the US speed and temperatures are rounding up like they should. I have a few more tests to do with the different switches and when I get that done and I'm satisfied with how much I mess up the code I will release the program with the source. I think I will create my own thread so I can keep track of of the changes. I think this code will have to be modified for different versions of the can-view and can-view software. When I get samples of bin files from a few people I will know if changes will be needed.

 

I was about to PM you, but since I'm here now .... My laptop battery was low last night and I didn't have my in-car inverter with me. I'll try again this evening to get you a BIN file.

 

Made a new topic for my modified software.

http://priuschat.com/forums/audio-e...-raw-serial-output-something-more-useful.html