Bug Mesure

[heligone]

je documente ici l'exemple d'une mesure à 1000 survenue le 20 mai 2018 sur le device2 à 1h51 (soit 23h51 heure universel sur le log texte

Wakeup @ 2018-05-19T23:51:09Z 1393-1392-1392-1396-1395-1393-1395-1396-1396-1395-Distance brute: 139.50 1385-1395-1395- Wakeup @ 2018-05-19T23:51:19Z 9971-9970-9972-9972-9970-9969-9971-9971-9970-1605-Distance brute: 997.10 1395-1395-9971- Wakeup @ 2018-05-19T23:51:29Z 9972-9971-9971-9969-0-9969-9972-9971-9969-9970-Distance brute: 997.10 1395-9971-9971- 1395-9971-9971- Temperature : 12.90 Hygrometrie : 78.30 Batterie : 3.57 [{"epoch":"1526773890","key":"range","value":"997.10"},{"epoch":"1526773890","key":"temp","value":"12.90"},{"epoch":"1526773890","key":"hygro","value":"78.30"},{"epoch":"1526773890","key":"vbat","value":"3.57"}] HTTP Response : 204 Header Date:Sat, 19 May 2018 23:51:36 GMT Header Server:Apache/2.4.25 (Debian) Header Location:/device/GSM-357520074275682/samples Header Connection:close Body: Wakeup @ 2018-05-19T23:51:42Z 1408-1410-1410-1408-1407-1410-1410-1408-1410-1410-Distance brute: 141.00 9971-9971-1410- Wakeup @ 2018-05-19T23:51:52Z 1410-1408-1408-1408-1408-1407-1407-1405-1404-1404-Distance brute: 140.80 9971-1410-1408- Wakeup @ 2018-05-19T23:52:02Z 1401-1401-1400-1397-1398-1400-1400-1398-1399-1401-Distance brute: 140.00 1410-1408-1400- 1400-1408-1410- Temperature : 12.90 Hygrometrie : 78.30 Batterie : 3.57 [{"epoch":"1526773923","key":"range","value":"141.00"},{"epoch":"1526773923","key":"temp","value":"12.90"},{"epoch":"1526773923","key":"hygro","value":"78.30"},{"epoch":"1526773923","key":"vbat","value":"3.57"}] HTTP Response : 204 Header Date:Sat, 19 May 2018 23:52:09 GMT Header Server:Apache/2.4.25 (Debian) Header Location:/device/GSM-357520074275682/samples Header Connection:close Body: Wakeup @ 2018-05-19T23:52:15Z 1404-1403-1402-1405-1404-1403-1404-1401-1403-1404-Distance brute: 140.40 1408-1400-1404-

[heligone]

Apperemment le filtrage n'est pas en cause

à 2018-05-19T23:51:19Z et 2018-05-19T23:51:29Z

on a des séries de 10 mesures brutes défectueuses

Bien que la série précédente soit OK, cela fait que l'envoi GPRS suivant est défectueux malgré le second filtrage

Note : quand on enverra les mesures GPRS tous les quarts d'heure, je pense qu' il ne faudra pas faire le second filtrage pour ne pas que les mesures des 2 quarts d'heure précédent influe sur la mesure en question.

[heligone]

Je relance un test sur device 2 avec

• une mesure brute toutes les 10 secondes
• chaque mesure brute est un filtre mediane sur 21 mesure matérielels du capteur
• Envoi GPRS toutes les 6 mesures brutes soit toutes les minutes (pour éviter un bug d'affichage du graphe si on envoi plisueurs mesures dans une minute
• pas de filtrage sur la mesure envoyé GPRS : l'analyse ci dessu montre que cela n'a pas évité l'envoi GPRS d 'une mesure défectueuse. De plus, lorsqu'il y aura envoi tous les 1/4 heures, il n 'est pas utile de mélenager par un filtre médiane les mesures de 3 quart dh'eure successifs

[heligone]

clos suite à cet échange d'email et commit du 23/05

Oui, je crois que ce que tu proposes correspond à ce que j’ai écrit de façon compliquée.

Pour être plus clair, je propose de distinguer une fois pour toute :

• mesure brute : résultat de la primitive de mesure du capteur – renvoie une valeur entre 0 et 1000
• mesure encadrée (mesure matérielle dans mon message précédent, mais encadrée semble plus clair) : un résultat de mesure entre 600 et 900 (mesure brute OK) , et 0 en cas de toute autre valeur (mesure brute NOK)
• mesure filtrée[n] : résultat d’un filtre par médiane sur un train de n mesures encadrées n = 25 pour fixer les idées

L’idée est de ne faire un filtrage que sur une train de n=25 mesures « encadrées » toutes non nulles (un train de mesure « valide »), ce qui n’est jamais garanti, d’où le time out, ou bien comme tu proposes un nombre maximum de 125 mesures « encadrées » pour générer un train de mesures matérielles valide pour filtrage

Je proposai simplement en plus de refaire un train de (au maximum 125) mesures encadrées si le premier train ne permet pas de faire un filtrage valide. Si on n’arrive pas à obtenir un train de mesure encadrées valide pour le filtrage –> Erreur

Conclusion : Ok avec ton idée

Je me repète inline ci dessous

@@@

Sam

-- Bon je note :

• ne pas envoyer de valeur à zéro, Oui, renvoyer plutôt un NULL
• alerter en cas d'échec, Oui, logguer sur la base une erreur de capteur telemetre
• augmenter le nombre de mesures pour obtenir une valeur valide. de quelle mesure parles tu ? on n’est jamais assurer d’avoir une valeur non nulle pour une mesure encadrées ni même pour une succession de mesures encadrées, qui peuvent être toutes à 0 . Augmenter le nombres de mesures encadrées dans un train de mesure réduit la proba d’erreur, mais l’erreur reste possible --> voilà pourquoi il faut une time out, ou bien comme tu proposes un nombre maximum de mesures encadrées pour générer un train de mesure valide pour filtrage

1- J'ai déjà fait x2 sur le nombre de mesures ; allons jusqu'à x5 au maximum sachant que l'on ne conserve qu'au plus les 25 premières mesures valides pour faire la médiane et cela chaque minute ;

• de quelle mesure parles tu ? les mesures matérielles sans doute. Tu proposes donc de faire au maximum 125 mesures encadrées, sachant que dès que tu en as 25 valides, tu lances le filtrage par médiane ? C’est ok pour moi Je proposai simplement en plus de refaire un train de mesures encadrées si le premier train ne permet pas de faire un filtrage

2. ajouter l'envoi de trame d'erreur à l'issue de chaque échantillon (médiane) à 0 Oui
3. ne pas remonter de mesure à zéro. oui Ça va ça ?

Oui :) (Sous réserve que j’ai bien compris ce que tu proposes)

Marc

Marc Sibert marc@sibert.fr

Le 26 mai 2018 à 10:20, PROXY Informatique - Samuel BERNARDET contact@proxy-informatique.fr a écrit : Salut Marc,

Malgré le train de mesure à 25, il y a des cas où la mesure filtrée est à 0 : ce qui signifie que 25 mesures matérielles successives sont à 0.

Je propose la stratégie suivante, où pour fixer les idées (ce qui est déjà implémenté):

• on effectue une mesure brutes par minutes
• on envoie un gprs tous les ¼ h et en cas d’alerte
• une mesure matériel du capteur renvoie une valeur entre 60 et 900 cm, ou bien zéro en cas d’erreur

Donc, à chaque changement de minute (t=t_m) , on lance l’opération de mesure suivante

• on effectue un train de mesure jusqu’à ce qu’on ait n résultats de mesure matérielle non nulle (par exemple, n=25, ou n=10, mais n doit être supérieur à une valeur minimum à définir pour que le filtrage par médiane puisse opérer ensuite sur le train de mesure, car même si les n mesures matérielles sont OK, il peut y en avoir qui sont aberrante), ----> avec un time out pour éviter boucle infinie : vu que chaque mesure matérielle prend au plus 170 ms, un cas normal avec 25 mesures matérielles OK prend au maximum 5.88s Je propose de prendre comme timeout environ 5X ce délai soit environ 29.5 sec, ce qui laisse le temps au capteur d’effectuer 170 mesure matérielles au moins avant t_m+29.5s. On espère que sur les 170, 25 seront OK

• Si ce n’est pas le cas et que le timeout est dépassé (cela signifierai qu’on a eu 170 mesures matérielles à Zéros !) , on relance un train de mesure une fois. Si on n’a pas un train mesure correct, on est maintenant à t=t_m+59. C (Et donc 2 trains de170 mesures tous à éros !!)

• Si toujours NOK, on laisse tomber la mesure de cette minute et on envoie un GPRS de diagnostic pour notre info. A c

NB : si avec une mesure toutes les minutes on a trop d’erreurs, on peut passer à une mesure toutes les 2 minutes et répéter 4 fois le train de mesure ..

Problème : que se passe –t-il aux quart d’heure 00 :15 :30 :45 ? -> si on n’a pas de mesure filtrée correcte dans la minute correspondante , je propose d’envoyer une valeur NULL associé à un message de diagnostic. Cela ne se verra pas sur le graphe (Sauf que la « bullet » sera absente »), cela n’impacte pas les alertes, et on a l’info comme quoi il y a eu un pb de mesure.

Qu’en penses-tu ?

Cordialement,

r