Reprise du message précédent :
Welcome Lio!
 
The more people we get, the more we will find out..
 
I got a puppy last week so there hasn't been so much time for the computer or CDC project. I tries to follow the thread.  
 
The CDC will probably be the key to how the PIC should react on the VAN. I'll try to implement the behaviour in the code as fast as possible when we have the logs.
 
/Per

Hello!
 
Which must I send the files?
 
lio

 Hi everyone,
 
  with all those fancy devices, like the Mac Mini, the iPod
 or the new palmOne LifeDrive, is very likely that everyone
 may want to connect a different device to the VAN bus.
 
  I suggest to write our code as an interrupt-driven
 framework, which handles the VAN comms, and an "user-space"
 program which does the rest.
 
  The VAN code would be written in assembly, while
 the user-space could benefit from other high level languages.
 
  I've posted my thoughts here: http://rt3wiki.free.fr/pmwiki.php?n=VAN.Framework
 let me know what do you think.
 
--
 
 - alex.
 
 

 
I was actually thinking about something similar with the PC application under windows.
 
This application will parse the packets and handles plugins that will process the decoded packet.
Here is a screen capture of what I've done so far:

 
I'm currently working on the skin file format first.
Basicaly, the application will wait for packets coming through the com port and dispatch the decoded packet to the plugins interested by this packet.
Of course, it will be possible to write generic plugins that will request all unknown packets (says for logs etc...)
 
 
Fariouche.

fariouche a écrit :   I was actually thinking about something similar with the PC application under windows.   This application will parse the packets and handles plugins that will process the decoded packet. Here is a screen capture of what I've done so far:

 
 Wow! nice shot!
 
 please upload a beta as soon as possible
 
 did you manage to decode all the engine status bits? There are
 a couple in your screenshot which I haven't yet managed
 to decode.

Well, I Hope that a beta will be available soon
 
I didn't decoded all the bits.... this is included in the skin file for future
 
Fariouche

 I've got the cd changer but it seems
 my BSI doesn't recognize it.. maybe
 the BSI has not seen a CDC after it has
 been activated and automatically deactivated it.
 
 This could also be the reason for those missing
 packets..
 
 I'll try to go to my dealer in the next few days..
 
--
 
 - alex.

 
 
Hum... that's strange...
I hope that PSA did not implemented such a stupid feature!
Maybe there is some kind of security on the CDC as in the HU?...
I will activate the CDC on the BSI this friday, and I hope that it will be sufficient...
 
Fariouche

 
 No, it has not. The cdc was still enable but it doesn't
 work. It's a Clarion DC628/206 which was mounted
 on a 206 XT 1999 which probably is not compatbile  
 with my 206cc 2004 .
 
 Internally it show some pcb tracks clearly
 marked VAN and VAN/ .
 
 I'll try to snoop the bus anyway...
 
--
 
 - alex.
 

Hi,
 
I've just get back my car...
 
Well, now my clim is working (it was just a error flag to clear I think)
Just in time (it's really hot here today! )
 
They did not activated my CDC in the BSI because PPS needs both the HU and the CDC to activate it (something related to security check by the CDC I think)
They will activate it as soon  as they have a CDC+cables. This is just to lure PPS. This HU and the CDC are pretty well securised... pfff but who in hell will be interrested in robbing the stock HU???
 
Also, to confirm : We are still unable to activate the CDC input?
 
Anyone have a Bortesi device here?? Will be really nice to see how it operates!
 
 
Fariouche

Hi all,
 
Good new. I've completed a beta of my software.
This windows application includes plugins that help debugging and decoding VAN packets (at least this is what a think )
 
You can download it here:
http://fafou.ben.free.fr/van/Van_main.html
 
I did not had time to test it very well. Please let me know of any problem.
All the instructions are provided on the link above.
 
During my capture session (to test this application) I've found some thinks:
1- Van_Monitor send me corrupted packets (I think that it's sending wrong packets only when there is too many packet on the VAN network! (there is missing bytes))
2- I've found 7 new addresses!! (8D4, 200, F00, 504, 554,4C5 and EEE??? (the last one is probably a bug... the packet was EEE W-- EEEEEEE ??? weird))
3- The total time of the CD is located on the 2 bytes following track count (min:sec, in BCD)
 
I'm getting 8D4 packets when I power off or power on the HU. (but that's not the only solution to have this packet)
 
Power off:
8D4 WA- 1110 A
 
Power On:
8D4 WA- 11D0 A
564 RA- 850000000000000000001800001B0000FFFF0000FFFFFFFF014D85 A
8D4 WA- 1201 A
 
8D4 is very strange : Sometime it's shorter:
8D4 WA- D3 A
 
F00 only shows up after I'm ready to start the engine:
F00 W-- 000001 -
F00 W-- 000001 -
F00 W-- 000001 -
 
It stops when the engine is running.
 
It stops after some time if I switch of the key...
 
Hope this help.
 
Fariouche
 

Hi
 
Nice with some new software!
 
I think it is a bug in the van-mon software when too much data is transmittet on the VAN. There is just RAM memory for three packets at a time before they are converted to ascii and sent via RS232. A packet can be overwritten if there are no empty buffers when a new packet is received. The solution is to activate the filters ("-" or "+" commands) to remove, for uninterested packets with address 0xE24 (car serial) so they doesn't use up bandwith on the RS232.  
 
Both addresses 0x8D4 and 0x554 are described on the RT3 Wiki. Not 100% but a lot information about these packets are known. 0x8D4 is the command port for the radio and 0x554 contains RDS/frequency/CD information read from the radio by the display.  
 
0xF00 can be a new port. I don't remember if I've seen it in my logs. All known addresses/IDEN:s so far has been even numbers where bits 0/1 has been zero (xx0/xx4/xx8/xxC).  
 
/Per

Arf... actually for 554 is not a new packets (I've already included the decoding of this packet in my software ). For 8D4, I've based my decoder on ParseableCommands witch does not include 8D4
 

Ok, that explain why some packets a malformed... In that case, maybe some of the new addresses are not real
Maybe you should add a flag for the buffer when still not sent? If there is a new van packet and no buffer is free, you trow the new packet?

Hey! You're right! I've never figured it out...
 
How high the baudrate can go relliably on this PIC?
 
Fariouche
 

I've thought about using a flag if all buffers are full but there aren't so much free time in the interrupt routine to select to save/ignore data in the current packet. I need to read all bytes in all packets to stay in sync with the VAN bus.  
 
The maximum working speed for the RS232 port in combination with the PIC is 115200. My USB serial port shall handle speeds up to 460 800 baud but it doesn't work together with the PIC and hyperterminal. This combination should handle atleast 230400 baud. There are only unrecognizable characters.
 
Alex, any success with the cdc?
 
/Per
 
 

 
OK, I see...
I just checked the PIC datasheet, and baudrate error is too high above 230400 I think.
Be warnned that most of the USB serial adapters uses 'low speed' RS232 converters (but the USB chip is able to handle high baudrate). Mine use a 'ADM213 EARS' witch is certified to run at 230400 bauds.
 
Also, I've just finished to modify the VAN_Monitor source to send data in raw hexa. This will divide by 2 the RS232 bandwidh. It seems to work.
I've just changed the _WriteDecByte function.  
Using my application, it's now possible for Van_mon to send data in hexa (And it simply the parser a lot in my code! )
I will keep you informed.
 
Fariouche

 Hi,
 
   no success with my CDC. It seems is the version for pre 2000
 cars, so it will not work with my head unit. It has VAN
 tracks on the pcb.. so it must be VAN...
 
  Anyway, I'll be at a 206cc meeting this weekend and
 maybe I will be able to find someone with a CDC and sniff the bus..
 
--
 
  - alex.

Piffo,
 
I've read the PIC code.Tell me if I understood.
 
The PIC have 3 buffer for storeing VAN packets. They are selected in turn.
The PIC select a buffer, and begins to store VAN bytes.
Once the VAN packet is totally stored, you set a size so that the RS232 Transmit function knows that this buffer can be transmitted.
 
The UART Function select a buffer that have VAN bytes and begins to transmit them.
 
Is it like that?
 
I'm still trying to find a solution for the data corruption.
I have this problem if one big packet is being transmitted and then two small packets are read on the VAN bus! Especially the "XXX RAT -" packets.
 
I think that I have a solution.
We must add two variables.
One is VAN_In_process that is one when we found a VAN_start and not finished reading the packet.
The second variable will be free_buffers and will hold the number of free VAN buffer.
 
So, For the VAN reader.
 
if there is no free buffer (free_buffers is zero), then we exit
else
   If we have a VAN_start then
      we set the Van_In_process flag
   else if Van_In_process flag is set then,
     store the bytes in the selected buffer
   else if end of packet
     if Van_In_process flag is set then decrement free_buffers and reset Van_In_process flag
 
 
This should do the think. But I do not know if this will fit
What do you think?
 
By the way, I've also tryed 230800 baud without any success like you
 
Brouno, what is your status?
 
Oh! I forgot : I will maybe buy a bortesi adapter to see how they are emulating the CDC ... it's only about 75€ from what I've read somewhere...
 
Fariouche

fariouche a écrit :   Piffo,   I've read the PIC code.Tell me if I understood.   The PIC have 3 buffer for storeing VAN packets. They are selected in turn. The PIC select a buffer, and begins to store VAN bytes. Once the VAN packet is totally stored, you set a size so that the RS232 Transmit function knows that this buffer can be transmitted.   The UART Function select a buffer that have VAN bytes and begins to transmit them.   Is it like that?   I'm still trying to find a solution for the data corruption. I have this problem if one big packet is being transmitted and then two small packets are read on the VAN bus! Especially the "XXX RAT -" packets.   I think that I have a solution. We must add two variables. One is VAN_In_process that is one when we found a VAN_start and not finished reading the packet. The second variable will be free_buffers and will hold the number of free VAN buffer.   So, For the VAN reader.   if there is no free buffer (free_buffers is zero), then we exit else    If we have a VAN_start then       we set the Van_In_process flag    else if Van_In_process flag is set then,      store the bytes in the selected buffer    else if end of packet      if Van_In_process flag is set then decrement free_buffers and reset Van_In_process flag     This should do the think. But I do not know if this will fit What do you think?   By the way, I've also tryed 230800 baud without any success like you   Brouno, what is your status?   Oh! I forgot : I will maybe buy a bortesi adapter to see how they are emulating the CDC ... it's only about 75€ from what I've read somewhere...   Fariouche

ARG! All the formating is gone! I should have used the preview button before posting
 
Fariouche

Hello
 
I have just finished some tests.
 
I provided the file of the circuit and the captured screens on http://louptiprat.free.fr/
 
My circuit work, i obtain weave on hyperterminal and led on rb4 flicker (see capture.txt...)
I will make of other captures later with indications  
 
I tested with the software  van-analyser.pl and Virtual_Dash.exe without result
With Virtual_dash i obtain a bug (see http://louptiprat.free.fr/bug_virtual_dash.JPG)
With van-analyser i installed Active-pearl and open van-analyser.pl but no result
 
What is the problem with Virtual-dash?
 
thanks for your support
lio

Hi
 
Fariouche, you have understod the function of the VAN monitor correctly. I've started to analyze the software myself It was a couple of month since I wrote it
 
The problem is to be able to ignore packets but still respond to any requests from other devices. I hope I'll have time this week to implement the updates.
 
Nice work Lio with the new PCB. Can we place it to the Rt3wiki?
 
/Per

Hi,
 
Lio, can you give me the debug output of DbgMon.exe?
Did you used the "Send 'c'" option? (I did not completely tested it)
If you are using log file, make sure that the log file does not contain Non VAN packets at the begining (like '()' or 'c')
 
Fariouche

Piffo77 a écrit :   Hi   Fariouche, you have understod the function of the VAN monitor correctly. I've started to analyze the software myself It was a couple of month since I wrote it   The problem is to be able to ignore packets but still respond to any requests from other devices. I hope I'll have time this week to implement the updates.   Nice work Lio with the new PCB. Can we place it to the Rt3wiki?   /Per

 
 
Piffo,
 
I forgot something.
In the function that outputs data to RS232, Once a packet was sent it must increment free_buffers variable of course.
 
Fariouche

Yes we can
---------------
Sorry fariouche it's Ok for Virtual-dash, i didn't read your topic. I dont't have left click on mouse to access to log file.
I made of another captures (http://louptiprat.free.fr/capt_07-06-05/).
 
lio

 
Cool!
I'm glad that it's working
 
Fariouche

 Hi,
 
   I was able to find one with a CDC but had no time
 to snoop the bus. Anyway he lives at about 150km
 so maybe we will be able to meet within the month.
 
   I probably will be able to get my hands on a diag2000
 this weekend and will try to activate the parking aid
 to see if any new packet appears on the bus.
 
--
 
 - alex.

Hé, hi
 
I'm here But I did not work on the subject ...
 
B.

Hi
 
 
I can't use van-parser.pl with van-frames.txt.I have installed Activeperl  .You can see captures of error message on http://louptiprat.free.fr/Pb%20van-parser.pl.jpeg.
 
 
Thanks for your help :-)
lio

Hi everyone.  
 
I've released a rev 04 of the VAN monitor software. When all three receive buffers are filled, new VAN packets are ignored. This prevents the buffers from being overwritten while or before they are transmitted via RS232.  
 
The implementation is slightly different than the one Fariouche suggested. I still want the software to be able to answer on RTR requests even if all buffers are filled. I had to expermient a lot with the timing before it worked.  
 
This software has only been tested on my "experimental" VAN with the radio and display. I'll try to test the software in my car later this week.
 
/Per

 
 Hi,
 
   open the file with an ascii editor and remove
 the line that starts with use Scalar::Util
 it should work.

 
 
 Hi,
 
   I'll try it asap. Did you gave a look at my proposed
 architecture for the PIC firmware on the wiki?
 
 On a side note, I've been able to play with a Diag 2000... It's
 amazing what you can do with it.. almost every actuator
 on the car can be controlled and almost all commands
 can be monitored...
 
 
--
 
 - alex.
 
 
 
 
 
 

Hi
 
I've looked on the framework proposal but I think the RAM in the PIC16F876 is too small for this solution. The monitor already uses >90 % of the RAM. Maybe a 18Fxxx can do the trick?  
 
Then you played with the Diag 2000, did you sniff the VAN for any "special" configuration packages, for example to activate/deactivate the CDC?
 
/Per

 
 
Hi,
 
I have remove line and now a new error message appear :
 
------------------
van parser.pl 0.1
include :
exclude:
unknow type eval
-------------------------
Why?
 
lio

Wow! If we can do a Diag2000 emulator!!
 
Cool for the rev04! Great work. I will try it this week end I hope.
If we can find how to activate the CDC ourselves, it will be really cool!
 
I just got an answer from Bortesi, and my HU is not in the compatibility list ... too bad. I do not understand what are the differences between the HU versions... The VAN protocol should be the same.
 
From what peugeot told me, Diag2000 talks to the HU and the CDC to activate the it. So Van Mon should be able to see the Diag2000 communicating.
 
Fariouche

[citation]From what peugeot told me, Diag2000 talks to the HU and the CDC to activate the it.  
 
If the CDC was activated in the HU, I would have seen these CDC VAN packets on my experimental VAN. When I sniff the VAN in my car, the VAN tries to locate the CDC but I cannot detect these packets when I only use the radio and display indoors. I still suspect this configuration is placed in the display since it controls the radio.  
 
/Per

 
 I would suggest switching to something like the 18F2550 . Is a pretty neat
 chip with 2K of RAM.
 
 I was unable to do sniffing while playing with the diag,
 not enough time
 
--
 
 - alex.
 
 

 
 The CDC is activated in the BSI. Probably some kind of configuration
 is stored in the display, but I don't know for sure.
 
--
 
 - alex.