string(4) "2786" Passion Espace Club • Auditorium - Affichage déporté
Page 1 sur 1

Auditorium - Affichage déporté

Publié : 12 sept. 2015, 21:40
par Ludospace
Salut,

Certains diront qu'il y a déjà des tonnes de post sur l'affichage déporté des auditoriums de nos camions, mais très peu parlent vraiment de l'étude du protocole de communication utilisé par Pioneer pour l'affichage déporté sur le TdB.

Mon précédent Espace n'étant pas équipé d'un auditorium, je ne m'étais pas franchement penché sur le sujet. Mais désormais, le challenge me semble jouable, même si beaucoup n'ont pas avancés sur les 10 dernières années quand je lis les posts de ce forum ou des autres.

Il est clair que cela demande un peu de matériel et de connaissance :
-> Un boitier auditorium
-> Un TdB
-> Une télécommande et le récepteur associé
-> Un oscillo
-> Un peu de développement soft ou hard

On trouve le matériel dans un Espace, mais il faut avouer que cela n'est pas très pratique de démonter le siège passager tous les soirs :mrgreen: , pour coller l'oscilloscope et le PC sur le BUS de l'auditorium.

Donc première chose à faire, avoir accès soit à l'équipement sur le bureau, ou alors déporter une prise raccordée sur la prise DIN 8 broches qui va de l'auditorium au TdB.

J'ai parcouru beaucoup de forums français et étrangers qui parlent du hack de ce bus, mais je n'ai trouvé que des suppositions et quasiment aucune explication ou travaux d'investigations.
Soit Pioneer a utilisé un bus hyper protégé et crypté (ce qui m'étonnerait pour un "simple" autoradio), soit personne ne partage les infos (c'est plutôt mon sentiment).

Déjà, les suppositions :
-> Un bus CAN : Pas possible
-> Un bus I2C : la longueur des câbles me laisse septique

Pourquoi ?
Si on regarde "simplement" les schémas des SCU-2xxx et du lecteur CD déporté (je n'ai pas trouvé le K7 et si quelqu'un à celui du TdB je suis preneur), on peut voir que les bus se composent de plusieurs informations :

Sur les prises K7 et CD du SCU :
-> BDATA
-> BSCK
-> BRXEN
-> BRST
-> BSRQ

Et pour l'affichage (DISPLAY) du SCU :
-> BDATA
-> BSCK
-> BRXEN
-> BSET
-> BINH

Un CAN n'utilise pas le clock et l'I2C n'utilise que deux fils (Clock et Data).

Ce bus SERIE SYNCHRONE se rapprochant plus d'un bus SPI, sur lequel on retrouve quasiment toutes les entrées/sorties présentent dans le système.

Mais vous me direz, pourquoi un bus "SERIE" ET "SYNCHRONE" :D ?

Si on regarde de plus près le schéma (SCU-2xxx) et en particulier le brochage du µCPU principal (PD4538B) on peut voir que la ligne "BDATA" est en fait reliée sur ses broches 62 (BSI) et 63 (BSO).

BSO : Serial Output
BSI : Serial Input

Le bus est donc certainement un bus SERIE (un TX et un RX) ce qui pourrait éliminer l'I2C, mais qui fonctionne sur une seule broche (collecteur ouvert), comme on peut en trouver dans les lecteurs de cartes à puces pour ceux qui connaissent...
Il est synchrone car il a besoin d'une horloge (SCK) pour synchroniser des données

Toujours en regardant les docs et schémas des SCU on voit le sens des broches : Ouput (O) ou Input (I) ou les deux (I/O).
Le sens est représenté par des flèches sur les broches du µCPU.

Pour le SCU :
-> BDATA : I/O (normal vu que l'on vient de dire qu'on y retrouve le TX et le RX)
-> BSCK : I/O Chaque émission de données est accompagné du signal horloge
-> BRST : O Broche du RESET du bus (niveau haut) pour le CD et la K7
-> BRXEN : I/O Broche qui permet de mettre le bus en émission ou en réception.
-> BSRQ : I Broche qui doit permettre au CD ou à la K7 de faire une demande d'envoi de données au CPU (REQUETE).

-> BSET : O Broche du RESET du bus (niveau haut) pour l'afficheur uniquement (ce qui veut dire qu'il n'est pas traité comme le CD et la K7)
-> BINH : O Broche d'inhibition de réception des données (niveau haut) pour l'afficheur uniquement. Quand cette broche est au niveau bas, l'afficheur peut recevoir les données

Le fonctionnement des broches est à confirmer par des mesures en réel.

Prochaines étapes :
-> Intercaler une prise sur le bus DISPLAY (la prise de la K7 ne possède pas les broches BSET et BINH).
-> Controler la fréquence de l'horloge pour en déduire la vitesse de transfert pour pouvoir espionner le bus via un PC
-> Logguer les données pour en comprendre le protocole et les commandes
-> Et enfin, émuler des commandes d'affichage

Je ferai cela à mon rythme vu que je n'ai pas e matos sur le bureau et partagerai certainement les avancées, mais pas forcément au fur et à mesure.
Si d'autres ont déjà avancé, les informations sont les bienvenues.

A+
Ludo

Re: Auditorium - Affichage déporté

Publié : 12 sept. 2015, 21:59
par supev-77
Et bien, j'ai pas compris grand chose, mais c'est interressant.
Si besoin, j'avais récupérer les schemas pour la commande au volant pour d'autre pioneer sur un site polonais, je mettrais le lien plus tard.
C'est un systeme tout bete avec un jeu de resistance sur une prise jack, ca marchais nickel sur ma R25.

Re: Auditorium - Affichage déporté

Publié : 12 sept. 2015, 22:26
par Ludospace
Re,

Liosyl (sur ce forum) avait déjà pas mal avancé sur le sujet mais pas eu de suite depuis les posts dans le sujet ;

https://www.passion-espace-club.com/view ... 3&start=25

Re: Auditorium - Affichage déporté

Publié : 12 sept. 2015, 22:30
par secaj
Salut ce qui permettrai de coupler d'autres autoradio, se serait super ;)

Re: Auditorium - Affichage déporté

Publié : 13 sept. 2015, 09:30
par pub2n
Salut

Beau challenge, car pour l'instant, j'en suis resté à mettre un autre afficheur déporté type Renault.
Si tu as besoin d'un tableau de bord qui fonctionne à mettre en statique, fait moi signe en MP

Re: Auditorium - Affichage déporté

Publié : 14 sept. 2015, 11:16
par Ludospace
Salut,
pub2n a écrit : Si tu as besoin d'un tableau de bord qui fonctionne à mettre en statique, fait moi signe en MP
En effet, je comptais acquérir un TdB d'occaz pour pouvoir faire les essais en statique bien au chaud (l'hiver arrive !).
J'ai déjà :
-> Un Auditorium à remettre en vie (SCU-2056) et que je vais passer en 4 x 40W par la même occasion :mrgreen:
-> Une commande au volant d'une Clio 1, qu'il faut que je vérifie pour valider la compatibilité avec celui de l'auditorium pour au moins pouvoir l'allumer (sinon un bête bouton fera l'affaire :lol: ).

Il me reste donc un récepteur IR pour la télécommande et le TdB.

Le but d'acquérir un TdB est aussi de pouvoir faire un banc de test pour la partie CAN (pour le dépannage ca devrait être utile) et aussi de comprendre comment l'auditorium arrive à afficher "SEEK" sur l'afficheur carré (celui qui affiche l'heure et la T°, le multifonction), alors que celui-ci est sur le réseau CAN.

Si tu en as un de dispo en prêt ou à la vente ça m'intéresse aussi :)

Voici une représentation de ce qui serait un des aboutissements du projet (cas où l'on garde un auditorium en base) avec la récupération de la commande au volant pour piloter un lecteur MP3 "home made" avec affichage sur le TdB.
schéma_modif_MP3.jpg
A+
Ludo

Re: Auditorium - Affichage déporté

Publié : 16 sept. 2015, 19:23
par pub2n
Tu es du 72 , c'est bien cela :?:

Re: Auditorium - Affichage déporté

Publié : 17 sept. 2015, 00:46
par Ludospace
Oui,
Le pays de la rillette :)

Re: Auditorium - Affichage déporté

Publié : 27 sept. 2015, 19:05
par Ludospace
Salut,

J'ai récupéré dernièrement des infos sur les commandes qui transitent sur le bus entre le SCU et le CD, K7 et TdB.
C'est un anglais (Rob Clive que je salue au passage) qui m'a refilé ce qu'il avait déjà étudié sur le système en 2011.
Plus qu'à mettre tout cela en musique dans une interface avec µC pour tester l'affichage sur le TdB.

A+
Ludo

Re: Auditorium - Affichage déporté

Publié : 13 nov. 2015, 01:52
par asf21
Bonjour à tous. Bonjour Ludospace.
Ca fait un moment que j'avais calé l'affaire avec cette histoire de can bus/i2c/spi, tant affichage déporté que acquisition de données de l'ECU et du BII.
en ce moment, je repotasse un peu cette vieille histoire. Bossant sur Arduino pour divers projets, ça fait un moment que ça me titille de tripatouiller du spi avec Arduino mais sans grand espoir. Et voilà que je tombe sur ton topic fort intéressant et détaillant ce que j'avais grosso merdo conclu.
Tu es entré dans des détails lesquels, pour certains, j'étais passé à côté...
J'ai toujours ce truc qui me trotte dans la tête de pouvoir afficher un jour les ID tags d'un autoradio pourvu d'une ligne spi.
J'ai aussi toujours ce truc qui me trotte de pouvoir accéder en full reading des trames can de l'ECU et du BII. Mais ça, c'est presque pisser à contre vent...
Si j'arrive à envoyer quoique ce soit à l'afficheur tdb depuis Arduino, que ce soit en simulation ou en réel, je ne manquerai pas de t'en faire part! ;)
A plus. Francis.

Re: Auditorium - Affichage déporté

Publié : 13 nov. 2015, 20:56
par Ludospace
Salut asf21,

Ce qui est sur, c'est que ce n'est pas un bus SPI car la ligne DATA est unidirectionnelle (SPI a une ligne In et une Out).

C'est un bus série synchrone, ce que confirme Rob Clive qui avait déjà fait du "reverse" sur le sujet :
D'après les timings qu'il a donné, ça donnerait du 38400 bauds, mais c'est à confirmer.

Voici donc ce qu'il m'a envoyé par mail (brut et in english) :

Code : Tout sélectionner

Send by Rob Clive.

M(P) Bus Lines

All lines have 5V levels.

BCLK	Clock.  Bidirectional, idle high. Timing 20-30us per bit, 3-8ms between bytes
BDATA	Data.  Bidirectional, idle high. Data changes at clock negative edge. 8 bit, transmitted LS bit first
BRST	Reset. Unidirectional, idle high. Pulled low by head unit for about 0.5s at startup, before any
	other bus activity and again when power to head unit is off
BSRQ	Service request.  Unidirectional, idle high. Asserted at startup by peripherals (CD or tape) needing
	attention.  Then while a peripheral is playing may be asserted at 0.5 - 1 second intervals.  Head
	unit does not poll peripherals at startup so if SRQ not asserted will assume none are present.
BRXEN 	Receivers Enable.  Bidirectional, idle high. Pulled low by talker when sending each byte


Messages from / to head unit

First 2 bytes are message type and number of bytes in rest of message.  Thus each message is a minimum of 
2 bytes.

Type
 00	status when system off?
 01	head unit status?
 03	command to tape?
 06	command to CD
 21	command to dashboard
 60	status from CD (not playing)
 61	status from CD (playing)
 71	status from tuner

Status (01)
	01	Type
	03	always 3 bytes
	p1	bit 4 appears to be power flag: off=1
	0s	source: 0=off, 6=cd, 7=tuner
	00,02,04

to tape (03) 1st message in response to SRQ, probably to determine if there's a tape
	03	Type
	00	No more bytes

to CD (06) 1st message in response to SRQ, probably to determine if there's a cd
	06	Type
	00	No more bytes

to CD (06)
	06	Type
	01	always 1 byte
	cc	command: 00=statusreq, 06=play, 16=stop, 26=track+, 27=track-, 28=toggle random, 3d=change disc to d,
		f0=?, f6=? these 2 appear only at start up, ff=reset

to dashboard (21)
	21	Type
	08	always 8 bytes
	00
	0d	Display type: 0=normal, 1=cd selector, 2=bass, 3=treble, 4=balance, 5=fade, 6=volume
	vv	volume, hex 00-1E
	30
	00
	00
	00
	00	value

from CD (60) response to first message (06 00) and reset command (ff). Head unit will send reset at power off
	60	Type
	01	always 1 byte
	1c	bit 3 is cd magazine presence, bit 4 is acknowledge.  if b4=0 the head unit will reset again

from CD (60) response to status request (00) when not playing
	60	Type
	02	always 2 bytes
	0c	bit 3 is cd magazine presence
	ss	previous state of cd: 11=off, 12=no magazine, 00=playing

from CD (60) response to f0 command (only occurs at startup)
	60	Type
	03	always 3 bytes
	1c	bit 3 is cd magazine presence, bit 4 is acknowledge
	ss	previous state of cd: 11=off, 12=no magazine, 00=playing
	01	?, always the same

from CD (60) response to f6 command (only occurs at startup) if not playing, otherwise 61 response as below
	60	Type
	02	always 2 bytes
	1c	bit 3 is cd magazine presence, bit 4 is acknowledge
	ss	previous state of cd: 11=off, 12=no magazine, 00=playing

from CD (61) response to any command when playing
	61	Type
	0A	always 10 bytes
	ss      command status: 08 normally, 18 to acknowledge command (not status), 48 when changing track
	SS	State: 00=stopped, 01=paused, 02=reading disc, 03=changing track, 04=playing, 07=buffer filling, 11=changing disc
	Fd	d = disc number 1-6
	mm	Track time minutes, BCD.  FF if not relevant
	ss	Track time seconds, BCD.  FF if not relevant
	tt	Track number, 1-99, BCD.  FF if not relevant
	00
	3F	?, always the same
	dd	Discs present (bits): 0 : 0 : disc6 : disc5 : disc4 : disc3 : disc2 : disc1
	00

from tuner (71)
	71	Type
	0A,12	10 bytes if no RDS name, 18 otherwise
	00
	10,11,12,13,16	appears to be some indication of lock
	fl	frequency bcd coded FM: 100's MHz, F=blank | tuner list in use: 1,2,3 for FM, D for LW
	ff	frequency bcd coded FM: 1's | 10's MHz, LW: 1's | 10's kHz
	0f	frequency bcd coded FM: 0 | tenths MHz, LW: ?
	pp	preset number 01-06
	01
	04,14	bit4=RDS present?
	00,34
	00
	nn	RDS station name char 1, ascii, hex
	nn	  char 2
	nn	  char 3
	nn	  char 4
	nn	  char 5
	nn	  char 6
	nn	  char 7
	nn	  char 8
J'attends les pièces pour réparer l'auditorium que j'avais en panne quand j'ai acheté le véhicule, en espérant qu'il redémarre car sinon il faut que me branche dans la voiture pour faire les tests et ca caille maintenant ;)
J'ai déjà fait une rallonge DIN pour la prise K7 (male / femelle) pour brancher le lecteur MP3.

Pour l'Arduino ca sera aussi la base sur laquelle je travaillerai, avec comme processeur principal un ATMega1284p :)
Le montage de la télécommande de la clio fonctionne sur un 328.

J'ai aussi acheté un shield CAN Bus pour me brancher sur le bus entre le B2I et le tableau de bord, même problème pour faire les tests, c'est dans la voiture que ça se passe et ça prend plus de temps que tranquille derrière son bureau !!! :)

A+
Ludo