ouf!

Code:

NOTE: If, in spite of following the steps as specified above, you aren't able to receive the message on the target handset, then it might be that you need to set the SMS Message Center number. Send the command AT+CSCA="+919032055002" and press the Enter Key. Send this command in between the AT+CMGF and AT+CMGS commands

Peut-être que le AT&F était trop violent... 
et que le numéro du centre de message a été "déprogrammé"?

de mémoire, il ne faut pas faire un Ctrl+Z pour l'envoyer ce fameux message?

un délai de 2 secondes semble nécessaire selon Mr Hayes
Sinon, il y a aussi AT&F, reset usine

oui 

Elle est pas bien la vidéo?

Si elle est sympa, pourquoi?
Ca va donner des idées à mes enfants ce genre de chose 

 

Elle est pas bien la vidéo?

A coeur vaillant, rien n'est impossible!
Tu comptes faire On/Off avec tes leds, ou bien faire varier leur intensité?
Cela conditionnera le choix des CI...
Sinon pour 4000 ou 5000 leds, je crois que tu peux d'ors et déjà t'orienter vers
un Mega voire même plus probablement un Due...

Perso j'opterais plutôt pour une webcam + openCV pour faire la détection de mouvement.
Mais je ne pense pas qu'OpenCV tourne sur Arduino, vaudrait mieux un raspberry Pi ou BeagleBoard pour ça.

Je plussoie absolument!
et rien ne t’empêcherait d'utiliser un arduino pour contrôler deux servo en pwm (le Raspberry Pi en a aussi
des sorties PWM d'ailleurs). En gros fais des recherches Pan-Tilt ou Sentry gun
http://raspberrypirobot.blogspot.fr/2012/09/pan-and-tilt.html


Jean Francois a fait pas mal de tuto sur le sujet ;-)

Dans l'absolu tu n'as pas réellement besoin d'un optocoupleur, car tu vas utiliser un relai...
L' Arduino va commander le relais directement, et puis c'est tout...
L'optocoupleur permettrait juste de protéger ton arduino... 

Entre 4Ko/s et 90Ko/s, il y a une grosse marge de progression... non?
Je viens de relire ton post, et télécharger ton exemple (je ne peux tester ce soir...).
Je veux bien essayer la lib TinyWebServer, mais sur le coup faudra bien m'expliquer
comment cette dernière balance des données à plus de 50Ko/s, alors que mon maigre
sketch, simple au possible n'en balance que 4 au max...

M'enfin pourquoi pas :-)

Sinon, je me suis lancé dans ma mémoire tournante ou buffer circulaire comme dit Skywodd ;-)

Code:

const unsigned int NB_MESURE_RAM = 100;

typedef struct {
  long timeStamp;
  unsigned int voie1;
  unsigned int voie2;
  unsigned int voie3;
  unsigned int voie4;
  unsigned int voie5;
  unsigned int voie6;
  unsigned int voie7;
  unsigned int voie8;
} 
uneMesure;

uneMesure listeMesure[NB_MESURE_RAM];

void memoireTournante(){
  for(int i = (NB_MESURE_RAM - 1) ; i == 1 ; i--){
    // de la fin du tableau au début, moins un element zappé pour la bonne cause
    // on copie l'element n vers n+1, faut partir de la fin
    listeMesure[i+1].timeStamp = listeMesure[i].timeStamp;
    listeMesure[i+1].voie1 = listeMesure[i].voie1;
    listeMesure[i+1].voie2 = listeMesure[i].voie2;
    listeMesure[i+1].voie3 = listeMesure[i].voie3;
    listeMesure[i+1].voie4 = listeMesure[i].voie4;
    listeMesure[i+1].voie5 = listeMesure[i].voie5;
    listeMesure[i+1].voie6 = listeMesure[i].voie6;
    listeMesure[i+1].voie7 = listeMesure[i].voie7;
    listeMesure[i+1].voie8 = listeMesure[i].voie8;
  }
}

Je regarde aussi du coté de EDB :
http://playground.arduino.cc//Code/ExtendedDatabaseLibrary
cela donne des idées!

Sur ce bonne soirée!

ben la pin SQW/OU fournit un signal à 1Hz, donc une fois par seconde...
donc une led en série avec une résistance sur cette même pin, et tu
devrais voir clignoter la led à la fréquence d'une fois par seconde...

Issu d'un post de Skywodd:

- Les objets Client, Server et UDP de la librairie Ethernet ont été renommés en EthernetClient, EthernetServer et EthernetUDP afin d’éviter tout conflit lors de l’utilisation de plusieurs librairies orientées réseaux,

http://skyduino.wordpress.com/2012/02/09/arduino-1-0-et-uno-rev3-les-changements-qui-changent-tout/

En gros lors de la dernière mise à jour, les objets Ethernet ont été renommés, donc change juste les
imports, non?

Merci Skywodd!

Je fais déjà (un peu) ce travail de concaténation de char avant l'envoi au client Ethernet.
En gros je fais un readLine avant de l'envoyer... et oui cela a améliorer très notablement
le débit (faudrait que je quantifie tout de même).
J'utilise un String pour ce faire (pas taper! pas taper :-))
Bon du coup, j'ai essayé de poursuivre un peu en dimensionnant à la louche ce String:

Code:

         
          File dataFile = SD.open("test125.txt", FILE_READ);
          char cc;
          String buffer;
          buffer.reserve(200);
          if (dataFile) {
            while (dataFile.available()) {
              cc = dataFile.read();
              if(cc == 13){  // CR
                //dataFile.available();
                dataFile.read();  // LF
                buffer += "<BR>";
                client.println(buffer);
                buffer = "";
              }
              else{
                buffer += cc;               
              }             
            }
            dataFile.close();           
            client.println("</html>");
          }
          else {
            client.println(F("Fichier NOK"));
          }

Les résultats sont peu concluants... 3.4 Ko/s


Viens ma nouvelle question:
Comment créer une mémoire tournante ?
Je vois bien un tableau de String assez grand pour contenir x jours de données qui,
à chaque nouvelle mesure, pousserait la donnée précédente à l'indice n +1
Je m'y attelle 

Je vais poser ma question autrement:
Est-ce qu'un débit de 3.75 Ko/s vous parait un débit plausible en réseau local?

Je me pose une autre question du coup:
L' ethernet et la carte SD partagant le bus SPI, et dans la logique de tous les codes
trouvés ici et là, il y a un ping pong permanent entre
     lire un char du fichier sur la SD
     basculer sur le chip ethernet
     écrire dans le buffer du chip ethernet (enfin j'imagine)
     basculer sur la SD
     lire un autre char du fichier sur la SD
     etc...
Cela me parait diablement inefficace, non?