question à propos du bod
-
Salut
Sur pile 1.5V j'imagine ?
Oulala DHT22 c'est tout sauf low power ces trucs là en plus çà met plus d'une seconde pour effectuer une mesure
Pour le bus I2C tout dépends de comment tu pars en veille. J'ai rencontré ce type de soucis avec le SPI du module RF.
J'ai pas trop eu le temps de faire de l'ULPNode ces derniers temps mais semaine prochaine je m'en occupe et même si je suis pas tout à fait prêt je vais mettre au propre et, je vais releaser les schémas et source code (et tu verras au niveau du code y'a des astuces dans tous les coins) d'ici la fin du mois, beaucoup de personnes semblent intéressées et je vais profiter de la communauté pour être plusieurs a bosser dessus ce sera plus cool
Pour les MOSFET, je sais pas te dire, mais perso je mets pas de diode et ma commande se fait avec une I/O comme çà :
Pour l'I2C et les sensors power c'est un peu plus tordu car je power toute la zone y compris les pull up de l'I2C
Peut être ton sensor doit attendre un peu dès que tu le power avant de fonctionner ?
T'as eu aucun soucis de consommation à la mise en veille/reveil du RFM69 ? parce que j'en ai eu 2 sérieux qui me torpillaient le mode LOWPower et me faisait sortir du mode veille toutes les secondes !!
Ahahah excellent le MysensorsGW_huzzah
je viens de faire un design basé dessus pour la teleinfo !!!
Perso j'utilise plus les cartes nodemcu (pas en LUA) car elles ont le convertisseur USB/Serie intégré ce qui est bien pratique pour le DEV (surtout au même prix)Merci pour la GW mais y'a un taff de dingue à faire
-
merci pour ta réponse!
oui je fait mes tests avec 2 piles 1.5v. on fait comme on peut!
oui pour les diodes sur le schema, je les ai mis. mais là pour l'instant j'ai mis des res de 120o (sous la main). les diodes je pensais que ça m'assurerait de moins consommer, mais quand j'ai eu le probleme de mosfet, je les ai viré pour test avec res. ça n'a rien changé, j'ai changé les mos ensuite. et c'était bon. sur ton schema, tu n'as pas mis de 10k entre le Vcc et le gate? c'est l'arduino qui polarise j'imagine?pour l'i2c, en fait je dois me trouver plus ou moins dans le meme cas : le module BH1750 que j'ai à les pull up dessus (donc elles sont reliés au vcc du module) et je power le module par mosfet. Donc ça doit être pareil je pense. Et avant d'aller en veille je configure mes pin en output=0 pour etre sûr. d'ailleurs si je fais pas ça j'ai une surconso.
Humm, mon probleme d'init i2c doit se trouver du côté du sketch car si je reset ça refonctionne tant que je vais pas en veille...pourtant j'ai même rajouté un delay de 10sec!Non, pas eu de souci avec la radio...j'utilise le nrf pour l'instant et dans la lib mysensors 1.4 il n'utilise pas l'irq pour l'instant. J'imagine que c'était l'irq du rfm qui t'as embeté??? mais merci pour l'info ça m'évitera de galérer qd je passerai au rfm. Très hate de voir ton travail sur l'ulp, surtout tes astuces. car plus j'avance et plus je me rends compte qu'il y a des astuces à droite à gauche.
Hihihi, oui pour le GW huzzah, c'est pas complexe comme truc. j'ai même pas eu le temps de test en plus! et faut toujours que je me rajoutes des trucs à faire, lol! en parallèle je bosse sur un flower version pro (sans oxydation des sondes, précis...), et jme dessine une board neutrino pour le fun! (j'ai en commande des sample atmel). J'attends des pcb aussi pour me faire un roller shutter avec mesure conso pour détecter les fins de course et pouvoir ouvrir en %...bref, je geek à fond aaaaaaaaaah!
pour ta GW, tu m'étonnes qu'il doit y a avoir du boulot, mais ça aura de la gueule tout ton ptit réseau. Moi aussi, j'aime bien la spark family, dommage que j'ai pas plus de temps à y consacrer.
-
Ah ok, t'es en 3V mais sans le booster pour le moment, je comprends mieux ta consommation. Effectivement, je n'ai pas testé avec un NRF il est for possible que tu n'ais pas ce problème avec, et c'est bon à savoir.
Non c'était pas l'IRQ (puisqu'elle est en input) c'était les pin genre MOSI, SCK puisque même le RF69 sans "power" et bien du courant est consommé par ces pins MOSI et SCK car elle étaient à 1. du coup je les passe en input avant la mise en veille (j'ai cherché un moment celle là !!!!) même en les passant à 0 çà merdait.Oui pour la gate du fet, dans le bootloader, direct je mets cette pin en output à 1 pour couper l'alim. mais tu as raison, une 10K sur le VCC assure un état stable à l'init, je vais modifier
-
ahah, ben oui j'ai triché, lol.
pour le dht22, c'est que j'avais pas de sensor temp i2c sous la main, et jvoulais voir si y avait moyen de le rendre un peu moins gourmand. mais c'est vrai que c'est pas la meilleure idée!!
du coup pour mon i2c j'ai essayé de les passer en input comme ce que tu as fait pour ton spi. mais non ça passe pas non plus. Si je mets input (ça freeze, surement resté bloqué dans l'i2c), input_pullup et output=0 pas de freeze mais ça me lit 0. bizarre, Pour l'i2c aussi tu mets en input? output?jvais bien finir par trouver car c'est plutôt assez proche de ton schema ce que je fait et vu que ça fonctionne bien chez toi, ben c'est que je me plante sur un truc.
-
Je viens de regarder mon code je mets bien en input no pull-up mais je viens de voir que je fais une spéciale dont j'avais oublié l'existence aussi, regardes tu vas trouver direct
* ====================================================================== Function: disableCPUDevices Purpose : disable Atmel integrated devices (for low power) Input : - Output : - Comments: - ====================================================================== */ void ULPNode::disableCPUDevices(void) { // Disable ADC ADCSRA &= ~_BV(ADEN) ; // disable Analog comparator ACSR |= _BV(ACD); // Disable digital input buffers on all ADC0-ADC5 pins DIDR0 = 0x3F; // set I2C pin as input no pull up // this prevent current draw on I2C pins that // completly destroy our low power mode //Disable I2C interface so we can control the SDA and SCL pins directly TWCR &= ~(_BV(TWEN)); // disable I2C module this allow us to control // SCA/SCL pins and reinitialize the I2C bus at wake up TWCR = 0; pinMode(SDA, INPUT); pinMode(SCL, INPUT); digitalWrite(SDA, LOW); digitalWrite(SCL, LOW); power_all_disable(); } -
J'imagine que tu veux aussi le WakeUp ;-). t’inquiète pas pour les traces de debug restantes, c'est parce que ce #!#!" de module th02 n'est pas compatible I2C. Tant qu'il est tout seul sur le bus tout va bien, dès qu'il est plus tout seul sur le bus I2C (dans mon cas le capteur de lumière) bien çà mettait la zone, tout plantait !!!! Et crois moi que j'ai mis un moment à comprendre que çà venait pas de mon code
Résultat : changement de capteur, exit le TH02 !!/* ====================================================================== Function: readTLS Purpose : Input : - Output : - Comments: - ====================================================================== */ uint16_t ULPNode::readTLS() { unsigned int ms, data0, data1; // Enable I2C (just in case) power_twi_enable(); // Init I2C Bus // not needed, done in _tsl.begin // Wire.begin(); //i2cScan(); DebugF("Reading TSL2561..."); _tsl.begin(); DebugF(".0."); DebugFlush(); // Set I2C 100KHz for 4MHz speed //TWBR = ((4000000L / 100000L) - 16) / 2; // The light sensor has a default integration time of 402ms, // and a default gain of low (1X). // If you would like to change either of these, you can // do so using the setTiming() command. // If gain = false (0), device is set to low gain (1X) // If gain = high (1), device is set to high gain (16X) // If time = 0, integration will be 13.7ms // If time = 1, integration will be 101ms // If time = 2, integration will be 402ms // If time = 3, use manual start / stop to perform your own integration // setTiming() will set the third parameter (ms) to the // requested integration time in ms (this will be useful later): // Gain=0, timing=1 _tsl.setTiming( 0, 1, ms); DebugF(".1."); DebugFlush(); // To start taking measurements, power up the sensor: if (!_tsl.setPowerUp()) { DebugF("Error="); Debug(_tsl.getError()); _status &= ~RF_NODE_STATE_TSL2561 ; return 0; } DebugF(".2.");DebugFlush(); // We detected the module _status |= RF_NODE_STATE_TSL2561 ; // Wait to settle DebugFlush(); sleepQuickWake( WDTO_120MS ); DebugF(".3.");DebugFlush(); // Getting data ok ? if (!_tsl.getData(data0,data1)) { DebugF("Error="); Debug(_tsl.getError()); return 0; } DebugF(".4.");DebugFlush(); double lux; // Resulting lux value boolean good; // True if neither sensor is saturated // Perform lux calculation: if (!_tsl.getLux(0,ms,data0,data1,lux)) { DebugF("getLux BAD!"); DebugF(" data0: "); Debug(data0); DebugF(" data1: "); Debug(data1); return 0; } else { // Convert to integer value, keep one digit _lux = (int16_t) lux * 10; // Print out the results: //DebugF(" lux: "); //Debugln(lux); } DebugF(".5.");DebugFlush(); // Set it to power down _tsl.setPowerDown(); // release I2C bus //Wire.endTransmission(true); //I2c.end(); DebuglnF("OK!"); DebugFlush(); return _lux; } -
merci pour l'exclu c'est coool!
j'ai bien vu ton astuce (registres et pinmode), du coup jviens d'essayer vite fait mais ça ne m'a pas amélioré mon souci. mais c'est bizarre, pour debug, j'ai ajouté le i2cscan après le wakeup mosfet et il me trouve bien l'adresse du sensor. mais la lecture des lux me donne 0. je reboot et tout rentre dans l'ordre jsqu'au sleep. jregarde la datasheet du bh et jfais un ptit clean dans mon code pour voir si jfais pas une betise. je te redis ça.
bien vu sinon l'astuce! c'est du fin du fin tout ça! -
J'imagine que tu refais bien une init complète de ton sensor au wake up ?
-
oui, pour être sûr je l'ai mis juste avant la lecture.
jclean ça et jte montre si tu veux mais c'est simple pour l'instant. -
peut être une particularité de ton capteur, j'me suis bien fait avoir avec le TH02 aussi
-
oui c'est ce que j'envisage. faut que je test avec un autre capteur aussi. bmp180 par exemple, tu as déjà essayé en ulpnode?
-
Heu non, je crois que j'en ai un mais jamais testé !!! bonne idée dès que je m'y remets
tu as pris quelle librairie, il doit en avoir 15 tonnes comme d'hab ? -
j'utilise celle que Mysensors utilise de base dans leur sketch (Adafruit_BMP085 compatible avec le 180). en checkant jviens de voir qu'ils en ont une autre faite par sparkfun mais j'ai pas test.
https://github.com/mysensors/Arduino/tree/master/libraries -
Ah perso jamais de mauvaises surprises avec les lib de Sparkfun, et c'est assez rare pour le souligner
-
c'est vrai qu'ils sont pas mal chez sparkfun, ça fait un bout de temps qu'ils sont présents en plus.
sinon, après un ptit clean , j'arrive à lire mon sensor après power up mosfet. ouf enfin! bon maintenant jvais pouvoir checker les consos. voir si rien n'as bougé!
en tout cas merci, car je pense que c'est ton astuce plus le clean qui m'ont dbloqué.en fouinant pour trouver mon souci, je suis tombé sur cette routine pour clean le i2c. je m'en sers pas spécialement mais peut être que ça pourrait te servir un jour http://www.forward.com.au/pfod/ArduinoProgramming/I2C_ClearBus/index.html
-
au fait je t'ai pas demandé, pour ton capteur de temp/hum tu va prendre quoi comme ref? pour ma part je viens de me commander qq Si7021 sur ali pour voir. en espérant qu'ils soient bien, quasi le mm prix que les dht22, y a pas photo. c'est celui que mysensors mettent sur leur sensebender...wait&see
-
Arrfffff t'aurais du me demander, j'ai ai fait 5 grove SI7021 qui trainent au fond d'une boite
Combien et quelle réf chez ALI ? juste curieux car les prix ont doublés en qq mois pour ces trucs
-
N'y vois pas une attaque personnelle, mais perso je ne comprends cet engouement pour le NRF24L01, c'est quand même super limité (et je pèse mes mots) en portée à coté du RFM69
-
ah ben zut c'est pas grave quoique faut voir tu en vendrais un? tu en penses quoi de ces capteurs? tu les as test avec ton ulp? 2.90€ fdpi sur ali.
-
Non, non, t'inquietes, je suis completement d'accord avec toi pour le nrf vs rfm. le nrf c'est du low cost 2.4ghz bourré de fake. et petite portée comparé au rfm qui en plus embarque des fonctions interessantes.
Le truc j'ai l'impression c'est que pour beaucoup le diy ça veut dire lowcost avec pleins de fils (quelle horreur, lol). pour ma part je suis pas à 2-3 euros près si c'est plus pérein et performant. et j'aime pas la filasse dans tous les sens donc je préfère partir from scratch si c'est avantageux.
pour l'instant j'ai pas trop eu le temps de tester comme je veux ce rfm. la lib mysensors n'est compatible avec que depuis peu. et c'est la branche de dev. ça me dérange pas trop encore, mais à vrai dire vu que ça fait pas longtemps que je me lance dans la domo, j'ai pas grand chose en prod. jsuis dans mes design et liste des besoins. mais c'est sûr que pour moi ce sera rfm. c'est vrai que beaucoup sont en nrf et jpense on peut toujours leur dire rfm ils diront que c'est trop cher. en plus pas d bol s'ils en ont plein en prod!
Oulà, j'espère qu'il va pas y avoir de fervents défenseurs du nrf et fil volant sinon jvais me faire lincher, lol!!!
