Reprise du message précédent :

 
 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.
 
 
 

 
 It's my fault, I've removed the type "eval" from van-parser
 because it always evaluate expressions with int and bcd types.
 
 If this is ok for the others, we can change all the eval
 in van-frames.txt to int or bcd, as appropriate.
 
 Meanwhile, you can do that in your own van-frames.txt
 
--
 
 - alex.
 
p.s.
 
  There are no shipping charges if you order PICs on buy.microchip.com
 before the 17. You will only pay the 5EUR handling fee. There's also a 10%  discount on development tools. If we decide to switch to the 18F2550 we should do it fast to save some money! let me know what you all think!
(anyway the sampling options is available, as always..)
 
p.s. 2
 
 Fariouche, regardin the total cd time in packet
 554. I was unable to find it in my logs. Is this confirmed?
 
p.s. 3
 
 This forum wont'allow me to post a message right after another,
 so i'm editing this one. Maybe we should use a real mailing list?
 
 
 

 Hi everybody,
 
   I'm going to try the rev4 firmware in a few hours.
 
 I've noticed the hex for the F876 and the 876A is exactly
 the same..
 
--
 
 - alex.

 
I'm not 100% sure yet, but I've tried with 2 audio CD and the total time seems ok.
I have a RD3 headunit (VDO).
 
Fariouche

I tried rev 4 and sampled the VAN for two trips of 30 minutes each. During the first capture which resulted in a 3.2 mb text file by the hyperterminal I found 4 rows with invalid data. The text line was partially overwritten with new ascii data. During the next trip (about 2.8 mb), I got one row with an invalid address (0xfff) and about 5-10 rows with partially overwritten data. The capturing stopped twice so I had to restart it with the "c" command.  
 
There are no counters in the rev 4 code to count missed packets and the problem with partially overwritten lines can be caused by the hyperterminal. I don't have any other software to verify this but rev 4 seems to work better than earlier versions.
 
The reason why the software stops capturing packers is also unknown.  
 
/Per

 Hi,
 
   can you post some logs so that I can update the parser?
 My Clarion RD3 show FF.
 
   I've also noticed that in lio's RB3 logs the source
 field is 30 or 31, while we used to see
 50 and 51.
 
--
 
 - alex.

 
 Hi,
 
  I tried it today, rev4 rocks. I found some data about the a/c unit
 which I will post after a bit of re-organization. The IDENs are 4DC
 and 464.
 
  I'd appreciate to have your logs so I can maybe sort
 out the fuel and oil gauge and the oil and water temp.
 
--
 
 - alex.
 

 
Hi,
 
I'm using mtty, and it's the same problem.
It's also the same with virtualDash...
I will upload mtty in wiki...
 
My 554 packet is:
554 RA- 86D6001100000001177510FFFFFFFFFFFFFF86 A
 
The CD was 75min 10s long.
 
Fariouche

You can download mtty at http://rt3wiki.free.fr/uploads/Us/Mtty
 
Oh, I just noticed that I forgot to put the file extention while uploading it.
It's a .rar file. Rename it to Mtty.rar.
 
Fariouche

 
 Hi,
 
  that means there are different RD3s in the wild...  
 
  I'm using
 
   cat /dev/tts/0 | ./van-parser.pl  
 
 
--
 
 - alex.
 
 

 Hi,
 
  regarding the CDC, I can confirm there are two models
 for the 206. Both of them are VAN capable but only
 one of them can be connected on the RD3 of multiplexed
 cars (2002-2005).
 
  Since the 307 is newer, I believe there's only one for
 her.
   
  I don't know of other cars.
 
  Do you all here have RD3 on a recent car?  
 
--
 
 - alex.

Hi,
 
I think I know why we still have corrupted VAN packets.
 
-> When _VAN_rx read one byte, it check if there is a free buffer and store it if yes. If not, the byte is discarded.
-> At the same time, we are sending a packet through RS232. Once done, we have one more free buffer.
 
So, what happen if _VAN_rx read one more byte (says byte 5) and RS232 just finished sending? VAN_rx will begin to store VAN bytes, even in the middle of a VAN packet. byte 5 will then be stored... but it's not the begining of a VAN packet!
 
I think that we'll need just one more variable (that we can call discard_bytes).
1- This variable will be set to 1 if we begin to read a New VAN packet and no free buffer.  
2- Then VAN_rx will rely on this variable to discard bytes. (in stead of relying free_buffer variable)
3- At the same time, one more buffer is free.
4- Then, once we have a new VAN packet, we set discard_bytes to 1 or 0 depending on free_buffers again, And so on.
 
What do you think?
 
Bortesi just replyed to me and told me that it should work with my HU (even if it's not in the compatible list) -> If it's not working, I always have the option to return it to them.
They also told me that Diag2000 will be able to detect this adapter as a real CDC (so they will be able to activate the CDC with it)
 
 
For the new pic18C, I think that it's a good idea, but this will force piffo to redo all the timing calculations!
 
Alex, Did you see F00 packets? (you may have to start the engine for them to shows up)
 
Fariouche

 
 Hi,
  if you want to save some moneys, I think i should be able to meet
 the guy with the CDC in the next 2/3 weeks.
 

 
 Well, not immediately.. 95% of the code could be ported as is, only
 a few instructions need to be replaced.
 
 In the future, we could maybe have to tap into VAN with different
 speeds (there are 3 VANs on a car, 2 at 125 and one at 65 if I remember  correct).
 
 Also while we can initially run the PIC18 at the same speed, we
 can later switch to 40/48MHz.. so we must find a way to do timing
 in a portable and reconfigurable way.
 
 If the platform I have described on the wiki will be created, we will
 be able to build a lot of things above it.. a CDC/iPod converter,
 a kind-of-BSI with enhanced functions, etc etc.
[/citation]
 

 
 No. i will pay attention to them on the next run, but I'm fairly
 sure I haven't seen them.
 
--
 
 - alex.
 

Hi
 
>think that we'll need just one more variable (that we can call discard_bytes).  
>1- This variable will be set to 1 if we begin to read a New VAN packet and no free buffer.  
>2- Then VAN_rx will rely on this variable to discard bytes. (in stead of relying free_buffer variable)  
>3- At the same time, one more buffer is free.  
>4- Then, once we have a new VAN packet, we set discard_bytes to 1 or 0 depending on free_buffers again, And so on.  
 
I have tried to locate the problems with overwritten packets but I haven't found it yet. When a new VAN packet is detected, the software will stay in the interrupt routine and receive the whole VAN packet before the control is back in the main program again. The number of free buffers are increased after the last byte in a buffer has been sent using RS232. Perhaps the RS232 buffer handling is faulty? I'm working on "Rev 5" now. Anyway, the log file was more than 110000 text lines long and there where only 5-10 rows with overwritten data (<0.1 %). The more serious problem are when capturing of packets is aborted. I suspect some parts of the software which can cause this behaviour.
 
The packets with address 0xF00 can be invalid. Since they occurs intermittent , it's hard to find out where they comes from.
 
I spent some time yesterday to capture A/C packets:
 
464 WA- 14 000000 08 A
 
The first byte: 0x00, 0x10, 0x11 or 0x14. 0x00 = A/C Off, 0x14 = Rear window heater on.
The last byte has something to do with the fan speed. 0x00 = 0ff, 0x13 = Max
 
4DC WA- C1 E0 1D 01D2 FFFF A
 
The first byte: 0x00 = Off, 0x01 = ?, 0x80 = A/C off (auto), 0xC0 = ? A/C starting up?, 0xC1 = A/C on (normal mode), 0xE1 = Rear window heater on (bit 5?).  
 
Next byte: 0xE0 = A/C on (and engine on), 0xFC = off (and engine off)
 
0x1D seems to have something with the fan speed to do.
 
01D2 is probably the temperature in the cupé.  
 
FFFF is unknown
 
The sun light sensor, the temperature setting and selection of where the air shall go (down/window etc) as not been located.  
 
The packet "8FC RA- 81xxxxxx81" is sent when starting up the engine. The xxxxxx is the hexadecimal value for how long the car has gone. 0x030D40 = 20000.0 km
 
This information needs to be verified and if it's correct, added to the Wiki.
 
I have an ICD2 and some PIC18F processors at home but I don't know if or when I have the time to convert the "VAN mon" software. Rewriting the software for different crystal frequences can be complicated since the timing is critical. Some limitations, for example 2 choices, 20 or 40 MHz, must be specified.
 
/Per  

 
 Hi,
 
   I agree. The way it works now is more than enough for our research.
 

 
The light and rain sensor is on another bus, VAN BODY 1.
 

 
8FC RA- 820069BF82 A
 
 I've found it in my logs, seems reasonable.
 

 
 Ok, I would use the same speed we have now to ease the task.
 Maybe we'll switch to a different speed later, or use
 one of the Atmel chips to interface with the VAN.
 
 Regarding the a/c, here are my notes:
 
4DC: a/c unit status, sent only with engine on
 
byte 0
        bit 7 seems always on
        bit 6 and 5 are related to a/c and back de-icing status.
byte 1
        unknown, always 0 here.
byte 2
        internal temperature, X/2
bytes 3-4
        this is a 2 byte gauge, somewhat inversely proportional
        to the current temperature.
bytes 5-6
        always 0xFFFF
 
 I hadn;t the time to investigate further. I suspect it works
 pretty much like the radio, one port to tell the BSI the button
that has been pressed and the other one for doing things.
 
 I've been driven to this explanation due to the fact that,
 when the roof id open, the rear-window heater can't be activated.
 
--
 
 - alex.
 

 
 Hi,
 
  I bought another cdc on ebay.. this one should be
 ok and be there within a week
 
  if anyone is interested in the old one, compatible
 only with 2001 and pre-2001 cars, drop me a note..
 
--
 
 - alex.

Hi,
 
I've received the bortesi interface, and it's working great!
As soon as I have some time, I will try to log some packets...
 
Fariouche

 
Fariouche, what's your headunit model serial/number ? Is your car muxed ?

 
Hi,
 
I have a 307, so muxed, HU VDO 22RC280/65 (not in their comatibility list)
 
It's working great, but there is a mis-connection in the resistors near the RCA plugs... If a touch them a bit, the sound becomes clear. Else, it's just impossible to hear or the sound is very low and noisy.
 
Just some resoldering will do it I think.
 
Fariouche.

Hi all, and thanks for this thread. I just spent 2 hours to read it from the beginning. You are great engeneering guys !
 
I recently bought a 607 (03/2001) which has an RT2 (radio + telephone) and a CD Charger. It also has the monochrome GPS installed.
 
I read that this car has also a VAN bus between CDC and radio. So I think your project can be easily ported to my car... What do you think of that ?
 
I'm a newby in PIC programmming, electronic stuffes, and serial communication. I don't understand why you are implementing a first 'software' stage in the PIC to do a 'simple' VAN monitor. I understand that the final goal is to develop a CDC interface that will be fully compliant with VAN protocol, and that embbeded PIC will be the final solution.
 
But your first goal is to analyse packets and not send packet : so why don't do that directly on the computer ? Wouldn't this be easier to analyse and correct code (only PC software to change, no buffering problem because PC RAM should be enough ( no ? ) ) ?
 
Perhaps I'm totally wrong, perhaps VAN data voltage and current level don't feet RS232, perhaps the VAN data is to fast for RS232, or even for USB... tell me where I made a mistake...
 
 
 

 
 Hi,
 
  yes, I think it should work. RT2, as far as I know, uses VAN. Can you tell us
 the model number/product number on your CDC?
 
 You're also the first one with a GPS, so I think we could discover
 interesting things by snooping the bus on your car.
 

 
 The problem is all related to timing. To communicate on the VAN bus, timing
 must be perfect and we would not be able to do that on a PC.
 
 The voltage levels on the VAN bus are also not compatible with any
 port found on a standard PC: they're called "differential". Much more
 like RS422 or RS485 than RS232.
--
 
 - alex.
 

Hi,  
 
I don't know the product number : here is what I can see :  
 


 
the CAA-355 number references the 6 disc magazine : I found on the clarion website that this magazine is suitable for CDC655Tz, CDC634, CDC635
So I'm not sure of mine.
Do you know how to remove the cover to unmount the CDC from the car ?
 
 
For the serial interface : I understand now : thanks for the explanation.
I will think of buying a PIC programmer and some electronic tools.
 
Baf

 
 Hi,
 
  your CDC is a DC628, peugeot part number 6564.45, which is the one used  
 also on 2001 206s . The newest cars uses 6564.55.
 
  You have VAN onboard, but probably the packets wil be a little
 different from the ones we already sniffed.
 
--
 
 - alex.

Wahou, je ne suis pas venu depuis des mois ici. J'ai l'impression que ça a pas mal avancé
Quelqu'un me fait un résumé ???

faignant

Hi!
 
I have read the entire thread and I must confess that I am rather curious if I will be able to get the results necessary to get a "fake" CDC running.
 
I've ordered the parts for the interface and will try them as soon as I get my hands on them.
 
But before that one question:
 
How did you manage to get the connection interface.
Some got hold to an iso plug. Which ones?
If I recall from this kind of interfaces it is not possible to interrupt the wires and each end much be terminated with a 120ohm resistor. (It was needed in CAN.. I assume the same for VAN...)
So a T configuration would be needed. How to get the T connector for the plug behind the radio?
 
I'll keep you posted as soon as I get some news.

MoebiuS a écrit :   Wahou, je ne suis pas venu depuis des mois ici. J'ai l'impression que ça a pas mal avancé Quelqu'un me fait un résumé ???

 
+1 :-p

 
 There's no doubt! We are pretty close...
 

 
 Don't worry for termination.. just connect the two wires behind  
 the radio using a mini-ISO plug (mini-ISO is composed of
 three blocks, you need the blue one).
 
 You can also attach your wires to the ISO connector
 you already have on the car. The pinout is on the wiki.
 
--
 
 - alex.
 

good news!
 
 I managed to capture some packets from a CDC. I
 had only a small amount of time, so I was
 not able to do the reverse engineering at
 the same time...
 
 capture file with notes here:
 
 http://rt3wiki.free.fr/uploads/Us/cdc-capture.txt
 
 this is my proposed decoding of port 4EC:
 
4EC::4::bcd:                            : track time (m)
4EC::5::bcd:                            : track time (s)
4EC::6::bcd:                            : current track
4EC::7::bcd:                            : cd number
4EC::8::bcd:                            : track count
 
 
--
 
 - alex
 

Good work Alex!
 
I've started working on rev 5 of the VAN mon software to include CDC emulation. There were a lot of interesting information in the log fil. Obviously the CDC replies with writing 0x96 -> 0x8C4 (display command port) to acknowledge (CDC ACK) received commands on port 0x8EC or to force an update of the display every second.
 
The code for replying with ACK on certain addresses (for example 0x8EC) and let other devices read data on an address (0x4EC) is already implemented in rev 3 and 4 of the VAN mon software. I made a "quick and dirty" and added some functions so the monitor software replied with the ACK when a command was received on address 0x8EC. The software also replies with the RTR data on 0x4EC (fixed, containing the first packet read from 0x4EC in the log file).
 
When i pressed the CDC button on the radio it switched to the CDC input for about two seconds and then back to the radio. There are no code for updating the display info by sending a "CDC ACK" once a second and the buffer doesn't change between each read. I think the display belives the CDC is "dead" and switches back to the previous audio source.
 
I get the same reaction when I press the "source" button on the remote control stick. The CDC input is activated for a few seconds.
 
Hopefully there will be a "release version" of Rev 5 during this or next week. I don't have so much free time for the moment.
 
/Per

 
 wow! we are homing on the target...! don't worry, we are in no hurry.  
 
 another useful sequence i forgot to post:
 
 direct access to cd using 1-6 keys on the radio
 
 8C4: WA- 8A2201 A
 8EC: WA- 4101 A
 8C4: WA- 96 A
 4EC: RA- 8600D316FFFF0101FF003F86 A
 5E4: WA- 201F A
 9C4: WA- 0082 A
 8C4: WA- 8A2241 A
 5E4: WA- 201F A
 9C4: WA- 0082 A
 4EC: RA- 8600D316FFFF0101FF003F86 A
 5E4: WA- 201F A
 9C4: WA- 0082 A
 5E4: WA- 201F A
 9C4: WA- 0082 A
 8C4: WA- 8A2202 A
 8EC: WA- 4102 A
 8C4: WA- 96 A
 4EC: RA- 8700D316FFFF0102FF003F87 A
 5E4: WA- 201F A
 9C4: WA- 0082 A
 8C4: WA- 8A2242 A
 5E4: WA- 201F A
 9C4: WA- 0082 A
 4EC: RA- 8700D316FFFF0102FF003F87 A
 5E4: WA- 201F A
 9C4: WA- 0082 A
 5E4: WA- 201F A
 9C4: WA- 0082 A
 
 on port 8C4 we see 8A22 insteal of the usual 8AC2.
 on 8EC, 41 is the change cd command and the payload
 is the cd number.
 
 a short list of command i;ve seen on 8EC:
 
        41FF    next cd
        41FE    prev cd
        410X    direct cd selection
        4106
        31FF    ? next track
        31FE    ? prev track
        1183    mute/pause ?
        1181    unmute/play ?
        1184    fwd
        1183    rev?
        1185    ?
--
 
 - alex.

Hi
 
The experiments has continued. Finally I have managed to emulate some basic CDC functions in my car.  
 
An early beta of revision 5 (probably with many bugs since I haven't tried to optimize or analyze the code) of the VAN monitor is availible at
http://rt3wiki.free.fr/uploads/Us/VAN%20mon%20rev5%20beta%201.txt
 
It contains some debug code and only emulates basic disc changing functions for the CDC. The VAN monitor must be "capturing" data in order to emulate a CDC. The track number is fixed to 1, number of tracks to 18 and the second counter only steps from 0:00 to 0:09 and then restarts. It is possible to "select disc" by using keys 1..6 or the wheel on the remote control. The code only interprets commands 0x1101, 0x1181, 0x1183, 0x41FE, 0x41FF and 0x4101..0x4106. Trying to change tracks or fast forward/rewind is not recommended. Test the software on your own risk..
 
I've tried to update the Wiki table commands list but I cannot save the data (timeout) and the wiki is very slow. Can anyone try to get it to work?
 
How should the CDC emulation work? Now the radio switches to the CDC input and it remains active until another audio source is selected so the current implementation should be enough for many applications.  
 
Does anyone know if the RD3 radio and CDC supports cd-text? The packet read from 0x4EC doesn't seem to have any unused data for this.
 
/Per

 
 great work!
 

 
 My opinion is that we should build a generic VAN platform which can
 be used to do different things, ranging from simply feeding
 audio to driving an ipod via its remote control interface.
 
 basically, a VAN subsystem with a well defined programming
 interface.
 
 I've read some docs about PIC18F migration.. it should be fairly
 easy, requiring only register name changes, removing banking
 instructions and a few other minor mods. I'll try to do
 that on rev 5 in the weekend and let you know.
 
 I will then volunteer for the iPod related work.
 

 
 I've been told it doesn't support it
 
--
 
 - alex.

Non, d' un fromage, 18 pages
Je suis content que mon poste est pris de l' ampleur!!!
Felicitation, les gars..
 
Alors cette emulation du CDC, ce n' est finalement pas si facile, apparement
J' ai pu lire que le boitier de bortesi fonctionnait finalement sur la liste noir des RD3, qu' en penses tu Moebius?
 
Si on peut avoir quelque infos sur la compatibilité final sur ton RD3

Voici le passage en question

 
 
Bonjour,
 
Hehe, ca marche nickel. C'etait en effet un probleme de soudure.
Je ne vois paq pourquoi il y aaurait des incompatibilités... Apres tout peugeot a fait en sorte de rester compatible pour eviter les version de CDC.
 
 
Long time since my last post.... I see that we have some good news! Good work Alex and piffo!
I did not get much time for that these days. I'm currently trying to continue virtual dash so that I can use it in my carPC...
 
Fariouche