framboise314.fr

Oui je pense que le canal 0 est mort, mais vous avez vue que vous pouviez utiliser les autres.
les signaux sur 2 et 4 sont bien du à de "l'induction" surtout si les câbles 2 et 4 sont en nappes avec le 3 et son en l 'aire , ca fait "antenne , pour éviter ca , utiliser que le nombres de câbles nécessaires ou connecter les câbles non utilisés à un potentiel fixe.

bon courage pour la suite.@+

Bonsoir à tous,

guillaume9344 a écrit :
Bon courage , je continu à suivre votre post , meme si je n'ai pas encore craqué pour l 'achat des module ESp (je me bas encore avec mes nrf24l01)
@+

Pour réaliser des commandes sans fil, j’ai utilisé pour ma part les modules RF 433MHZ de GROVE avec un Arduino pour piloter des Interrupteurs domotique Blyss de castorama
http://www.castorama.fr/store/Module-re ... navCount=0
Je ne sais pas si ces modules sont encore vendus, mais c'est pratique pour gérer du 220V.

On peut trouver des informations sur Google -> « interrupteur blyss arduino » sur le reverse engineering du protocole utilisé par Blyss.

C’est vrai que l’on oublie les différents modules de tests qui trainent au fond des tiroirs.
http://dangerousprototypes.com/docs/Bus_Pirate
Pour ma part, j’ai oublié mon BUS Pirate qui permet de tester les protocoles :

– 1-Wire
– I2C
– SPI
– Asynchronous serial
– MIDI
– HD44780 LCD
– 2 et 3-wire + « bitwise pin control »
– mode « raw binary » sur les modes bitbang, 1-Wire, I2C, SPI, et UART

Voir le lien pour des exemples.
https://skyduino.wordpress.com/2011/10/ ... situation/

Voici par exemple l’utilisation du BUS Pirate sur le DS1337.
On peut trouver l’adresse des puces I2C
On peut lire et écrire des données sur l’IDC.
On peut sniffer le bus I2C.

Code : Tout sélectionner

HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)

(1)>4
Set speed:
 1. ~5KHz
 2. ~50KHz
 3. ~100KHz
 4. ~400KHz

(1)>4
Ready
I2C>W
Power supplies ON
I2C>P
Pull-up resistors ON
I2C>(1)
Searching I2C address space. Found devices at:
0xD0(0x68 W) 0xD1(0x68 R)

I2C>(2)
Sniffer
Any key to exit

I2C>[0xd0 0 [0xd1 r:16]
I2C START BIT
WRITE: 0xD0 ACK
WRITE: 0x00 ACK
I2C START BIT
WRITE: 0xD1 ACK
READ: 0x19  ACK 0x04  ACK 0x02  ACK 0x03  ACK 0x04  ACK 0x05  ACK 0x06  ACK 0x00  ACK 0x81  ACK 0x82  ACK 0x83  ACK 0x80  ACK 0x81  ACK 0x82  ACK 0x07  ACK 0x83
NACK
I2C STOP BIT
I2C>

Une fois le BUS Pirate configuré, pour lire des données sur l’I2C on utilise la syntaxe :
[0xd0 0 [0xd1 r:16]
En plus on peut flasher l’AVR pour mettre à jour le BUS Pirate.

Jean-Marie a écrit :- A2F à un signifie qu'il y a eu une égalité entre le temps d'horloge et le registre d'alarme N°2. Ce flag va générer sur INTA un niveau bas si INTCN est au niveau zéro et que A2IE est au niveau un. Si INTCN et A2IE valent 1, c'est INTB qui passe à 0. Aucun de ces cas n'est réalisé ici.

Jean-Marie, je pense que tu as voulu dire :
c’est INTB qui va passer au niveau bas si INTCN est à 1 et A2IE à 1.

Jean-Marie a écrit : J'ai plusieurs fonctions du genre char i2c_write(address). Cette fonction retourne théoriquement une valeur de type char. Or les exemples que je vois (et que j'utilise) appellent souvent cette fonction sans valeur de retour, du genre i2c_write(Ad) au lieu de ch = i2c_write(Ad). Est-ce autorisé en C ? Si je me souviens bien, ça ne l'est pas en Pascal.

Oui on peut ne pas indiquer de variable de retour, mais dans ce cas la fonction peut renseigner une ou plusieurs variables globales (Variables accessibles dans la totalité du programme).

Jean-Marie a écrit : @ SMBA38 : la pin 7 pulse bien à 32kHz. Pourquoi je n'ai rien détecté à la carte-son ? PARCE QU' ELLE NE VA QUE JUSQU' A 20kHz !!!

Donc la question de l’alimentation du circuit à l’initialisation du DS1337 reste d’actualité.
Le signal ne semble pas tout à fait carré sur l'analyseur ?

La suite au prochain numéro.

SMBA38.

Hello SMBA
J'ai écrit : Si INTCN et A2IE valent 1, c'est INTB qui passe à 0.

SMBA a écrit :Jean-Marie, je pense que tu as voulu dire :
c’est INTB qui va passer au niveau bas si INTCN est à 1 et A2IE à 1.

J'ai beau relire trois fois ta remarque, je pense que nous disons la même chose.

En parlant de la SQW après une interruption de l'alimentation ...

Donc la question de l’alimentation du circuit à l’initialisation du DS1337 reste d’actualité.

Quelle était précisément ton idée ? Se servir du SQW pour déclencher l'alim du module et provoquer un boot de l'ESP et du µC ? Comment faire pour consommer le moins d'énergie possible ?

Le signal ne semble pas tout à fait carré sur l'analyseur ?

Je suppose que tu veux parler du rapport cyclique qui n'est pas 50%. Je ne me souviens pas que la Datasheet précise le duty cycle. D'après l'analyseur logique, l'état haut dure 21 µS et l'état bas dure 9,5 µS. La période est la somme des deux, c à d 30,5 µS.

Hello SMBA

Voila, j'ai écrit le petit programme que tu proposais.

Code : Tout sélectionner

int main(void)
{
	byte Reg;
	byte Data[0x10] ={0x50, 0x01 ,0x02, 0x03, 0x04, 0x05,0x06, 0x00, 0x00 ,0x00, 0x00,0x80, 0x81 ,0x82,0x06,0x00};
	AVR_init();
	UART_init();
    stdout = &UART_output;
    stdin  = &UART_input;
	i2c_init();
	printf("Ecriture des registres de DS1337\n");
    i2c_start_wait(DS1337_W);   // set device address and write mode
    i2c_write(0x00);			// Set Address of Register
	for (Reg = 0x00; Reg < 0x10 ; Reg++)
	{
		printf("Write Reg %X : %X  Result %X \n", Reg, Data[Reg], i2c_write(Data[Reg]));
	}
	i2c_stop();
	
	_delay_ms(5000);
	
	printf("\nLecture des registres de DS1337 après 5 secondes\n");
    i2c_start_wait(DS1337_W);   // set device address and write mode
	i2c_write(0x00);			// Set Address of Register
	i2c_rep_start(DS1337_R);    // set device address and read mode
	
	for (Reg = 0x00; Reg < 0x0F ; Reg++)
	{
		printf("Reg %X : %X \n", Reg, i2c_readAck());
	}
	printf("Reg %X : %X \n", Reg, i2c_readNak());
	i2c_stop();
	
	while(1)
	{
		FlashLED();
	}
}

Et voici la trace dans le moniteur :

: 64.jpg (68.9 Kio) Vu 7530 fois

.

Sur la breadboard, ma led témoin de la pin SQW/ INTB est d'abord allumée pendant 10 secondes, puis elle s'éteint.
Tout semble donc normal.
Bon, la-dessus je me paye un Senseo !

Hello Jean-Marie.

Jean-Marie a écrit :
J'ai beau relire trois fois ta remarque, je pense que nous disons la même chose.

Oui tu as raison, en fait tu indiques en plus qu’avec INTCN=0 A2IE=1 permet de gérer INTA.

Jean-Marie a écrit :
Quelle était précisément ton idée ? Se servir du SQW pour déclencher l'alim du module et provoquer un boot de l'ESP et du µC ? Comment faire pour consommer le moins d'énergie possible ?

Oui C’était mon idée pour alimenter les circuits à l’initialisation du DS1337.
Mais ta solution d’un contact peut marcher.

A la place du contact on pourrait mettre un interrupteur que l’on ferme au changement de piles et que l’on ouvre après que l'initialisation soit terminée (ça doit être l'affaire de quelques secondes).
A l'initialisation , on pourrait rechercher via le WiFi la date sur un serveur NTP pour mettre à jour l'horloge du DS1337.

Le programme peut s’apercevoir qu’il s’agit d’une initialisation si RS1=RS2=1.

Jean-Marie a écrit :
Je suppose que tu veux parler du rapport cyclique qui n'est pas 50%. Je ne me souviens pas que la Datasheet précise le duty cycle. D'après l'analyseur logique, l'état haut dure 21 µS et l'état bas dure 9,5 µS. La période est la somme des deux, c à d 30,5 µS.

Oui je pensais que le rapport cyclique était de 50%, c’est ce que j’avais vu sur le lien pour un DS1307.
http://www.idreammicro.com/post/Utilisa ... -du-DS1307

Je viens de recevoir les Quartz 32.768KHZ, c’était mon quartz qui ne fonctionnait pas.
Donc voici la sortie à l’initialisation du DS1337.

: DS1337 SQW.JPG (111.8 Kio) Vu 7522 fois

le signal n'est pas trop carré, ça vient peut-être du câble nom blindé que j'utilise, quand j'ai récupéré l'Oscillo il n'y avait pas de câbles.
J'ai commandé des sondes sur Internet.

Nous en sommes au même point sur nos montages, mais je vais attendre que tu résolves la partie électronique pour me lancer à mon tour.

A+
SMBA38

Je suis bien content que ton nouveau quartz fonctionne bien.
Sur ton oscillo, on voit aussi que le signal bas est plus étroit que le signal haut. Le front montant est un peu arrondi, rappelant la charge d'une capacité à travers la résistance de 10k, mais ce n'est probablement pas la raison car le front descendant est bien carré.

Réfléchissons à la réinitialisation de l'horloge lorsque l'alimentation est rétablie après une coupure.
RS1 et RS2 sont tous les deux à 1 et la pin SQW/INTB pulse à 32kHz.
Les bits RS1 et RS2 nécessitent un µC pour les détecter. Or le µC et l'ESP ne reçoivent leur alimentation que quand l'alarme de l'horloge est déclenchée, c'est à dire quant INTA passe à 0.
On ne peut pas se servir de SQW/INTB de manière directe sur la gate du transistor switch de l'alimentation du module car cela reviendrait à pulser l'alimentation à une fréquence de 32kHz. Il faudrait donc au moins une bascule entre SQW/INTB et la gate. Mais ce serait dommage de devoir alimenter une bascule pendant plusieurs années pour que la DS1337 puisse se réinitialiser automatiquement le jour où on remplace sa pile.

Je continue à penser que la meilleure solution est de prévoir sur le module un bouton de "Reset" forçant l'alimentation du module, la communication de l'ESP avec l'unité centrale, la récupération de l'heure et de la date, provenant soit de l'unité centrale, soit d'Internet (avec une préférence pour l'unité centrale car la connexion est plus rapide et Internet peut être en panne). Il faut également obtenir la prochaine heure d'alarme ou la fréquence de celle-ci et réinitialiser la DS1337 avec toutes ces données. De plus, le bouton "Reset" sera bien utile pour la mise au point du module et pour tout ce qui pourrait se produire et qui n'a pas été prévu dans les programmes informatiques ou à la conception du module.

J'ai reçu (d'AliExpress comme d'habitude) des petites platines photovolaïques de 6 x 6 cm, produisant théoriquement 2V et 150mA.

: 65.jpg (67.08 Kio) Vu 7512 fois

Dans une piece, non exposée aux rayons aux rayons du soleil, la platine me donne 1,2V.
C'est très largement suffisant comme Vin à un circuit intégré comme le LTC3105 pour charger une batterie Li-ion de 3.6V. Le système est renseigné dans un article récent de Digikey. Je vais tester le système. J'ai déjà reçu les LTC3105 (minuscules !!!) et j'attend avec impatience des batteries 18650 de 3000mA commandées chez AliExpress il y a exactement un mois. J'ai aussi commandé récemment des batteries rechargeables LIR2032 qui pourraient servir uniquement à la DS1332. J'ai hâte de tester les différentes configurations avec la cellule solaire et voir si les batteries tiennent leur charge.

Bonsoir Jean-Marie.

Au bouton, je préfère l'interrupteur qui permet d'alimenter le microcontrôleur sans laisser le doigt sur le bouton.
Comme dans mon cas je pense utiliser des ESP8266 autonomes programmés en LUA, j'ai la possibilité de modifier le programme interprété en WiFi via un client Telnet, et c'est plus pratique de programmer avec les deux mains.

De plus le microcontrôleur peut s'apercevoir qu'il est alimenté depuis plus de n secondes et dans ce cas avoir un comportement différent, par exemple envoyer la valeur lue sur un capteur toutes les minutes.

Tes cellules photovoltaïques vont faire double emploi avec les DS1337, car si ces cellules fournissent assez de jus, il est peut-être suffisant de mettre le microcontrôleur en mode économie d'énergie.

Je regarde de temps en temps les nouveautés annoncées, en voici une:
https://www.kickstarter.com/projects/15 ... 9-computer

Je me pose souvent la question de savoir ce qui peut nous faire choisir un microcontrôleur (ou nano ordinateur) plutôt qu'un autre ?.

La consommation,
la puissance,
Les connexions réseau,
Les entrées sorties (GPIO)
La facilité de programmation.
La taille.

En tout cas ce n'est pas le prix car si on regarde bien un système tout prêt coûte souvent moins cher qu'un système assemblé avec plusieurs composants.

Et comme dans le cas des retraités le temps ne compte pas, ça doit être le plaisir de surmonter les difficultés que l'on s'impose.

En ce qui me concerne, à part les cas ou la consommation et / ou la taille sont primordiales, la solution Raspberry PI me convient parfaitement.

A+
SMBA38

Hello SMBA

D'après ce que je comprends, tu préfères un interrupteur parce que la durée de pression sur un bouton est imprécise.
En réalité, dès que l'alimentation est lancée, l'idée est que le module maintienne lui-même son alimentation et ne la coupe que quand toutes les tâches sont terminées.
Je n'ai pas trouvé la durée du boot pour l'ESP. Par contre, je la connais pour un Atmega. On a le choix entre plusieurs durées mais tout le monde choisit toujours la durée la plus longue pour être sûr de la stabilité de l'alimentation et de l'oscillateur interne. Cette durée est de 65 mSec. C'est évidemment très court et je ne pense pas qu'on puisse physiquement relâcher le bouton poussoir avant ça. La première instruction du programme sera de prendre le relais du bouton poussoir en commandant le niveau d'une pin.

Puisque tu envisages d'utiliser l'ESP sans µC externe, tu avais un jour manifesté une réticence à l'idée de consacrer une pin de l'ESP à la gestion de l'alimentation. Cela vaut peut-être pour l'ESP-1 mais l'ESP-12 possède 9 GPIO en plus de l'alimentation, de Rx/Tx, de l'ADC et du Reset. Même si l'ESP doit gérer 3 capteurs, ça laisse encore de la marge.

Je préfère un bouton poussoir parce que c'est moins volumineux qu'un interrupteur et que cela élimine le risque de l'oublier en position ON. Et comme c'est le module qui coupe le courant, il n'y a pas de risque de couper l'alimentation avant que les échanges wifi ne soient terminés. En effet, il peut y avoir du retard parce que l'unité centrale ou Internet peuvent être busy.

Tes cellules photovoltaïques vont faire double emploi avec les DS1337, car si ces cellules fournissent assez de jus, il est peut-être suffisant de mettre le microcontrôleur en mode économie d'énergie.

Oui, il est possible que l'énergie fournie par la cellule solaire soit suffisante pour que le µC reste en sleep et se réveille lui-même quand il doit envoyer sa mesure. Mais c'est difficile à prévoir car cela dépend d'une part des conditions d'éclairage (qui diffèrent selon la période de l'année et la localisation géographique) et d'autre part de la fréquence d'envoi des données que tu imposes au module.
Il serait probablement utile de séparer le module capteur-transmetteur (ESP + éventuellement un µC externe) du module d'alimentation. Ce dernier pourrait être de divers types : modèle simple comportant des piles sèches, modèle à batteries rechargeables mais sans système de recharge, modèle à recharge photovoltaïque, modèle à alimentation par le 220V.

J'ai reçu aujourd'hui les batteries rechargeables 18650 commandées. Elles ont l'air chargées et donnent actuellement 3,8V.
Mais sacrebleu ! J'ai oublié de commander des boîtiers (holder).

Coucou,

Le dash button d'Amazon semble utiliser un ESP8266.

http://www.amazon.com/s/ref=nb_sb_noss_ ... ash+button

http://rue89.nouvelobs.com/2015/04/01/d ... yer-258472

D'autres exemples de "Dash Button"
http://forum.allaboutcircuits.com/threa ... ca.110965/
Plus une simulation sympa http://everycircuit.com/circuit/5147923 ... ash-button

http://www.esp8266.com/viewtopic.php?f=6&t=2240

https://github.com/DeqingSun/ESP8266-Dash-Button

Amazon doit de temps en temps parcourir le forum de Framboise 314 ?

A+
SMBA38

framboise314.fr

Tous les capteurs reliés au RPI par Wifi avec module ESP8266

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP

Re: Tous les capteurs reliés au RPI par Wifi avec module ESP