aircockpit.com

Avant tout merci
Je mesure le travail réalisé de Jean-Luc depuis les premières versions
et le plaisir que vous nous donnez à chaque mise à jours
ainsi que la documentation que je trouve très importante,
et que tu tiens à jour avec Jean-Luc et qui évite souvent de reposer les mêmes questions.
Merci aussi à toi Michel

je realise plusieurs project avec des arduinos les deux "mcdu"


et l''ECP


APE 5100





Actuellement 100 /100 compatible et que pour FMGS A320

aujourd'hui, j'aimerai réalisé les ACP ainsi que les RMP
Jean-Luc a parlé un jours qu'il réfléchi sur une possibilité de réalisé une passerelle vers USB


De plus, nous pouvons à se jours proposé à Jean-Luc un protocole puissant de communication entièrement écrit et surtout documenté et 100/100 libre d'utilisation sans aucun droit qui pourrais realiser cette tache.
pour plus d'information je me tiens à votre disposition!

à vous Jean-Luc et Michel

Bonsoir Laurent,

Seul Jean Luc pourra te répondre sur cette proposition.

Effectivement, je crois qu'il avait évoqué ce sujet de passerelle il y a quelques temps...
De souvenir, il avait fait part d'un certain nombre de fonctions non modélisées dans FMGS, au niveau des ACP et RMP. On retrouve d'ailleurs ces limites dans le Manuel Experts, au chapitre (6) traitant de la connexion avec les modules OC.

Personnellement je n'en sais pas davantage, mais le sujet est intéressant.
Tu m'en apprendras certainement, le cas échéant, le moment venu... .

D'autant que je m'arrache parfois les cheveux avec les caprices du Profiler Skalarki... mais c'est une autre histoire...

@++ ,
Michel

Bonjour à vous tous, JeeHell, Michel, Lolo et les autres.

Je confirme les propos de Lolo:
Nous sommes quelques uns à faire notre hardware sur la base d'ARDUINO
et somment tous "coincés" par le nombre limité de variables circulant sur FSUIPC.
Nous avons bien concience que FSUIPC ne permet pas de donner accès à toutes les données de A320FMGS.

Sollicité l'été dernier à ce sujet, JeeHell a été très clair: pas de nouveaux offsets pour des données type ACP.
Mais il n'a pas fermé la porte à la livraison d'une release qui permetterait de communiquer directement avec nos chères cartes à microcontroleurs.
Depuis, nous "guettons" la sortie de chaque release.

Autant dire qu'en voyant que la V50 s'ouvrait à l'acquisition de joysticks déportés, j'ai été plus qu'attentif.
Merci JeeHell pour cette évolution.

Reste que nous rêvons quand même toujours pouvoir adresser toutes les données présentes dans FMGS_Config.exe (voir d'autres encore) avec nos petites cartes ARDUINO, par quelque média que ce soit.

A ce sujet, le protocole de com auquel Lolo fait référence est "SimCom", une couche de communication TCP/IP que j'ai dévellopé il y a une dizaine d'années,
livrée sous la forme d'une simple dll, et aussi simple d'utilisation que possible:

il suffit dans le serveur de déclarer les données à mettre à disposition -une seule ligne de code c# ou c++, c'est tout.
Les clients interressés, dans leur code, se connectent au serveur à l'aide d'une seule ligne de commande et s'abonnent aux différentes données souhaitées.
Le processus de connexion / déconnexion / reconnexion / diffusion est transparent (géré par simcom dans des threads indépendants...)

Je l'utilise sans modération pour mon simu perso, pour partager des données entre mes différents softs.
Tous type de donnée peuvent êtres déclarées: events, bytes, int16, int32, double, string...

Il n'y a pas de limite au nombre de données partageables. Il n'y a qu'à les déclarer dans le serveur.

JeeHell, si toutefois tu étais interressé, dis le moi, je te transmettrait mon dossier d'étude et mes sources.
Les spécifications de la version c# de simcom (appelée simcomnet) sont même disponibles sur le web ici:
https://simua320.jimdo.com/app/download ... 1507569943

Quand aux sources en C# ils sont disponibles ici:
https://drive.google.com/open?id=0B-G_3 ... 0twaE03TGc


Simcom existe en deux versions:
C++
C#

Ayant repris mes softs en C# depuis quelque temps, c'est bien évidement la version C# que j'utilise aujourd'hui.
La version C++ est plus ancienne, je l'utilisait pour mon simu version 1, avant de connaître le travail de JeeHell.
Son fonctionnement est semblable à celui de la version C#.
Elle doit être, à ma connaissance, stable.
En tous les cas, si elle ne l'était pas, je me chargerais de sa maintenance, de ses évolutions, si JeeHell n'a pas le temps...
Le code est libre de droits, je le donne pour la bonne cause.

Et ceci nous permettrait à nous tous d'accéder à toutes les données A320FMGS à volonté depuis nos modestes petits softs à nous...

Merci encore à JeeHell et à tous ceux qui travaillent à ses coté au développement, à la documentation et à la diffusion de ce merveilleux projet.

David.

Hello

Désolé pour la réponse tardive, mais en ce moment la seule chose dont je ne manque pas c'est de boulot...

Je ne suis toujours pas contre un module port COM générique. je ne sais pas encore quel format/protocole cela va utiliser, j'en suis assez loin dans ma roadmap...

David, ton protocole Simconn, tu as quoi comme performance avec? (latence, quantité max de données envoyées par seconde ?)

A+
Jean Luc

Hello JeeHell.
Coté performances de simcom, je ne sais pas exactement.
Pour tout dire, ça marche, je n'ai jamais essayé d'en savoir d'avantage...
...et pire, je ne sais pas comment mesurer les temps de latence ou la quantité d'informations qu'il est possible d'envoyer dans le tuyau en une seconde.

Ce que je connais, c'est le contenu de chaque message: Je l'ai optimisé autant que possible.
Ainsi, une fois la donnée abonnée (2 échanges d'une trentaine d'octets pour l'abonnement),
la trame de mise à jour de la valeur d'une donnée est très petite, il faut compter 8 octets de définition de la donnée,
un octet de qualité et ensuite la valeur elle même, donc pour un int16 on est rendu à 11 octets:
1 : int16 : taille du message en octets (11 octets)
2 : int16 : function code (2 : FCCODE_UPDATEVALUE)
3 : int16 : datatype (type de la donnée : TYPE_INT16 : 1)
4 : int16 : datarow : index de la donnée dans la table du client
5 : octet : qualité
6 : int16 : Valeur.

C'est donc de tout petits messages, ça tient clairement dans un seul packet TCP/IP.

Dans sa version C++, j'utilise les sockets de l'API WSA windows, je ne maitrise pas ce qui se passe derrière,
mais ça a l'air d'être assez bas niveau donc ça doit être plutôt rapide.
Les performances doivent surtout être liées au hardware réseau(type de carte ethernet, qualité des câbles, des switches...)

Dans la version C#, j'utilise les TcpListener de la librairie System native.
Il est certain que c'est d'un niveau plus élevé, avec des performaces certainement moindres, qui dépendent cette fois
non seulement du matériel réseau mais également de la technologie (Intel, AMD...), de la fréquence du processeur, et de la version du .net framework installé...

Concernant les temps de traitement hors réseau (internes à Simcom donc) ce sont de petites fonctions très simples, avec une hiérarchie très 'plate'.
Ca doit donc être également assez véloce, d'autant que chaque donnée est directement connue par son rang dans un tableau: il n'y a pas de temps consacré à rechercher une donnée dans une liste par parcours de toutes les occurences, par exemple.

Dans l'idée, l'envoi d'une donnée est évennementielle, il n'y a pas de temps de traitement autre que celui de la fonction qui met en forme la trame et qui passe un 'send()' à la socket.
Pour ce qui est de la réception, il y a un thread qui tourne en permanence et qui réagit dès qu'une donnée est présente sur la socket attribuée.
Les quelques octets sont lus et le traitement se borne à les mettre dans une structure, et d'agir avec un pauvre "switch case" en fonction du type de donnée arrivant. De la même manière que pour l'émission, la donnée est directement identifiée par son rang dans un tableau: pas de temps de recherche de la donnée destination, pas de fioritures, je vais à l'essentiel.

Après,de là à mesurer ces temps...

Tout ça pour te dire que je ne sais pas te donner les performances réelles de Simcom, mais elles me paraissent être suffisante pour bon nombre d'applications clientes.

Merci en tous cas pour l'intérêt que tu as porté à mon message, ça m'a fait très plaisir.


A ta disposition pour toute question complémentaire.
David.