Archive T-U-F 25 Octobre 2010 > SIEL pour les bus à Paris :c'est de pire en pire ?

Voir le sujet précédent Voir le sujet suivant Aller en bas

Archive T-U-F 25 Octobre 2010 > SIEL pour les bus à Paris :c'est de pire en pire ?

Message  quentin.51 le Ven 29 Juil - 18:27

Lien vers le forum d'origine : http://www.t-u-f.frbb.net/t1101-siel-pour-les-bus-a-paris-c-est-de-pire-en-pire

Prince des Tenebres a écrit:Bonjour

Est-ce que je suis le seul à penser que c'est n'importe quoi l'affichage de SIEL pour les bus à Paris ?

Hier soir Gare de l'Est : le N02 est annoncé à 30 minutes, donc je pars à pied, 5 minutes plus tard ya un N02 qui me double.

Avant hier, St Michel : le N14 annoncé à 10 minutes, il me faut 3 minutes pour aller jusqu'à l'arrêt et je vois le N14 qui se barre devant moi.

Très souvent : le compteur indique 2 mn, 1mn, 0.... toujours pas de bus... puis hop il se remet à 9 minutes

Si c'est pour faire ça, il vaudrait peut-être mieux supprimer le système non ?

Je veux bien admettre que la circulation etc rend difficile d'être très précis mais on doit quand même pouvoir faire mieux !!!

Quand pensez-vous ?

Agora Line 41 TCL a écrit:Tout tes exemples sont pour le Noctilien. Pour les lignes de jour c'est la même chose ?

Prince des Tenebres a écrit:
Agora Line 41 TCL a écrit:Tout tes exemples sont pour le Noctilien. Pour les lignes de jour c'est la même chose ?

Le coup du compteur qui descend puis remonte, je l'ai constaté plein de fois dans la journée, notamment ligne 85 .

Sinon le coup du N14 qui a de l'avance, là c'était vraiment une grosse avance, mais c'est quasiment toujours le cas pour les N d'avoir 2 ou 3 mn d'avance.

Le coup du N02 là ça m'a scié, j'avais encore jamais vu ça !!!

Iristom a écrit:Le coup du compteur qui descend et qui remonte, je l'ai aussi constaté dans le métro avant-hier, sur la ligne 4 à Gare de l'Est.

Prince des Tenebres a écrit:
Citeyosh a écrit:Le coup du compteur qui descend et qui remonte, je l'ai aussi constaté dans le métro avant-hier, sur la ligne 4 à Gare de l'Est.

Ah bon, moi j'ai jamais vu de bizarrerie dans le métro (sauf quand la ligne est coupée par un incident, là c'est n'importe quoi).

Ah si en fait: ça m'a toujours bien énervé qu'on ne puisse pas savoir en arrivant sur le quai si le dernier est déjà passé ou non.
Quand le dernier est passé, ça continue à afficher un nombre de minutes comme si de rien n'était.

Ca serait quand même pas compliqué d'éteindre le bidule!!! C'est trop demander?

Billy a écrit:Je suis d'accord avec Prince des Ténebres. Aujourd'hui j'ai du prendre 5 bus (différents dans la journée hein) et y en à 3 où l'attente était à 0 ... Et il n'est jamais passé. Par contre après j'ai eu le bonheur de voir deux 126 débouler cul à cul Quand ca ne fonctionne pas cela pourrait passer temporairement HS ou mettre quelque chose genre "Attente probable"

Iristom a écrit:SIEL ne vaut pas Visulys mon cher Billy, et inversement !

Prince des Tenebres a écrit:Alors ce soir gros LOL, l'afficheur indique 7 minutes. Je vois le bus arrêté au feu à 200 m de là. Bon.... que va-t-il se passer ?

Le bus démarre, arrive à l'arrêt. L'affichage passe brutalement de 7 à... 2 minutes.

Ben oui mais les gars, 2 minutes, c'est encore trop, le bus est à l'arrêt !!!

C'est quand même pas au point leur truc.

Christobal a écrit:Vu comment le système fonctionne, ça peut arriver en effet...

Prince des Tenebres a écrit:
Christobal a écrit:Vu comment le système fonctionne, ça peut arriver en effet...

Comment ça ? Tu as l'air de savoir des choses... comment le système fonctionne-t-il ?

Christobal a écrit:Le temps d'attente affiché sur les écrans aux arrêts prend en compte plusieurs paramètres.

Tout d'abord le temps de parcours théorique prévu au tableau de marche. Logique me direz-vous !
Imaginons que le bus soit à l'arrêt D et que vous l'attendiez à l'arrêt F, si le temps de parcours prévu entre ces deux arrêts est de 5 min, l'écran affichera "5 min".

Maintenant, chacun sait qu'un tableau de marche reste théorique, et que les temps de parcours peuvent varier en fonction des conditions de circulation.
C'est pour cette raison que SIEL pondère le temps de parcours théorique en fonction des conditions réelles de circulation, en se basant sur les temps de parcours réalisés par les bus précédents.

Pour revenir à l'exemple ci-dessus, si les bus précédant celui que vous attendez n'ont pas mis 5 min pour faire le trajet D -> F mais 10 min, le système va automatiquement augmenter l'estimation du temps de parcours. Et votre bus ne va plus être affiché dans "5 min", mais peut-être dans "8 min" ou "9 min"... Vous suivez ?

Je reviens maintenant à la remarque de Prince des Tenebres trois messages plus haut. Question : as-tu pris ton bus en fin d'heure de pointe ?
Imaginons que les conditions de circulation pendant l'heure de pointe aient été particulièrement dégradées, ou qu'une livraison ait perturbé le trafic en bloquant une voie : le système a augmenté ses estimations de temps de parcours. Si la circulation redevient fluide très rapidement, il faut quelques passages de bus pour que le système recale ses estimations de temps de parcours à la baisse, en intégrant progressivement les temps plus courts réalisés. Ainsi, on peut encore constater quelques temps de parcours "surestimés", le temps que ceux-ci soit recalés à la baisse...

Au-delà de ces considérations, les écrans reçoivent les informations par radio. On n'est pas à l'abri non plus de perturbations dans les transmissions entre l'émetteur et l'écran, d'où un affichage aberrant...  

Billy a écrit:Ca craint de se baser sur des estimations ! A Lyon au moins ils sont suivi avec Visulys sur la position exacte ! De 3 minutes on passe à Bus à l'arrêt des fois et il l'est vraiment

Prince des Tenebres a écrit:
Billy a écrit:Ca craint de se baser sur des estimations ! A Lyon au moins ils sont suivi avec Visulys sur la position exacte ! De 3 minutes on passe à Bus à l'arrêt des fois et il l'est vraiment

Alors là ... + 50000 !  Les estimations c'est bien mais la position réelle doit être prioritaire. Puisqu'on la connaît, et que c'est quand même une info un petit peu importante pour le calcul. Les estimations devraient être utilisées seulement pour corriger tant que le bus n'est pas proche de l'arrêt.

Par ailleurs dès qu'un bus est arrivé à son arrêt avec un temps de parcours normal, on devrait pouvoir immédiatement revoir à la baisse le temps de parcours nécessaire pour les bus suivants, je ne vois pas pourquoi cette baisse devrait être progressive.
En effet :

  • si le problème était ponctuel (livraison, etc), dès qu'un bus à fait un parcours avec un temps normal ça veut dire que le problème a disparu et tous les bus suivants auront un temps normal.
  • si le problème est à long terme (circulation dense) aucun bus n'aura de temps de parcours normal donc pas de raison de toucher à l'estimation.


Là au contraire on a un système qui tente de faire des estimations super-rusées, à tel point qu'il est incapable de prendre en compte la position réelle du bus, qui lui indiquerait justement que sa ruse ne marche pas !!

Christobal a écrit:Le temps d'attente affiché sur les écrans aux arrêts prend en compte plusieurs paramètres. (...)

Comment as-tu eu connaissance de tous ces détails ?

Christobal a écrit:
Je reviens maintenant à la remarque de Prince des Tenebres trois messages plus haut. Question : as-tu pris ton bus en fin d'heure de pointe ?

Les temps surestimés ont été constatés sur les Noctiliens, à des heures où la circulation est faible (en semaine, même pas le vendredi, quelque part entre 2h et 4h30).

Pour ce qui est du compteur qui arrive à 0 puis remonte, c'est plutôt dans la journée.

Christobal : tu sembles bien renseigné, tu as tes entrées à la RATP ? Est-ce qu'il y a moyen d'avoir des infos techniques détaillées?

Christobal a écrit:
Billy a écrit:Ca craint de se baser sur des estimations ! A Lyon au moins ils sont suivi avec Visulys sur la position exacte ! De 3 minutes on passe à Bus à l'arrêt des fois et il l'est vraiment
J'en déduis que Visulys utilise des algorithmes semblables à ceux de SIEL !  :10:

Prince des Tenebres a écrit:Les estimations c'est bien mais la position réelle doit être prioritaire.
C'est le cas, puisque le système s'en sert pour réajuster en permanence ses calculs.

Si on se trouvait dans un environnement sans aucune perturbation extérieure, avec des temps de parcours parfaitement maîtrisés, ces ajustements des temps d'attente n'auraient bien sûr pas lieu d'être puisqu'il suffirait de se baser sur les temps de parcours théoriques. Malheureusement, il paraîtrait que les bus sont parfois gênés dans leur progression par des difficultés de circulation diverses et variées...  Shocked

Prince des Tenebres a écrit:Puisqu'on la connaît, et que c'est quand même une info un petit peu importante pour le calcul. Les estimations devraient être utilisées seulement pour corriger tant que le bus n'est pas proche de l'arrêt.
Je ne comprends pas ta remarque, puisque c'est a priori exactement ce qui se fait !  

Après, on peut sans doute reprocher une certaine inertie au système, mais elle est je pense nécessaire pour ne pas réagir trop vite à une perturbation qui ne serait que ponctuelle...

Prince des Tenebres a écrit:
Christobal a écrit:

Prince des Tenebres a écrit:Les estimations c'est bien mais la position réelle doit être prioritaire.

C'est le cas, puisque le système s'en sert pour réajuster en permanence ses calculs.

Il ne s'en sert pas très bien (voir mon post précédent).

Christobal a écrit:

Prince des Tenebres a écrit:Puisqu'on la connaît, et que c'est quand même une info un petit peu importante pour le calcul. Les estimations devraient être utilisées seulement pour corriger tant que le bus n'est pas proche de l'arrêt.
Je ne comprends pas ta remarque, puisque c'est a priori exactement ce qui se fait !  

Après, on peut sans doute reprocher une certaine inertie au système, mais elle est je pense nécessaire pour ne pas réagir trop vite à une perturbation qui ne serait que ponctuelle...

J'ai déjà dit dans mon post précédent ce que je pensais de cette inertie, ainsi que de la mauvaise utilisation de la position du bus. Si la perturbation est ponctuelle, justement il faut y réagir vite !

Mais tu ne m'as toujours pas dit comment tu avais toutes ces infos si détaillées ?


Christobal a écrit:
Prince des Tenebres a écrit:J'ai déjà dit dans mon post précédent ce que je pensais de cette inertie, ainsi que de la mauvaise utilisation de la position du bus. Si la perturbation est ponctuelle, justement il faut y réagir vite !
Je ne suis pas certain que ce soit la meilleure solution...

Réagir plus vite, peut-être, mais pas trop vite !  

Prince des Tenebres a écrit:
Christobal a écrit:
Prince des Tenebres a écrit:J'ai déjà dit dans mon post précédent ce que je pensais de cette inertie, ainsi que de la mauvaise utilisation de la position du bus. Si la perturbation est ponctuelle, justement il faut y réagir vite !
Je ne suis pas certain que ce soit la meilleure solution...

Réagir plus vite, peut-être, mais pas trop vite !  

Je ne vois pas comment justifier ça.

Prenons un exemple :
L'estimation dit que le bus doit mettre 10 minutes.
La position courante du bus dit que finalement, ça y est, au bout de 6 mintues il est à l'arrêt.

Comment peux-tu justifier de continuer à indiquer que le bus arrivera dans 4 minutes, alors que sa position courante indique qu'il est à l'arrêt?
Dans ce cas il n'y a qu'une seule chose à faire : jeter l'estimation, qui n'était qu'une estimation, et on indique la réalité puisqu'on la connaît.

Mais j'aimerais bien savoir d'où viennent tes infos sur le fonctionnement détaillé du système ? Tu as des documents ?

Christobal a écrit:C'est une connaissance avec qui j'en ai discuté...  

Métronome a écrit:J'ai vu à Bruxelles un système qui pourrait en réjouir plus d'un à Paris, car il n'indique pas de bêtes temps d'attentes, imprécis, et issus d'une estimation : le panneau, qui est en fait un plan synoptique, présente pour chaque station et interstation une diode, et une diode allumée représente un train situé à cet endroit.

Beaucoup plus intelligent comme système !

Christobal a écrit:À noter que cette information est aussi accessible en direct sur le site Internet de la STIB.

Par exemple pour la ligne 5 en direction d'Erasme :

http://www.stib.be/cgi-bin/cgi_infodyn.exe?State=vFramesInfodyn&Lang=1&Mode=M&Line=5&Iti=2

Christobal a écrit:D'une manière générale, aller sur le site de la STIB : http://www.stib.be

Rubrique "Horaires".

Sélectionner la ligne.

Sélectionner la destination.

Cliquer sur "Position des véhicules temps réel".


JM-C a écrit:Pour bien connaître les deux systèmes, Visulys et Siel utilisent à peu près les mêmes principes et Visulys fonctionne globalement plus mal que Siel (mais il faut prendre le bus souvent pour pouvoir faire la comparaison et je ne suis pas sûr que ce soit le cas de nos touristes ...).
Il arrive que Visulys affiche ARRET NON DESSERVI alors qu'un bus est à l'arrêt !

Car il ne faut pas oublier une chose importante, c'est que pour qu'un SIV fonctionne, il faut qu'il détecte les bus. Et pour des tas de raisons, il y en a qui ne le sont pas (perte du signal radio, émetteur en panne, voiture mal codée par le MR, bus pas équipé ...) et donc Visulys se recale sur le TM théorique. Si c'est une perte passagère du signal GPS (par exemple à cause d'un obstacle) et quand l'info revient, il peut y avoir une différence et donc le temps d'attente varie brusquement. Et puis il y a le problème du livreur qui s'arrête brusquement et bloque le bus.

Un autre exemple, à Lyon: les trams plantent régulièrement les bornes de C3 parce que si un trolley est à 100 mètres, Visulys l'annonce dans une minute et si par hasard, un tram arrive, le feu passe au rouge pendant 2 minutes s'il est loin et s'il en croise un autre. Et donc avec deux carrefours avec le tram (Cours Lafayette), on peut passer de 1 minutes à 5 ! Et ça se répercute sur les arrêts suivants alors que le C3 suivant peut très bien arriver sans être bloqué et à faible charge (le précédent ayant tout ramassé) si bien qu'il va rattraper le précédent alors que Visulys avait prévu le même temps de trajet !

Prince des Tenebres a écrit:
Métronome a écrit:
de bêtes temps d'attentes, imprécis, et issus d'une estimation


.... et issus d'un algorithme de calcul déficient, incapable de prendre en compte la moitié des données disponibles !!

Métronome a écrit:
un plan synoptique, présente pour chaque station et interstation une diode


Moui, pas idiot. Sauf que là on parlait des bus à Paris, et ça veut dire qu'il faudrait mettre un panneau plein de LEDs sur chaque arrêt, c'est à dire en extérieur, et sur beaucoup d'arrêts il n'y a pas la place (ceux où il n'ya pas d'abribus), sans parler du prix de l'équipement et des frais liés à la maintenance (ou au vandalisme...).

Moi ce que j'aimerais bien c'est avoir accès aux données brutes (positions des bus en temps réel) et je fais le pari que je pourrais sortir un algorithme plus performant que celui qui existe. (Sans parler des possibilités d'applications iPhone).

Christobal, ton mystérieux inconnu pourrait-il faire quelque chose pour moi ?

Christobal a écrit:Ben tu as beau dire ce que tu veux, mais la seule connaissance de la position des véhicules en temps réel ne serait certainement pas suffisante...

Car le paramètre géographique seul n'apporte pas grand chose, il te manquerait le paramètre "vitesse" pour pouvoir en déduire un temps.

L'équation est bien connue : V = d / t, avec les combinaisons possibles d = V . t et t = d / V.

À moins que tu ne sois magicien, si tu ne disposes pas au moins de deux paramètres, je ne vois pas trop comment tu peux faire...

Et sachant que le paramètre "vitesse" est susceptible de variations totalement aléatoires et imprévisibles, ça ne facilite pas la chose !

Mais vu que tu sembles t'y connaître, peut-être pourrais-tu nous éclairer sur la façon dont tu pourrais traiter le problème ?  



PS : pour répondre à ta question : "Non"...

Prince des Tenebres a écrit:
JM-C a écrit:
il faut qu'il détecte les bus. Et pour des tas de raisons, il y en a qui ne le sont pas (perte du signal radio, émetteur en panne, voiture mal codée par le MR, bus pas équipé ...)

Ok, là on ne peut pas faire grand chose.

JM-C a écrit:
Si c'est une perte passagère du signal GPS (par exemple à cause d'un obstacle) et quand l'info revient, il peut y avoir une différence et donc le temps d'attente varie brusquement.

Oui d'accord ça doit pouvoir perturber le système. Mais moi dans Paris je ne perds jamais mon signal GPS, sauf dans les tunnels. Les problèmes que j'ai constatés étaient sur des parcours sans tunnels.

JM-C a écrit:
Et puis il y a le problème du livreur qui s'arrête brusquement et bloque le bus.

Dans ce cas je pense que l'estimation du temps de parcours devrait rester figée.
Par exemple un bus est à 5mn de l'arrêt, puis 4, et là... livraison !! L'affichage devrait donc rester sur 4 minutes.
En effet c'est le temps de parcours qu'il faudra lorsque le livreur aura fini, et on ne sait pas combien de temps il va durer donc on ne peut pas faire mieux.


JM-C a écrit:
Un autre exemple, à Lyon: les trams plantent régulièrement les bornes de C3 parce que si un trolley est à 100 mètres, Visulys l'annonce dans une minute et si par hasard, un tram arrive, le feu passe au rouge pendant 2 minutes s'il est loin et s'il en croise un autre. Et donc avec deux carrefours avec le tram (Cours Lafayette), on peut passer de 1 minutes à 5 ! Et ça se répercute sur les arrêts suivants alors que le C3 suivant peut très bien arriver sans être bloqué et à faible charge (le précédent ayant tout ramassé) si bien qu'il va rattraper le précédent alors que Visulys avait prévu le même temps de trajet !

Oui mais si on dispose des positions exactes en temps réel un bon algorithme doit en tenir compte. Quitte à afficher 2 minutes pour chacun des 2 bus qui sont maintenant cul à cul.

Pour résumer: je reconnais qu'on ne peut pas faire de prévision exacte.
Mais entre prévision approximative et prévision débile, il y a une ligne dont SIEL ne s'approche même pas? En effet indiquer 2 minutes alors que le bus est à l'arrêt, et on le sait, car on reçoit sa position indiquant qu'il est à l'arrêt, là, je ne vois pas d'excuse.

Ou alors ce sont des bus non équipés? Mais dans ce cas, yen a beaucoup, puisque ce genre de problème arrive régulièrement, et dans ce cas si on ne veut pas équiper, alors arrêtons aussi d'équiper les arrêts !!

Prince des Tenebres a écrit:
Christobal a écrit:
Car le paramètre géographique seul n'apporte pas grand chose, il te manquerait le paramètre "vitesse" pour pouvoir en déduire un temps.

L'équation est bien connue : V = d / t, avec les combinaisons possibles d = V . t et t = d / V.

À moins que tu ne sois magicien, si tu ne disposes pas au moins de deux paramètres, je ne vois pas trop comment tu peux faire...

Et sachant que le paramètre "vitesse" est susceptible de variations totalement aléatoires et imprévisibles, ça ne facilite pas la chose !

Mais vu que tu sembles t'y connaître, peut-être pourrais-tu nous éclairer sur la façon dont tu pourrais traiter le problème ?  


Ben ya plusieurs facteurs qui interviennent :

  • quelles sont les infos envoyées par les bus
  • tous les combien de temps


Je suppose que les infos arrivent sur un serveur quelconque.
Une autre question est donc :


  • à quelle fréquence les affichages sur les arrêts sont-ils remis à jour


Si un bus envoie sa position GPS exacte toutes les 10 secondes, le serveur a donc une assez bonne idée
de sa vitesse, en faisant par exemple une moyenne glissante sur les 10 derniers échantillons.

Le serveur est donc capable de remettre à jour son estimation toutes les 10 secondes.
Si l'arrêt va chercher les infos toutes les 30 secondes disons, ça veut dire qu'on peut avoir une info
remise à jour au pire toutes les 40 secondes. C'est déjà pas mal.

La difficulté est ensuite de faire un mix correct entre les estimations ainsi obtenues, et la position réelle.
En tout cas je garantis que mon algo n'indiquera pas 2 minutes d'attente si le bus est à l'arrêt !!!

Maintenant si les bus ne transmettent que toutes les minutes, là on a un problème.

Mais à la RATP on aime bien savoir où sont les bus donc ça doit être plus souvent que ça (enfin j'espère).
Je vais aller les voir tiens.

Christobal a écrit:Aux heures de pointe, il doit y avoir environ 3.800 bus en circulation. J'ose pas imaginer la taille du serveur si tous ces bus lui envoyaient leurs informations à une fréquence inférieure à 10 secondes !  Shocked

Après, je reviendrai quelques instants sur les contraintes techniques évoquées par JM-C.

Le bus est équipé d'un système lui permettant de définir sa position via le GPS. Il lui faut ensuite transmettre cette information au serveur. Ça nécessite donc que le système de localisation fonctionne, et que toute la connectique soit bonne pour envoyer les informations via son antenne.

En ce qui concerne SIEL, la transmission se fait a priori par liaison radio, si j'ai bien tout compris. Avec les risques de perturbations inhérents à ce mode de transmission.

Quand le signal parvient au serveur, il est mouliné avec tous les autres. Vu le volume d'informations à traiter, ça doit quand même prendre quelques secondes... L'information sur les temps d'attente repart ensuite, toujours par radio, vers les écrans aux arrêts. Avec de nouveau les possibles aléas sur la transmission de l'information...

Maintenant, depuis le début, je n'entends parler que des jours où ça ne fonctionne pas correctement. Mais en ce qui me concerne, d'une manière générale, je trouve tout de même que ça marche plutôt bien...  clown

Prince des Tenebres a écrit:
Christobal a écrit:
Aux heures de pointe, il doit y avoir environ 3.800 bus en circulation. J'ose pas imaginer la taille du serveur si tous ces bus lui envoyaient leurs informations à une fréquence inférieure à 10 secondes !  Shocked

Il faudrait savoir exactement quelles sont les données transmises.
Mais supposons :
4 octets pour le n° de voiture ce qui est énorme
4 octets pour le n° de ligne ce qui est gigantesque
8 octets pour la position GPS (2 nombres en virgule flottante sur 32 bits)
on est rendu à 16 octets à envoyer.

Ajoutons les entêtes, les cochonneries habituelles; on va dire 64 octets à envoyer par bus, c'est compté large.
Donc : 3800 * 64 = 243200 octets soit 240ko toutes les 10 secondes à recevoir par le serveur.
Ca ne me semble pas démesuré.

Ensuite bien sûr il y a le temps de calcul.
Imaginons qu'on ait 100 opérations (additions, multiplications, divisions) à faire à chaque fois.
3800 * 100 = 380 000 opérations toutes les 10 secondes soit 38 000 opérations par secondes.
Un Intel Core 2 Duo peut faire 22 GFLOPS (soit 22 000 000 000 opérations) donc ça laisse pas mal de temps
pour les tâches annexes comme recevoir les requêtes, envoyer les réponses, stocker tout ça.


Christobal a écrit:
Après, je reviendrai quelques instants sur les contraintes techniques évoquées par JM-C.

Le bus est équipé d'un système lui permettant de définir sa position via le GPS. Il lui faut ensuite transmettre cette information au serveur. Ça nécessite donc que le système de localisation fonctionne, et que toute la connectique soit bonne pour envoyer les informations via son antenne.

Oui on est d'accord, il vaut mieux que ça marche.

Christobal a écrit:
En ce qui concerne SIEL, la transmission se fait a priori par liaison radio, si j'ai bien tout compris. Avec les risques de perturbations inhérents à ce mode de transmission.

Oui, c'est forcément par liaison radio, puisqu'il n'y a pas de fil.
Il faudrait savoir quel genre de liaison radio. Du GPRS ? Un truc propriétaire? Quel est le débit ?

Christobal a écrit:
Quand le signal parvient au serveur, il est mouliné avec tous les autres. Vu le volume d'informations à traiter, ça doit quand même prendre quelques secondes... L'information sur les temps d'attente repart ensuite, toujours par radio, vers les écrans aux arrêts. Avec de nouveau les possibles aléas sur la transmission de l'information...

Voir mon calcul ci-dessus, fait à la louche, j'en conviens.

Christobal a écrit:
Maintenant, depuis le début, je n'entends parler que des jours où ça ne fonctionne pas correctement. Mais en ce qui me concerne, d'une manière générale, je trouve tout de même que ça marche plutôt bien...  clown

Bof bof.

Je ne prends pas le bus tous les jours, mais à chaque fois que je le prends, je trouve le fonctionnement bizarre.
Si c'est dû à des perturbations, ça veut dire que la techno employée n'est pas très fiable, parce qu'alors des perturbations yen a souvent !

Métronome a écrit:
Prince des Tenebres a écrit:Il faudrait savoir exactement quelles sont les données transmises.
Mais supposons :
4 octets pour le n° de voiture ce qui est énorme
4 octets pour le n° de ligne ce qui est gigantesque
8 octets pour la position GPS (2 nombres en virgule flottante sur 32 bits)
on est rendu à 16 octets à envoyer.

Ajoutons les entêtes, les cochonneries habituelles; on va dire 64 octets à envoyer par bus, c'est compté large.
Donc : 3800 * 64 = 243200 octets soit 240ko toutes les 10 secondes à recevoir par le serveur.
Ca ne me semble pas démesuré.
Toi tu fais sciences de l'ingénieur



Prince des Tenebres a écrit:Oui, c'est forcément par liaison radio, puisqu'il n'y a pas de fil.
Je suis pas d'accord. Il n'est nul besoin de rayonnements radio pour transmettre un signal sans fil, les possibilités sont nombreuses : satellite, infrarouge, induction magnétique, etc. Ensuite, c'est l'utilisateur qui choisit le mode de transmission le plus adapté.

Prince des Tenebres a écrit:
Métronome a écrit:

Je suis pas d'accord. Il n'est nul besoin de rayonnements radio pour transmettre un signal sans fil, les possibilités sont nombreuses : satellite, infrarouge, induction magnétique, etc. Ensuite, c'est l'utilisateur qui choisit le mode de transmission le plus adapté.


Oui enfin je me limitais à ce qui est raisonnablement utilisable par un bus. Le satellite c'est de la radio, l'infrarouge c'est a courte distance et il faut une ligne droite entre l'émetteur et le récepteur, l'induction magnétique il faut passer près d'un capteur. Sinon tu as oublié les signaux de fumée, le tamtam, et le télégraphe de Chappe. Laughing

Métronome a écrit:Perso ça m'étonnerait que les bus communiquent comme ça, mais on sait jamais

Prince des Tenebres a écrit:
Métronome a écrit:Perso ça m'étonnerait que les bus communiquent comme ça, mais on sait jamais

Ha ha , ça marcherait ptêtre un peu mieux !!

Nan, je suis méchant. Hier soir j'ai pris 2 Noctiliens et ya pas eu de problème. Ils ont dû lire ce fil.

Christobal a écrit:Non... C'est juste que... tu es... très mauvaise langue !  

Métronome a écrit:Sérieusement, en général ça a son efficacité. Si pour indiquer les temps il se sert d'une moyenne étalonnée par les bus précédents, alors c'est compréhensible. Si on a l'impression que ça fonctionne mal, c'est parce que quand ça fonctionne bien, on ne fait pas de remarque ; on ne retient pas ce qui nous paraît normal, par contre on se souvient de ce qui déclenche une émotion (j'ai vu ça dans Memoquiz  :noel: ).


J'ai réfléchi, et finalement je me suis dit que : 1) indiquer le  temps d'attente n'est pas très fiable ; 2) indiquer l'arrêt auquel le bus se trouve ne donne aucune idée de la durée : donc pourquoi ne pas donner une indication de la longueur restant à parcourir (avec éventuellement, écrit en petit, un estimation du temps nécessaire) ?

Christobal a écrit:Ou alors on ne se prend pas la tête : on ne donne rien du tout, comme avant...  

Je me souviens d'un séjour chez des amis au Pays de Galles il y a déjà quelques années. Je vais pour prendre le bus jusqu'à la ville voisine et consulte le poteau d'information. Ne trouvant pas d'horaire, je demande à une charmante dame qui attendait également. La réponse fut simple et sans appel : "Any time !".

Avec ça...  
avatar
quentin.51

Messages : 3937
Date d'inscription : 16/04/2014
Age : 25
Localisation : Reims

https://www.youtube.com/user/busreims51

Revenir en haut Aller en bas

Voir le sujet précédent Voir le sujet suivant Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum