Véhicule RC
- Thread starter dje8269
- Start date
Bonjour,
Je viens juste d'effectuer ces tests pendant mon café ; mais cette nuit , j'ai eu une idée , je pense que le "bug" survient que le Rx est bloqué par le RFin ? je sais pas il doit bloqué son accés au scratchpad un truc du genre . je vais faire un test tout de suite pour vérifier cela .
Oui ce sont bien toutes les valeurs qui sont a 255, du moins celle de b0 à b7 . je l'ai testé avec un debug a la place d'un sertxd . J'ai également enlevé tout ce qui est inutile dans le programme .
Je viens juste d'effectuer ces tests pendant mon café ; mais cette nuit , j'ai eu une idée , je pense que le "bug" survient que le Rx est bloqué par le RFin ? je sais pas il doit bloqué son accés au scratchpad un truc du genre . je vais faire un test tout de suite pour vérifier cela .
Le loop est juste en dessous , en faite je compte dans la boucle !
En exagérant un peu j'ai mis une pause de 10 ms après le put dans le programme réception . ainsi avant le RFin j'attends 10 ms pour me laisser le temps d'aller me lire mes données . et ben ça fonctionne bien .
Déduction , la commande bloquante RFin , empêche la lecture correcte de son scratchpad ou quelques chose du genre. Après réflexion je pense que le mode multi-maitre avait un peu le même genre de problématique .
Je vais donc tout reprendre pour essayer d'utiliser un serout ou un hserout ? il faut que je transforme le hard , car je n'avais pas prévu ça ; Un conseil ! hserout ou serout ?
Déduction , la commande bloquante RFin , empêche la lecture correcte de son scratchpad ou quelques chose du genre. Après réflexion je pense que le mode multi-maitre avait un peu le même genre de problématique .
Je vais donc tout reprendre pour essayer d'utiliser un serout ou un hserout ? il faut que je transforme le hard , car je n'avais pas prévu ça ; Un conseil ! hserout ou serout ?
Last edited:
PieM
Senior Member
Une commande bloquante est bloquante ! si le µC attends une info il ne peut gérer en même temps une liaison I2C.
Si le RFIN n'arrive pas , quel intérêt d'aller lire des infos qui ne sont pas actualisées ?
Tu n'avais pas une ligne busy en liaison directe qui te synchronisait ?
Utilise hserout et hserin à haut débit.
Oui , je pensais qu'on pouvait quand même avoir accès a sa mémoire strachpad . au moins la lire ! et ben non . Oui je vais donc utiliser hserout , car ca va être la même chose avec hserin je suppose? Je ne suis vraiment pas calé sur differents moyen s de transmissions et leur focntionnement ;
Donc je prefre envoyer les données vers le 20X2 apres un RFin, plutot que d'aller les récuperer apres le RFin car il se peu que ca bloque .
Merci PieM
*
Je n'avais pas lus ton édition . Qu'est ce qu'une ligne "busy" ( occupé en anglais) . ?
Voici ma plaquette d'essai :
Je vais bidouiller ma plaquette d'essai pour relié le 28X2 et le 20X2 avec la commande serout . car du coup, si je passe plus par l'i2c, plus besoin d'être en esclave , donc plus besoin de 28X2, un 14M2 suffiras amplement pour recevoir le RFin et transmettre avec un serout ? qu'en pense tu ?
Pour faire une liaison série , juste un fil suffit ? pas besoin de résistance entre ?
Elle me sert a detecter quand une info est passée , c'etait mon flag de MAJ dans l'ancienne version . si qui me sert aussi a compter quand je n'ai plus de com . dessus une led est branchée , ainsi visuellement elle me sert a voir quand mon Récepteur est bloqué ou non .
Oui oui , mais du coup, j'avais fais ma plaquette avec un 28X2, pensant utilisé l'i2c . Étant donné que le multi-maitre est bancale , je ne vais plus l'utiliser ( l'i2c), donc le 28X2 n'as plus lieu d'etre . Je ne peux pas refaire ma plaquette d'essai, mais dans le futur je passerais donc avec un 14M2 ( qui ne prends pas le Hserout je crois), donc autant ne pas le faire avec la plaquette d'essai ?
D'après toi qu'elle serait les inconvénients d'utiliser un serout plutôt qu'un hserout ; si tu me dis qu'il est préférable d'utiliser hserout , alors je garderais mon 28X2 . Tant qu'a faire chauffer le fer a souder pour modifier ma plaquette , je vais relier Hserout et une autre patte pour faire un serout au cas ou !
Bon cette fois , je craque . j'y arrive pas, j'en peux plus, je pense que je fais un burnout de l'i2c et du hserin.
Si une âme charitable à une idée de comment faire , je suis prêt à tout essayer .
Voici le schéma actuel de ma plaque d'essai
Voici le programme du 28X2
Voici le programme "simplifié" du 20X2
Explication .
le récepteur reçoit des infos ( il n'y a aucun problème de ce côté ci) .
le but du 28X2 : recevoir les infos rien de compliquer et pas de problème de ce coté la non plus. ensuite deux solutions :
- Les mettre à disposition pour que le 20X2 viennent les récupérer . Je pense que ce n'est pas le meilleur moyen car la récupération doit etre tres rapide avant que le Rfin ne re-bloque par le RFin .
- Les envoyées au 20x2 me parait le mieux , mais je peux me tromper ! .
Je précise que j'aimerais avoir un temps MAJ raisonnable 40ms me parait honorable . en sachant que le Rfin en prends 37ms . Il reste 3ms pour envoyer ou recevoir c'est large !
Le but du 20X2 .
Il attend que flagRx passe a 1 , cela signifie que les données sont a jour ! en attendant il compte , si le compteur déborde( trop long) , c'est que la com à un problème, Donc on arrête le VHL.
Une fois qu'il reçoit ce flag ( qui en fait met une broche a 1 en allumant une led au passage) , il faut soit aller lire les infos sur le 28X2 ( dur dur car il est souvent bloquer, faut être ultra rapide), soit il les récupères dans son scratchpad .
ensuite on traite mais ca , ce seras pour après .
avec le programme fournis au dessus , les valeurs de b3 et b5 reste inexorablement a zéro , alors que la réception est bonne !!!
Si vous avez d'autres infos, je peux tout donné , je dispo d'un analyseur logique au besoin ; Je peux aussi soudé des straps et faire quelques modifs minime sur la plaquette , car je suis a la maison .
Je n'ai pas réussis a mettre en œuvre les solutions de PieM !!
Si une âme charitable à une idée de comment faire , je suis prêt à tout essayer .
Voici le schéma actuel de ma plaque d'essai
Voici le programme du 28X2
Code:
#PICAXE 28X2
'#################################################################################
'########################## Programme 28X2 RX #############################
'#################################################################################
'######################### Configuration des I/O ##########################
'b0 a b7 pour les communications
'######################## Initialisation ########################
setfreq m8
hsersetup b115200_8,%01
hi2csetup i2cslave, %10100000 ' Met le 28X2 en Esclave
'#################################################################################
'########################## Programme Principal ############################
'#################################################################################
do
low B.2
RFin C.5,b0,b1,b2,b3,b4,b5,b6,b7 ' Enregistre les donnees du RX
High B.2
hserout 0,(b0,b1,b2,b3,b4,b5,b6,b7)
loop
Code:
#PICAXE 20X2
'#################################################################################
'########################## Programme 20X2 Slave #############################
'#################################################################################
'######################### Configuration des I/O #########################
'b0 a b7 pour les communications
Symbol flag_Rx = PinB.0
Symbol Tx_video = PinC.7
Symbol V_moteur = b3
Symbol V_dir = b5
Symbol Compt_err = b9
Symbol mem_Vitesse = b10
Symbol Compt_Vitesse = b11
Symbol mem_Diff = b12
Symbol Compt_Diff = b13
Symbol flag_Diff = bit4
Symbol flag_Vitesse = bit5
Symbol SD_20 = %11000010
Symbol Rx = %10100000
'########################### Initialisation ############################
setfreq m8
hi2csetup i2cmaster, %11000010, i2cfast_8, i2cbyte ' On passe en maitre avec le SD20 en esclave
read 0,mem_Vitesse,mem_Diff ' On lit dans l'EEprom, les valeur de vitesse et diff enregistrees
'#################################################################################
'########################## Programme Principal ############################
'#################################################################################
do
low C.1 ' Led Orange
do while flag_Rx = 0 ' on reboucle tant qu'on a rien recu
Compt_err = Compt_err + 1 max 255 ' incremente le compteur d'erreur
if Compt_err >= 254 then
gosub Escape ' au bout d'un certain temps on va arreter
exit ' Apres le retour d'un arret on sort de la boucle
end if
loop
High C.1
Compt_err = 0 ' Raz du compteur
pause 3 ' Pour laisser le temps d'ecrire dans le scratchpad duRX
get 0,b0,b1,b2,b3,b4,b5,b6,b7
loop
'#################################################################################
'########################## Programme Secondaire ###########################
'#################################################################################
Escape:
high C.0 ' led Rouge
do loop while flag_Rx = 0 ' On reste la tant qu'on recoit rien
Low C.0
returnle récepteur reçoit des infos ( il n'y a aucun problème de ce côté ci) .
le but du 28X2 : recevoir les infos rien de compliquer et pas de problème de ce coté la non plus. ensuite deux solutions :
- Les mettre à disposition pour que le 20X2 viennent les récupérer . Je pense que ce n'est pas le meilleur moyen car la récupération doit etre tres rapide avant que le Rfin ne re-bloque par le RFin .
- Les envoyées au 20x2 me parait le mieux , mais je peux me tromper ! .
Je précise que j'aimerais avoir un temps MAJ raisonnable 40ms me parait honorable . en sachant que le Rfin en prends 37ms . Il reste 3ms pour envoyer ou recevoir c'est large !
Le but du 20X2 .
Il attend que flagRx passe a 1 , cela signifie que les données sont a jour ! en attendant il compte , si le compteur déborde( trop long) , c'est que la com à un problème, Donc on arrête le VHL.
Une fois qu'il reçoit ce flag ( qui en fait met une broche a 1 en allumant une led au passage) , il faut soit aller lire les infos sur le 28X2 ( dur dur car il est souvent bloquer, faut être ultra rapide), soit il les récupères dans son scratchpad .
ensuite on traite mais ca , ce seras pour après .
avec le programme fournis au dessus , les valeurs de b3 et b5 reste inexorablement a zéro , alors que la réception est bonne !!!
Si vous avez d'autres infos, je peux tout donné , je dispo d'un analyseur logique au besoin ; Je peux aussi soudé des straps et faire quelques modifs minime sur la plaquette , car je suis a la maison .
Je n'ai pas réussis a mettre en œuvre les solutions de PieM !!
J'ai oublié de l'enlever, la laision i2C n'est plus d'actualité, comme je n'y suis pas arrivé
Car du temps de la fabrication de la plaquette d'essai le communication prévue était l'i2c, mais je n'ai pas réussis a faire une com fiable ( drone dans le mur sans explication , le moteur est reste bloqué a fond), je ne peux pertinemment pas présenter ca!
Je savais pas qu'il en fallait une . D'après ce que j'ai compris , avec hserout , le 28X2 ecrit directement dans le scratchpad du 20X2 !
a 9600 le hserout dur 8ms , beaucoup trop long , a 115200 cela dur 1.7ms . c'est du grosso modo a l'analyseur, car je calcule entre chaque front montant et descendant de la led , donc c'est certainement un peu plus court en vrai. l'espace entre deux émission ( par la télécommande) est de un peu moins de 41ms . je dois donc être plus rapide a la réception . bien sur je pourrais "ralentir" mon émission mais ce n'est vraiment pas le but , car je perdrais directement en réactivité . C'est pourquoi je ne dois pas dépassé les 40ms dans le programme reception
je ne suis pas a l'aise avec cette fonction . ( avec pas beaucoup d'ailleurs) ; faut-il configurer le hserin sur le 20X2 même si je l'utilise pas ?
Last edited:
PieM
Senior Member
Le hserflag fonctionne comme le Hi2cflag. Il est mis à 1 dès réception de données. C'est à l'utilisateur de le remettre à 0.
Par contre un truc pas clair et pas testé par moi:
le pointeur hserptr est incrémenté à chaque byte reçu. Il semblerait que ce pointeur ne soit par contre pas remis à 0. ce qui veut dire que les infos arrivent et s'accumulent dans le scratchpad.
auquel cas, il faudrait mettre hserptr = 0 après chaque lecture par get.
C'est à vérifier en faisant un txd de la valeur de hserptr. tu verras s'il s'incrémente en permanence.
Bonjour,
Mes test d'hier sont mitigés ! . Mais ton post de ce matin apporte peut etre un début de réponse .
Pour le moment j'arrive bien a récupérer mes infos au rythme de la réception : impeccable . je me sert du hserinflag comme avec l'i2c, ce qui m'évite de déclencher la sortie de la boucle d'attente avec l'allumage de la LED , donc pas bsoin de pause pour ralentir quoi que ce soit . gros point positif .
Par contre les valeurs sont erronées, je cherche encore la cause , car il y a une chose bizarre, j'ai 16 fois de suite la même valeur et le comportement est saccadé quand je test en réel ! ce qui confirme les 16 valeurs systématiques vu par un sertxd ! .
JE fais ton test tout de suite
PS :
j'ai reduit la vitesse a 57600 sa fonctionne bien . si je descend encore ca fonctionne moins bien , car des fois on loupe une MAJ de la télécommande ; ( on arrive apres les 40ms).
Re-PS : peut on voir les valeurs avec l'analyseur logique en hserout ? comme avec l'i2c?
Mes test d'hier sont mitigés ! . Mais ton post de ce matin apporte peut etre un début de réponse .
Pour le moment j'arrive bien a récupérer mes infos au rythme de la réception : impeccable . je me sert du hserinflag comme avec l'i2c, ce qui m'évite de déclencher la sortie de la boucle d'attente avec l'allumage de la LED , donc pas bsoin de pause pour ralentir quoi que ce soit . gros point positif .
Par contre les valeurs sont erronées, je cherche encore la cause , car il y a une chose bizarre, j'ai 16 fois de suite la même valeur et le comportement est saccadé quand je test en réel ! ce qui confirme les 16 valeurs systématiques vu par un sertxd ! .
JE fais ton test tout de suite
PS :
j'ai reduit la vitesse a 57600 sa fonctionne bien . si je descend encore ca fonctionne moins bien , car des fois on loupe une MAJ de la télécommande ; ( on arrive apres les 40ms).
Re-PS : peut on voir les valeurs avec l'analyseur logique en hserout ? comme avec l'i2c?
PieM
Senior Member
la doc dit qu'il est remis à 0 par la commande HSRSETUP, c'est à dire à l'initialisation.
Oui c'est exact , je trouve la traduction pas très clair la dessus ! . Enfin ce n'est que mon avis
En tout cas pour le moment ca a l'air de fonctionner correctement . Tu m'enlève un gros poids comme d'hab ! .
Si ca continue de fonctionner , je garderais donc cette méthode. verrai-tu un quelconque bug qui pourrais arrivé ? est il possible qu'une erreur de transmisison sur le bus puisse arriver si la vitesse est trop rapide par exemple ?
PieM
Senior Member
Comme ta transmission se fait sur la même platine, sans câblage, les risques sont faibles.
peut on etre sur que la communication hserout et i2c cohabite bien ensemble ?
Le VHL a des comportements tout a fait anormaux ! ;
Déjà le troisième envois au servo ne fonctionne plus . de plus des dysfonctionnement grave dans le fonctionnement se font ressentir . par exemple la voiture avant pas du tout , puis un petit peu , je coup les gaz , la led me signifiant que la voiture est arrete s'allume mais la voiture roule encore !!!!.
Bref y'as du bug a mort !!!
Le hserin en tache de fond ne peut il pas mettre le bazar dans l'i2C ?
Les données qui arrivent en tache de fond, sont bien stockés dans le scratchpad ?
le flag de hserin c'est bien hserflag ? pou hserinflag ? il parle des deux dans le manuel ?
Le VHL a des comportements tout a fait anormaux ! ;
Déjà le troisième envois au servo ne fonctionne plus . de plus des dysfonctionnement grave dans le fonctionnement se font ressentir . par exemple la voiture avant pas du tout , puis un petit peu , je coup les gaz , la led me signifiant que la voiture est arrete s'allume mais la voiture roule encore !!!!.
Bref y'as du bug a mort !!!
Le hserin en tache de fond ne peut il pas mettre le bazar dans l'i2C ?
Les données qui arrivent en tache de fond, sont bien stockés dans le scratchpad ?
le flag de hserin c'est bien hserflag ? pou hserinflag ? il parle des deux dans le manuel ?
Non pas tout a fait ! Ta phrase est elle tournée, d'une façon affirmatif ou c'est ce que tu propose ?
Car je pense que ca mérite des test ;
rien ne va plus ! je re-pete un cable!! . dur dur l'ascenseur emotionnel !! un coup j'avance et trois coups je recule .
Allez je recommence tout depuis le début
PS :
Ok car il en question deux fois dans le manuel Fr . Une petite erreur je pense
Savez-vous pourquoi à l'allumage de la plaquette, les servo bougent furtivement ? est ce a cause de l'alimentation ? Car d'aprés la DS du SD20, il sont inactif tant qu'il n'ont pas revus de valeur !( au début de la première page) . En enlevant le sd20, ils sautillent aussi !
Les servos sont branchés indépendamment de l'électronique derrière un regulateur à decoupage réglé sur 6.3V
Les servos sont branchés indépendamment de l'électronique derrière un regulateur à decoupage réglé sur 6.3V
Bonjour à tous,
Je vous sollicite encore une fois concernant la logique de travail.
Je desirerais dans la mesur edu possible , avant de faire mon backup ( protocole de marche arriére avec la memoire) , effectuer une reset avant ! .
et ce que ce petit logigramme serait convenable . je précise que la précision n'est pas du tout indispensable :
- perte de communication
- arrêt de la voiture
- Boucle d'attente si timer > 60 ( avec timer cale sur 1s)
- On met a 1 un flag avec une commande write
- On reset
- Apres le reset , on lit le flag
- si flag = 1 c'est qu'on a déjà arrêté la voiture , donc on va au back up, sinon c'est juste le premier allumage et donc on continue le programme normalement( en écrivant que le flag est a 0)
- Une fois au back up , on attend les 4 minutes qu'il reste( pour en faire 5)
- pendant l'attente on scrute la com : si elle revient, on sort ( est ce possible d'avoir deux return dans une sub ? ) de la sub
- si elle revient pas on déroule backup tant que la com ne revient pas
Voila a quoi j'avais pensé , pensez vous que c'est faisable
Je vous sollicite encore une fois concernant la logique de travail.
Je desirerais dans la mesur edu possible , avant de faire mon backup ( protocole de marche arriére avec la memoire) , effectuer une reset avant ! .
et ce que ce petit logigramme serait convenable . je précise que la précision n'est pas du tout indispensable :
- perte de communication
- arrêt de la voiture
- Boucle d'attente si timer > 60 ( avec timer cale sur 1s)
- On met a 1 un flag avec une commande write
- On reset
- Apres le reset , on lit le flag
- si flag = 1 c'est qu'on a déjà arrêté la voiture , donc on va au back up, sinon c'est juste le premier allumage et donc on continue le programme normalement( en écrivant que le flag est a 0)
- Une fois au back up , on attend les 4 minutes qu'il reste( pour en faire 5)
- pendant l'attente on scrute la com : si elle revient, on sort ( est ce possible d'avoir deux return dans une sub ? ) de la sub
- si elle revient pas on déroule backup tant que la com ne revient pas
Voila a quoi j'avais pensé , pensez vous que c'est faisable
Bonjour à tous ,
Pour ne pas polluer le post JRLC, je post ici . En effet il traite à peu pret du même probléme mais dans une tout autre mesure .
Puis je faire ceci ?
Mes questions , y'a t-il une tension Vds ?
est ce que quand le MOS n'est pas passant une petite consommation est présente ?
Je n'ai pas mis de resistance en serie a la sortie du uC, mais je pense que ca ne devrait pas gener, ou est il preferable d'en mettre une ?
Je compte alimenter l'emetteur vidéo avec une batterie de 3S LiPo de 5000mAh . la tension presente avec ce genre de batterie en pleine charge est superieur à 12V . et l'emetteur accepte un peu moins de 12V . , mais si la tension de Vds est trop grande je changerai eventuellement de batterie .
Vous l'aurez compris , il n'y as pas de frequence prevue, c'est juste un simple interrupteur j'allume la vidéo et je l'eteints?
Par avance merci
PS: si vous avez des suggestions plus "adequate" jue sui preneur
Pour ne pas polluer le post JRLC, je post ici . En effet il traite à peu pret du même probléme mais dans une tout autre mesure .
Puis je faire ceci ?
Mes questions , y'a t-il une tension Vds ?
est ce que quand le MOS n'est pas passant une petite consommation est présente ?
Je n'ai pas mis de resistance en serie a la sortie du uC, mais je pense que ca ne devrait pas gener, ou est il preferable d'en mettre une ?
Je compte alimenter l'emetteur vidéo avec une batterie de 3S LiPo de 5000mAh . la tension presente avec ce genre de batterie en pleine charge est superieur à 12V . et l'emetteur accepte un peu moins de 12V . , mais si la tension de Vds est trop grande je changerai eventuellement de batterie .
Vous l'aurez compris , il n'y as pas de frequence prevue, c'est juste un simple interrupteur j'allume la vidéo et je l'eteints?
Par avance merci
PS: si vous avez des suggestions plus "adequate" jue sui preneur
Voir le post #7 du thread cité : oui il faut une résistance pour limiter le courant lors de la charge du condensateur du MOSFET.
Le courant de fuite est normalement quasi nul.
Cela dit, si vous avez besoin d'un étage de régulation pour ne pas cramer votre émetteur, vous pouvez aussi utiliser un LM117 pour assurer l'interrupteur.
Voir figure 11 dans le datasheet Jameco
ou figure 35 dans le datasheet Philips
Plutôt que le LM117, un régulateur low drop est plus adapté : LT1085 voir en bas de la page 15. (mais c'est plus cher...)
Le courant de fuite est normalement quasi nul.
Cela dit, si vous avez besoin d'un étage de régulation pour ne pas cramer votre émetteur, vous pouvez aussi utiliser un LM117 pour assurer l'interrupteur.
Voir figure 11 dans le datasheet Jameco
ou figure 35 dans le datasheet Philips
Plutôt que le LM117, un régulateur low drop est plus adapté : LT1085 voir en bas de la page 15. (mais c'est plus cher...)
Last edited:
PieM
Senior Member
Comme déjà dit par Michel, cette résistance n'est pas forcément nécessaire. Elle n'est fonction que de la capacité de grille du MosFet.
En tout état de cause une R de 1k avec une pull down de 10k fait chuter la tension de grille de 10%. Selon le type de Mosfet le rémède est pire que le mal.
Pour limiter le courant de grille une résistance de 330 ohm est suffisante et une R de pull down de 100k est tout aussi efficace.
Mais sans connaître le type de MosFet, difficile de déterminer ce qu'il faut.
Last edited:
Oui, je verrais ce que j'ai dans mes tiroirs et je vous l'indiquerais , pour une éventuelle confirmation.
Ma crainte était plutôt pour être sûr, que cela coupe bien mon alimentation . Le courant de fuite doit être minime , pour un maximum d'autonomie.
Sur le prototype, j'avais mis un opto-coupleur pour isoler suivis d'un relais. Ici je souhaite supprimer une batterie, donc une seule batterie fournir l'énergie , pour l'électronique , les servos la camera et l'émetteur vidéo. Et deux autre pour la propulsion.
Les masses seront donc commune plus besoin de l’opto- coupleur.
J'ai opter pour cette solution pour diminuer les contraintes de l'utilisateur.
Merci à vous
Bonjour ,
Voila ce que j'ai dans mes tiroirs : MOSFET CANAL N 16A , j'ai aussi les mêmes en 60A et 100A . Mais je pense avoir besoin d'un si fort courant max entre le drain et la source.
J'ai également des transistors darlington dans ce style, mais j'ia cru comprendre que c'est moins bien .
Donc je pars pour le MOSFET. Avant de mettre sur la plaque d'essai, pouvez m'envoyer un feu vert , avec ce type de composant?
Voila ce que j'ai dans mes tiroirs : MOSFET CANAL N 16A , j'ai aussi les mêmes en 60A et 100A . Mais je pense avoir besoin d'un si fort courant max entre le drain et la source.
J'ai également des transistors darlington dans ce style, mais j'ia cru comprendre que c'est moins bien .
Donc je pars pour le MOSFET. Avant de mettre sur la plaque d'essai, pouvez m'envoyer un feu vert , avec ce type de composant?
PieM
Senior Member
Il convient très largement.
Le problème du darlington , c'est qui a une tension de saturation Vcesat de l'ordre de 2V . donc de ta batterie de 12V il ne reste que 10V utile et tu as 1.8W de dissipation thermique pour chauffer les oiseaux.
Remarque: il n'y a aucune masse commune entre ton émetteur et ton circuit picaxe j'espère.
Le problème du darlington , c'est qui a une tension de saturation Vcesat de l'ordre de 2V . donc de ta batterie de 12V il ne reste que 10V utile et tu as 1.8W de dissipation thermique pour chauffer les oiseaux.
Remarque: il n'y a aucune masse commune entre ton émetteur et ton circuit picaxe j'espère.
Génial , merci ; Donc ce sera un MOSFET ;
Sympa la petite explication qui va avec ; effectivement abaisser la tension de 2V , c'est pile poil ce que je veux éviter ;
Pour moi ce sera plus simple , et certainement plus fiable , que mon couple opto-coupleur et relais lol . Pour une fois, ca a l'air d'être mieux .
Allez zou je file tester ca
Sympa la petite explication qui va avec ; effectivement abaisser la tension de 2V , c'est pile poil ce que je veux éviter ;
Pour moi ce sera plus simple , et certainement plus fiable , que mon couple opto-coupleur et relais lol . Pour une fois, ca a l'air d'être mieux .
Allez zou je file tester ca
Vu le schéma, j'ai comme un gros doute là... d'autant qu'il n'y a qu'une seule batterie (#154) ...
Si .
Effectivement le but est d'utilisé une seule batterie ! . Pourquoi ? .
A l'allumage, tu crains un reset du picaxe ?
Le schéma général . ma batterie 3S alimente
les servos ( 8 au total) : qui sont derriere un regulateur a découpage reglable ( je l'ai mis a 6.5V)
L'electronique ( Picaxe memoire , leds ,etc ...) derriere un régulateur a découpage de 5V .
Et enfin l'emetteur direct sur la batterie . L'emetteur posséde des fils en sortie pour alimenter la camera .
Je souhaite, si c'est possible gagné une batterie . Car en tout et pour tout . le VHL en posséde 2 , la télécommande 1 , les lunettes d'immersion 1 , le recepteur video 1 , si je decide de faire le head tracker( ne croyez pas que je l'ia oublier celui la ) une de plus .