Je créé ce topic pour garder trace des échanges avec Etcher et Demon, relatifs au développement de la V2 du KaTZ-Link.

Objectifs du Link-V2 : (par priorité)

1> Garder une stabilité aussi bonne que celle de la V1 (plusieures heures de mission sans déco)
2> Optimiser (si possible) la transmission d'information SIOC<>Pit
3> Permettre le multi connection (plusieurs pit sur un avion) (écolage+pilotage)
4> Mieux intégrer les commandes TS
5> Possibilité d'échange de documents, d'information en cours de vol.

Problèmes Connus avec la V1 :

1> Pause du Link (en écoute) en l'absence d'informations descendantes de SIOC (donc quand DCS est en pause)
2> Détection de la déconnexion du pit (ping-pong sur websocket), lent et imparfait (en particulier dans le cas 1)
3> Qui dit Link en pause , dit commande TS inactive (multithread séquentiel et non parallèle).


Status à compléter durant le développement

Ont peut pas mettre j'aime !

Discussion KaTZe-Etcher du 2015/02/11 dans la nuit



Merci,

Je propose dans un premier temps de calmer un peu le jeu, et de vérifier que çà tourne stable (EKPI + le KatzPit comme actuel).

Pour le Link, il faudra effectivement travailler sur la version multi, et en effet j’atteins ma limite de compétence avec "l’orienté objet" , c'est pour çà que je m’étais arrêté au mono-poste.
Of course ton aide, ou même ton développement sera indispensable.

Il faudrait qu'on discute plus généralement de l'architecture du Link-V2
J'ai pas mal galéré avec les socket bloquantes, vs non bloquantes, et la mise en place du ping-pong pour détecter une déconnexion et libérer la socket.



Coté WebSocket, lorsqu'on arrive dans la boucle d'envoi/écoute, je teste si la socket est ready (5ms):


Si elle a reçu un message du KaTZ-Pit, je le lis, sinon j'incrémente un compteur.
Si le compteur dépasse n boucles sans recevoir de nouvelle du pit (le seuil (pulse_ws), alors il considère qu'il est déco, ferme la socket et se remet en écoute).

Pour s'assurer de ce trafic montant, le Link envoi à SIOC un pulseur (l'heure de mission), sur le canal 9 , à chaque boucle. (Accessoirement ce pulseur indique à SIOC qu'on est en écoute prêt à recevoir des ordres (Sans lui SIOC nous déco).

Sioc avec un intervalle de 5 secondes, le copie sur le canal 8, et le revoie ainsi au Link , qui le transmet au Pit (sous la forme "8=heure"), dans le pit la réception de ce ping, déclenche une réponse pong sur le Canal 7

C'est dans la fonction serverws_message


Donc toutes les 5 secondes (soit 50 boucles de 0.1 secondes maximum), même si on n'effectue pas de commande DCS depuis le pit, Link recoit un message du Pit sous forme du pong. Le compteur de "boucles sans réponse" est ainsi réinitialisé.



Bref ce système de ping/pong réfléchi sur SIOC, fonctionne très bien et le système est super stable pendant des vols de plusieurs heures (c'est pour cela, que je suis super prudent avec les évolutions du Link).



Là ou j'ai un problème, çà n'est donc pas côté WebSocket, mais du côté "client SIOC, client TS"
Pour TS pas de problème, comme on ne fait qu'envoyer des ordres (out only), on flood en UDP sur TS. (D'ailleurs si on met au point un retour de canal TS, il faudra alors changer pour un système in/out ??)

Pour SIOC , on est en TCP

A) Les envois sont effectué par

Si çà plante on considère qu'on a perdu la connexion avec SIOC (ou qu'il n'est pas démarré, et le programme stoppe et part dans la boucle de connexion avec message à l'utilisateur, et tentative de reco toutes les 15 secondes.

Les réceptions sont effectuées par



Or, cette instruction est bloquante, tant qu'on a pas de réponse de SIOC, la boucle (et donc tout le Link est en pause là).
C'est ce qui explique que si l'on démarre SIOC, sans DCS, puis le Link et le Pit, la commande TS ne fonctionne pas. Le link est en pause, en attente de recevoir une info. de SIOC.

C'est pour çà que j'exporte toujours chaque seconde l'heure de mission depuis DCS, pour assurer un flux de données descendantes, et garder le Link actif. Ainsi dès la "dépause", le Link, et donc le contrôle de TS fonctionne.

La solution au problème, (que j'avais utilisé dans la KaTZ-Radio), était de ne plus écouter SIOC, et de désactiver le PingPong, et le Link tourne en boucle ... mais çà n'est pas applicable pour le Pit.

Pour la V2, il faudrait trouver une instruction NON BLOCANTE de client TCP, qui écoute la socket, et sans réponse passe à la suite.
A ce moment, le TS commande fonctionnera, même sans connexion SIOC.

Autre alternative, que j'utilise lorsque je travaille sur les pits, j'ai un générateurs de pulsation en python (que j'appelle "DCS-Shadows"), qui se connecte sur SIOC et créé un traffic descendant virtuel (comme si DCS était présent). Ce générateur pourrait être intégré au Link dans un thread spécifique, avec comme but de rebondir sur SIOC en évitant ainsi le blocage de la socket d'écoute.

A discuter ce pm si tu es là

Je suis en train de me documenter sur l'implémentation Qt des sockets abstraits. L'idéal serait d'utiliser des sockets TCP KEEP_ALIVE, de manière à les blinder complètement contre la déco.

La thread principale serait à l'écoute de demandes de connexion, et créerait des threads secondaires chargées de la transmission de messages. On fait ainsi sauter la limite de connexion d'une personne par pit. J'utiliserai des threads bloquantes en lecture de manière à économiser au maximum les ressources, avec 100ms entre les checks pour les join. L'écriture sera épisodique et sera déclenchée par signal, donc ne pèsera rien non plus. On a donc les avantages des deux mondes.

Il y aura un socket en écoute, un second dédié à la connexion avec SIOC (TCP KEEP_ALIVE), éventuellement un troisième pour TS, et des sous-socket spawnés par le premier pour gérer les connexions Pit entrantes. Ils ne se bloqueront jamais les uns les autres, et on peut faire transiter les chaînes de données via deux queues principales par élément (SIOC, TS, Pit). Le socket principal sera bloquant, étant donné qu'il n' a rien d'autre à faire que d'attendre les demandes de connexion et d'effectuer l'opération de transfert vers le sous-socket.

Tout ce petit monde vit chacun dans sa thread, et dès qu'il y a une déco ou un plantage on peut aller aux nouvelles via le socket principal pour demander s'il faut faire perdurer la connexion ou si la déco était volontaire. Dans le pire des cas on aura 50ms de désynchro.

J'ai déjà une bonne idée de la structure à donner au programme, la seule chose à changer de toute façon ce serait la couche réseau. J'espère juste que ce sera possible de faire passer la connexion TS en TCP, parce que le flood UDP c'est pas vraiment l'idéal niveau fiabilité.

Je laisse un peu EKPI vivre sa vie pour le moment, j'ai besoin des retours utilisateur sur les bugs actuels avant d'en ajouter de nouveaux, donc je vais commencer à travailler sur un draft d'une nouvelle version du link pour ce week-end, qu'on puisse décider ensembles d'une direction à prendre.

Tant qu'on y est on essaierait pas d'implémenter toute les fonctions du SIOC dans le Link ? Ce serait une étape en moins à l'installation.

Deux commentaires :

J'ai découvert les websockets grâce à Le Créole, et honnêtement en terme de fiabilité et sécurité c'est remarquable ... je ne pense pas qu'on ai intérêt à changer la relation Link-Pit qui fonctionne bien.

Quand au TCP en java bof bof ...; , à ce moment on aurait pu mettre le pit direct sur SIOC

Si l'on veut se passer de SIOC, il faut alors faire appel à la solution de LeCréole, qui consiste à directement créer la websocket dans l'export de DCS (plus de SIOC, plus de Link), mais on perd la commande TS, la compatibilité avec les pit en dur, ainsi que le debugging/developpement facile grace à la console IOCP.

Par ailleurs entre une gestion par SIOC qui est compilé et super stable, et cette merde de Lua, je n'hésite pas une seconde.

Perso, j'aime bien SIOC, je le démarre avec le PC, et je n'y pense plus, çà bouffe rien et c'est quasi instantané
Idéalement il aurait fallu un SIOC/WebSocket compilé, stable, direct sur DCS, et autant de clients que désirés

Ok donc on garde SIOC.

Qu'est-ce qu'il a le TCP en Javascript ? Il est juste lourd à mort comme tout le reste de Java ou il est complètement pourri ?

Plussoiement

Bon, ben le père Noël (Etcher) est passé cette nuit vers 3hr du matin

On test et on vous tient au jus, mais sur le papier, c'est une tuerie "teaser inside"

Petit test rapide du KaTZ-Link V2 (qui devrait s'appeler Etch-Link V2 maintenant), c'est juste impressionnant.
Etcher a réussit à diviser le timing du programme par un facteur 10 (de 200ms à une 20aine de ms).

Du coup le KaTZ-Pit fonctionne en quasi instantané, avec rotation immédiate et fluide des cadrans

En prime :

> traitement multipit, je viens de faire un vol avec 4 pit connectés
Ce qui vous donne la possibilité de mettre les cadrans sur un écran html, et les menus sur un autre, et à plusieurs personnes de suivre votre vol "live".

> gestion du DCS focus pour rendre à DCS le focus quand vous avez clické sur le pit
le timing du focus est réglable sur l'interface

La détection des connection/déconnection des pits est instantanée, et suivie par une interface graphique
Cliquez pour voir le fichier-joint

On va donc s'attaquer aux tests de stabilité maintenant, et en multipit via internet

Miaouououou

Ah ouai la sa envoi du ours a poster en news extrême la !!!! Hate de tester!!!!.

Indeed, j'ai testé ce matin sur FC3, et sur le Mi-8 qui est un des plus complet ... c'est juste parfait
Etcher a bossé comme un malade

Grâce à SIOC qui filtre les exports en n'envoyant "que ce qui bouge", on a un flux limité à l'utile et donc super light et rapide.
Maintenant le bottleneck deviendra le timing des boucles d'export de DCS.
Pour que vous puissiez ajuster en fonction de votre config, on va mettre çà dans le GUI

Bref, le projet est quasiment terminé

A moi maintenant de continuer de compléter au fur et à mesure les panels de commande hélico (armement Mi8, Nav, Light, PVI800 et réglage LLTV du KA, Nav. du UH-1 ...)
Et aussi à compléter la gestion de documents de vol

Faut aussi écrire une sorte de user manual

Alors le comble: maintenant, le KatzePit affiche les infos avant le cockpit dans DCS

Ont attend la rélease !!!! ^^

C'est en test avec Katze, si on ne lève pas de lièvre d'ici à ce soir je lancerai une alpha publique =)

Premier test copilote:

Katze à Marseilles, Etcher en Belgique.

J'ai démarré son hélico à partir du KatzePit, avec un second KatzePit ouvert chez lui également.

On a connecté 10 KatzePit sur le même hélico =)

Retour des clics instantanés, aucune latence.

Impact performances insignifiant du côté du client, aucune différence avec ou sans.

Ça commence à sentir bon, je sors la tractopelle pour tenter de déterrer la gonade cachée dans le pâté ...

A nous les copilotes et les instructeurs !

C'est bon ça pour les trainings sur du full cliquable ! ^^ et training approche etc ! ça permet de voir les taux de descente, vitesse, etc . Good (et de faire des panne ) mais faut pas le dire .

Ouverture de l'alpha publique.

Téléchargement manuel ici: https://github.com/etcher3rd/Link/releases (lancer à la place du KatzeLink habituel).

Installation via EKPI possible, sélectionner le repo "etcher" (en haut à droite) et mettez à jour le "KatzeLink" uniquement (ignorer le reste de mises à jour). Revenir ensuite sur repo "Katze" pour mettre à jour le reste si nécessaire.

Si le LinkV2 ne fonctionne pas, ou fonctionne mal, retour à la V1 via EKPI: sélectionner le repo "Katze" et mettez le Link à jour.

Petite question (Bouling ?), relative aux altimètres affichés dans FC3 ....

Avec le pit j'ai les exports suivants de possibles :

> L'altitude extraite de la position xyz de l'avion
local objPlayer = LoGetObjectById(LoGetPlayerPlaneId())
local altitude = objPlayer.LatLongAlt.Alt

> L'altitude Baro exporté par
local altibaro = LoGetAltitudeAboveSeaLevel()

> L'altitude Radar
local altirad = LoGetAltitudeAboveGroundLevel()

> Le calage de l'altibaro
local QNH = LoGetBasicAtmospherePressure()

Pour le moment, mes pits sont alimenté en numérique et analogique pour l'altibaro par LoGetAltitudeAboveSeaLevel(), cette altitude est identique à l'altitude de la vrai position (xyz)

On peut faire varier le calage de l'altimetre dans le jeu de 710mmhg à 810mmhg, mais çà n'impacte pas l'export LoGetAltitudeAboveSeaLevel().
Ainsi donc, contrairement à Belsitec, FC3 exporte les valeurs exactes et non les indications du pit.

Par ailleurs, l'altimetre du pit, même calé correctement au QNH sur la piste (exemple 1013 ou 760mmhg, devient faux avec l'altitude. Il faudrait le recaler à 1031 hPa à 8000m pour qu'il indique une altitude correcte.

Donc si je veux que le pit soit raccord avec ce que le pit du jeu affiche il faudrait :
1- que je recréé cette erreur (Le problème c'est que je ne sais pas si c'est une erreur linéaire, ou une formule avec la température etc etc ???)
2- que je modifie l'indication avec le calage (çà c'est facile).

Donc mes questions sur le sujet :
a) comment vous avez géré çà avec LOTACT (je suppose position xyz ?)
b ) quand vous mettez un ravito dans une mission, à quelle altitude vole t'il (xyz, fl, qnh ?)
c) que voulez vous dans le pit, une altitude correct, une altitude avec calage QNH, ou que j'essaye de reproduire l'erreur d'affichage de DCS ?

Miaou

a)

Bienvenue dans les méandres de DCS... Il y a un moment, il faut prendre la pilule et accepter son sort ^^

LotAtc utilise la position z des objets. Tant qu'on aura les avions en papiers FC3 (troll inside), ça fait partie des problèmes (tout comme les true/magnétic heading). Vu que la majorité des pilotes sont sous FC3, il faut s'adapter...

Et tu peux me tutoyer ^^

Retour pour le KaTcher-Link V2 alpha4 en SU-25

Très bon comportement durant 3 heures de misssion. Pas de déco, très bonne fluidité.

Un niveau des bugs:
-HSI: les aiguilles indiquent des caps décalés de 20° par rapport au simu. Le cap de l'appareil est juste, le delta entre les aiguilles l'est aussi.

-Gmetre: à 1G ingame, le pit affiche 2.5G.

Le pit est très agréable, je pense que je vais finir par caler les écrans l'un sur l'autre.

Bref, super boulot les gars!

Merci Dart

Etant donné, ta réponse, pour le moment je propose de rester avec l'export de l'altitude tel quel.
On aura donc correspondance LoTact / KaTZ-Pit et je pense mission (à confirmer par les requins ref. la question du niveau de vol des ravitailleurs).

J'ai cependant exporté le calage QNH de l'altibaro (pour faire zouli )



This waved aside, nouvelle release avec :

> le pit complet pour le SU27 (je les avaient oublié ceux là )
Par contre, pas d'export des flaps sur le 27 , allez savoir pourquoi ???

> Machmètre SU33, 27 opérationnel (indique les valeurs vrais de l'export).
J'ai réussi à reproduire le mécanisme de l'aiguille + disque , plus le cache pour les basses vitesse, c'est mignon tout plein.

> Ajout du calage QNH de l'altibaro (à discuter si on le rend actif )

Miaou



Merci Bouling,

Je dois encore ajouter l'altiradar sur le 25, pour être conforme au pit de la trapanelle.

Je regarde les point de l'HSI et Gmetre à cet occasion (cette nuit normalement) (c'est super bizarre çà ???)

PS : tu as bien fait attention que le G-Metre du Pit a 3 aiguilles
G-Max durant le Vol : Aiguille Rouge
G-Min durant le vol : Aiguille Bleu
G-Actuel : Aiguille Blanche

Miaou

Tu me mets le doute maintenant, mais pour moi oui c'est bien l'aiguille blanche qui avait les bonnes variation de G mais avec un décalage de 2.5G

PS: Merci pour le machmetre!

Avant de relancer le jeu pour être sur qu'on a pas eu de bug d'export, peux tu me sauvegarder :
> le DCS.log, (qui est dans saved games/DCS/log
> le KTZ-SIOC5010_ComLog-20150215-hhmn.csv qui est dans saved games/DCS/log/KatzePit ?

Merci

Alors:
dcs.log
Log KatZe

La dream-team:

Merci Bouling,

C'est ce que je craignais, on a eu une erreur sur la boucle lente.
Faut que j'essaye de comprendre ce que çà peut bien être.

Le problème avec cette S...perie de Lua, c'est que suivant les erreurs, soit il plante tout l'export, soit il va faire planter quelques lignes ... soit il va fausser certaines valeurs ... totalement incompréhensible.
Le problème c'est déjà que j'arrive à reproduire vos erreurs.

Je me demande , si en fonction du la version de Lua installé sur la machine, si on a pas des comportements différents. Il se pourrait que le lua fourni avec l'install de DCS soit différent de celui que j'ai sur ma machine (d'où le fait que je n'ai aucun plantage).

Je te tiens au courant
Miaou

Intégration de la V2 (alpha) dans la branche principale, tous les utilisateurs auront la nouvelle version installée par défaut.