Bonjour les gens, j'ai pas mal de choses a raconter alors je vais tâcher d'être succinct.
Mon objectif final : Un systeme complet de Laser Game
(03/08/2014)
Objectifs :
Probleme actuel : Utilisant un module 2.4GHz (Frequence assez utilisé), existe-t-il des risques d'interferences avec d'autres appareil ?
Comment les minimiser ?
Tout betement, quelquechose comme ca pourrais marcher :
void loop(){
if (analogRead(A0) >= 170) {
Serial.println(time);
time = 0;
}
time++;
delay(1);
}
Mais ca pose des soucis de precision, le reglage est plutot coton :
Je peux avoir des valeurs plutot constantes mais pour certains reglages ca deviens assez aléatoire 
Merci pour ta reponse, c'est plus propre, en effet 
J'en suis donc a ce code :
int sensorPin = A0;
int threshold = 200;
int sensorValue = 0;
int time = 0;
int last = 0;
void setup() {
Serial.begin(9600);
}
void loop() {
time = micros();
sensorValue = analogRead(sensorPin);
if (sensorValue >= threshold) {
Serial.println(time - last);
last = time;
}
}
Si je fais clignoter une LED toutes les secondes, j'obtiens des valeurs autours de 18000.
Je devrais pas avoir 1 000 000 ?
Lorsque je laisse le capteur a la lumiere ambiente, j'ai exactement 6240. (Meme chose a la lumiere de mon laser par exemple)
Cela correspond a quoi ? au rafraichissement de mon capteur ?
PS : Il n'y a pas de balise "spoiler" sur ce forum ?
Si la LED clignote une fois par seconde, ça signifie qu'elle est allumée pendant une fraction de cette seconde, puis éteinte pendant le reste de la seconde.
Si sensorValue est plus grand que threshold pendant tout le temps que la LED est allumée, ton script devrait à mon avis afficher une suite de temps très courts pendant que la LED est allumée, puis un temps beaucoup plus long pendant que la LED est éteinte.
C'est quoi comme capteur? Une photorésistance?
Dans ton code, time et last devraient être des unsigned long plutôt que des int.
Ah bah oui, s'il compte les microsecondes, il a vite fait le tour d'un int... 
Merci.
J'utilise une photoresistance.
Du coups, pour ma LED, j'ai à peu près ces valeurs :
Quand elle clignote toutes les 0.1s , autours de 100 200.
Quand elle clignote toutes les 1s, autours de 1 002 200 .
Quand elle clignote toutes les 10s, autours de 10 022 000.
L'imprécision (si je puis dire) a donc l'air proportionnelle. Elle est du a quoi ?
De toute maniere, il me suffira de couper les 3 derniers chiffre pour tomber sur la bonne valeur envoyé. (Et donc le bon joueur)
Et le 6240 en lumiere continue c'est la vitesse d'execution d'une seule loop enfaite, non ?
Pourtant desfois j'ai des valeurs biens plus petites.
Au passage, quelqu'un sait comment les systeme "pro" fonctionnent ?
EDIT : Apperemment, certains fonctionne comme ce que je compte faire, mais la plupart utilise -en plus des lasers- des LEDs et capteurs IR.
Apparemment, la fonction pulseIn pourrait etre une bonne sloution pour mesurer la frequence... si mon etrée n'était pas une photoresistance mais un bouton 
(Même chose pour la librairie FreqCounter)
La photorésistance est un capteur analogique, mais rien ne nous empêche de la brancher à une entrée numérique pour qu'elle présente deux états logiques: HIGH quand elle est éclairée, LOW quand elle ne l'est pas (ou l'inverse, ça dépend comment on la branche).
Mais dans ce cas, impossible de regler le seuil pour lequel le capteur donne HIGH, si ?
(je viens de comprendre que tu es l'auteur de ce blog, qui est depuis peu une de mes references 
)
Tu devrais pouvoir ajuster la frontière entre LOW et HIGH en ajustant la valeur de la résistance de gauche dans le circuit illustré ci-dessous (tu augmente cette résistance pour diminuer le voltage seuil).
(On dirait que mon blog commence à être connu!)
J'ai fais pas mal de test avec cette technique du digitalRead, je galère vraiment avec le seuil je trouve ca pas pratique du tout, je pense repasser à l'analogRead. Je vous tiens au courant
En attendant, quelqu'un a des suggestion sur ça ou autre chose que j'aurais évoqué ?
Utiliser un analogRead() n'a pas de sens ici : d'une part ça va compliquer la prog, et une mesure analogique n'a aucun intérêt.
PulsIn() est également à proscrire, car blocante. Donc si ton joueur capter un signal parasite (néon ou autre) alors il ne pourra plus tirer ...
En gros je reprend mon ancien code (corrigé) mais avec une lecture en digital, ça serai la meilleure methode ?
Ok, je test ça ce soir, merci
Au fait, en digitalRead, on obtient HIGH quand le signal est à l'equivalant de la moitié de la valeur max de la valeur analog, non ? (je testerais ça ce soir aussi, tiens)
EDIT : C'est bizarre, le seuil à l'air d'être 460 en analogique... Enfin, à la limite on s'en fou enfaite.
Bonjour bonjour, ça fait longtemps, mon projet était en stand by.
De retour, j'ai laissé tombé l'idée du pulse laser, j'utilise maintenant une led IR, le capteur qui va bien et la lib IRremote.
=> Tout marche.
Maintenant, je voudrais que les clients (les guns/les joueurs) puissent communiquer avec le serveur :
Rien de bien compliqué, un module nRF24L01 et la lib Mirf (Ca, ça marche).
Mais chaque client doit avoir une adresse qui lui ai propre et je refuse de toutes les rentrer à la main dans chacun des guns. Alors comment faire ?
Hidjy:
Maintenant, je voudrais que les clients (les guns/les joueurs) puissent communiquer avec le serveur :
Rien de bien compliqué, un module nRF24L01 et la lib Mirf (Ca, ça marche).
Mais chaque client doit avoir une adresse qui lui ai propre et je refuse de toutes les rentrer à la main dans chacun des guns. Alors comment faire ?
bonjour
par "je refuse..." je suppose que tu veux dire , je ne veux pas injecter un code different (contenant l'adresse unique) dans chaque
"gun" ?
parce que d'une maniere ou d'une autre il faut bien affecter une adresse unique
Combien de "gun" au max ?
il y plusieurs solutions +/- simple et sans etre exhaustif
Je veux effectivement dire ne pas avoir à injecter un code different dans chaque gun.
J'aimerais dans l'absolu ne pas être limiter dans le nombre de joueur (même si je vois difficilement des parties à plus d'une vingtaine de joueur).
L'idée du codage hard me parraît assez restrictive.
J'aime assez celle du composant à ID unique, en connais-tu ?
Un syteme d'attribution d'id unique au niveau du logiciel n'est pas possible ?
Hidjy:
Je veux effectivement dire ne pas avoir à injecter un code different dans chaque gun.J'aimerais dans l'absolu ne pas être limiter dans le nombre de joueur (même si je vois difficilement des parties à plus d'une vingtaine de joueur).
L'idée du codage hard me parraît assez restrictive.
J'aime assez celle du composant à ID unique, en connais-tu ?
Un syteme d'attribution d'id unique au niveau du logiciel n'est pas possible ?
ok
donc en partant sur de la ^2 tu peux affecter 32 gun avec 5 bits
Tous le compos 1wire emportent par construction un ID unique
le DS2401 est le compo ideal pour ça (il ne fait que ça , fournir un ID unique)
http://pdfserv.maximintegrated.com/en/ds/DS2401.pdf
mais tu pourrais aussi bien utiliser le tres repandu DS18B20 pour juste utiliser cette fonctionnalité.
Faire attribuer par random un ID unique par soft est possible , mais cela necessite une etape de verification d'eventuels doublons, maintenant developper une petite etape "config/init" et injecter un ID en EEprom par serial ce n'est pas non plus tres compliqué, il faut juste disposer de la connectique mini sur "les guns"
Pour capter l'IR, j'utilise le TSOP4856.
Il n'a pas son ID unique lui aussi ?
Je peux l'utiliser lui, ou même un transistor qui traine dans ce cas, pourquoi préférer le DS2401 ?
Hidjy:
Pour capter l'IR, j'utilise le TSOP4856.
Il n'a pas son ID unique lui aussi ?
Je peux l'utiliser lui, ou même un transistor qui traine dans ce cas, pourquoi préférer le DS2401 ?
là je crois que tu confond topologie de boitier et fonctionnalité d'un composant 
si un DS2401 est dispo en format TO92 , ce n'est pas un transistor en "boitier" TO92
et ton capteur n'a pas lui non plus une adresse unique