CHERCHE spec de la messagerie VAN entre RD3 et Chargeur

[Invité §Del468tX]

Salut tout le monde,

en farfouillant un peu j'ai trouvé ça http://www.carrefourmultimedia.com/Data/FR/Magasin/Produit/p_mag_ProdDetail.asp?ID=21934&onglet=1&type=detail&libfiltre=&filtre=0&page=1&menu_id=3&Smenu_id=29#

 

 

j'en ai commandé un pour voir et je vous dirais si c'est valable.

 

C'est quoi ce truc, un emetteur fm ? Ben y en a des mieux deja et c'est limité a de la qualité FM.

 

[Invité §g_d458dm]

Première capture (01.dgt), première trame:

opération d'écriture vers l'IDEN 0x8C4 avec demande d'acquitement, données écrites = 0x8A0140

 

[Invité §g_d458dm]

Première capture (01.dgt), deuxième trame:

opération de lecture demandée à l'IDEN 0x4D4 avec demande d'acquitement. Données envoyées par l'IDEN: 0x81800F00003F3F3F3F3F0081

[Invité §dar478Ix]

Bon c'est bien cool tout ca....

 

Perso, j'ai commande un oscillo qui fait analyseur logique...mais vu que j'ai pas de chargeur ca sert pas a grand chose,en revanche, il fait aussi arbitrary waveform generator qui fait que je peux generer n'importe quelle forme : du coup je peux imiter le bus van et si on a les bonnes trames tenter de flooder l'autoradio avant de rentrer dans une version electronique...Moyen simple et rapide.

Sinon, je suis assez overbooke sur d'autres projets dont un avec un PIC et un protocole serie...donc ce que je fais pour ca, m'aidera pour notre floodeur...

Allez! ca s'approche!

[Invité §g_d458dm]

Je ne sais pas si ça sera vraiment facile à utiliser:

 

Apparemment, le poste de radio initie une tramme VAN et le chargeur est censé prendre le relais et générer la suite de la trame avec les données qu'il veut transmettre (en écrasant un des bits du début de trame à la volée).

 

Il faut être précis au cycle d'horloge près. Pas évident à simuler autrement qu'avec un PIC ou un PC.

 

[Invité §dar478Ix]

Ben au pire je le ferais au PIC no souci...

Reste a avoir des trames...d'ailleurs le Bortesi, si quelqu'un l'a pris peut aussi servir...en branchant le bortesi, on doit voir les trames minimales necessaire...

[Invité §g_d458dm]

Exact, tout est bon à prendre.

 

Pour en revenir aux trames que j'ai capturées, on a une série de 4 requêtes qui restent sans réponse (fichier 03.dgt et aussi dans 04.dgt). 4 fois la même requète, j'imagine que c'est la demande d'infos du poste vers le CDC.

le CDC aurait donc l'IDEN 0x4EC

Il faudrait donc répondre en écrasant le bit RTR, en insérant les données après le COM, en calculant le CRC, puis en fournissant le EOD.

 

La capture 05.dgt nous montre une trame plus longue:

Demande de lecture de l'IDEN 0x8D4, données répondues= 0x80C00F00033F3F443F440180.

[Invité §dar478Ix]

Ben maintenant reste a faire la meme chose avec un chargeur.....yakafokon!

[Invité §g_d458dm]

je remarque, avec quelques autres captures, que les réponses envoyées par les périphériques 0x4D4 et 0x8D4 sont bornées par des octets identiques.

Par exemple, la réponse de 0x4D4 commence et finit par 0x81, et la réponse de 0x8D4 commence et finit par 0x80. Contrôle?

 

J'ai aucune idée de la signification des octets.

Je me sens seul pour les tests...

[Invité §tra755fw]

GDUM, ah ca fait du bien, la motivation est relancée,

Je suis desolé de ne pouvoir vous aider mais là ca rentre dans des choses bien trop complexes pour moi

 

en tout cas, si je trouve un pote avec chargeur sur Paris ou Lille je vous previens,

 

Vivement que cet emulateur, soit operationnel, pour jouir des bienfaits de la musique haute qualité dans notre bonne petite >Peugeot

 

Bon courage,

[Invité §g_d458dm]

 

Allez, maintenant que j'ai prouvé que de brancher un PC portable sur le bus VAN ne grille ni le PC ni les équipements de la voiture, il nous faudrait un volontaire avec chargeur!

 

Je ne peux pas aller plus loin sans chargeur...

 

[Invité §g_d458dm]

Autres tests, toujours sans chargeur vu que personne ne veut s'y mettre

Quand je triture le volume à la télécommande: opération d'écriture sur le périphérique 0x8D4, données écrites: 0x22 0x10

Quand je triture le Seek à la télécommande: opération d'écriture sur le périphérique 0x8D4, données écrites: 0x14 0x40

Quand je triture le Band à la télécommande: opération d'écriture sur le périphérique 0x8D4, données écrites: 0x21 0x05

Quand je ne fais rien (Radio On): opération d'écriture répétitive sur le périphérique 0x8C4, données écrites: 0x8A 0x03 0x30

 

Parmis d'autres tests, je vois 2 choses:

- Chaque IDEN correspond à un périphérique ET une commande,

- certains IDEN sont en lecture seule, d'autres en écriture seule, d'autres les deux, et un en particulier ne répond pas (peut-être le chargeur absent?)

IDEN 0x554: Read only

IDEN 0x8D4: R/W

IDEN 0x8C4: Write only

IDEN 0x4D4: Read only

IDEN 0x4EC: ne répond pas (Chargeur?)

 

Il me faudrait un autre logiciel d'acquisition qui lise le bus plus longtemps qu'une demi-seconde...

[Invité §g_d458dm]

J'ai une 206 semi-multiplexée (09/2001), avec clim manuelle, sans chargeur CD. Pas de chargeur déclaré dans le BSI.

Donc, je me dis que l'IDEN 0x4EC n'est peut-être pas le chargeur, ça pourrait aussi bien être la clim auto, non? Est-ce que la clim auto fait l'objet d'une déclaration dans le BSI aussi?

 

Si j'ai bien compris, sur ce VAN, transitent des trames concernant:

- le BSI

- l'autoradio

- le chargeur de CD

- la clim

- l'affichage déporté

- le combiné (compte-tours, kilométrages, jauges, ...)

 

Vu que je suis branché sur la fiche ISO C de l'autoradio, je me demande si les messages ne sont pas filtrés, parce que lorsque l'autoradio est éteint, je n'ai aucun trafic (ou alors la fonction pass-through de l'autoradio est inactive quand il est éteint). Je devrais peut-être me mettre sur l'ISO A pour voir ce qui se passe, ça me permettrait de savoir quels IDEN ignorer?

 

Any comment?

 

[edit] autre chose: au lieu de se brancher sur le bus VAN par l'intermédiaire dur connecteur ISO A du poste, je préfère me câbler sur la prise Diag, mais je ne suis pas sûr du brochage que j'avais noté sur un brouillon. La masse correspond aux broches 4 et 5, mais où est le bus VAN? broches 2 et 10 ou broches 7 et 15?

 

[Invité §tra755fw]

Salut, cette semaine ,je fais ma revision des 60000 chez Peugeot Lille,

Je vais m' arranger pour qu' il declare le chargeur sur mon Poste; si tu veux que je pose 2 3 questions n' hesite pas à m' en faire la demande

 

[Invité §g_d458dm]

A moins qu'il ait une doc complète sur les échanges entre chargeur et autoradio, voire une liste des IDEN utilisés chez Peugeot, je ne vois pas ce que tu pourrais lui demander.

 

Toujours personne pour capturer les trames entre l'autoradio et le chargeur ou le Bortesi?

[Invité §Pif654Uh]

Bonjour

 

J'ai a suivi vos discussions en utilisant "babelfish.altavista.com" ; (désolé, ne peut pas parler français ainsi ce texte est également traduit en utilisant Babelfish de l'anglais). J'essaye également de relier un ordinateur à l'interface de commutateur de Cd de mon RD3 (Peugeot 2004 406).

 

J'ai relié le RD3 à un affichage (CDC ? en dehors de la voiture) et capturé les données de FOURGON. Pendant l'analyse, je pense que j'ai trouvé beaucoup d'informations sur la façon dont la radio montre des données sur l'affichage. Les données pour le commutateur de Cd (désolé, don't ont un l'un ou l'autre) sont probablement très semblables

 

Un paquet audio : 0x80 0C 01 00 51 00 3F 3F 40 40 80 le 0x80 dans le commencement et la fin reste 0x80 aussi longtemps que le contenu de paquet ne change pas. Le prochain paquet commencera et finira avec 0x81 (jusqu'à 0x87, puis à lui se remettra en marche de 0x80) Les 00 3F 3F 40 40 sont les arrangements pour le volume, la basse, le triple, l'affaiblisseur et l'équilibre.

 

0x50 est la source audio (la commutation 0x50 dessus ou au loin, 0x51 est par radio et 0x52 est construit en Cd).

 

J'essayerai de rassembler toutes les données dans un cahier de travail d'exceler.

 

Est-ce que je peux écrire des poteaux suivants en anglais? Je peux toujours traduire vos réponses de Babelfish employant français.

 

 

[Invité §Del468tX]

Hi Piffo,

 

Bab(y)belfish is not that smart :

 

...capturé les données de FOURGON[/quotemsg]

 

Obviously, it's VAN in French too

 

dans un cahier de travail d'exceler. [/quotemsg]

 

Excell workbook ?

 

le volume, la basse, le triple, l'affaiblisseur et l'équilibre[/quotemsg]

Volume, basse, trebble, fader & balance, isn'it ?

 

Man, as long as you don't use old form english with heaps of thou, thy, thine and verbs ending with "th", feel free to post here in english, there's no probleme (IMHO).

 

Regards, DFX.

 

[Invité §Pif654Uh]

Hi!

 

I have seen some interesting translations of the french but it's good enough to understand the ideas and technichal parts of your discussions. Too bad babelfish can't translate to swedish directly.

 

I took the french word "VAN" from the subject but the correct english word is "WAN"

 

It's correct I ment an Excel workbook but I think any type of document will fullfil the purpuse.

 

I've found a faulty display with some missing rows and connected a PIC16F877 between the WAN circuit (an Atmel TSS461C) and the CPU in the display. My car radio is only connected to a powersupply and the display. I can catch most of the data between these CPU and WAN circuit. The data sent to my PC from the PIC16F877 using RS232 so I get a lot of data to interpret. The plan is to remove the original CPU in the "faulty" display and use the PIC processor instead to communicate with the WAN in my car (using RS232 and a PC in the trunk connected to the cd-changer cable).

 

I have the same problems as you since I don't have a cd-changer to get the correct commands from. Peugeot here in Sweden doesn't have any information about the car radio/changer. Any faulty units are sent to France to be repaired. A question about the interface protocol and connections to Peugeot in France resulted in a angry reply: "The safety in the car can be affected so therefore we wont share any information.". Trial and error seems to be the only way out..

 

I've seen at least 5 types of packages sent from the radio:

11 bytes "xx 0C .. xx" with audio settings (yes, I ment "volume"..etc)

24 bytes "xx D1 .. xx" with frequency, radio band/settings and RDS text

12 bytes "xx D3 .. xx" with text / frequency when choosing 1 of 6 memorized channels

24 bytes "xx D6 .. xx" with cd player track and time (built in cd)

3 bytes "8A .. .." with key codes from keys pressed/released on the radio

 

(xx = "packed id" 0x80..0x87)

 

I'm not sure about which adresses / IDEN the display uses but the WAN circuit seems to listen/use 0xA44, 0xAC4, 0x524, 0x8A4 and 0x8C4. It's possible this list isn't correct (yet ).

 

Regards Piffo

[Invité §g_d458dm]

Hi and welcome in our discussion.

Your tests are very appreciated and I'm sure we're all going to sort this out.

 

Personally, I was plugged into the radio unit connector dedicated to the CDC. I'm not sure I'm catching all the VAN trafic (VAN here stands for Vehicle Area Network, what is your W? ).

As I understand, because you are connected between the LCD display and the radio unit, you are probably connected to the A connector, which is common to the LCD display, the radio unit, the BSI (Boitier de Servitude Intelligent, which is the brain of the car) and the dashboard. Plugging there makes you sure that you get all the traffic.

 

I'm using a lame program to catch the packets and I'm very limited. Can you give us more details on the PIC interface you're using?

 

Another question comes to my mind: is the CDC declared in the configuration of the BSI?

 

Last point, people from Peugeot here are not very cooperative either...

 

Regards

[Invité §Pif654Uh]

Hi

 

You're right, it's must be VAN (thought about wide-area-network). I plugged in an oscilloscope in the car in the A connector and saw the traffic (two wire differential). I hoped the CDC would use a simpler interface but it seemed to be the same data in the CDC connector (e.g. all traffic). Earlier in your discussions you said the CDC probably sends the text directly to the displays and receives keys from the joystick and radio. If this is the case, which I also believe, the CDC must be able to send and receive VAN data unfiltered by the car radio (installing a packet filter there would only cost a lot of money..).

 

I asked the people at Peugeot where I bought the car and they said the CDC is not declared in the BSI (atleast these Peugeot people are nice They even gave me a cdc cable with the car and I didn't have to paying for it. I wanted to install a computer one year ago since I had one in my old Mazda 323). It's just to install a cdc in the car.

 

My interface is built of a Peugeot display (a LCD with some missing display lines), a PIC16F877 running at 20 MHz, some logic (buffers 74HC574 to catch data, address and status lines) and a MAX232 driver. The buffers are connected directly to the circuit board of the display. Peugeot has placed some pads around the VAN circuit (TSS461C) for the data bus and control pins (probably used when testing the circuit board during manufacturing). By using this arrangement I can catch all data between the TSS461 and the CPU in the display. Atleast during read, the PIC processor has about 7 us (about 35 instructions @ 20 MHz) to store the read address, data and control pin status in a buffer using interrupts. The "main program" in the PIC processor reads the data from the buffer and transmit the operation "Read"/"Write", address and data in hexadecimal format to the PC using RS232 and hyperterminal.

 

When the data has been recorded to a file I use UltraEdit to sort all information so it can be decoded. My printer has worked overtime to print all data

 

The limitation with this setup is which addresses (IDENs) I can record. Only the packet sent to and from the display is catched since the built in CPU set up the TSS461 to listen on certain addresses. I cannot connect my interface to the car since it would have two displays in the VAN. The next step is to remove the CPU from the display and only use the PIC processor to setup and communicate using the TSS461. Then I can use a "spy-mode" where the VAN circuit only listens on packages and doesn't send any acknowledges. When this is done, all packages in the (comfort-) VAN can be store and possibly interpreted.

 

I've found a strange thing with the RD3 radio. I connnected 4 speakers to the B connector to get the sound but the radio "beeps" every 2 seconds independant of the volume setting so I don't know if it's missing the VAN in the car or if it some type of anti-theft. I haven't connected it to the car yet but I hope it'll stop beeping then... I run the radio without the speakers now so I don't need to hear the noise.

 

/Piffo

[Invité §g_d458dm]

Concerning the VAN spying using connector C (my case) was not necessarily a good idea just because the VAN bus is stopped on that connector when the radio unit is off. The radio is not using any kind of filter, but more probably a bus amplifier.

 

The VAN bus is not differential as you mentionned, it's using regular TTL-level signals. The two different pins are Data and /Data. You can use one or the other or both if you want to be fault-tolerant.

When I catch the data, I'm using a regular parallel port of a PC directly connected to the Data pin. No adaptation needed. The bad point is that I have to manually parse the VAN protocol.

 

Are you sure that the VSS461 is filtering the IDENs? I do have the specs here but only had a quick look over it. If you're right, this would help us to determine which IDENs are not concerned by the CDC. Can you for example do a simple test: click on the radio key "Seek+" and catch the data, then use the Seek+ on the joystick and catch the data. If you get exactly the same data, that means the filter is on (but do you have a joystick on your system?)

Talking about filters, you should be able to catch the data from the display CPU to the VSS461. Then we can try to figure out what filter is applyed.

 

I have no idea about the beeps when not connected to the car. Maybe it's a warning message meaning that the radio didn't receive any configuration packet from the BSI (CDC present or not for instance).

I'm affraid that as long as the radio doesn't receive this configuration, it won't try to communicate with an external CDC.

But using your data is very helpfull because your VAN bus is not polluted by messages concerning the dashboard and the BSI.

 

Gautier.

 

[Invité §Pif654Uh]

I've seen the VAN go into "sleep-mode" about one minute after the last door has been closed (the radio is off and I don't touch any other controls in the car). Implementing a bidirectional bus amplifier is not easy.

 

I call the bus differential since one wire is inverted (like the RS485 bus) independant of the voltage levels.

 

The TSS461 is filtering messages if it's programmed to do so. It has 14 "channels" where each channel has an address/IDEN, configuration (including max packet length), pointer to the built in 128 bytes RAM and a 12 mask bits which defines valid address bits. The display seems to have 10 active channels. One channel each are using 0xA44, 0xAC4, 0x524, 0x8A4. Five channels are listening on 0x8C4 and the last channel uses different addresses (probably for transmission). All channel has the mask bits set to 0xFFF, e.g. only listen on the defined addresses.

 

When I press for example the "memory 1 button" on the radio, the display receives the package "8A C2 01". When the button is released, a package "8A C2 41" is received (bit 6 in the last byte is set to 1). I haven't tried this in the car since I don't want two displays coexisting on the VAN. My Peugeot has "paddles" to control the radio (right side of the steering wheel) and cruise control (left side).

 

/Piffo

[Invité §g_d458dm]

I'm trying to write a program that will spy on the VAN bus via the parallel port, and dump all the decoded traffic into a text file. But my laptop is a lame PII 233MHz, I wonder if it will be able to bear with the bus speed...

I should be able to make some tests this week-end, I'll keep you updated.

 

Do you think the LCD display is sending messages? The only things I can do from the two keys is display infos (radio ok, cdc out) and change the local configuration like language, degree mode, time. It seems to me that to info is needed by the radio unit, but I'm confused because the LCD display is using a 10th channel to send messages...

Well, I guess I need intensive tests this week-end...

 

Regards.

[Invité §Pif654Uh]

Hi again. I think the easiest way to get correct timing when capturing data is to use a PIC16F877. The PIC captures the data and sends the information to the PC using either the serial or parallell port. I'm still not sure it can be done without missing packages on the VAN since each VAN byte takes 80 us to receive and a serial port, 115200 baud, needs 90 us to handle one byte.

 

I've done some analysis on the displays functions in the VAN. Almost all presentation and interface handling is done by the display. The radio sends packages with, for example the audio settings and the display shows the graphical parts, receives the keys pressed and sends back to the radio if the new balance settings. The volume control is handled entirely by the radio and the display only shows the "volume bar". All keys are not sent to the display. Each "key" package contains of three bytes. The first is always 0x8A but the two last differs. Some bits in the second byte seems to reflect in which mode the radio is (for example playing a cd or radio displaying the 6 memorized channels). When the CDC key is pressed the display only recieves "key down" and "key released" packages so I don't think it's up to the display to "detect" a external cd changer.

 

The keys are received by the display at IDEN 0x8C4 and packages with audio, frequency etc is received at IDEN 0x4D4 (I think but not 100% sure). The display transmits packages to the radio using IDEN 0x8D4 (audio settings and requests for data). The display also sends "status" packages to IDEN 0x5E4 several times every second but I don't know if it's to the radio or any other unit connected to the VAN. I suspect the outdoor thermometer is connected to the display so maybe the display tries to send this information? Do you have any data about the connectors and pin usage to other VAN units other than the car radio?

 

The radio keeps sending packages with audio settings even when it's "off". I'll try to find out more about the packages..

 

/Per

[Invité §g_d458dm]

Hi,

you're right, using directly the parallel port was a mistake, especially with a 233MHz PentiumII...

I just finished writing a VAN analyzer for the PIC16F877 and can't wait trying it. It also will send the analyzed VAN traffic to the PC serial port. Even if I miss some packets, it will be reliable enough to understand what's going on between VAN peripherals.

 

Concerning the temperature, date and time, I'm almost sure it's only processed inside the display unit and not shared at all.

As the display knows if there is a radio and/or a CDC installed (vieawable through the two buttons on the display unit), I'm pretty sure the BSI is broadcasting messages to warn every device about the car configuration. That's why the CDC npresence has to be recorded in the BSI by Peugeot people.

 

The BSI is also sending infos to the dashboard several times per seconds (jauges positions, alarm lights, speed meter, ...) as soon as the car is powered on (not necessarily the engine).

This leads me to a 1000 euro question: is the mileage handled by the VAN protocol? This would explain why the Peugeot people don't want to share any info. If this is true, I guess they are carefully reading this topic to see if we want to mess with mileage modification...

 

Back to the display: depending on the car configuration, displays are not all the same. I know for sure there is a one graphical line display (which we both have), but there is also a basic time display (probably not connected to the VAN), and a more complicated display (sharing air conditioning infos? GPS infos? not sure about other displays). So the 0x5E4 IDEN might be used to send a who-I-am message?

 

OK, time for me to go make some tests now. We keep in touch.

[Invité §Pif654Uh]

I think the outdoor temperature is shared with the aircondition unit.

 

Going through my prints of VAN data I've observed the following:

 

IDEN 0x5E4. The Display writs 00 01 or 20 1E to this address. It keeps on sending this data atleast one a second.

 

IDEN 0x984. The displays sends the package 00 00 00 FF FF to this address. I haven't seen any other package contents. Maybe one a minute or so.

 

IDEN 0x4D4. The display listens for audio settings from the radio on this address.

 

IDEN 0x554. The display receives frequency/cd player/memorized stations information from the radio on this address.

 

IDEN 0x8C4. The display receives button information from the radio using this address.

 

IDEN 0x8D4. The display sends commands to the radio using this address:

 

0x12 0x01 -> Use radio (is sent when display receives "radio button" pressed

0x12 0x02 -> Use built in cd (sent when receiving "cd button pressed)

 

0x27 0x21 .. 0x27 0x26 -> Read preset memory address 1..6 (current band fm/am?)

 

0x14 xx xx xx xx -> Update settings for fader, balance, bass and treble when any of these settings are changed

 

0x11 0xc0 / 0x11 0xc2 / 0x11 0xe0 / 0x11 0xe2 -> Update settings for "loudness on/off, speed volume on/off"

 

0x11 0x00 -> Switch "off" radio ?

 

The question is, can "command 0x12 0x03" force the radio to switch to the cd changer input??

 

Do you know if this "comfort" VAN is connected to any other units other than radio, steering wheel radio controls, cd changer, airconditioner and BSI? If Peugeot has made the VAN and BSI correct, the comfort bus would not contain any unneccesary packages.

 

Good lucks with your experiments.

 

/Per

 

[Invité §g_d458dm]

You're right again, temperature is needed by the air condition.

The dashboard is connected to the comfort VAN too. Try the second position of the engine key to check if you get extra messages (fuel level, airbag lights, ...). No, damn, I forgot you were AFTER the TSS461...

 

I experiment issues with the PIC interface. Basically I'm unable to synchronize to the bus frequency.

I configured the PIC to run without interupts, timer0 based on the 20MHz clock, prescaler = 1/8 (or 1/16, I forgot).

First I wait for a bus Idle.

Then when I detect a low level on VANData, I initialize the timer0 to 0.

I wait for a high level, record the timer0 value (this will be recorded as t1) and set timer0 to 0

I wait for a low level again, record timer0 as t2, set timer0 to 0

I wait for a high level, record timer0 as t3, set timer0 to 0

 

With these measurement, I compare t1 to t2 and 4*t3 to t1.

But I'm not getting what I expect, but values would be okay if increased by 1.

So I decided to round the values, by dividing each value by 4 and using 2 instead of 0 for timer0 reset values.

 

Still the same: t1=39 t2=39 t3=9

I decided then to optimize the code by removing sub-routines. It seems to be more stable, but I ran out of batteries...

PC is charging, I have to wait.

Btw, it's freezing outside... it's even snowing...

 

Your tests are impressive. You should try to find an official CDC and spy on it's TSS461, that would be perfect...

[Invité §Pif654Uh]

I thought about not using the timers in the PIC16F877. Every instruction at 20 MHz takes 200 ns. The TSS461 (using the datasheet from Atmel) uses a crystal of 4,00 MHz and divides its frequency by 2, e.g. 500 ns per cycle. The shortest bit on the VAN is 500 x 16 = 8 us (40 exactly instructions in the PIC processor). By syncronizing the software by waiting on the preable of 64 us and then syncronize with the "Start Sync" of 16 us it possible to ensure the timing without using the timers or interrupts. The first bit of the frame is read 12 us after the rising edge of the "Start sync" (12 x 5 = 60 instructions). It's a lot of "free" time between storing the data. When a byte is read (after 8 + 8 + 8 + 16 + 8 + 8 + 8 + 16 us = 80 us) this byte can be buffered or sent by RS232 or placed at 8 bit data on, for example PORTD and trigger an interrupt on the PC (ACK signal in the parallell port or polled) to read the 8 bits (bidirectional parallell port in input mode) and display/store the data. An other input on bit in the port to the PC can tell it's the first byte in package after the preamble. I think this solution will work using the parallell port and a simple DOS based pascal/assembler program.

 

They thought the easiest way to solve the problem at Peugeot was to buy a cd changer but I said I've already bought computer hardware for the money

 

/Per

[Invité §Pif654Uh]

I've tried to write a PIC16F877 program to receive the VAN packages. It has not been tested since I don't have any circuit board area to connect the PIC16F877 directly to the VAN instead of the display. The PIC is supposed to run at 20 MHz but I cannot promise it'll work (you try it on your own risk..).

 

The VAN input is connected to PORTB bit 0 (normally high when the VAN bus is "Free"). This program outputs 8 bits of data from PORTD every time a byte is received. To signal "data availible", PORTB bit 1 goes high. If it's the first byte in the packet, PORTB bit 2 goes high to. The port bit(s) will stay high until 4 new bits has been received from the VAN (about 40-50 us). I hope the Pentium 233 is fast enough to read and store the data from the serial port.

 

 

list p=16f877, st=OFF, x=OFF, n=0

errorlevel -302

#include <p16f877.inc>

 

; Variables in common bank (0x70 - 0x7F)

 

CBLOCK 0x70

byte_no: 1 ; Byte in package (0..xx)

count: 1 ; Bit in current byte (0..7)

databyte: 1 ; Received data

 

ENDC

 

ORG 0x0000

 

bcf INTCON,7 ; Disable all interrupts

 

bsf STATUS,RP0 ; RAM bank 1

bcf STATUS,RP1

 

movlw 0xf9 ; Bit 0 : VAN input (normally high),

movwf TRISB ; Bit 1 : high = Byte availible, Bit 2 : high = First byte in package

 

clrf TRISD ; Each received byte is presented on PORTD

 

bcf STATUS,RP0 ; RAM bank 0

bcf STATUS,RP1

 

clrf PORTB

 

WaitPre:

 

clrw

btfsc PORTB,0 ; Wait for Preamble (VAN input goes low)

goto WaitPre

 

CountLow:

 

nop

addlw 0x01 ; Count length of Preamble in us

btfss PORTB,0

goto CountLow

 

sublw 0x1c ; Preamble must be longer than 28 us

btfsc STATUS,C

goto WaitPre

 

WaitSyncLow:

nop

btfsc PORTB,0 ; Wait for start sync (VAN input goes low)

goto WaitSyncLow

 

WaitSyncHigh:

btfss PORTB,0 ; Wait for sync (VAN input goes high)

goto WaitSyncHigh

 

; First bit shall be read 12 us after sync

 

movlw 0x00-0x05 ; Next loop shall wait 5 us

 

Wait3:

nop ; Wait 1 us every turn (last turn the nop after

addlw 0x01 ; goto ensure it takes 1 us)

btfss STATUS,Z

goto Wait3

nop

 

NewByte:

 

clrf byte_no ; Time to receive a new packet (Preamble and sync received)

 

ByteLoop: ; Each turn in "ByteLoop" takes 80 us or 400 instructions

 

clrf count ; Time to receive a new byte from VAN

 

BitLoop: ; Each turn in "BitLoop" takes 8 us or 40 instructions

 

movf count,W ; Has the 4:th bit been received?

sublw 0x04

movlw 0x00-0x05 ; Bits 1,2,3,5,6,7 are NRZ bits (8 us)

btfsc STATUS,Z

movlw 0x00-0x0D ; Wait 8 us extra after 4:th bit (manchester coded)

 

Wait1:

nop ; Wait 1 us for every turn (last turn the nop after

addlw 0x01 ; goto ensure it takes 1 us)

btfss STATUS,Z

goto Wait1

nop

 

rrf PORTB,W ; Store PORTB, bit 0 from VAN

rlf databyte,F ; Store most significant bit first

 

btfsc count,2

bcf PORTB,1 ; Clear "Data availible" flag

btfsc count,2

bcf PORTB,2 ; Clear "first byte" flag

incf count,F

btfss count,3

goto BitLoop

 

movf byte_no,W ; Wait 8 us extra after 8:th bit (manchester coded)

btfsc STATUS,Z

bsf PORTB,2 ; First byte in VAN package

 

movf databyte,W

movwf PORTD

 

movlw 0x00-0x05 ; Next loop shall wait 5 us

 

Wait2:

bsf PORTB,1 ; Set "Data availible" flag

addlw 0x01 ; Wait 1 us for every turn

btfss STATUS,Z

goto Wait2

nop

 

movf PORTB,W ; Check for End-of-packet (EOP)

incf byte_no,F

nop

xorwf databyte,W ; The 8:th bit shall be manchester coded, if it's

andlw 0x01 ; not (low-high or high-low) it must be EOP

btfss STATUS,Z

goto NewByte ; Not EOP, decode next byte

 

goto WaitPre ; Wait for new Preamble and package

 

END

 

[Invité §g_d458dm]

Thanks for your program.

I have no time to test it tonight, and I realize I'm not using a 16F877 but a 16F876. It's basically the same thing except there is no PortD.

I'll do the adaptation later.

 

I don't even know if my lame laptop's parallel port is bi-directional. Well, it's not that old, it has to be... If not, I'll have to write an acquisition program to use the Ack, Busy, PaperEnd and SelectIn entries, and modify your program in order to get 4 bits instead of bytes

 

[Invité §Pif654Uh]

Why not change the program to use TRISC/PORTC instead?

 

If you check in the BIOS (probably "DEL" or "F1" key during startup of your laptop) and tries to find "Parallell port mode". It shall be possible to set it to "Normal" / "Bidirecional/PS2" / "ECP" / "ECP+EPP". Think the last two modes only exists on newer computers. I have an "old" IBM Pentium 100 here and it has "Bidirectional" mode.

 

When the port mode has been set to "bidirectional", bit 5 (0x20) on address 0x37A controls the direction. 1 = input, 0 = output. A pascal example:

 

{ Set port to input }

Port[$37a]:=(Port[$37a] and $df) or $20;

 

{ Read data from port }

byData := Port[$378];

 

If you use the example above, the pc program must be started before the PIC so the two ports isn't set to output at the same time (or use seris resistors of 1 kOhm on the datalines)

 

/Per

[Invité §g_d458dm]

A tout le monde,

les choses avancent bien sur le décryptage du protocole VAN, grâce notamment à notre ami suédois Piffo77 qui nous est d'une grande aide.

N'hésitez pas à poster vos commentaires.

 

Aux modérateurs,

Est-ce que l'on peut continuer à poster en anglais sur ce forum ou doit-on de temps en temps poster des traductions afin que tout le monde puisse suivre?

 

Merci.

 

 

 

[Invité §lio642dv]

Bonjour

 

Bravo continuez ainsi

le shmilblick avance!!

[Invité §g_d458dm]

Okay... I had a busy evening, but I modified the PIC program to fit the 16F876, wrote the PC program to acquire and save the data present on the parallel port, and made some soldering to make the PIC/DB25 cable.

 

Enough for tonight, I'm dead tired and need some sleep.

More news later.

 

[Invité §g_d458dm]

First tests. No good news, it doesn't work.

The PC seems to work: when I manually set the 'data available' to the ground, I record a bunch of 0xFF values (contact to ground is not perfect, so it gets several high and low states before having a steady low state)

 

I added the serial communication routines included in my PIC development environment (using PortC) and inserted logs.

It seems that the PIC is properly detecting the VAN preamble (2 per second)

I decided to log the byte_no value just before jumping back to WaitPre. Only 1 byte is detected, always the same byte (I forgot the value).

The PC software is not detecting any activity on the 'data available' line, I must have messed around with the PIC code, as I need an adaptation to fit the requirements of the PIC development evironment...

 

I didn't make further tests, it was -4°C outside...

I'll have a closer look to the PIC and the Parallel acquisition codes later.

I wish I had a portable oscilloscope.