next topic »

[Reply #15 on:]

Trop drôle, les forums sont tous les mêmes : on a des réponses que quand on troll

Pour ce qui est des points abordés :

Mais en France il me semble qu'il y a aussi le CCI / Maison de l’Artisanat locale afin de se mettre en relation avec les BE/artisans.

Soyons sérieux, pourquoi ne pas confier un projet industriel à un stagiaire de 1re année de DUT...

Coté technique, la plupart des capteurs identifiés retournent une valeur en tension (0-1V) ou courant (4-20mA). La conversion en valeur se fait au travers d'une équation linéaire, voire polynomiale. Je ne pense pas que les quelques conversions à faire toutes les minutes (disons 5-6 capteurs par station type) soient insurmontable pour une seule UNO.

Coté cadences d'échantillonnage et d'enregistrement, on peut partir sur les bases suivantes :
- échantillonnage de chaque capteur toutes les minutes -> conversion et stockage temporaire ;
- au bout de 5 minutes (5 enregistrements temporaires) -> calcul de la variable 'définitive' (qui sera enregistrée dans le fichier) soit par exemple pour les températures : la plus faible mesure est conservée comme température mini ; la max en maxi et la moyenne des 5 en température moyenne.

Ainsi 1 capteur génère 2-3 variables par horodatage dans le fichier. Avec 5-6 capteurs, on parle de 15 valeurs par ligne de fichier, soit 180 valeurs par heure, soit 4320 valeurs par jour soit un fichier d'environ 40 ko. Sachant qu'à l'heure actuelle, la plupart de nos clients ne retiennent qu'une valeur par heure soit des fichiers journaliers de 4-5 ko.

3-4 fois par jour, la station transfère son fichier vers le serveur via gprs, ethernet, wifi,...

A vote avis, c'est gérable par une UNO ou pas ?

Edouard

[Reply #16 on:]

Je ne vois pas ce qui ne serait pas jouable...
Dans la logique du prototypage, le mieux est de faire le test, mais franchement, un ARDUINO doit largement pouvoir au besoin...
Coté production, vous devrez équiper combien de stations?
Avez-vous les références datasheets des capteurs que vous allez utiliser? Je suis curieux de voir si vous utiliserez les mêmes références que les hackeurs que l'on croise ici 

[Reply #17 on:]

Bonjour Ojal,

On en écoule aujourd'hui 200 par an et sur des bases tarifaires bien supérieures, le marché pourrait en absorber un millier par an suivant l'effort commercial et les applications en backoffice (la donnée brute ne sert à rien et les clients peuvent avoir la même chose avec un pluvio plastique et un thermomètre à mercure pour 10 €)

j'ai commencé le tableau ci-joint pour les capteurs. si on prend par exemple le HC2-S3 (température et hygrométrie) cela n'a rien à voir avec les capteurs utilisés généralement par les hobbyistes : plus de 100 € HT pièce. Mais super précision.

[Reply #18 on:]

Coté technique, la plupart des capteurs identifiés retournent une valeur en tension (0-1V) ou courant (4-20mA). La conversion en valeur se fait au travers d'une équation linéaire, voire polynomiale. Je ne pense pas que les quelques conversions à faire toutes les minutes (disons 5-6 capteurs par station type) soient insurmontable pour une seule UNO.

Pour ça en effet l'Atmega328 de l'Arduino Uno fera l'affaire.

Ainsi 1 capteur génère 2-3 variables par horodatage dans le fichier. Avec 5-6 capteurs, on parle de 15 valeurs par ligne de fichier, soit 180 valeurs par heure, soit 4320 valeurs par jour soit un fichier d'environ 40 ko. Sachant qu'à l'heure actuelle, la plupart de nos clients ne retiennent qu'une valeur par heure soit des fichiers journaliers de 4-5 ko.

3-4 fois par jour, la station transfère son fichier vers le serveur via gprs, ethernet, wifi,...

C'est là qu'est ma crainte concernant la mémoire, dans le pire cas avec les volumes de données les plus importants... Où comptes-tu stocker tes données ?

[Reply #19 on:]

Avec ça :

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039


Autrement il existe des pistes avec des clé usb :

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1294520080

[Reply #20 on:]

bonsoir

On peut rajouter une mémoire type AT25640A
Doc ici : www.datasheetcatalog.org/datasheet/atmel/doc3347.pdf

A+
chabot380

[Reply #21 on:]

Suivant comment tu utilises l'Eeprom, elle ne durera pas une année....

[Reply #22 on:]

On nous dit que le fichier de données journalier est composé au maximum de 4.320 valeurs... Il faut analyser la taille qu'occuperont ces valeurs...
Le transfert de données se fait 4 fois par jour, soit un stockage de 1.080 valeurs en mémoire au grand maximum...
Ensuite la réalité terrain nous dit qu'un fichier journalier représente 4 à 5 Ko soit un besoin en mémoire entre 2 transmissions d'au maximum 1.25Ko...

Et pourquoi ne pas transmettre les données avec une fréquence un peu plus élevée, par exemple toutes les 2 heures au grand bonheur des utilisateurs?

Je ne suis pas pessimiste sur cet aspect là...

[Reply #23 on:]

voici une idée du type de fichier généré.
Celui ci est issu d'une station météo davis, n'est pas optimisé en terme de place, mais cela donne une bonne idée.

Et pourquoi ne pas transmettre les données avec une fréquence un peu plus élevée, par exemple toutes les 2 heures au grand bonheur des utilisateurs?

A l'heure actuelle chaque connexion gprs coûte encore assez cher en France et il semble y avoir des coûts fixes liés aux headers, etc... Il semble plus économique de faire moins de transmissions avec des fichiers un poil plus gros.
En LAN, tu as évidemment raison, autant envoyer les infos dès qu'on les a.

Coté stockage j'imaginais volontiers un carte SD, cela ne coute plus grand chose (hardware et carte), ou sur clé USB ?

Est-t-il possible d'envisager un mode (changer un jumper ?) pour rebooter et faire la mise à jour du firmware à partir de la carte SD ou de la clé usb ?

[Reply #24 on:]

A l'heure actuelle chaque connexion gprs coûte encore assez cher en France et il semble y avoir des coûts fixes liés aux headers, etc... Il semble plus économique de faire moins de transmissions avec des fichiers un poil plus gros.

En effet, c'est cher, long et ça consomme énormément d'énergie (du moins par rapport aux autres fonctions).

Coté stockage j'imaginais volontiers un carte SD, cela ne coute plus grand chose (hardware et carte), ou sur clé USB ?

En prenant un microcontrôleur suffisamment gros tu fais l'économie d'une mémoire externe. Mais si justement tu ajoutes un support externe, un Atmega328 suffira... A toi de faire le choix  Quelque soit le support, le problème du nombre de cycles d'écriture se posera. Toute mémoire lâchera un jour ou l'autre, mais en choisissant bien, la station météo aura été remplacée avant que ça n'arrive... Et puis plusieurs solutions sont envisageables pour réduire les écritures en mémoire...

[Reply #25 on:]

De mémoire, au moins un opérateur lowcost propose des abonnements avec 200Mo/mois pour moins de 20€/mois... Peut être même 15€/mois... Vous pouvez alors transférer avec la fréquence de votre choix et plus de pb de mémoire...

[Reply #26 on:]

On ne parle heureusement que de quelques Mo par mois, soit environ 7€/ mois en France. C'est cher par rapport à d’autres pays (Australie, moins de 1$AUS), mais reste abordable.
C'est aussi cher par rapport au coût de la carte électronique. Pour l'utilisateur final, il lâche environ 100 € par an à l'opérateur, soit autant que le coût d'achat du matériel.

Ceci dit ce n'est rien par rapport à ce qu'on leur fait économiser !

Bref tout est relatif...

[Reply #27 on:]

D'un autre coté une carte SD de 4G coute dans les environs de 5€, je ne sais pas si l'on peut enregistrer dessus par secteur, mais si c'est le cas tu change de secteur tout les mois et ta carte dure 10 ans.... et autrement si le client doit la changer, c'est pas la misère non plus  

[Reply #28 on:]

Pour l'utilisateur final, il lâche environ 100 € par an à l'opérateur, soit autant que le coût d'achat du matériel.

Vous parlez de quel matériel pour 100€???

7€ par mois c'est complètement transparent... Je ne comprends pas que cela conditionne un choix technique dans la fréquense de transmission des données...???

Avez-vous reçu des propositions de consultants?

[Reply #29 on:]

L'aspect coût est une chose. Mais selon les systèmes, il peut être nécessaire de limiter le nombre de connexions GPRS pour économiser du temps CPU et de l'énergie. A voir si c'est un critère pour Promete...