Version B50.x

[tabar57]

De mémoire et pour l'appliquer , une ligne Kill : nom du process dans Fsuipc.ini devrait pouvoir régler le problème

Cordialement

Bernard

[gegene89]

ok Michel, je ferais cette manip.
pour tout
gérard

[Paul-Henri]

Bonjour Jean-Luc !

Pour notre simulateur nous avons développé un module RMP hardware (le précédent venait de chez FDS, mais ne comportait que 5 digits pour les fréquences et les boutons VHFx etc étaient fictifs...). Notre hardware s'interface uniquement par Ethernet (nous ne sommes pas très friands de l'USB). Nous nous sommes donc interfacé avec ton logiciel via SIOC (nous fournissons les variables SIOC d'entrées (encodeurs rotatifs, boutons) et nous consommons tous les leds (digits, décimales, leds).
Au début je craignais un peu d'avoir du retard introduit par le réseau lorsqu'on tourne rapidement les encodeurs, mais il s'avère que ça fonctionne très bien (fluide). Du coup, je me repose complément sur ta logique (merci pour le travail !).

J'utilise ta version 50.2. Durant les essais j'ai noté les points suivants:

1) Fréquences:
Lorsqu'on est en mode VHF1/VHF2/VHF3, l’incrément des khz sur les standby se fait de 5 en 5, sauf pour certaines valeurs pour lesquelles on observe des sauts : on a 0,5,10,15 puis on saute à 25, 30,35,40 puis on saute à 50, 55,60,65 puis on saute à 75, 80,85,90 puis on saute à 100,etc... L'affichage coté RMP logiciel est correct, mais je pense qu'on observe un soucis avec les variables SIOC.

2) Affichage de la décimale:
Pour chaque fréquence (active et standby) il y a 3 variables SIOC qui précisent si la décimale du digit est allumé ou non.
J’ai noté les points suivants:
• Pour le RMP 1, je ne reçois pas la variable RMP1Stby2_Dec.
• Pour le RMP 2, je ne reçois pas la variable RMP2Act2_Dec.
• En mode NAV, en VOR/ILS ou ADF, la décimale reçue pour la fréquence active et standby n'est pas au même endroit
Ex :VOR - ACTIVE 109.65 – STBY 117.85
RMP2Act_Dec =0
(Pas de RMP2Act2_Dec car le serveur ne la reçoit pas)
RMP2SAct3_Dec =1
RMP2Stby_Dec =0
RMP2Stby2_Dec =1
RMP2Stby3_Dec =0

3) Affichage du mot "DATA"
Pour l’affichage de la fréquence en mode VHF3, s’il n’y a pas de fréquence le message « DATA » est affiché. On ne sait pas faire le "T" avec nos afficheurs 7 segments, donc j'ai décidé d'afficher dans ce cas "----". Les variables SIOC reçues dans ce cas sont:
Pour le « D » la valeur -999995.
Pour le « T » la valeur -999996.
Pour le « A » la valeur 4.
La valeur correspondante du "A" me pose un petit problème car je ne sais pas, sans analyse des caractères reçus précédemment, faire la différence entre le 4 d'une fréquence (140.000) et la 'A' de DATA.

Je ne sais pas si quelqu'un a rencontré les mêmes petits problèmes ?
De mon côté je peux toujours remettre l’intelligence dans notre module, mais je risque de me désynchroniser avec tes données et donc avoir un affichage sur le ND incorrect.
Je voulais savoir ce que tu en pensais que je puisse décider si je reste en mode "esclave" complet ou si j'implémente la logique RMP dans mon module.

Merci encore Jean-Luc pour cet énorme travail !
A bientôt.
Paul-Henri

[JeeHell]

Hello Paul-Henri,

1) Fréquences:
Lorsqu'on est en mode VHF1/VHF2/VHF3, l’incrément des khz sur les standby se fait de 5 en 5, sauf pour certaines valeurs pour lesquelles on observe des sauts : on a 0,5,10,15 puis on saute à 25, 30,35,40 puis on saute à 50, 55,60,65 puis on saute à 75, 80,85,90 puis on saute à 100,etc... L'affichage coté RMP logiciel est correct, mais je pense qu'on observe un soucis avec les variables SIOC.

Non c'est bien le comportement normal des radios "8.33khz". Comme tu ne peux pas afficher 120.00833, il arrondi à 120.010. Du coup, 120.005 correspond à la fréquence 120.000 en 8.33, là où 120.000 affiché utilisera la même fréquence mais en mode 25khz!! afin de garder la compatibilité (en interne, la radio utilise une bande passante plus grande sur le 25khz).

2) Affichage de la décimale:
Pour chaque fréquence (active et standby) il y a 3 variables SIOC qui précisent si la décimale du digit est allumé ou non.
J’ai noté les points suivants:
• Pour le RMP 1, je ne reçois pas la variable RMP1Stby2_Dec.
• Pour le RMP 2, je ne reçois pas la variable RMP2Act2_Dec.
• En mode NAV, en VOR/ILS ou ADF, la décimale reçue pour la fréquence active et standby n'est pas au même endroit
Ex :VOR - ACTIVE 109.65 – STBY 117.85
RMP2Act_Dec =0
(Pas de RMP2Act2_Dec car le serveur ne la reçoit pas)
RMP2SAct3_Dec =1
RMP2Stby_Dec =0
RMP2Stby2_Dec =1
RMP2Stby3_Dec =0

Là comme ça je sais plus trop, mais chaque mode à sa décimale mise à un endroit différent.
Je regarderai si une des variables manque à l'envoi.

3) Affichage du mot "DATA"
Pour l’affichage de la fréquence en mode VHF3, s’il n’y a pas de fréquence le message « DATA » est affiché. On ne sait pas faire le "T" avec nos afficheurs 7 segments, donc j'ai décidé d'afficher dans ce cas "----". Les variables SIOC reçues dans ce cas sont:
Pour le « D » la valeur -999995.
Pour le « T » la valeur -999996.
Pour le « A » la valeur 4.
La valeur correspondante du "A" me pose un petit problème car je ne sais pas, sans analyse des caractères reçus précédemment, faire la différence entre le 4 d'une fréquence (140.000) et la 'A' de DATA.

Je ne sais pas si quelqu'un a rencontré les mêmes petits problèmes ?
De mon côté je peux toujours remettre l’intelligence dans notre module, mais je risque de me désynchroniser avec tes données et donc avoir un affichage sur le ND incorrect.
Je voulais savoir ce que tu en pensais que je puisse décider si je reste en mode "esclave" complet ou si j'implémente la logique RMP dans mon module.

Tu n'auras pas le choix que de remettre un peu de logique.
Tu peux éventuellement mettre la logique dans une autre variable SIOC que tu liras en place des miennes (qui afficheront les --- si tu détectes DATA sur l'ensemble des afficheurs).

A+
JL

[Paul-Henri]

Bonjour Jean-Luc !

1) Merci pour cette précision. Je n'y avais pas pensé !
2) OK, merci.
3) Pas de problème, je garde un peu de logique chez moi.

Merci encore et à bientôt !
Paul-Henri

[Paul-Henri]

Bonjour Jean-Luc,

J'ai encore une petite question concernant les RMPs.
Voici ce que j'observe:
Si je suis en mode NAV/VOR sur le RMP CPT, après transfert de la fréqence du VOR, je peux sélectionner la course. Lorsque je tourne le bouton du RMP CPT, j'ai bien la course qui se modifie sur l'afficheur du RMP, et sur le ND CPT (mode VOR), on voit bien tourner la course.
Ce que je constate dans ce mode, c'est que quand je tourne le bouton (du RMP CPT), si je suis en mode NAV/VOR, sélection de la course sur le RMP FO, je vois également la course s'afficher sur les digits du RMP FO... Par contre, sur l'affichage du ND FO (mode VOR), rien ne bouge (fct normal).
Si maintenant je veux sélectionner une course du VOR sur le RMP FO, lorsque je tourne le bouton, je vois bien l'affichage du ND FO tourner sur l'écran en fonction de mes actions sur le bouton, mais par contre mon affichage au niveau des digits du RMP FO ne bouge pas.

Cela te dit-il quelque chose ?
Merci et à bientôt !
Paul-Henri

[JeeHell]

hello Paul Henri,

Surprenant, le RMP1 devrait controler le VOR1 affiché au ND1 et le RMP2 le VOR2 affiché au ND2... donc bizarre que ça te fasse ça, je vais regarder de plus près...

[JeeHell]

C'est bon c'est corrigé pour la prochaine version

[tabar57]

Bonjour,

Même si je ne suis pas Airbussien, je suis admiratif devant ta réactivité JL, ah si on pouvait avoir la même en payant ce serait bien.
C'est bien sûr un trait d'humour mais en tous cas chapeau ...

Cordialement

Bernard

[arcc]

je suis admiratif devant ta réactivité

Ca c'est bien vrai. Je plussois.

Christian