Programation d'un éclairage LED

[mic8]

Bonjour,

J'ai réalisé il y a quelques années un petit montage tout simple sur mon
balcon composé de 4 circuits LED séparés (12V et 250mA chacun) dont
l'allumage est commandé par un détecteur crépusculaire et une horloge
programable de camping. Un commutateur rotatif me permet de choisir
quel(s) circuit s'allume, et l'horloge me permet de limiter les heures
d'éclairage (soir et matin seulement, au milieu de la nuit je dors :-)

Le tout est alimenté par une batterie 12V au plomb chargée par un
panneau solaire au travers d'un régulateur.

Tout fonctionne très bien, mais j'aimerai aller plus loin dans les
fonctionalités, comme programmer le nombre de circuit en fonction de
l'heure et/ou de la luminosité ambiante, tout en limitant au maximum la
consomation du circuit de commande.

J'ai pensé partir sur un Arduino (la partie software ne me fait pas
peur), mais cela pose quelques questions:

- quel modèle choisir ? Peux d'entre-eux indiquent une valeur de
consomation. Il me faut 4 sorties pour commander les 4 circuitsl, une
entrée analogique pour le capteur de luminosité, au moins 3 entrées
numériques (reset, marche forcée, extinction forcée), mais je préfère
prévoir plus large, pour p.ex. ajouter une roue codeuse afin de
sélectionner différents programmes.

- quel relais de sortie utiliser? Bi-stable, solid-state ?

- la fréquence de l'Arduino est-elle suffisament stable pour en tirer
une horloge basique par programation ? Je n'ai pas besoin d'une grande
précision et je peux tolérer une dérive de 2-3 minutes par semaine. Ou
alors ajouter un module de synchro NTP (j'ai du wifi disponnible, ça
pourrait être une ouverture pour du développement futur, commande par
web p.ex.)

Je suis bien sûr ouvert à toute autre idée ou conseil de résiliation.
D'avance merci de vos conseils

[Pascal-J]

Si autonomie un facteur critique oublier relais, wifi et ntp ...... et si besoin d'un horloge RTC sauvegardée voir modules I2c
DS1307.

http://www.miniinthebox.com/fr/ds1307-a-base-de-l-horloge-temps-reel-rtc-i2c-minuscule-module-24c32-memoire-pour-arduino-ak_p1113835.html?currency=EUR&litb_from=paid_adwords_shopping&country_code=fr&utm_source=google_shopping&utm_medium=cpc&adword_mt=&adword_ct=208973324079&adword_kw=&adword_pos=1o4&adword_pl=&adword_net=g&adword_tar=&adw_src_id=37789470111_867011721_46189462033_pla-363375052034&gclid=EAIaIQobChMIs4_Q66SC1gIVzJPtCh0V0AO8EAQYBCABEgJfr_D_BwE

Pour l'arduino, utiliser un a faible conso (voir les datasheets) donc éviter mega et due.

[olivier B.]

Post by mic8
Bonjour,
J'ai réalisé il y a quelques années un petit montage tout simple sur mon
balcon composé de 4 circuits LED séparés (12V et 250mA chacun) dont
l'allumage est commandé par un détecteur crépusculaire et une horloge
programable de camping. Un commutateur rotatif me permet de choisir
quel(s) circuit s'allume, et l'horloge me permet de limiter les heures
d'éclairage (soir et matin seulement, au milieu de la nuit je dors :-)
Le tout est alimenté par une batterie 12V au plomb chargée par un
panneau solaire au travers d'un régulateur.
Tout fonctionne très bien, mais j'aimerai aller plus loin dans les
fonctionalités, comme programmer le nombre de circuit en fonction de
l'heure et/ou de la luminosité ambiante, tout en limitant au maximum la
consomation du circuit de commande.
J'ai pensé partir sur un Arduino (la partie software ne me fait pas
- quel modèle choisir ? Peux d'entre-eux indiquent une valeur de
consomation.

je partirais sur le 328 dil (uno) afin de ne conerver dans le projet que le
chip avec l'oscillateur interne, il ne consomme alors qu'un peu moins de
5mA

https://www.avrprogrammers.com/howto/atmega328-power

tu peux aussi la passer en sleep, la conso est alors négligeable.

Post by mic8
Il me faut 4 sorties pour commander les 4 circuitsl, une
entrée analogique pour le capteur de luminosité, au moins 3 entrées
numériques (reset, marche forcée, extinction forcée), mais je préfère
prévoir plus large, pour p.ex. ajouter une roue codeuse afin de
sélectionner différents programmes.

le 328 me semble adapté, la selection des programes peut se faire avec une
seule entrée analogique que ce soit avec une codeuse ou du contact up/down

Post by mic8
- quel relais de sortie utiliser? Bi-stable, solid-state ?

Saufa à avoir besoin d'isolation je piloterais 4 mosfet directement avec
les sorties du 328

Post by mic8
- la fréquence de l'Arduino est-elle suffisament stable pour en tirer
une horloge basique par programation ? Je n'ai pas besoin d'une grande
précision et je peux tolérer une dérive de 2-3 minutes par semaine.

ça sera stable mais mais avec de la dérive, au pire tu peux utiliser un
quartz externe (et du cous descendre à 1Mhz) et capa ajustable afin de
tuner l'horloge, ou corriger en soft, sinon il existe des modules RTC pour
arduino (I2C) pour moins de 3€

Post by mic8
Ou
alors ajouter un module de synchro NTP (j'ai du wifi disponnible, ça
pourrait être une ouverture pour du développement futur, commande par
web p.ex.)

c'est sur que ça offre des possibilité mais... faut savoir si tu tiens à
la conso ou pas

Post by mic8
Je suis bien sûr ouvert à toute autre idée ou conseil de résiliation.
D'avance merci de vos conseils

[franssoa]

Post by olivier B.
je partirais sur le 328 dil (uno) afin de ne conerver dans le projet que le
chip avec l'oscillateur interne, il ne consomme alors qu'un peu moins de
5mA (...)

Je plussoie (et pour la suite de la réponse aussi)

franssoa

[Pascal-J]

Post by olivier B.
je partirais sur le 328 dil (uno) afin de ne conerver dans le projet que le

chip avec l'oscillateur interne, il ne consomme alors qu'un peu moins de
5mA

Si il veut programmer sa mise en route et ses plages horaire cela implique un afficheur et quelques boutons. Donc pour ne pas
s'emm....er une carte standard et le shield qui va bien. De plus il aura directement le régulateur LDO intégré pour utiliser son
alimentation 14v.

En outre le probleme de l'oscillateur interne est qu'il change la fréquence du port série et qu'il faut bien penser a modifier le
paramétrage de l'IDE, et vu son manque de stabilité a oublier pour du comptage horaire.

[olivier B.]

Post by olivier B.

Post by olivier B.
je partirais sur le 328 dil (uno) afin de ne conerver dans le projet que le

chip avec l'oscillateur interne, il ne consomme alors qu'un peu moins de
5mA
Si il veut programmer sa mise en route et ses plages horaire cela implique
un afficheur et quelques boutons. Donc pour ne pas s'emm....er une carte
standard et le shield qui va bien. De plus il aura directement le régulateur
LDO intégré pour utiliser son
alimentation 14v.

possible, faut voir le niveau de programmation désiré

Post by olivier B.
En outre le probleme de l'oscillateur interne est qu'il change la fréquence
du port série et qu'il faut bien penser a modifier le
paramétrage de l'IDE, et vu son manque de stabilité a oublier pour du comptage horaire.

je pensais qu'il était assez stable pour se limiter à "une dérive de 2-3
minutes par semaine." moyennant un calibrage soft.

[mic8]

Post by olivier B.

Post by olivier B.

Post by olivier B.
je partirais sur le 328 dil (uno) afin de ne conerver dans le projet que le

chip avec l'oscillateur interne, il ne consomme alors qu'un peu moins de
5mA
Si il veut programmer sa mise en route et ses plages horaire cela implique
un afficheur et quelques boutons. Donc pour ne pas s'emm....er une carte
standard et le shield qui va bien. De plus il aura directement le régulateur
LDO intégré pour utiliser son
alimentation 14v.

possible, faut voir le niveau de programmation désiré

Merci pour vos pistes, je vais examiner de plus pret le uno.
Pour l'affichage, pas nécessaire: je vais coder directement les
(quelques) programmes souhaités, et les sélectionnerait via une entrée
de l'arduino.

Post by olivier B.

Post by olivier B.
En outre le probleme de l'oscillateur interne est qu'il change la fréquence
du port série et qu'il faut bien penser a modifier le
paramétrage de l'IDE, et vu son manque de stabilité a oublier pour du
comptage horaire.

je pensais qu'il était assez stable pour se limiter à "une dérive de 2-3
minutes par semaine." moyennant un calibrage soft.

Pascal-J m'a judicieusement indiqué un module i2c DS1307, je vais
examiner cette piste. J'ai aussi pensé à un module DFC77 qui ne serait
sollicité (et donc alimenté) que de temps à autre pour recadrer
l'horloge.

En sortie, effeictivement les mosfet seront plus judicieux que des
relais.

[franssoa]

Post by mic8
Pascal-J m'a judicieusement indiqué un module i2c DS1307, je vais
examiner cette piste. J'ai aussi pensé à un module DFC77 qui ne serait
sollicité (et donc alimenté) que de temps à autre pour recadrer
l'horloge.

Perso je ne m'embêterais pas avec un DFC77, j'ai fait il y a pas mal de
temps un compteur moto avec un ATMEGA168* + DS1307 dans un boîtier
plexiglass soumis aux conditions météo (four solaire en été, et glacière
en hivers). Je n'ai jamais changé la pile du DS1307 et pas constaté de
grosse dérive (mais je mettais à l'heure aux changements été/hivers)

Puisque tu en es à la quasi conclusion, je t'offre une autre piste pour
brouiller un peu ton choix : ESP8266 :-)

franssoa

*ATMEGA168 = uC de la (vieille) carte arduino Diecimila.

[mic8]

Post by franssoa
Perso je ne m'embêterais pas avec un DFC77, j'ai fait il y a pas mal de
temps un compteur moto avec un ATMEGA168* + DS1307 dans un boîtier
plexiglass soumis aux conditions météo (four solaire en été, et glacière
en hivers). Je n'ai jamais changé la pile du DS1307 et pas constaté de
grosse dérive (mais je mettais à l'heure aux changements été/hivers)

OK, je suis convaincu. Largement suffisant pour mes besoins.

Post by franssoa
Puisque tu en es à la quasi conclusion, je t'offre une autre piste pour
brouiller un peu ton choix : ESP8266 :-)

Je vais déjà mettre en oeuvre le projet sans commande à distance.
On verra plus tard :-)

Merci à tous, le temps de rassembler le matos et je m'y colle.

[olivier B.]

Post by mic8

Post by Pascal-J

Post by olivier B.

Post by olivier B.
je partirais sur le 328 dil (uno) afin de ne conerver dans le projet que

le

Post by olivier B.
chip avec l'oscillateur interne, il ne consomme alors qu'un peu moins de
5mA
Si il veut programmer sa mise en route et ses plages horaire cela

implique

Post by olivier B.
un afficheur et quelques boutons. Donc pour ne pas s'emm....er une

carte

Post by olivier B.
standard et le shield qui va bien. De plus il aura directement le

régulateur

Post by olivier B.
LDO intégré pour utiliser son
alimentation 14v.

possible, faut voir le niveau de programmation désiré

Merci pour vos pistes, je vais examiner de plus pret le uno.
Pour l'affichage, pas nécessaire: je vais coder directement les
(quelques) programmes souhaités, et les sélectionnerait via une entrée
de l'arduino.

Outre la position d'un potentiomètre, tu peux générer une tension
analogique à partir d'une roue codeuse ou d'un commutateur multi-positions
+ résistances, et récupérer l'index par soft.

Post by mic8

Post by Pascal-J

Post by olivier B.
En outre le probleme de l'oscillateur interne est qu'il change la

fréquence

Post by olivier B.
du port série et qu'il faut bien penser a modifier le
paramétrage de l'IDE, et vu son manque de stabilité a oublier pour du
comptage horaire.

je pensais qu'il était assez stable pour se limiter à "une dérive de 2-3
minutes par semaine." moyennant un calibrage soft.

Pascal-J m'a judicieusement indiqué un module i2c DS1307,

c'est ce dont je parlais "des modules RTC pour arduino (I2C) pour moins de
3€"

Post by mic8
je vais
examiner cette piste. J'ai aussi pensé à un module DFC77 qui ne serait
sollicité (et donc alimenté) que de temps à autre pour recadrer
l'horloge.

Pour faire cheap tu pourrais l'alimenter en même temps qu'une des rampes
de led

Post by mic8
En sortie, effeictivement les mosfet seront plus judicieux que des
relais.

fais gaffe à la tension de grille nécéssaire.
Je récupère pas mal de ces bestioles sur les cartes mère (et certains
vidéo), déssoudage en balayant avec un chalumeau l'arrière de la carte
placée verticalement, quand le point de fusion est atteint quelque
secousses et tout tombe :-)

[mic8]

Post by olivier B.

Post by mic8
En sortie, effeictivement les mosfet seront plus judicieux que des
relais.

fais gaffe à la tension de grille nécéssaire.
Je récupère pas mal de ces bestioles sur les cartes mère (et certains
vidéo), déssoudage en balayant avec un chalumeau l'arrière de la carte
placée verticalement, quand le point de fusion est atteint quelque
secousses et tout tombe :-)

Je pensais à des IRLZ44NPBF

[Pascal-J]

Post by mic8
Je pensais à des IRLZ44NPBF

Gros marteau .......... mais il enfoncera le clou ;>)

[Pascal-J]

Post by olivier B.
je pensais qu'il était assez stable pour se limiter à "une dérive de 2-3

minutes par semaine." moyennant un calibrage soft.

L'oscillateur RC interne est donné a 10% en sortie d'usine (nettement moins en réalité) et a 1% avec étalonnage utilisateur
(variation selon vcc et t° moyenne d'utilisation).

Et 1% cela fait 100 minutes par semaine ;>)



(Ok, c'est la limite et le pire cas).

[olivier B.]

Post by olivier B.

Post by olivier B.
je pensais qu'il était assez stable pour se limiter à "une dérive de 2-3

minutes par semaine." moyennant un calibrage soft.
L'oscillateur RC interne est donné a 10% en sortie d'usine (nettement moins
en réalité) et a 1% avec étalonnage utilisateur

si je te comprend bien, en admettant qu'en labo on compense précisément
par soft, il subsisterait une instabilité de 1% à laquelle on ne peut
rien faire?

Post by olivier B.
(variation selon vcc et t° moyenne d'utilisation).
Et 1% cela fait 100 minutes par semaine ;>)

ha... flûte, ça c'est encore un coups des 35h ;-)

Post by olivier B.
(Ok, c'est la limite et le pire cas).

dans ce cas, je pense que je m'orienterais vers une RTC.

J'avais aussi penser à "tracker" la fenêtre coucher/lever du jour et
s'ajuster dessus pour la période de blackout, mais ça ne gèrerait pas le
changement d'heure.

[Benoit-Pierre DEMAINE]

Post by mic8
J'ai pensé partir sur un Arduino

Je propose, en connaissance de cause, son concurrent: le rPi. Vérifier les
4 versions disponibles pour voir laquelle consomme le moins,
éventuellement aller chercher une v1 sur eBay.

La consommation du rPi varie avec la fréquence de son CPU; et la fréquence
est un paramètre facilement ajustable (enfin, quand on sait demander à
google). Un rPi bien ajusté ne consomme pas beaucoup plus qu'un Arduino.
Et dans tous les cas, ça reste négligeable devant la consommation des
rubans de LEDs, et la puissance apportée par un panneau solaire sérieux
(10 à 20W).

Le point faible du rPi pour les autres gens, c'est l'alimentation. Pour
moi, c'est la carte SD (soit que la carte parte en badblocks, soit que le
système de fichier parte à l'ouest).

Certains rPi ont le wifi intégré; sinon, voir ethernet, ou usb-wifi.
L'ethernet peut avoir une consommation raisonnable; mais le seul dongle
USB-Wifi, lui, risque de multiplier la consommation du rPi par 3 à 10.

Pour la dérive du temps, il est fiable. Moins de 5mn par semaine sans
réseau. Si il a du réseau, on en parle pas. Envisager de n'allumer la
carte wifi que 10mn par jour (et en fin d'après midi, quand le panneau a
finit de recharger l'accu) (ça se gère à coup de modprobe-rmmod).

L'avantage du rPi est qu'on pars d'une plateforme réellement logicielle,
donc, ultra simple de lui faire un serveur web.

Si pas de réseau du tout, on peut lui coller en option des RTC externes (à
peu près les mêmes que pour Arduino, sauf qu'on les trouve dans un format
matériellement pret à l'emploi pour rPi).

Pour la gestion des I/O. Selon la configuration retenue, il a entre 3 et
12 I/O utilisables. Mon choix personnel est de partir d'un démultiplexeur
I2C 8 ou 16 sorties. Mais il est possible de lui demander dectement 4 I/O.
Il travaille en 3.3V; son courant de sortie est très faible; il faut
envisager deux étages pour ne pas le fatiguer: un premier TTL (de type
porte OUI), puis, un gros machin de puissance au choix. J'ai réussi à lui
faire driver des gros SSD en directe (SSR40DA), mais c'est franchement
limite; vaut mieux un transistor entre le rPi et le SSD.

Donc pour toi:
http://www.ebay.fr/itm/SODIAL-R-SSR-25DD-Monophase-statique-Module-Relais-25A-DC-5-60V-WT-/272361141549?hash=item3f69fd352d:g:ze8AAOSwvzRXyGLN

Pour les capteurs de lumière, j'en ai jamais utilisé; il y a des kits. Le
rPi n'a pas d'entrée analogique; il faut soit utiliser une sonde
numérique, soit un ADC I2C. Il y a des kits à base de sonde de lumière +
ptentiomètre; le règlage se fait alors au potar, pas en soft.

Le rPi permettra plus facilement une ouverture au web dans le futur. Avec
ssh et httpd.

Pour recaler l'heure, pas besoin d'horloge précise, ni de RTC. Dès que tu
as une sonde de lumière, tu regarde l'heure de lever et coucher de soleil;
tu moyenne sur 3J, et le point milieu entre les levers et les couchers, ça
doit être le midi solaire; si ça l'est pas, tu sais que tu dois ajuster
ton horloge interne. Faisable par script shell.

Personellement, tous mes rPi utilisent l'écran 4" chinois basique; un LCD
tactile autour de 9e. La consommation totale reste sous les 4W; je me
demande si c'est pas même autour de 2W.
https://fr.aliexpress.com/item/Free-shipping-LCD-module-Pi-TFT-3-5-inch-320-480-Touchscreen-Display-Module-TFT-for/32232959941.html?spm=a2g0w.search0304.4.30.YRIa2X
Attention, faut utiliser l'image ROM fournie; le chipset XPT ne foncitonne
pas avec les ROM officielles.

[Pascal-J]

C'est pour paraitre intelligent ou crise de shadockerie aigue ?


;>))

[bp]

Post by Benoit-Pierre DEMAINE

Post by mic8
J'ai pensé partir sur un Arduino

Je propose, en connaissance de cause, son concurrent: le rPi. Vérifier les
4 versions disponibles pour voir laquelle consomme le moins,

.../...

Post by Benoit-Pierre DEMAINE
https://fr.aliexpress.com/item/Free-shipping-LCD-module-Pi-TFT-3-5-inch-320-480-Touchscreen-Display-Module-TFT-for/32232959941.html?spm=a2g0w.search0304.4.30.YRIa2X
Attention, faut utiliser l'image ROM fournie; le chipset XPT ne foncitonne
pas avec les ROM officielles.

j'envisage de me pencher sur ces petites bêtes (arduino ou rpi) et ton
compte rendu est instructif

[olivier B.]

Post by Benoit-Pierre DEMAINE
La consommation du rPi varie avec la fréquence de son CPU; et la fréquence
est un paramètre facilement ajustable (enfin, quand on sait demander à
google). Un rPi bien ajusté ne consomme pas beaucoup plus qu'un Arduino.

[...]

Post by Benoit-Pierre DEMAINE
Personellement, tous mes rPi utilisent l'écran 4" chinois basique; un LCD
tactile autour de 9e. La consommation totale reste sous les 4W; je me
demande si c'est pas même autour de 2W.

soit environ 50 fois plus que la conso d'un 328 "bien ajusté" ce qui amha
mérite qu'on le qualifie de "beaucoup plus"

[franssoa]

Post by Benoit-Pierre DEMAINE

Post by mic8
J'ai pensé partir sur un Arduino

Je propose, en connaissance de cause, son concurrent: le rPi

C'est un peu "overkill" non ?

D'autre part le rpi est un ordinateur, avec tous les aléas d'un ordi et
sa foultitude de composants qui peuvent foirer dans le temps, à
commencer par la carte SD. Je ne m'y fierai pas pour du 24/365. Un
atmega bien programmé (avec watchdog), tu l'allumes et tu ne t'en
soucies plus pendant des années.

Juste une réflexion perso, faut pas le prendre mal :-)

franssoa

[Benoit-Pierre DEMAINE]

avec tous les aléas d'un ordi et sa foultitude de composants qui peuvent
foirer dans le temps, à commencer par la carte SD.

Ca, je l'ai moi même soulevé dans mon message. La carte SD est un énorme
problème sur le rPi; pas juste pour la qualité du matériel; mais, j'ai
très souvent des corruptions du système de fichier (et pas que sur rPi:
avant d'avoir des rPi, j'ai eu deux corruptions d'ext3 sur PC, sans lien
avec des pannes secteur; plus une dizaine sous XFS).

Dans les deux cas, il y a des problèmes d'alimentation.

Je ne m'y fierai pas
pour du 24/365. Un atmega bien programmé (avec watchdog), tu l'allumes et
tu ne t'en soucies plus pendant des années.

Statistiquement, oui, un Atmel avec FLASH intégré est probablement plus
fiable. Ponctuellement, tu peux avoir un Atmel qui fume plus vite que le
rPi de ton voisin.

J'ai du abandonner un énorme projet de lampe sous marine avec chargeur
intelligent, parce que pour des raisons de volume j'avais été obligé de
tout souder directement sur l'uC (strictement impossible de mettre un
socket); puis après une cinquantaine de mise à jour logicielle, la FLASH
du PIC (Microchip, genre un 12F ou 16F, en version SO) a rendu l'âme. Plus
le temps de transposer les composants sur une puce neuve, déprimé, j'ai
laissé tomber. Ces machins sont garantis 1000 ou 10000 cycles, j'en avais
pas fait 100.

Sur les fprums rPi, certains ont des machines avec 2 ans d'uptime; et
certains marchent en continu depuis 3 ans (SD fonctionnelle).

Juste une réflexion perso, faut pas le prendre mal :-)

Ce qui m'a motivé à m'étendre, c'est 3 choses: il a demandé deS
alternativeS, puis il a parlé de Wifi, et de controle web.

[olivier B.]

Post by Benoit-Pierre DEMAINE

avec tous les aléas d'un ordi et sa foultitude de composants qui peuvent
foirer dans le temps, à commencer par la carte SD.

Ca, je l'ai moi même soulevé dans mon message. La carte SD est un énorme
problème sur le rPi; pas juste pour la qualité du matériel; mais, j'ai
avant d'avoir des rPi, j'ai eu deux corruptions d'ext3 sur PC, sans lien
avec des pannes secteur; plus une dizaine sous XFS).
Dans les deux cas, il y a des problèmes d'alimentation.

pas de panne secteur mais des problèmes d'alimentation, tu peux préciser
?

Post by Benoit-Pierre DEMAINE

Je ne m'y fierai pas
pour du 24/365. Un atmega bien programmé (avec watchdog), tu l'allumes et
tu ne t'en soucies plus pendant des années.

Statistiquement, oui, un Atmel avec FLASH intégré est probablement plus
fiable. Ponctuellement, tu peux avoir un Atmel qui fume plus vite que le
rPi de ton voisin.

évidement

Post by Benoit-Pierre DEMAINE
J'ai du abandonner un énorme projet de lampe sous marine avec chargeur
intelligent, parce que pour des raisons de volume j'avais été obligé de
tout souder directement sur l'uC (strictement impossible de mettre un
socket); puis après une cinquantaine de mise à jour logicielle, la FLASH
du PIC (Microchip, genre un 12F ou 16F, en version SO) a rendu l'âme. Plus
le temps de transposer les composants sur une puce neuve, déprimé, j'ai
laissé tomber. Ces machins sont garantis 1000 ou 10000 cycles, j'en avais
pas fait 100.

pas cool, pourquoi n'as-tu pas prévu de support ?

Post by Benoit-Pierre DEMAINE
Sur les fprums rPi, certains ont des machines avec 2 ans d'uptime; et
certains marchent en continu depuis 3 ans (SD fonctionnelle).

En dehors de problèmes d'alimentation, y-aurait-il une raison pour que
l'usage d'une carte SD soit moins fiable qu'un autre support de masse
habituellement utilisé pour le stockage d'OS ?

Post by Benoit-Pierre DEMAINE

Juste une réflexion perso, faut pas le prendre mal :-)

Ce qui m'a motivé à m'étendre, c'est 3 choses: il a demandé deS
alternativeS, puis il a parlé de Wifi, et de controle web.

[Benoit-Pierre DEMAINE]

Post by olivier B.

Post by Benoit-Pierre DEMAINE
Dans les deux cas, il y a des problèmes d'alimentation.

pas de panne secteur mais des problèmes d'alimentation, tu peux préciser
?

Problème de fiabilité des alimentations (chinoises ou pas).

Post by olivier B.

Post by Benoit-Pierre DEMAINE
parce que pour des raisons de volume j'avais été obligé de
tout souder directement sur l'uC (strictement impossible de mettre un
socket

pas cool, pourquoi n'as-tu pas prévu de support ?

parce que pour des raisons de volume j'avais été obligé de
tout souder directement sur l'uC (strictement impossible de mettre un
socket)

Post by olivier B.

Post by Benoit-Pierre DEMAINE
Sur les fprums rPi, certains ont des machines avec 2 ans d'uptime; et
certains marchent en continu depuis 3 ans (SD fonctionnelle).

En dehors de problèmes d'alimentation, y-aurait-il une raison pour que
l'usage d'une carte SD soit moins fiable qu'un autre support de masse
habituellement utilisé pour le stockage d'OS ?

La qualité des FLASH modernes. Avant, on avait que deux qualités de FLASH:
la premier prix, avec un mappage linéaire, qui fumait au premier
transistor mort; et la haut de gamme. Maintenant, on a tout un pannel de
qualité, avec plus d'une centaine de raisons différentes d'avoir un truc
qui cesse de fonctionner au bout d'un certain temps. Rien de déterminer
quel algorythme de réallocation des secteurs morts est un défi; puis
déterminer le taux de secteurs surnuméraires; l'algorythme de rotation des
blocs alloués pour l'homogénéisation de l'usure; la tolérance de la puce
aux problèmes d'alimentation (sous tension, surtension, parasites), ultra
variable ...

Sans compter que dans le rPi V1, il y a eu deux séries qui incluaient un
firware qui suralimentait le slot SD et provoquait des grillages rapides
(quelques mois) (le bug a été reconnu par la fondation, et corrigé).

A quoi tu dois ajouter les contrefaçons:
(on m'avait passé un lien sur un mec qui s'est retrouvé avec un lot de
10000 cartes labellisées Sandisk, contenant des puces KingStom: un night
batch. Des 32GiB, avec une date d'usinage de 2002 ... )

Ces problèmes sont réduits avec les FLASH internes aux périphériques; mais
pas inexistants. En particulier, si un périphérique est fabriqué par une
usine X, mais que tu préfère l'algorythme de gestion des blocs
surnuméraires du brevet Y, tu es coincé.

[JKB]

Le Thu, 07 Sep 2017 00:49:43 +0200,

Post by Benoit-Pierre DEMAINE

avec tous les aléas d'un ordi et sa foultitude de composants qui peuvent
foirer dans le temps, à commencer par la carte SD.

Ca, je l'ai moi même soulevé dans mon message. La carte SD est un énorme
problème sur le rPi; pas juste pour la qualité du matériel; mais, j'ai
avant d'avoir des rPi, j'ai eu deux corruptions d'ext3 sur PC, sans lien
avec des pannes secteur; plus une dizaine sous XFS).

Ça, je n'ai jamais eu. Pourtant, j'en ai eu des serveurs avec
ext2/3/4 depuis le noyau 1.0.9 qui ne me rajeunit pas. Il n'y avait
pas par hasard un problème de mémoire ou de disque ?

Post by Benoit-Pierre DEMAINE
J'ai du abandonner un énorme projet de lampe sous marine avec chargeur
intelligent, parce que pour des raisons de volume j'avais été obligé de
tout souder directement sur l'uC (strictement impossible de mettre un
socket); puis après une cinquantaine de mise à jour logicielle, la FLASH
du PIC (Microchip, genre un 12F ou 16F, en version SO) a rendu l'âme. Plus
le temps de transposer les composants sur une puce neuve, déprimé, j'ai
laissé tomber. Ces machins sont garantis 1000 ou 10000 cycles, j'en avais
pas fait 100.

Les flashes n'aiment pas la température. 60°C, c'est un maximum
(c'est écrit en tout petit dans les datasheets).

Post by Benoit-Pierre DEMAINE
Sur les fprums rPi, certains ont des machines avec 2 ans d'uptime; et
certains marchent en continu depuis 3 ans (SD fonctionnelle).

J'en ai en prod depuis plus longtemps. Carte SD en lecture seule
avec les bonnes options de montage pour /var.

Sinon, un boot en fat et le reste en UBIFS avec l'émulation mdblock,
ça fonctionne au poil.

JKB

[Benoit-Pierre DEMAINE]

Post by JKB
Le Thu, 07 Sep 2017 00:49:43 +0200,

Post by Benoit-Pierre DEMAINE

avec tous les aléas d'un ordi et sa foultitude de composants qui peuvent
foirer dans le temps, à commencer par la carte SD.

Ca, je l'ai moi même soulevé dans mon message. La carte SD est un énorme
problème sur le rPi; pas juste pour la qualité du matériel; mais, j'ai
avant d'avoir des rPi, j'ai eu deux corruptions d'ext3 sur PC, sans lien
avec des pannes secteur; plus une dizaine sous XFS).

Ça, je n'ai jamais eu. Pourtant, j'en ai eu des serveurs avec
ext2/3/4 depuis le noyau 1.0.9 qui ne me rajeunit pas. Il n'y avait
pas par hasard un problème de mémoire ou de disque ?

EXT3, le plus fun que j'ai eu de toute ma vie: "invalid boot sector".
Avant de refaire fdisk, j'ai jeté un oeil au bloc avec head: une entête
email. Dans le secteur 0. Un email généré par cron, envoyé à exim. Dans le
secteur 0. C'était une débian toute neuve (45mn). Je vois même pas comment
c'est possible. J'en étais encore à installer ssh, et importer mon profile
vimrc.

XFS, ce qui est écrit dans la documentation: "UPS fortement recommandé".
Dans un PC portable ou la journée se termine souvent par une batterie à
0%, ça pardonne pas.

Post by JKB

Post by Benoit-Pierre DEMAINE
Sur les fprums rPi, certains ont des machines avec 2 ans d'uptime; et
certains marchent en continu depuis 3 ans (SD fonctionnelle).

J'en ai en prod depuis plus longtemps. Carte SD en lecture seule
avec les bonnes options de montage pour /var.
Sinon, un boot en fat et le reste en UBIFS avec l'émulation mdblock,
ça fonctionne au poil.

Quand on sait faire. Quand on a le temps, et les connaissances. T'as
publié un tuto sur le forum officiel ?

[JKB]

Le Fri, 08 Sep 2017 08:04:53 +0200,

Post by Benoit-Pierre DEMAINE

Post by JKB
Le Thu, 07 Sep 2017 00:49:43 +0200,

Post by Benoit-Pierre DEMAINE

avec tous les aléas d'un ordi et sa foultitude de composants qui peuvent
foirer dans le temps, à commencer par la carte SD.

Ca, je l'ai moi même soulevé dans mon message. La carte SD est un énorme
problème sur le rPi; pas juste pour la qualité du matériel; mais, j'ai
avant d'avoir des rPi, j'ai eu deux corruptions d'ext3 sur PC, sans lien
avec des pannes secteur; plus une dizaine sous XFS).

Ça, je n'ai jamais eu. Pourtant, j'en ai eu des serveurs avec
ext2/3/4 depuis le noyau 1.0.9 qui ne me rajeunit pas. Il n'y avait
pas par hasard un problème de mémoire ou de disque ?

EXT3, le plus fun que j'ai eu de toute ma vie: "invalid boot sector".
Avant de refaire fdisk, j'ai jeté un oeil au bloc avec head: une entête
email. Dans le secteur 0. Un email généré par cron, envoyé à exim. Dans le
secteur 0. C'était une débian toute neuve (45mn). Je vois même pas comment
c'est possible. J'en étais encore à installer ssh, et importer mon profile
vimrc.

C'est possible lorsqu'on a foiré son installation de raid soft où
qu'on s'est pris les pieds dans le tapis entre partitions, lvm et
disque complet. Ce n'est pas la faute à ext3.

Post by Benoit-Pierre DEMAINE
XFS, ce qui est écrit dans la documentation: "UPS fortement recommandé".
Dans un PC portable ou la journée se termine souvent par une batterie à
0%, ça pardonne pas.

Pour tous les systèmes de fichiers montés avec async, l'UPS est
fortement recommandé.

Post by Benoit-Pierre DEMAINE

Post by JKB

Post by Benoit-Pierre DEMAINE
Sur les fprums rPi, certains ont des machines avec 2 ans d'uptime; et
certains marchent en continu depuis 3 ans (SD fonctionnelle).

J'en ai en prod depuis plus longtemps. Carte SD en lecture seule
avec les bonnes options de montage pour /var.
Sinon, un boot en fat et le reste en UBIFS avec l'émulation mdblock,
ça fonctionne au poil.

Quand on sait faire. Quand on a le temps, et les connaissances. T'as
publié un tuto sur le forum officiel ?

Non. Mais un coup de recherche google sur block2md te donnera tout
ce qu'il faut. Il existe par ailleurs plein de tutorials causant des
problèmes des mémoires flash et de la façon de les résoudre par
yaffs ou plus facilement ubifs.

Grosso-modo :
- copie de la partition système (pour avoir sa taille exacte) de la
SD vers un fichier ;
- création du volume ubifs sur le fichier ;
- copie des fichiers ;
- utilisation de block2md
- reboot.

JKB

[Benoit-Pierre DEMAINE]

Post by JKB

Post by Benoit-Pierre DEMAINE
EXT3, le plus fun que j'ai eu de toute ma vie: "invalid boot sector".
Avant de refaire fdisk, j'ai jeté un oeil au bloc avec head: une entête
email. Dans le secteur 0. Un email généré par cron, envoyé à exim. Dans le
secteur 0. C'était une débian toute neuve (45mn). Je vois même pas comment
c'est possible. J'en étais encore à installer ssh, et importer mon profile
vimrc.

C'est possible lorsqu'on a foiré son installation de raid soft où
qu'on s'est pris les pieds dans le tapis entre partitions, lvm et
disque complet. Ce n'est pas la faute à ext3.

PC portable P3 avec un seul disque à plateaux, installation Debian tout
par défaut (installeur en mode flemmard).

Certes, c'est pas la faute à EXT3, mais à celui qui a écrit au mauvais
endroit; de toute façon, ce jour là, c'est la table qui avait pété; il
aurait fallu au minimum un GPT avec backups en fin de disque pour réparer
la chose.

Mais si on part de l'idée qu'il est très peu probable que l'auto-conf ait
dit à exim de stocker le cache dans /dev/sda ... il ne reste pas beaucoup
d'options: une erreur dans l'adressage RAM (bus physique HS), ou une
corruption de la mémoire noyeau (bug de driver).

Post by JKB

Post by Benoit-Pierre DEMAINE
XFS, ce qui est écrit dans la documentation: "UPS fortement recommandé".
Dans un PC portable ou la journée se termine souvent par une batterie à
0%, ça pardonne pas.

Pour tous les systèmes de fichiers montés avec async, l'UPS est
fortement recommandé.

Et encore, ça n'a d'utilité que quand tu as un onduleur en réseau, et que
ta machine monitor le bousin ... pour s'éteindre au moment opportun.

Mais quand je vois que Windows 10 n'inclus toujours pas de SMARTd ...

Post by JKB
Non. Mais un coup de recherche google sur block2md te donnera tout
ce qu'il faut. Il existe par ailleurs plein de tutorials causant des
problèmes des mémoires flash et de la façon de les résoudre par
yaffs ou plus facilement ubifs.

Va expliquer ça à la fondation Framboise ...

[Benoit-Pierre DEMAINE]

Consommation mesurée, rPi1, fréquence par défaut.

Avec écran et périphériques: 0.5 à 0.9A (afficheurs LED de 60cm, sondes I2C).

Sans écran ni rien: 0.1 à 0.50A. Compter en moyenne 0.30A, avec un système
relativement chargé (85% iddle en moyenne). Soit 1.5W

Les puissances officielles vont de 0.8W à 7W selon les modèles. Dans tous
les cas, ça diminue en baissant la fréquence.
http://elinux.org/RPi_Hardware

Mon écran consomme donc environ 0.1A, soit 0.5W.

Pour le cas du jour, je pense que 1.5W est très peu. On parle de piloter
12W de guirelandes ... C'est à l'auteur de trancher selon la puissance de
son panneau, et la capacité de sa batterie.

On est là pour proposer des solutions techniques (et des critères de
choix); pas pour décider à la place de Mic8 ... surtout quand il nous
manque deux valeurs capitales.

Je ne doute pas qu'un Atmel ou un PIC puissent descendre beaucoup plus
bas; mais quand Mic8 voudra leur coller une RTC, du Wifi, et du web ... le
rPi sera beaucoup plus souple.

[mic8]

Post by Benoit-Pierre DEMAINE
Pour le cas du jour, je pense que 1.5W est très peu. On parle de piloter
12W de guirelandes ... C'est à l'auteur de trancher selon la puissance de
son panneau, et la capacité de sa batterie.
On est là pour proposer des solutions techniques (et des critères de
choix); pas pour décider à la place de Mic8 ... surtout quand il nous
manque deux valeurs capitales.

Ne vous battez pas, j'ai fait mon choix et vient de reevoir les
composants.
Y a plus qu'à.... :-)

Arduino Uno avec un DS1307 pour commander 4 mosfets. y a tout pour mon
bonheur.

Mais encore merci pour vos avis et propositions fort apréciables.

[olivier B.]

Post by mic8

Post by Benoit-Pierre DEMAINE
Pour le cas du jour, je pense que 1.5W est très peu. On parle de piloter
12W de guirelandes ... C'est à l'auteur de trancher selon la puissance de
son panneau, et la capacité de sa batterie.
On est là pour proposer des solutions techniques (et des critères de
choix); pas pour décider à la place de Mic8 ... surtout quand il nous
manque deux valeurs capitales.

Ne vous battez pas, j'ai fait mon choix et vient de reevoir les
composants.
Y a plus qu'à.... :-)
Arduino Uno avec un DS1307 pour commander 4 mosfets. y a tout pour mon
bonheur.

très bien :-)

Post by mic8
Mais encore merci pour vos avis et propositions fort appréciables.

Petit complément, l'utilisation de sorties PWM te permet d'envisager de
graduer l'éclairage (chose que tu n'aurais pas pu faire avec des relais).

ça peut être bien pour Noël...

Autre chose que tu peux envisager de faire si ton régulateur solaire est
de type basique, c'est d'ajouter au 328 une fonction de power-tracking, si
ça te tente ça fera un bon sujet de conversation sur ce groupe :-p

[mic8]

Post by olivier B.
Petit complément, l'utilisation de sorties PWM te permet d'envisager de
graduer l'éclairage (chose que tu n'aurais pas pu faire avec des relais).

Oui en effet, j'ai d'ailleurs déjà fait quelques tests hier soir avec
une simple led.

Post by olivier B.
ça peut être bien pour Noël...

Là j'ai déjà tout plein de trucs qui clignottent :-)

Post by olivier B.
Autre chose que tu peux envisager de faire si ton régulateur solaire est
de type basique, c'est d'ajouter au 328 une fonction de power-tracking, si
ça te tente ça fera un bon sujet de conversation sur ce groupe :-p

Cela m'a traversé l'esprit en effet: influer sur le programme
d'éclairage en tenant compte de l'état de charge de la batterie ou de
l'ensoleillement du/des jours précédent et de la saison (que je vais
connaître via l'horloge)

[olivier B.]

Post by mic8

Post by olivier B.
Autre chose que tu peux envisager de faire si ton régulateur solaire est
de type basique, c'est d'ajouter au 328 une fonction de power-tracking, si
ça te tente ça fera un bon sujet de conversation sur ce groupe :-p

Cela m'a traversé l'esprit en effet: influer sur le programme
d'éclairage en tenant compte de l'état de charge de la batterie ou de
l'ensoleillement du/des jours précédent et de la saison (que je vais
connaître via l'horloge)

ça c'est de la gestion d’énergie, que tu peux aussi implémenter, mais
ce dont je parle est en amont et permet de tirer le maximum d’énergie
voltaïque:

http://bryanwbuckley.com/projects/mppt.html

Les mesures faite pour le power-tracking peuvent meme servir à faire un
sun ou solar-tracking

On ne s'ennuie jamais avec Arduino :-p

[mic8]

ça c'est de la gestion d'énergie, que tu peux aussi implémenter, mais
ce dont je parle est en amont et permet de tirer le maximum d'énergie
http://bryanwbuckley.com/projects/mppt.html
Les mesures faite pour le power-tracking peuvent meme servir à faire un
sun ou solar-tracking

Le plus simple n'est-i

On ne s'ennuie jamais avec Arduino :-p

[mic8]

ça c'est de la gestion d'énergie, que tu peux aussi implémenter, mais
ce dont je parle est en amont et permet de tirer le maximum d'énergie
http://bryanwbuckley.com/projects/mppt.html
Les mesures faite pour le power-tracking peuvent meme servir à faire un
sun ou solar-tracking

Ah, ok. Mais mes panneaux sont fixe, je ne peux les articuler.
Par contre je ferais plutôt cela avec 4 photorésitances (2 pour chaque
axe) et deux comparateurs.

On ne s'ennuie jamais avec Arduino :-p

Je n'en doute point.
D'ailleurs j'y retourne :-)

[olivier B.]

Post by mic8

ça c'est de la gestion d'énergie, que tu peux aussi implémenter, mais
ce dont je parle est en amont et permet de tirer le maximum d'énergie
http://bryanwbuckley.com/projects/mppt.html
Les mesures faite pour le power-tracking peuvent meme servir à faire un
sun ou solar-tracking

Ah, ok. Mais mes panneaux sont fixe, je ne peux les articuler.
Par contre je ferais plutôt cela avec 4 photorésitances (2 pour chaque
axe) et deux comparateurs.

Le plus important est de positionner le premier axe en équatorial, il
suffit alors à tracker déjà efficacement sur 24h, le deuxième axe est
l'élévation, variant annuellement, qui est souvent fixe sur les
installations que j'ai vu, positionné proche de l'optimal hiver.

Attention je précise pour éviter les confusion que le power-tracking ne
concerne pas l'orientation des panneaux mais le fait d'en tirer
électriquement le maximum d’énergie, ça peut t'être utile si tu as de
fin de journée ou la batterie n'est pas totalement chargée.

Voir par exemple:
http://www.instructables.com/id/ARDUINO-SOLAR-CHARGE-CONTROLLER-Version-30/

Je pense que le buck doit être implémentable via mosfet et pwm du 328.

Post by mic8

On ne s'ennuie jamais avec Arduino :-p

Je n'en doute point.
D'ailleurs j'y retourne :-)

:-)