Comment choisir son enregistreur de données

[invitefb01e94a]

Bonjour à tous,

Je cherche a dimensionner un enregistreur de données dans le but de récupérer les informations enregistrées tout les 3 mois.
Je dipose de capteurs avec des sorties analogies et numériques
* Analogique:
- jauges de contraintes
- sonde de température

*Numérique:
- GPS
- Centrale inertielle
- Inclinomètre (clinomètre)
- ...

Pour les sorties analogiques, je ne pense pas avoir de soucis pour déterminer la quantité de données que je vais avoir au bout de 3 mois. Fonction de ma fréquence d’échantillonnage et de ma conversion Analogique/numérique. Généralement 8 bits.

Mais j'ai des doutes en ce qui concerne les sorties numériques (RS232, RS422...)
En fait, je comptais utiliser le débit binaire (bande passante) fournit dans la doc pour pouvoir déterminer ma quantité de données sur 3 mois. En faisant le calcul, je trouve ça énorme!

J'ai un capteur qui m'indique: interface RS232 à 4800 bauds. D'après ce que j'ai lu, un port serie comme celui la à en général une modulation NRZ soit une valence de 2 ce qui fait que le débit de transmission est égal au débit binaire 4800 bauds = 4800 bits/seconde = 600 octets/seconde soit sur 3 mois = 7889400 secondes ==> ce qui correspond à 4.8 Go

Je fais le même raisonnement avec la Centrale inertielle. La doc spécifie 600 à 115.2kbauds... Dans le "pire" des cas, je prends le max. Avec le même raisonnement j'ai une quantité de données sur 3 mois de : 113.7 Go (ça me parait beaucoup même si la durée est longue)

Je post ceci pour avoir un avis sur la méthode d'estimation de la capacité de stockage de l'enregistreur mais également afin d'avoir des informations que j'aurais pu omettre.

Merci d'avance.

Floub'
-----

[invitee05a3fcc]

J'ai un capteur

Tu peux préciser ? un GPS?

interface RS232 à 4800 bauds. D'après ce que j'ai lu, un port serie comme celui la à en général une modulation NRZ soit une valence de 2 ce qui fait que le débit de transmission est égal au débit binaire 4800 bauds = 4800 bits/seconde = 600 octets/seconde

non . Un octet est empacté avec un start, un stop et quelque fois une parité. Le débit est donc de 4800/10=480 ou 4800/11= 436
Et si c'est un GPS, c'est une trame NMEA (de X? octets) qui est envoyé généralement toute les secondes

Je fais le même raisonnement avec la Centrale inertielle. La doc spécifie 600 à 115.2kbauds..

mêmes remarques

En fait, il faut que tu détermines avec quelle résolution tu veux tracer la position de ton mobile. Si c'est un missile , faut une bonne résolution temporelle. Si c'est un camion, une information positon/vélocité toutes les minutes est sans doute suffisante . A toi de voir ce que tu veux

PS : Les trames NMEA ou Inertielle comportent beaucoup d'informations inutiles . Tu as intérêt à faire une opération de trie et de compactage avant stockage

[invitefb01e94a]

Le capteur en question est un waveRADAR rex de RS AQUA où il y a bien précisé ce que tu disais: RS232 at 4800 bauds 8 data bits, no parity, one stop bit

Le gps est celui ci: GPS avec son guide

Merci pour les info! Bon mon application n'est pas pour un missile mais plus pour un bateau que pour un camion ^^

[invitefb01e94a]

Par contre je n'arrive pas a determiner la quantité de données d'une trame.. En gros, seul la RMC m'intéresse si ce n'est que pour récuperer la position l'heure et le cap

[A voir en vidéo sur Futura]

[invitee05a3fcc]

Une trame NMEA c'est ICI : http://fr.wikipedia.org/wiki/NMEA_0183
Tu récupères les informations que tu veux et à la cadence que tu veux (toutes les secondes ? les heures? les jours?
Pour ta centrale inertielle, c'est dans la doc .....

PS : ce n'est pas la doc technique du Radar que tu donnes ..... mais la doc commerciale. aucun intérêt !

[invitee05a3fcc]

Tu pourrais donner plus d'indication sur le but final de l'opération?
Pourquoi prendre un GPS aussi sophistiqué (qui, à mon avis, ne convient pas) ? Parce que c'est sur un bateau de course ? Et tu veux refaire le trajet à posteriori ?
Dans ce cas, un point toutes les 5 minutes, c'est largement suffisant et utilise un vulgaire récepteur GPS à 50€ qui sera beaucoup plus facile à interfacer (je pense que ton truc n'a pas les trames MNEA ...). Quitte à avoir 2 GPS, un pour naviguer, un pour mémoriser.

[invite01fb7c33]

Pas sur qu'un bête enregistreur permette de faire le traitement des trames.
Tu comptes procéder comment? Un pc et écriture d'un bout de programme pour extraire ce qui t'intéresse dans les trames.
Datation (IRIG) des infos et stockage.
Fourniture d'une datation vers l'enregistreur (S'il a ce qu'il faut pour ça)
Ecriture d'un logiciel de dépouillement avec corrélation temporelle infos PC et infos enregistreur.
Bon, il y a quand même du boulot.

[invitee05a3fcc]

Pas sur qu'un bête enregistreur permette de faire le traitement des trames.

je confirme !

écriture d'un bout de programme pour extraire ce qui t'intéresse dans les trames.

Il y a de toutes les façons un traitement "intelligent" à faire entre les divers capteurs et l’enregistreur . Et vu la complexité, le dataLoger n'est plus utile. C'est le µC qui va trier les données reçues et les enregistrer directement sur une carte HD

Ecriture d'un logiciel de dépouillement avec corrélation temporelle infos PC et infos enregistreur.

Avec le bon format, le fichier peut être compatible Excel

Bon, il y a quand même du boulot.

Oui, et il faut un peu de poils aux pattes pour mener ce projet à bonne fin !

[invitefb01e94a]

Tu pourrais donner plus d'indication sur le but final de l'opération?

Pour placer les choses dans leur contexte. Je dois écrire une spécification technique pour l'instrumentation d'une éolienne offshore. Je référence donc les technologies de capteurs qui peuvent être utilisé pour répondre aux mesures que le Bureau d’études souhaiterai avoir. Ceci étant fait, on m'a demandé de déterminer la capacité de stockage d'un enregistreur de sorte qu'on récupère nos mesures tous les 3 mois. Par la suite, cette spec sera envoyé à l'un de nos partenaires qui s'occupera de l'installation et du monitoring. Je n'ai donc pas à écrire le programme par exemple de récupération des données GPS mais je dois prévoir la quantité de données que l'on aura a stocker sur 3 mois.

Je suis d'accord avec toi DAUDET qu'un simple recepteur GPS peut être plus ingénieux que celui proposé.

Je comprend le fait qu'il est nécessaire de ne récupérer que les trames qui m’intéresse positionnement, cap etc etc pour le GPS où la je pense plus ou moins pouvoir prévoir les trames que l'on a besoin et donc leur qiuantité de données. Mais je ne connais pas grand chose de la norme NMEA et j'ai plusieurs instruments qui l'utilise comme pour la centrale par exemple où là on ne dispose que de très peu d'informations puisque l'on parle essentiellement de nmea et GPs sur le net.

Voilà, je me sens... perdu ...

Merci de vos réponses

[invitee05a3fcc]

La centrale? tu as la doc ?
De toutes les façons, tu ne coupes pas au prétraitement de tes trames pour ne conserver que les informations intéressantes. D'autre part, tu peux ne mémoriser les informations que toutes les X secondes . L'amplitude max/min d'une vague ne change pas en un dixième de seconde

En fait tu fais une mesure sur une bouée au futur emplacement et on veut mémoriser les paramètres de la mer et de la météo ?

Le choix de ton module GPS est mauvais. C'est un truc de navigation pour régate.

[invitefb01e94a]

Je suis en train de me battre pour avoir la doc par le fournisseur...

Ce que je peux te dire, c'est que l'éolienne sera déposé sur un flotteur.
donc le gps servira pour la localisation du flotteur
la centrale pour connaitre les mouvements du flotteur
le radar a connaitre la hauteur de la vague quand elle frappera les paroi du flotteur
la bouée a connaitre la hauteur significative de la vague

les mesures qui concerne l'éolienne comme les données météo seront gérés par le fabriquant de l'éolienne.

En gros, je dois définir les besoins d'instruments pour le flotteur et savoir comment on récupère les informations afin que les hydrodynamiciens, mecaniciens, aéro et autres puissent interpréter les résultats des mesures. Le but étant de valider les modélisations faites lors de la conception et des essais réalisé sur un modèle réduit

[invite01fb7c33]

Donc que ce soit du NMEA ou n'importe quoi d'autre n'a pas d'importance.
Tu ne dois considérer que les paramètres à enregistrer. C'est à dire le format des nombres qui satisfont la résolution des paramètres, et la fréquence de récurrence des différentes informations. Le reste est éliminer par traitement avant le stockage.
Il faut connaitre la dynamique des évènements à analyser.
La vitesse du vent ou la température n'ont pas besoin d'être échantillonnés très vite.
La position GPS j'ai du mal à suivre. Ton éolienne n'est pas en train de traverser l'atlantique, par contre l'heure GPS est indispensable.
La bande fréquence de la houle s'étale entre 1/10eme Hz et 1Hz, là il faut sans doute aller un peu plus vite.
Maintenant il n'est peut être pas pertinent de tout enregistrer, tout dépend de ce que l'on souhaite précisément analyser.

[invitefb01e94a]

Merci pour vos commentaires

La position GPS j'ai du mal à suivre. Ton éolienne n'est pas en train de traverser l'atlantique, par contre l'heure GPS est indispensable.

Le GPS servira aussi à installer le flotteur.

par contre l'heure GPS est indispensable

Je suis entièrement d'accord, c'est ce que je pensais.

Il faut connaitre la dynamique des évènements à analyser

J'ai référencé les fréquences des phénomènes appliqués au flotteur.

Ce que j'ai du mal à comprendre c'est les faces cachés de la vitesse de transmission ( rapidité de modulation) en Bauds. J'ai l'impression que l'on fait passer un peu tout et n'importe quoi. En faisant des recherches, je suis tombé sur plusieurs remarques qui précisé que les fabricants utilisés parfois le Baud alors qu'il s'agit en réalité d'un débit binaire. Bien que les 2 soient liés, en lisant les docs je ne sais plus quoi en penser. Sur certain site dédié aux gps par exempel: une fois on me dit que c'est transmis à 4800 bauds et une autres fois a 4800 bit/sec (vitesse de transmission d'une trame) . Autre exemple sur ce site: http://opencpn.shoreline.fr/8_Dossie...DT_31_NMEA.htm

Le GPS émet chaque trame à la vitesse de 4800 bauds autrement dit 4800 caractères par seconde.
Soit une vitesse de 38400 bits par seconde. (codé sur 8 bits Débit bianire = Rapidité de modulation * log2(Valence) soit 4800*8 )

Nota bene :

Il se pourrait, à la vue de certaines publicités, pour certains GPS, annonçant une vitesse de 38400 bauds, que les fabricants confondent, peut être volontairement, les deux façons d'exprimer la vitesse d'émission des trames par le GPS. Marketing oblige !

[invitee05a3fcc]

En faisant des recherches, je suis tombé sur plusieurs remarques qui précisé que les fabricants utilisés parfois le Baud alors qu'il s'agit en réalité d'un débit binaire. Bien que les 2 soient liés,

C'est exactement la même chose ! Maintenant, pour avoir le débit en octet (ou en caractère), il faut diviser la vitesse de transmission par 1,25 (un octet, c'est 10 bits à transmettre !)

je ne sais plus quoi en penser. Sur certain site dédié aux gps par exempel: une fois on me dit que c'est transmis à 4800 bauds et une autres fois a 4800 bit/sec (vitesse de transmission d'une trame) .

Voir explication ci dessus

Autre exemple sur ce site:

je n'ai pas vérifier sa présence, mais cette phrase est fausse.

Mais pourquoi tu te polarises sur ces histoires ? ? ?
Un GPS qui transmet à 4800 bauds ou à 38400 te donne exactement le même flux d'information .... vu que la trame est de même longueur et émise toutes les secondes . Ca ne change strictement rien ! Sauf que la trame à 38400 dure 8 fois moins de temps que la trame à 4800

[invitee05a3fcc]

Maintenant, pour avoir le débit en octet (ou en caractère), il faut diviser la vitesse de transmission par 1,25 (un octet, c'est 10 bits à transmettre !)

Petites précisions ....

• Si tu divises par 1,25 ..... tu as la vitesse de débit de BITs utiles . Par exemple 4800Bds, c'est 3840 bits utiles par seconde
• Si tu divises par 1,25x8=10 ..... tu as la vitesse de débit en octet . Par exemple 4800Bds, c'est 480 octets par seconde

[invitee05a3fcc]

Je cherche a dimensionner un enregistreur de données dans le but de récupérer les informations enregistrées tout les 3 mois.

C'est un faux problème et ce n'est pas la question qu'il faut se poser. Il y aura toujours une solution , carte HD ou disque SSD

La bonne question ? c'est comment faire le concentrateur qui, à partir de liaison RS232, va me permettre de recevoir les trames, trier les infos utiles et les enregistrer sur un support non volatile. Comme tu ne peux pas te permettre de faire de la bidouille avec une carte µC, je te conseille de t'orienter sur le format PC104 ou tu vas trouver :
- des cartes mères
- des cartes I/0
- des alimentations
- des coffrets

Bref un vrai Lego ou Meccano !

Tu obtiens l'équivalent d'un PC en petit avec un O.S. que tu choisis (Windows ou Linux) et tu as à ta disposition tous les drivers à ta disposition (Liaison série, accès aux disques etc ). De plus, comme c'est sur un PC, tu peux faire ta mise au point sur un PC normal, dans le langage que tu connais, et transférer ton code (avec quelques modifs) sur la PC104

[invite0324077b]

dans ta question de depart tu calcul comme si tu voulais enregistrer le signal RS232 comme un signal analogique ! c'est completement inutile

tu enregistre avec un microcontroleur quelquonque qui a un uart , et un octet recu fait 1 octet en memoire peu importe a quel baud rate il a été transmis ... il suffit que le microcontroleur soit programé pour recevoir le bon baud rate

il faut choisir un microcontroleur capable d'ecrire dans une carte SD , et tu a autant de Goctet que tu veux a bas prix

j'ai deja utilisé un recepteur GPS simple : il envoie a cadense fixe des message dans different format avec differente information : il serait possible de trier et de n'enregistrer que celle dont tu a besoin ... mais vu le bas prix des memoire SD inutile de se casser la tête : enregistrer tous les messages envoyé par le gps sans trier

actuellement je suis dans les cartes microcontroleur arduino : facile a programmer , entré analogique pour tes capteur analogique ... uart pour recevoir le rs232 , carte enfichable disponible pour carte memoire SD

la plus simple devrait suffir
http://www.lextronic.fr/P4124-platin...uno-rev-3.html
et ça pour une carte SD
http://www.lextronic.fr/P5912-module...r-arduino.html

[invitefb01e94a]

]dans ta question de depart tu calcul comme si tu voulais enregistrer le signal RS232 comme un signal analogique ! c'est completement inutile [...] et un octet recu fait 1 octet en memoire peu importe a quel baud rate il a été transmis ...

Je me suis rendu compte de mon erreur, tout à fait. En contactant les fournisseurs j'ai pu avoir quelques renseignements sur la taille de leurs données. Cela commence à s'éclaircir. Pour le Gps je pensais enregistrer l'équivalent d'une trame.

actuellement je suis dans les cartes microcontroleur arduino

Je m'étais posé la question sur l'utilisation de Arduino, j'aime beaucoup ce micro controleur, je m'en suis acheté un personnel pour quelques applications chez moi, histoire de "m'amuser". Sa simplicité est particulièrement agréable et j'ai vu que de plus en plus en industrie ou recherche "Popeye on mars" par exemple où j'ai été surpris de voir son utilisation. J'en ai une Duelmilanove ça fonctionne très bien. Merci beaucoup de votre aide!