question à propos du bod



  • Bonjour Charles,

    comment vas-tu? Actuellement je suis en train de debugger mon pcb et je fais des tests de conso avec mon ucurrent gold homemade. Je compare un peu les sketchs de Gammon pour voir les options que j'ai. Et j'ai un petit souci concernant son sketch J. Peut être pourras-tu m'aiguiller???

    • j'ai modifié un arduino mini pro (led et régul retirés)
    • j'ai modifié optiboot pour être en InternalRc 8Mhz, et BOD=1.8V. J'upload par usbasp+avrdudess pour l'instant.
    • je me suis fait un petit sketch et ajouté la fonction de sleep du sketch J. Ca fonctionne bien. Sur une pin cela se réveille bien, puis retourne to sleep. J'obtiens 140nA (avec les deux lignes désactivant le bod) et environ 18uA si j'enleve ces deux lignes. Logique je pense.

    Mon souci : lorsque j'utilise les deux lignes pour le bod, impossible de réuploader le sketch par ftdi. Je suis obligé de remettre le bootloader.
    Si j'enlève ces deux lignes, je n'ai plus le problème mais consomme un peu plus en veille (18ua).
    Les deux lignes sont :
    MCUCR = bit (BODS) | bit (BODSE);
    MCUCR = bit (BODS);

    Mon idée est que l'appel de ces deux lignes me modifie quelque chose en rapport avec l'irq RST qui fait que je ne peux plus utiliser le bootloader (comme si l'irq n'était plus détectée) Le plus bizarre c'est que cela fait pareil depuis le bouton de l'arduino (il devrait être sensé se réinitialiser, non?). Faut que je regarde mieux dans la datasheet la section du RST et du MCUCR, mais si tu as déjà expérimenté cela, ou si tu as l'explication cela m'intéresse! J'imagine qu'il faut que je rétablisse certaines fonctions dans le code et que cela doit être une erreur bête.
    Ou alors l'astuce serait de ne pas utiliser ces deux lignes et de jouer sur la fréquence et le voltage (la capa) pour faire baisser la conso de 18uA pendant le sleep? tu désactives le bod pendant la veille?j'ai hate de voir ta lib!

    en attendant jvais continuer de fouiner (jvais aller checker la lib Lowpowerlab pour voir mais j'avais de moins bon résultat avec il me semble), et peut être que je vais trouver mon erreur tout seul!

    Note: mon post est en français mais peut être préfères tu en anglais pour la suite?
    @+



  • problème résolu en repartant du bootloader de base crystal ext. donc j'avais dû faire une bourde. désolé.
    c'est sympa le ucurrent quand même, c'est vrai que ce petit 328p c'est un vrai ptit chameau quand même!
    @+ bonne continuation pour tes projets


  • Staff

    Salut scaltz,
    çà va, j'suis un peu sur tous les fronts d'ou mon silence. Mais je viens de voir ton article. 140nA ???? T'es alimenté comment ? Parce que je ne suis pas tout à fait si bas de mémoire



  • salut!
    dsl j'ai pas précisé mais je mesure sur pile. J'ai voulu connecter l'ucurrent sur ma vieille alim stabilisée mais elle doit pas être bien filtrée. du coup suis sur pile. Le ucurrent je me le suis fait (gold version), j'ai vérifié le calibrage avec des res et je suis à peu près bon (j'avais des res 5% sous la main). 140nA c'était juste l'arduino, sans rien d'autre. et sans booster d'activé (sur ma board je peux désactiver plusieurs fonctions, je tests petit à petit certaines parties). J'ai pas commencé à tester les booster.

    Pour la board que j'ai fait, mon schema est sur mon git (tu verras je suis dans tes followers). Pour l'instant avec dht22, et bh1750, mosfet coupé je suis entre 200 et 300nA en fait. J'ai eu des soucis avec les mosfet qui sont sur mon schema, l'arduino rebootait en boucle. j'ai changé par des bs250 to92 (dans mon stock) pour voir et plus de problèmes. donc faut que je revoie mes mosfets. T'as une explication pour ça??? (vu que j'ai pas touché au bootloader encore, je pense que c'est peut être du à la config des pins au startup).

    Sinon j'ai un petit souci depuis hier soir, jvais bien trouver, mais à tout hasard si tu as expérimenté...J'arrive pas à récupérer le bus i2c après le retour de veille et power up du mosfet. Ca doit être une config de registre. En fait avant d'aller en veille, au début du prog, je fait une lecture BH1750. Ca se passe ok. Je coupe mosfet, pin en output=0, et sleep pin change interrupt. Mais quand je le réveille, il me lit 0! Si je press le reset button, il me refait ma lecture du début. ce qui me laisse penser que je fais pas bien le réveil (et même souci avec le dht22 mais ça c'est une autre histoire)...par contre aucun souci avec ma radio spi que je reinit. Je pensais que le Wire.begin (utilisé par la lib BH1750) refaisait le config. Comment as-tu fait pour ton sensor i2c sur ta board???tu lui coupes bien le mosfet?

    Sinon, j'ai pas commenté ton dernier article, mais c'est top ta GW. Y a de l'idée. et puis ta board pour les sondes pt aussi. merci pour tout ce que tu fais, y a pleins de choses qui me seront utiles!


  • Staff

    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 çà :
    Capture.JPG

    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
    Capture.JPG

    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.


  • Staff

    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.


  • Staff

    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();
    }
    
    

  • Staff

    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!


  • Staff

    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.


  • Staff

    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?


  • Staff

    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


  • Staff

    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


Log in to reply
 

Looks like your connection to hallard.me's community was lost, please wait while we try to reconnect.