Reprise du message précédent :

 
 Could be some kind of power supply related
 to the VAN bus... we would need some schematics
 to be sure.
 
--
 
 - alex.
 

 
 Hi,
 
   which one did you ordered?
 
--
 
 - alex.

 
 I'll try and let you know.
 
  Today I noticed that my air conditioning unit wouldn't
 allow me to activate the heater of the rear windshield
 if my roof is open (quite obvious). This means that
 either the status of the rooftop is somewhere
 in the VAN, the a/c unit is connected to another VAN or
 the a/c has anpther way to know.
 
--
 
 - alex.

Hi,
 
I've completed the circuit.
Everything seems to work except the VAN...
 
As soon as I plug it to the van network (I unplugged the headunit and plugged the sniffer instead), the display and the control leds begins to blink...
Seems that it didn't liked the sniffer
As soon as i remove it, the dashboard returns to normal. (I didn't put the car key)
 
My circuit seems correct. I can dialog with the pic using the rs232 interface.
So, the problem seems to be with the SN75176AP driver
 
I've connected pin6 of the driver to the PIN2 of the ISO connector and pin7 to PIN3.
 
I've got the pinout from this link http://rt3wiki.free.fr/pmwiki.php?n=Main.RT3
The pinout is from the headunit point of view, isn't it?
 
Fariouche.

 
 Your connections are ok. Try to cut the connection between
 the driver and the PIC so that the PIC can't write to the
 bus. Something is probably keeping the bus in it's dominant
 state.
 
 If it doesn't yet work, double check your connections
 to the driver.
 
--
 
 - alex.
 

hum... I've double/triple checked my connections without finding any problem.
I've used rev02, the pdf version.
 
I will try to unconnect pin5 of the PIC to see if this solves the problem.
I will try tommorow since I do not have the necessary tools here.
 
By the way, from the schematics I do not understand how you can write something to the VAN bus...
I've checked the driver datasheet and  I saw that that the only thing the PIC can do with pin5 is to put AB=LH or AB = ZZ since D is always 0. Or is it just that to transmit something to the van bus, we only need ZZ and LH?
 
Fariouche

fariouche a écrit :     By the way, from the schematics I do not understand how you can write something to the VAN bus... I've checked the driver datasheet and  I saw that that the only thing the PIC can do with pin5 is to put AB=LH or AB = ZZ since D is always 0. Or is it just that to transmit something to the van bus, we only need ZZ and LH?

 
Nevermind, I've just read an old post from piffo77 that answaers this question
 
Fariouche.

 
A simple one, on a french website
 
B.

Hi,
 
I've found that the PIn5 of the PIC is always 5V... I've cut this connection between the driver and the pic and I was able to log some packets!
 
I will check why later.
For the moment, here are some packet (without the headunit connected)
307 HDI, no CDC, manual clim.
Before putting the car's:
824 W-- 00000000000000 -  <- The last byte is always zero.
Key at first position:
824 W-- 00060000000001 -
824 W-- 00520000000001 -
824 W-- 014D0000000002 -
824 W-- 033B0000000002 -
824 W-- 05FE0000000003 -
824 W-- 09310000000003 -
etc...
824 definitly does not carry the rpms or car speed.
The last byte keeps increasing...
 
I started the engine and now it's:
824 W-- 1963000000002C -
824 W-- 1961000000002D -
824 W-- 195E000000002D -
824 W-- 195C000000002D -
824 W-- 195A000000002D -
...
824 W-- 18F3000000003A -
824 W-- 18F0000000003A -
824 W-- 18EE000000003A -
824 W-- 18EC000000003A -
824 W-- 18EB000000003A -
824 W-- 18E9000000003A -
824 W-- 18E8000000003B -
824 W-- 18E7000000003B -
 
Then I stopped the engine and removed the key:
824 W-- FFFFFFFF00003B -
Same packet till the end.
 
Also I had the followinf packet before and when the engine was started:
5E4 WA- 201E A
After removing the key (or switching off the car's engine)
5E4 WA- 0001 A
 
I will try to have better logs later.
 
Also, do you think that it's better to send the data in raw hex instead of converting them on the PIC to ascii? We should win a lot of uart bandwidth!
If you want, I can write a windows application that will be able to writes/read the com port and display in hex.
 
Fariouche.

fariouche a écrit :   Hi,   I've found that the PIn5 of the PIC is always 5V... I've cut this connection between the driver and the pic and I was able to log some packets!

 
 great!
 

 
 We could, but it seems the pic is doing the job pretty
 well.
 
 If you use perl, I've a script which decodes
 the log files.
 
--
 
 - alex.
 
 

 
The main thing here is to win about 50% of the uart bandwidth and we'll be able to log more packets (since the van bus is at 125kbits, 115200 is equivalent to 92kbits, and i'm sure that the van bus is not used at 100%)
But maybe it's not that important with the filtering activated.
 
Fariouche

Hello guys,
 
It's fun. I'd the same idea. Waiting my pic programmer, I'm working on an app for getting, logging, decoding and displaying packet.
 
Here a screenshoot of the work in progress
 

 
The right panel show the live captured packet sort by IDEN
The left panel show a treeview of decoded information (light on, door open, radio station, ...)
 
On the top you can send data on the VAN to know IDEN
 
Some other functionnality on going: logging packet in file, simulation by using logging file (or in database ?)
 
I would put all information in database (iden, decoding), so, we can add know data without changing code.
 
At this time, the design is almost ready, the database too.
Comm code (capture packet) is almost ready
 
Todo : decoding, showing, simulating(but near comm code)
 
I'm using VisualBasic 6 and Access database. I know it's not very portable, but it's the most accessible to me, ... and the fastest ;-)
 
Alex : perhap's your perl script can help to code the decoding thread ;-)
 
B.

Don't forget iden's for hand-brake and rear gear, if such events can be logged...

Hi all,
 
Here are some logs:
Port 5E4:
5E4 WA- 0001 A  when display is off
5E4 WA- 201F A  when display is on
 
Port 824:
824 W-- FFFFFFFF000000 -  when key at position 0 or 1
824 W-- 00000000000000 -  when key at position 2 (ready to start engine)
824 W-- 18FF0000000041 -  when engine started. First two byte increase quickly at the begining and then to stabilize at around 1900 (variable between 18E1 and 1911) -> actually sounds like rpm
The last two bytes keeps increasing.
824 W-- FFFFFFFF0000A0 -  when engine stopped. Counter stopped also to the last value.
 
 
Port 4FC:
 
No key or key at position1:
4FC WA- 80007FFE0000FF000000FE A  or
4FC WA- 00007FFE0000FF000000FE A
 
Key at position2 (engine ready to start):
First 4FC WA- 840001820000FF00FE00FE A
Then  4FC WA- 8000018200000D00FE00FE A
after 4FC WA- 800001820000XX625E00FE A  where XX is 0D or 17 or 1F or 26 and stabilize at 3F
 
Key at position3 (engine running):
4FC WA- 8400018200003F625E00FE A  just when the engine started? (got it one time)
4FC WA- 8000018200003F625E00FE A  all the other time.
 
 
Port 524:
524 W-- 000000000000000040FF00000000 -  when no key, door not locked
524 W-- 000000000000000041FF00000000 -  when no key, door locked
524 W-- 000000002000000040FF00000000 -  when key at position1, door not locked
 
When a set the key at position2 I got first
524 W-- 082080032001800040FF00000000 -  then
524 W-- 0820A1032001800000FF00000000 -  then
524 W-- 080081002001000000FF00000000 -  
 
WHen the engine is running:
524 W-- 000001000001000000FF00000000 - (or is it still for position2?) and then
524 W-- 000000000003000000FF00000000 -
The first bytes seems to be related to engine/ESP/ABS/etc status.
 
Port 664:
664 WA- 00000F04FFFF00FFFFFF00 A  always
 
Port 984:
984 W-- 0181012014 - (I only got it once!)
 
I forgot : My radio was on for all my testings.
 
phewwww....
 
More to come soon.... after some sleep ...
 
Fariouche

 
 Hi,
 
   i'm going to upload it. I was thinking.. if we can come up
 with a file which describes the packets in the VAN, we could
 then use the same data source for both programs.  
 
  this data file should be able to describe packets
 with variable length data, bitfields and values
 that require a formula to be applied.. what do you
 all think?
 
 
 something like that:
 
ort E24 (Vehicle Identification Number)
0-::ascii: VIN
:end
 
ort 8A4
0:0x20:bit:     heartbeat
0:0x0F:int:     brightness
1:0x01:bit:     contact
1:0x02:bit:     engine
1:0x04:bit:     economy
2:0xFF:formula: X/2 : temperature (water)
3:0xFF:int:     oil level
4:0xFF:int:     fuel level
5:0xFF:formula: X/2 : temperature (oil)
6:0xFF:formula: (X-0x50)/2 : temperature (ext)
:end
ort 9C4 (remote control)
0:0x80:bit:seek+
0:0x40:bit:seek-
0:0x20:bit:?1
0:0x10:bit:?2
0:0x08:bit:vol+
0:0x04:bit:vol-
0:0x02:bit:source
0:0x01:bit:?3
1:0xFF:intheel
:end
 
ort 984 (time)
3:0xFF:int:hours
4:0xFF:int:minutes
:end
 
ort 554/**D6 (cd track info)
5:0xFF:int:track time (m)
6:0xFF:int:track time (s)
7:0xFF:int:current track
8:0xFF:int:track count
:end
 
 
the first line, ort matches the port number and eventually
the payload ( port/payload )
 
each line starts with a range, a mask, the value type, optional data and the description (always the last one).
 
so
 
 8:0xFF:int:track count
 
means take byte 8 , apply a mask of 0xFF, call it "track count"
 
0:0x02:bit:source
 
 byte 0, if bit 0x02 is on, call it "source"
 
6:0xFF:formula: (X-0x50)/2 : temperature (ext)
 
 take byte 0 as X, apply a mask ox 0xFF,
 apply the formula.
 
0-::ascii: VIN
 
 byte 0 to the end of packet, no mask, ascii value, it's the VIN.
 
--
 
 - alex.

Yep, Alex, you get it !
 
It was I mean by

 
Your description seems fine to me. But for easier coding I'll add IDEN at start of each line rather than "port" ... ":end" with payload information (
 
I'll add starting byte and ending byte in ascii mode too because it can be not to the end of the packet (as in radio information : there is a byte after radio name"
 
IDENayload ID:Byte number:Value:Type:Name
 
 
E24::::: Vehicle Identification Number
E24::00:12:ascii: VIN  
-> no payload
 
8A4::::: BSI Information
8A4::00:20:bit: heartbeat  
8A4::00:0F:int: brightness  
8A4::01:01:bit: contact
-> no payload
 
554:1:011ay: radio info
554:1:0B:0A:bit: RDS text available
-> payload 1 : cd trackinfo
 
554:2:016ay: cd track info
554:2:05:FF:int:track time (min)
-> payload 2 : cd trackinfo
 
 
Frequency is a problem with this :-( I'm tired now (it's 02:30 here now) . Thinking tomorrow ;-) But I'm afraid we can't do all in something like that. We certainly do some hard coding :-(
 
B.

Brouno a écrit :     Your description seems fine to me. But for easier coding I'll add IDEN at start of each line rather than "port" ... ":end" with payload information (   IDENayload ID:Byte number:Value:Type:Name     E24::::: Vehicle Identification Number E24::00:12:ascii: VIN   -> no payload

 
My range syntax is:
 
x -> single byte
x- -> start at x, go till the end
x-y -> start at x, go till y
 
so it would be:
 
E24::0-:ascii:VIN
 
could be ok?
 
 
defined types are:
 
int -> integer
eval -> a formula to be evaluated, X will be substituted with the value
ascii
bcd
assert -> like eval, valid if the eval'ed result is true
cmp -> comparison with value, internally converted to assert X == value
bit -> AND with value, internaly converted to assert X & value
 
 
 

 
 I would rather handle those kind of ports as if
they were different ports, like:
 
554/**D6
 
 to tell the parser that the port must be 554, the first
 byte should be ignored, the second one must be D6
 
 so we would have:
 
IDEN[/filter]mask:typeescription
 
 optional parts between square brackets.
 
 for coding purposes, an empty filter
 is equivalent to /*, an empty mask
 to 0xFF, an empty range should be considered
 invalid.
 
 mask is required when you have, for example,
 a bitfield in the upper 4 bits and an integer
 in the lower ones.
 
 I've started to describe some packets, see  
 http://rt3wiki.free.fr/pmwiki.php?n=VAN.ParseableCommands
 
 I would like to use a Wiki page se we can all easily
 edit it, but I was unable to tell PmWiki to show
 the page as is, without any formatting at all.
 

 
 we are in the same timezone, so I guess is time to go to bed  
 for me too
 
--
 
 - alex.
 

Hi,
 
I confirm the values for port 9C4. I have the same.
 
For the file format, sounds good for me... It will simplify a lot the analysis.
 
Fariouche.

OK, great.
 
I think args option should be (keep delim).
 
IDEN[/filter]mask:type:[args]escription  
 
BTW, data not need in some case (description, mask, args) are optionnal
 
I'm searching for the unformatting on Wiki
 
B.

OOP's i forgot :
 
Why you doing
 
IDEN[/filter]mask:type:[args]escription  
 
Rather than
 
IDEN:[filter]mask:type:[args]escription  
 
(assuming my modif on optionnal arg is OK)
 
B.

Brouno a écrit :   OOP's i forgot :   Why you doing   IDEN[/filter]mask:type:[args]escription     Rather than   IDEN:[filter]mask:type:[args]escription     (assuming my modif on optionnal arg is OK)

 
 No particular reasons, your mods
 are ok to me.
 
 Ho do we call that file, van-frames.txt ?
 
--
 
 - alex.
 
 

OK, let's go like that.
 
OK for van-frames.txt
 
 
B.
 
P.S. : I received my pic programmer ;-) I had to go to the elec shop to get my 20 Mhz crystal and some goodies, and I'm OK :-)

great!
 
 I'v finished to modify my program to use
 the description file.
 
 I'm going to modify the wiki page with the
 latest revision i'm using.
 
 (which still misses the description of some radio/cd
 related frames)
 
 I would rather not publish a separate downloadable
 version of the description because otherwise
 we would have two probably out-of-sync versions.
 
--
 
 - alex.

 I've updated van-frames.txt and added 554 "D3" and "D1"
 descriptions.
 
 I also changed the args field to be expression, as it seemed
 more appropriate to me to handle eval, bcd and assert types.
 
 I'm not sure about the RDS status flags... heare are some
 packets of mine:
 
 554: RA- 84D10180C2036160FFFFA10000000000000000000084 A
 554: RA- 85D10180C203C160FFFFA10000000000000000000085 A
 554: RA- 86D10180C2036120FFFFA10000000000000000000086 A
 554: RA- 87D10180C2036100FFFFA10000000000000000000087 A
 554: RA- 80D10480FC0305605215A10000000000000000000080 A
 554: RA- 81D10480FC0305605215A10000000000000000000081 A
 554: RA- 84D10480FC0305605215A1004F4E454F4F4E45200084 A
 554: RA- 85D10480FC0305605215A1094F4E454F4F4E45200085 A
 554: RA- 86D10480FC0305605215A10943454E544F554E4F0086 A
 554: RA- 87D10480DA0365605238A10000000000000000000087 A
 554: RA- 80D10480DA03C5605238A10000000000000000000080 A
 554: RA- 82D10480DA03C560539FA10000000000000000000082 A
 554: RA- 84D10480DA031560539F810100000000000000000084 A
 554: RA- 86D10480DA030560539F810120472E522E502E200086 A
 554: RA- 85D10480DA030540539F810120472E522E502E200085 A
 554: RA- 87D10180FF070F60FFFFA10020472E522E502E200087 A
 554: RA- 82D10480DA0305605238A10000000000000000000082 A
 554: RA- 84D10480DA030560539FA10000000000000000000084 A
 554: RA- 85D10480DA032560539F810100000000000000000085 A
 554: RA- 80D10480DA030560539F810120472E522E502E200080 A
 
 bytes 8 and 9 are interesting because they sometimes
 are set to FFFF, which we have learned is often
 used to signal "no availability" of something.
 
--
 
 - alex.
 
 

Hi,
 
Here are some of mine:
554 RA- 85D10180E8030067FFFFA00000000000000000000085 A
554 RA- 86D6001100000001177510FFFFFFFFFFFFFF86 A
554 RA- 87D101800E040D67F217A1002020462055204E200087 A
554 RA- 80D119800E040D67F217A1002020462055204E200080 A
554 RA- 80D119800E040D67F217A1002020462055204E200080 A
 
554 RA- 85D101900E040D67FFFFA10000000000000000000085 A
554 RA- 86D1019010040D67FFFFA10000000000000000000086 A
554 RA- 87D1019012040D67FFFFA10000000000000000000087 A
554 RA- 80D1019014040D67FFFFA10000000000000000000080 A
554 RA- 81D1019016040D67FFFFA10000000000000000000081 A
554 RA- 82D1018016040D67FE40A10000000000000000000082 A
554 RA- 83D1018016040D67FE40A10020204F554920464D0083 A
 
I do not see also why some packets are shorter...
 
 
Fariouche

 
 Hi,
 
   because they carry different infos. Those with D1
 in their second byte are related to the radio,
 those with D6 to the CD.
 
--
 
 - alex.
 
 

 
 
Thank you... I didn't saw the D6 byte
 
I have an other question for you:
I got this packet one time : 4D4 RAT  -
Why does it mean?
 
Also, can you explain me the meaning of the RAT attributes? The A at the end of some packets? I did not see any explaination of pmwiki about these flags...
 
Sine I'm here, I've found a packet that was not listed in pmwiki or van_log.txt
8FC RA- 820D1A0D82 A
 
8FC RA- 820D188082 A
 
I wonder what is it for?
I didn't got it a lot. I think that it's sent once a second like the time (I think that's why it's difficult to have it without filtering)
 
Fariouche?

 Hi,
 
   there's a quick description here: http://rt3wiki.free.fr/pmwiki.php?n=VAN.LogFileFormat
 
 for a detailed one you'll have to read the datasheet
of one of the TSS VAN controllers.
 
 I think I never got 4D4 or 8FC.. I'll pay attention to them
in the next capture session.
 
--
 
 - alex.

 I've just finished reading some
 documents I've found on the web.. some sparse
 thoughts:
 
 elements on the VAN:
 
VAN Comfort
 
BSI1    BSI
7215    Display
8410    Radio
8415    CDC
8500    GPS
8025    Air conditioning unit
0004    Dashboard
????    Parking aid
 
VAN Body 2
 
BSI1    BSI
2003    Driving school instructor's unit
8602    Alarm
 
VAN Body 1
 
BSI1    BSI
CV00    COM2000
BM34    Fuse box
5007    Light/rain sensors
6570    Air bag
 
 
 radio. the common one is the RD3. There's also an RB3,
 which is cassette only. That means the display should
 have some kind of support for the it. Maybe we
 could use that support to do something useful...
 
 comm2000. should be in charge of receiving the radio
 signal from the remote control. buzzer is also there.
 
 bm34. fuse box, in charge of operating lights
 and other equipements.
 
 parking aid. should be interesting to see if, after activating
 it in the BSI, we see new messages.
 maybe someone of you could ask his dealer to activate it.
 
 the air conditioning unit is on the VAN. I don't know if the
 internal temperature sensor is connected directly to it
 (quite probable) or if it gets the data from the VAN.
 
 urls:
 
 http://home.hccnet.nl/b.kool/
 http://www.autoelectric.ru/auto/peugeot/wd/wiringdiagrams.htm
 http://www.peugeotlogic.com/fuses/fuses206/fuses9.htm
 
--
 
 - alex.
 

Hi,
 
I think that I've found why I cannot send data...
The PIC keeps Pio3 to 5V always...
 
After some researches, I've found that the 75176AP driver is very sensitive!
With my multimeter,if I try to measure VANB or VAN the driver think that there is a change in the state... If I touch VANB pin, the pic automatically puts it's PIN3 to +5V. If I touch VAN pin, it goes to 0V...
 
 
I think that I will add a pullup resistor to VANB and a pulldown to VAN or something like that.
 
What do you think?
What the PIC tries to write to the VAN Bus?
 
Fariouche

 
 The PIC shouldn't be trying to write to the bus..
 RA3 hould be low unless you instruct the PIC
 to transit via software.
 
 You may weant to double check
 that your PIC has been programmed correctly...
 or maybe the PIC is damaged.. you could alter the source
 code to use RA2 instead of RA3.
 
--
 
 - alex

 
Thank you for your advice.
 
I actually found that the PIC has dead digital outputs!
I've tried with port A and PORT B and it's the same.
Fortunately I've bought 2 PICs! And the second one is working fine.
 
Fariouche

Hello guys,
 
Just a little word to you : I was busy this week-end and this week, so nothing to my side.
 
I received my pic programmer last week : programming my pic with soft rev03 is ok :-)
 
I must always go to the shop to get my crystal and some others goodies, perhap's tomorrow ... if I can.
 
B.

 
 good news!  
 
 Can you upload some logs of yours on the wiki so that
 we have more data to validate the frame definitions?
 
--
 
 - alex.

 
 
How can I upload them on wiki? It's requesting a password...
 
Fariouche

Argh ! I have all but crystal. My elec shop can't get one 20 MHz ! :-(
 
I have to order one crystal at selectronique !
 
B.
 
P.S. : Fariouche, pwd en mp ;-)