Télécommande voiture RC + caméra

dje8269

Senior Member
Hello PieM,

Ouais ben ça tu évites !!!
Pas de soucis . c'est ce que j'ai remarqué ; le fait de l'activé ou non a la suite provoque quelques réponses plutôt aléatoires . Ce qui continue de démontré qu'il y as un rapport de temps ou de synchro quelques part, même si je n'est toujours pas trouvé a ce jour la relation entre les temps de pause
 

dje8269

Senior Member
Bonjour à tous ,

Je suis de retour au travail :mad: . Mais je peux donc maintenant bénéficié de quelques avantages , plaque d'essai , matos de rechange , et oscilloscope ;

Auriez vous quelques nouveaux tests a effectuer ? visu a l'oscillo ou autres ?

tests effectués :

Mise du circuit Rx sur plaque d'essai . visualisation a l'oscillo de ce qui sort de la patte du Rx et qui va sur le µC . Le Rx à une pause de 15ms apres le Rfin.

Quand je fais varié de 5ms de pause a 40ms de pause sur le Tx ; la courbe est propre, un joli créneau avec le respect du temps de pause . par contre , la led clignote parfaitement entre 15ms et 20ms de pause . en dessous ou au dessus de ses valeurs , la led clignote mal ou presque pas . Contre toute attente il s'agirait donc de la réception voir même du picaxe le problème non ?

En effet , le picaxe reçoit bien un signal propre et net (par exemple avec 25ms de pause sur le Tx) , mais la led reste bloquée , donc le Rfin est bloqué ; Pourtant le signal arrive bien sur sa broche(vu à l'oscillo) . Le signal serait-il trop rapide pour le picaxe en réception ou quelques chose du genre ?

Toujours sur la broche data du Rx, au delà de 40ms de pause en émission, la courbe se dégrade à la réception ( les bords s'arrondissent et un trou se forme au milieu). Je comprends pas trop pourquoi . Alors qu'il ne devrait y avoir qu'une difference du temps de pause entre deux salves émission . bizarre comme d'hab , j'ai jamais un problème simple j'ai l'impression .
 
Last edited:

dje8269

Senior Member
Re-moi ,

Bon j'avance , j'ai des résultats , mais sans trop comprendre pour être honnête . Tout d'abord je pense que plusieurs problèmes se superpose . Le temps de reception d'emission , et le parasitage .

En effet , étant à la maison , j'ai laissé tombé l'idée de faire plan de sol comme sur la première télécommande. Puis je me suis souvenus de PieM qui disais a Mike ( post chrono agilty) de mettre un plaque perpendiculaire au connecteur de l'antenne , pour faire le ground plane . c'est ce que j'ai fais . Au miracle ca fonctionne énormément mieux .

J'ai ajusté les temps de pause en émission et en réception . Puis je me suis rendu compte que ca fonctionnait parfaitement ;

Actuellement j'en suis rendu à :

Cote Tx : je suis repassé à 32Mhz , sans aucun temps de pause à l'émission . parfait.
Coté Rx : Reduis le temps de pause à 20ms ( pour voir clignoté ma led hein !) . parfait .
 

dje8269

Senior Member
Re-re-moi,

Je n'ose y croire, mais je pense que la , c'est la bonne ! du moins je l'espère . Il s'agit effectivement d'un problème dû à un défaut de transmission .

En rajoutant un plan de sol ca fonctionne du tonnerre , sans aucune pauses des deux cotés . Quand je l'enlève ca re-déconne.

Comme on peut le voir ici le connecteur de base est au bord de la plaque du CI, et ça je pense que c'est mauvais (Georges pourrait peut être me le confirmer ou pas ?!) . Avec le recul , je me souviens avoir lu quelques part ,qu'un plan de sol doit être le plus centré possible afin d'émettre avec une certaine homogénéité autour de l'antenne . Comme je suis au bord les ondes partent mal et dans un seul sens pour schématiser , certainement du coté de l'électronique en plus.

Avec l'ajout d'une plaque de cuivre de 8x4 ( en cm) , perpendiculaire à la plaque du CI ça fonctionne nickel .

Pour des questions d'hesthetique , je vais essayé de reduire et d'integrer cette plaque dans la télécommande .

Je retrouve enfin le sourire sur ce projet .
 

dje8269

Senior Member
Bon ben , je crois que cette fois j'ai mon compte.

petit test avant d'attaqué le boulot , paf , ca marche plus !!! j'ai encore une fois parler trop vite . J'y croyais vraiment cette fois , tant pis !

J'ai tout essayé, blindage , refais et encore refais des typons en DF , changer le programme , blindé les cables , lus et relus la DS en anglais ...... mis des condo de découplage, de filtrage des resistances de pull up/down . Bref je suis au bout du bout la ! .

Allez Zou au placard !! Jérémy mode [dégouté]

Pfff les anglais on gagné
 

dje8269

Senior Member
Avant de tout jeter à la poubelle , j'ai une éventuelle mini pistouille .

Après des tests en filaire ( j'ai relie la broche Rfout à la broche Rfin , et mis la masse en commun) . Tout fonctionnait parfaitement, je me suis absenté quelques minutes, et en revenant ça déconnait même en filaire . J'ai l'impression que quand les deux picaxes à 4Mhz, pas de bug , quand je met le picaxe TX à 32 mhz, au bout d'un moment ça commence a foiré en filaire .

En relisant la DS ,j'ai trouvé ceci, mais malheureusement je ne suis pas assez calé la dessus , quelques chose sur la DS du Tx : en Page 4 , Sur le schéma il parle de "Preamble / RX data slicer" .
settling time".

N'y aurait-il pas un problème qui glisse dans le temps et qui "désynchronise" les datas ( je sais pas si c'est le bon terme) , mais disons qu'a des fréquences différentes au bout d'un moment ca déconne ;A l'oscilloscope les courbes sont toujours les mêmes.

Peut être aussi que mon test de clignotement de led est trop pechû.

Si je pousse un peu la réflexion .

Imaginons, que le RFin attend son premier octet . Mais que le moment ou il attend son premier octets , le TX lui ( comme il n'ont pas la même horloge et programme), et en train d'envoyer le deuxième octet . C'est comme si le Tx avait eu un peu d'avance sur le Rx . Donc le RX ne recevra que 7 octets , et attendras le huitième au tour prochain . Mais le 8 huitième ne seras pas le bon car il seras en fait le 1 octets du deuxiéme envoi du TX ? non . Ou alors le preambule doit être envoyé a chaque fois ? Je suis perdu et comprends pas trop .

Si y'as des soucis la dessus , cela signifierait que pour recevoir "proprement" sur le RFin, il faudrait attendre quasiment deux envois ( pour etre certain) du TX . Donc le temps de pause du Rx devrait être 2 fois moins rapide non ? C'est tiré par les cheveux ou j'ai du vrai
 

GM39

Senior Member
Après des tests en filaire ( j'ai relie la broche Rfout à la broche Rfin , et mis la masse en commun) . Tout fonctionnait parfaitement, je me suis absenté quelques minutes, et en revenant ça déconnait même en filaire . J'ai l'impression que quand les deux picaxes à 4Mhz, pas de bug , quand je met le picaxe TX à 32 mhz, au bout d'un moment ça commence a foiré en filaire .
Essai de voir si ça déconne aussi rapidement à froid qu'à chaud. Il peut y avoir un composant défectueux.
Tu pars d'un système froid, tu regarde au bout de combien de temps ça déconne, puis tu réinitialise tout et tu regarde au bout de combien de temps ça déconne.

Au pire reste à 4Mhz si tout fonctionne

En relisant la DS ,j'ai trouvé ceci, mais malheureusement je ne suis pas assez calé la dessus , quelques chose sur la DS du Tx : en Page 4 , Sur le schéma il parle de "Preamble / RX data slicer" .
settling time".
Le RX se règle pour discriminer 0 et 1. Vu que ça déconne en filaire...
 

jojojo

Senior Member
D'accord avec GM.

Ca déconne à chaud, donc, neuf chances sur dix pour un problème d'alim.

Et, pour info, et rester dans la même logique, les picaxes consomment davantage, lorsque l'on monte la fréquence d'horloge.
 

dje8269

Senior Member
Essai de voir si ça déconne aussi rapidement à froid qu'à chaud. Il peut y avoir un composant défectueux.
Je ne pense pas que ce soit possible . Que je mets 15ms et 20ms de pause ca fonctionne parfaitement et ce en RF pendant plusieurs minutes ( et le tx est chaud) . En filaire je n'utilise pas les RX/TX , donc pas de problème juste les deux picaxes relié ensembles . Aucune chauffe possible, et pour tant ca déconne . Le Rx est sur plaque d'essai et sur alim stabilisé ; Le 20M2 émission consomme rien du tout et est sur batterie lui .

Au pire reste à 4Mhz si tout fonctionne
Oui mais ça c'est en filaire pas en RF .

En fait le Rfout passe automatiquement le µC 4 mhz , puis il repasse à 32Mhz , je le vois avec les temps de pause qui sont divisé par 8 . Peut etre que la pause après RFout permet de repasser correctement à 32 Mhz .

J'ai eu une idée, au lieu de visualiser la led qui s'allume et s'eteint ( je suis obligé de mettre une pause de 20ms pour voir quand elle s'eteint . j'ai mis la sortie du ^picaxe a l'oscillo . Ainsi je vois parfaitement quand le RFin passe oun reste bloqué ; ainsi je n'est plus de pause dans la réception.

Je vais repassé en RF pour voir ce qui ce passe ainsi .

Le seul chose qu'on n'as pas etudié c'est la communication des picaxes ; Je ne vois plus que ca .

Le Tx est bon le signal est propre . avec 15ms de pause ca fonctionne avec 30 ms ca déconne. Pourtant le signal a l'oscillo reste identique ( sauf le temps de pause entre deux)
Le Rx est bon aussi . La courbe qui entre sur la broche du picaxe est impeccable .

Il ne me reste plus que la communication des picaxes et un certains respect de temps de pause ou je sais pas quoi, mais je suis persuadé qu'il y as une relation de temps

@Georges :
Ca déconne à chaud, donc, neuf chances sur dix pour un problème d'alim.
Ce n'est pas la chaleur le facteur , c'est le temps . au pire je vais faire une autre plaque d'essai pour le TX on sera fixé .
 

dje8269

Senior Member
Bon, la chaleur est écarté je fais plusieurs tests a chaud et a froid .

Par contre un truc me chiffonne .J'ai remplacé la led par ma sonde d'oscillo ; ainsi je peux voir le très court changement d'état de la sortie ou était branché la led . J'ai donc plus aucune pause en réception . J'ai juste :
- mise a l'état haut de la broche
- suivis du Rfin
- mise a l'état bas de la broche
- puis sa reboucle .

Quand je met aucun temps de pause a l'emission ca fonctionne , plus j'augmente les temps de pause , plus ca deconne ; Alors que normalement ca ne devrais pas . il devrait juste moins y avoir plus de temps entre deux informations.
 

dje8269

Senior Member
Bon j'ai peut être encore une lueur d'espoir ., mais on va laissé passer la nuit hein .....

Questions pour un expert : ( Georges ?) Tu m'as parler une fois de saturation de l'étage d'entrée quelques choses comme ça !!! . Peut tu m'en dire un chouille plus . Je pense que ça venait de là ! . ( mais y'avais pas que ça c'est sur).

Après une moultitude de modifs, voila que ça fonctionne parfaitement a nouveau, vous savez comment ?!!??

En éloignement d'un bon 2 metres les Tx/Rx .

Ceci explique le coté aléatoire de la chose je suppose non ? Après une bonne trentaine d'allumages , attentes , rallumage etc .... ca fonctionne parfaitement quand je suis derrière un mur en ayant enlevé l'antenne du Rx .

Est ce que ca peut vous paraitre plausible ? car c'est vrai que 450mW d'émission, ca envoie fort quand même
 

PieM

Senior Member
Après une moultitude de modifs, voila que ça fonctionne parfaitement a nouveau, vous savez comment ?!!??
En éloignement d'un bon 2 metres les Tx/Rx .
Ceci explique le coté aléatoire de la chose je suppose non ? Après une bonne trentaine d'allumages , attentes , rallumage etc .... ca fonctionne parfaitement quand je suis derrière un mur en ayant enlevé l'antenne du Rx .
Est ce que ca peut vous paraitre plausible ? car c'est vrai que 450mW d'émission, ca envoie fort quand même
Quelle trouvaille !!! Quand je t'ai dit qu'on ne balançait pas 500 mW sur un récepteur situé à coté, finalement ça ne t'a servi à rien! :mad:
De toute façon ça n'explique pas les pb en liaison filaire. si ils existent car je ne sais plus trop ...

Tout pendant que ça ne marche pas PARFAITEMENT en filaire, tu peux laisser tes TX/Rx dans un placard.
 
Last edited:

dje8269

Senior Member
Qu'elle trouvaille !!! Quand je t'ai dit qu'on ne balançait pas 500 mW sur un récepteur situé à coté, finalement ça ne t'a servi à rien!
Je sais, je sais ..... mais mets toi un tout petit peu a ma place , je fais 50 essais a la minute m'éloigner de 2 mètres a chaque fois n'était vraiment pas pratique ...... Si tu savais comme je m'en mords les doigts ...... . mais bon la nuit n'est pas encore passé, hier soir aussi je croyais avoir trouvé, avant que tout ne s'effondre .

Pour être encore super honnête comme je l'ai toujours été, avant de partir j'ai refais une bonne dizaine de test , et un petit bug m'a interpellé , je pense qu'il faudra que je marque la pause à l'activation du Tx pour lui laissé le temps de se caler , car il m'est arrivé une fois, qu'en appuyant sur le joystick très légèrement , juste de quoi voir la led EN s'allumée , et ben je n'ai rien reçu . Peut être était-ce par ce que c'était trop furtif pour le calage ? A confirmer !!

De toute façon ça n'explique pas les pb en liaison filaire. si ils existent car je ne sais plus trop ...
Oui oui il existe , enfin euhhhhhh, en écrivant ces lignes pour vous expliquer , je me rends compte que j'ai pas mis de R de 1K en série pour la liaison, directement un fil ..... Donc ...... .

Sinon il suffit de mettre deux picaxes relié par un fil ( avec une R de 1K) faire un RFin et Rfout , et mettre deux fréquences de travail différentes . au bon d'un moment la liaison par en sucette .

J'éspere que cette histoire d'éloignement sera LA bonne solution ......

En tout cas je n'avais pas de bug sur la lecture des readadc ? même en émettant ca bouge pas .
Une fois la transmission lancée je n'ai eu aucun bug .
 

jojojo

Senior Member
Questions pour un expert : ( Georges ?) Tu m'as parler une fois de saturation de l'étage d'entrée quelques choses comme ça !!!
C'est pas une expertise, mais, oui, le (les) étage(s) d'entrée d'un RX est (sont) pénalisé(s) par des signaux trop forts. Hormis l'intermodulation, tu as aussi la CAG, qui tente d'inhiber ce qu'elle peut, et parfois trop. Aussi: On a déjà vu des étages d'entrée purement et simplement détruits, par un champ trop important. Donc, prudence...

Le truc, pour moi, assez "chiffonnant", ce sont les tests en filaire.
La résistance de 1k, c'est pipeau ! Aucune utilité. Ca DOIT fonctionner nickel, sans. A la limite, dans certains cas (mais pas ici) une pull down serait utile...

Je sais, que tu utilises une entrée en mode trigger, pour le RFIN, mais, vu que au boulôt, tu as de la ressource, fais mois plaisir, ajoute deux vrais trigger, en série, entre le RX et le pic. (soit du 4093, soit du 40106).

Et, comme le précise Piem, ne repasse en HF,qu'une fois TOUS les problèmes réglés, en filaire.

Ca va le faire :D

PS: Mon petit fils et sa maman viennent de rentrer de vacances. ET, le tiot a joué tout le mois, avec sa belle voiture télécommandée Picaxe made in Papy. Tu vois ...
 

PieM

Senior Member
je fais 50 essais a la minute m'éloigner de 2 mètres a chaque fois n'était vraiment pas pratique
Alors là il n'y a plus qu'à tirer l'échelle ! Alimente tes picaxes en 220 Vac, c'est plus pratique: pas besoin d'alim.

La résistance de 1k, c'est pipeau ! Aucune utilité.
Fonctionnellement non, mais l'utilité de mettre une résistance, c'est que quand on fait des essais, ça limite le risque de balancer une sortie à 1sur une broche configurée en sortie à 0 sur l'autre...
 

dje8269

Senior Member
Ok. Pas de souci pour le test avec les 4093, je crois que j'en ai. Je te dois bien ça. Et puis imagine que ça marche du tonnerre. Pour la liaison série tout le monde peut faire les test du coup car pas besoin de Rx/Tx.

Bravo pour la voiture du petit. Tu dois être sacrément fier! Et lui de toi aussi
 

dje8269

Senior Member
Ok. Pas de souci pour le test avec les 4093, je crois que j'en ai. Je te dois bien ça. Et puis imagine que ça marche du tonnerre. Pour la liaison série tout le monde peut faire les test du coup car pas besoin de Rx/Tx.

Bravo pour la voiture du petit. Tu dois être sacrément fier! Et lui de toi aussi
 

dje8269

Senior Member
Oui c'est pas faux. Mais les deux picaxes à 4 MHz ça fonctionnait impeccable , même après 10 minutes. C'est forcément le timing le problème . Car avec un 4 MHz et l'autre a 32mhz patatras ....
 
Last edited:

PieM

Senior Member
Oui c'est pas faux. Mais les deux picaxes à 4 MHz ça fonctionnait impeccable , même après 10 minutes. C'est forcément le timing le problème . Car avec un 4 MHz et l'autre a 32mhz patatras ....
Alors tu restes à 4MHz. De toute façon vu le programme tu ne gagnes pas grand chose à 32.
Tu valides ton prog, et ensuite seulement tu passes aux Tx/Rx.
 

dje8269

Senior Member
Alors tu restes à 4MHz. De toute façon vu le programme tu ne gagnes pas grand chose à 32.
Ca c'est bien vrai, le programme émission est relativement court ; Par curiosité , quand tout marcheras parfaitement, et en permanence, j'essayerai jsute pour voir ; Mais la en attendant c'est 4 Mhz et pi c'est tout lol .

Tu valides ton prog, et ensuite seulement tu passes aux Tx/Rx.
Aïe, je suis déja passé aux Tx/Rx . comme ca fonctionnait bien en filaire avec 4Mhz . C'est comme ca que j'ai trouvé en m'éloignant ( ceci dit en passant, c'est aussi un peu dû au hazard). Donc avant de repassé en filaire , je vais juste testé le programme vu avec MG39 pour mettre une pause lors de la première activation du Tx. Si ça ne fonctionne toujours pas je repasse en filaire, et résoud le problème ainsi .

Après recherche sur le net, l'explication de Georges , tiens bien la route . La saturation de l'étage d'entrée, et la CAG qui ne peut plus parvenir à compenser tout ca ; Donc j'ai bon espoir, que cela fonctionne encore en m'éloignant.
 

dje8269

Senior Member
Bonjour à tous,

Pensez vous qu'il est possible de réduire la sensibilité de la réception afin de faire d les test sans trop m'éloigner ? Genre en enlevant l'antenne du Rx, et si je met une boîte en alu dessus , ça aiderai ?
Je pense entrevoir ma réponse mais bon , j'essaie des fois qu'il y aurai une solution facile pour m'aider
 

PieM

Senior Member
Il faut être sérieux. soit tu veux faire des tests E/R réalistes, soit tu résous tes problèmes de confort et de facilité.
Si tu réduis ta réception, tu réduis tout y compris d'éventuels parasites.
 

dje8269

Senior Member
bonjour à tous,

Comme dis en #1021 , j'étais déjà passé en RF , et ça fonctionnait plutôt bien (pour ne pas dire parfaitement). Ce matin j'ai encore fais plein de test . et ca fonctionne parfaitement, toujours en RF; et toujours la télécommande loin du Rx .

Cependant , au bout d'une minute environ d'émission permanente j'ai eu un petit loupé de 400ms , pensez vous que c'est grave , ou alors que ça peut arrivé de temps en temps , du au parasite ?
 

dje8269

Senior Member
Les tests continuent d'etre concluant en RF . Bien sur il se glisse maintenant quelques bug du à mon programme je pense .Mais comme je n'en suis pas sûr, je me tourne vres vous.

Je me focalise aujourd'hui , sur les tests à fond ; afin d'être certains que la communication passe bien et ainsi , pouvoir emmener la voiture à la maison ce week end pour enfin passé à la programmation.

Pour le moment j'en suis rendu la .

test en RF condition réel ( voiture + télécommande ) . Pour faire mes tests , j'ai mis la sonde de l'oscillo sur une sortie du 14M2 de reception comme si je voulais allumer une led mais sans les pauses .
Le Tx et le Rx sont eloignés de 2/3 mètres .Le Rx à son antenne .

Question hard, quand j'émet (CàD que la broche ENable passe à 1), cela allume une led , ainsi je vois quand j'emets. J'ai un BP sur la télécommande branché sur une broche , et un interrupteur à levier branché aussi sur une entrée .

Voici le programme de réception :

Code:
#PICAXE 14M2

'#################################################################################
'##########################    Programme Recepteur    ############################	
'#################################################################################

'########################  Configuration  ########################

dirC.0=0				'declare C.0 en entrée DATA

inputtype %0000000100000000 	'met la broche C.0 en  mode TDS


'########################  Initialisation  ########################

setfreq m4

hi2csetup i2cmaster, %10100000, i2cfast_4, i2cbyte 	' met le 14M2 en mode maitre


'####################################################################################################
'					Programme Principal
'####################################################################################################
do

high B.1

RFin C.0,b0,b1,b2,b3,b4,b5,b6,b7		' Enregistre les données du RX

hi2cout 0,(b0,b1,b2,b3,b4,b5,b6,b7)	

low B.1


loop
La sonde de l'oscillo est branchée sur la broche B.1 . Et j'observe a l'oscillo des pics j'émets courts qui passent a zéro . Quand le RFin est bloqué la courbe reste à l'état haut . Ainsi même éloigné je vois la courbe a l'oscillo, et ainsi je peux savoir si la transmission passe.

A l'émission:
Code:
#PICAXE 20M2

'#################################################################################
'########################    Programme Emetteur V4.0   ###########################	
'#################################################################################

'##########################    configuration    ################################	
' B_ pour Broche, c'est le nom ou est branché le composant
' E_ pour Etat, c'est la valeur de la broche
' V_ pour variable, ou est enregistrée l'Etat de la broche

'b0 à b7 pour les infos envoyés
'b8 flag_EN
'b9 V_TOR


symbol B_BP		= PinB.5
symbol B_EN 	= B.6
symbol B_DONNEE 	= B.7
symbol B_Inter	= PinC.1

symbol flag_EN	= b8
symbol V_TOR	= b9
symbol V_Joystick = W13


dirsB = %11000000	'declare B.7 et B.6 en sortie


'##########################    Initialisation    ################################	

setfreq m4

V_TOR = b0

'#################################################################################
'##########################    Programme Principal    ############################	
'#################################################################################

do

readadc C.3,b1	' potar Av/ar Vhl/cam
readadc B.0,b3	' Potar Dr/Ga Vhl
readadc C.7,b5	' Potar Dr/Ga cam

bit0 = B_Inter	' Activation de l'emetteur Vidéo
bit1= B_BP		' Activation du mouvement camera

V_Joystick = b1+b3+b5	' Calcul de la position des joysticks



if V_Joystick < 370 or V_Joystick > 380 or  V_TOR<> b0 then		' on verifie qu'une commande est appuyée ou u nchangement d'etat d'un TOR


 	if flag_EN = 0 then 	' A chaque nouvelle activation on marque une pause de 80ms pour stabilisé le Tx
		high B_EN
		pause 80		' pause de 80ms
		flag_EN = 1		' Met le flag d'activation a 1
	end if
	
	V_TOR = b0			' Sauvegarde des TOR
 	time = 0			' remise a zéro du timer
 else
 
 	if time > 1 then 		' Si les commandes sont au PM, pendant plus de 1s on eteind
 		low B_EN
 		flag_EN = 0		' Raz du flag
 	end if
 
end if


rfout B_DONNEE,(b0,b1,b2,b3,b4,b5,b6,b7) 			'envoi des données par RF


loop
j'observe quelques bugs dans certains conditions. Commençons par la ou tout va bien .

Dés que je touche à peine a une commande joysticks ( je sors de la plage morte), je relâche immédiatement, ca fonctionne à 100%, il y a une émission de 1s , c'est parfait .
Quand je manipule les joysticks longtemps , pas de problème , ça fonctionne aussi dans 100% des cas . A part quelques petit loupés de temps en temps genre une trame de manqué en 30 secondes ; Mais c'est trés minime , et largement acceptable .

Maintenant ca se corse. Mais je pense pas que cela viennent de la transmission radio, car quand je manipule les joysticks ca focntionne parfaitement et tout le temps.

dans 90% des cas que , je bascule par exemple, l'interrupteur a levier ( qui me sert a allumer mon emetteur vidéo), tout ce passe bien , j'ai une detection d'un changement d'etat, et une transmission part pour une seconde. Mais dans le cas contraire, aucune transmission n'est emises, pourtant l'emetteur emet( je le vois grace a la led qui s'allume) mais je ne recois rien (RFin est bloqué) , mon signal reste à l'etat haut. Je pense que cela est dû , à un probléme de timing ; A savoir ou en est le programme quand je bascule l'inter . Car en fait le basculement de l'inter est extremement bref, et peut etre qu'il loupe l'info de changement d'etat, mais alors il ne devrait pas emettre.
Pourtant s'il emet c'est qu'il as vu un changement d'etat alors pourquoi je recois rien ?

Ce cas reste particulier est assez rare , mais pas négligeable . Voyez vous un bug ou un creux dans mon programme qui pourrait faire ce symptome .

Je sais pas si j'ai été super clair ? .

Modif : je précise que ce petit bug était déjà existant avec l'ancienne télécommande, j'avais parfois du mal a eteindre l'emetteur vidéo , il fallait que je me reprenne a deux fois . Ca confirme qu'il ne s'agit probablement pas d'un probléme de liaison RF
 
Last edited:

dje8269

Senior Member
A quoi ça te sert d'envoyer des RFout si ton émetteur n'est pas allumé ?
Euh...... a rien , tu as raison . Tu pense qu'il faut que je fasse les RFout seulement a l'activation du TX ?

comprends pas trop là ...
En fait j'ai peut être fait une mauvaise stratégie .

Car le Tx s'active sur un changement d'état et non sur un état fixe . Donc en fait , lorsque que je bascule l'inter , le changement d'état est extrement rapide quelques ms , c'est juste le fait de passer de 0 à 1 qui est détecté. car il enregistre le nouvel etat tout de suite aprés .

Je sais pas si j'ai été plus clair
 

PieM

Senior Member
Je sais pas si j'ai été plus clair
Non. comprends pas! tu parles de TX vidéo. il est sur la voiture non ?
le bit0 est à 1 ou à 0 en fonction de ton inter, non ? Donc je ne vois pas ou il y a détection sur un front montant !
Explique un peu mieux ton système car là je nage...
 

dje8269

Senior Member
tu parles de TX vidéo. il est sur la voiture non ?
Oui c'est ca .

le bit0 est à 1 ou à 0 en fonction de ton inter, non ?
Exactement

Donc je ne vois pas ou il y a détection sur un front montant !
La subtilité se trouve ici ; La détection se trouve sur le programme émission . Il se peut fortement que c'est moi qui est mal fait les choses dans le programme .

Car je fais :

lecture de l'inter avec : bit0 = B_Inter
Comparaison avec l'ancien état avec : V_TOR<> b0
enregistrement de l'état en cours pour la comparaison avec : V_TOR = b0

Je me demandais, si jamais je fais le changement d'état, à un "mauvais" moment peut être qu'il ne serait pas pris en compte ! un truc du genre . Car il n'y as qu'une seule chance de détecter un changement d'état vu qu'après s'est enregistré . Une seule chance peut signifié un seul front montant dans ce cas non ? Peut être que je me gourre totalement . Je m'en remet a ton expérience.

Je cherche la cause du pourquoi des fois TOR ne sont pas pris en compte alors que l'émetteur passe en émission.

Pourquoi je n'ai que des problèmes bizarre ...... . Avec les joysticks ca fonctionne a tout les coups, mais pas avec les TOR . Et je n'arrive pas a reproduire la chose systématiquement. C'est pour ca que je pensais que c'est plutôt a cause du programme que de la liaison. Je précise que ca marche parfaitement dans 90% des cas .

Explique un peu mieux ton système car là je nage...
Un interrupteur à levier sur la télécommande, me permet de passer le bit0 à 1 ou 0 . Ensuite la bit0 est envoyé par RF , la voiture détecte donc l'état de l'interrupteur pour activé ou non l'émetteur vidéo .
Un BP est aussi sur la télécommande , il me permet de passer le bit1 à 1 ou 0 . Ensuite le bit14 est envoyé ( tout comme le bit0 via la variable b0) par RF , et la voiture détecte si elle doit piloter soit la voiture soit la camera .
J'ai aussi 3 potar pour les commandes . Quand on regarde la télécommande du dessus , le joystick de gauche me permet soit d'avancer/ reculer la voiture(BP relaché) ou de monter et de descendre la camera ( si le BP est appuyé), toujours sur le joysticke de gauche , l'(autre potar me permet de tourner la camera à droite et gauche( seulement quand le BP est appuyé sinon aucune action).
Le joystick de droite, ne sert que pour la direction de la voiture .

Pour les voyants , quand je bascule l'interrupteur à levier , j'allume une led sur la télécommande pour visualisé l'état de mon émetteur vidéo . ( inter en haut , la broche = 1 , la led est allumée ).
J'ai également mis une led sur la broche Enable de l'émetteur radio . ainsi je visualise si l'émetteur est activé(donc émet) ou non .
 

PieM

Senior Member
La détection se trouve sur le programme émission
Non! l'émetteur doit se contenter d'envoyer l'état brut des capteurs. La gestion doit se faire à la réception.
Mais de toute façon je ne comprends toujours pas! tu transmets b0. b0 contient bien l'état de ton inter. il n'y a pas de notion de changement d'état !
Dans ton prog, tu lis b0 et tu le transmets si il a changé.
peu importe le timing.
 

dje8269

Senior Member
Effectivement je dois mal m'exprimé, je le concois .

Non! l'émetteur doit se contenter d'envoyer l'état brut des capteurs. La gestion doit se faire à la réception.
Oui oui , ca c'est bon . Il envoie les infos seulement le traitement propre de l'info se fait à la reception .

tu transmets b0. b0 contient bien l'état de ton inter. il n'y a pas de notion de changement d'état !
Si justement car je veut transmettre quand il y as un changement d'état justement ; Afin de transmettre ce changement d'état . Je prends un exemple plus concret .

La voiture est stoppée . je ne touche pas les joysticks ; au bout d'une seconde l'émetteur radio s'éteint .

Maintenant je décide d'allumer ma vidéo . je bascule mon inter ; dans ce cas de figure , j'ai mon changement d'état très bref ( passage de 0 à 1 ) qui doit etre envoyé par voie radio pour être interprété a la réception ! .

Dans ton prog, tu lis b0 et tu le transmets si il a changé.
Oui mais ca ne fonctionne pas à tout les coups . des fois b0 change , ca émet , mais le récepteur ne réagis pas !
 

PieM

Senior Member
Maintenant je décide d'allumer ma vidéo . je bascule mon inter ; dans ce cas de figure , j'ai mon changement d'état très bref ( passage de 0 à 1 )
Mais c'est pas le changement d'état qui est en cause là ! il n'est pas bref ! le nouvel état reste!
tu as bit0 à 0
tu le passes à 1
donc tu allumes ton TX
il envoie b0 qui contient la valeur bit0 = 1

et ton bit0 reste à un jusqu'à ce que tu mettes ton inter à 0

mais le récepteur ne réagis pas !
ça veut dire quoi ?
tu n'as pas la nouvelle valeur , ou tu restes sur RFin ?
 

dje8269

Senior Member
Mais c'est pas le changement d'état qui est en cause là ! il n'est pas bref ! le nouvel état reste!
Oui tu as raison .
En fait je reste bloquée sur le RF in ! C'est étrange non !
A chaque changement aussi bref soit il , je devrais avoir une réception de 1s.
Ça marche parfaitement avec les joystick mais pas systématiquement avec les TOR.
 
Last edited:

PieM

Senior Member
Ton flag_EN ne sert strictement à rien.

Si tu restes bloqué sur RFin c'est qu'il y a un pb de transmission.
 
Last edited:

dje8269

Senior Member
Je peux pas faire ca . Je mange la procedure sinon .

le delais de 80 ms n'est fait que pour la premiere activation du Tx ensuite il ne faut plus laissé de delais de 80ms . D'ou l'utilité du Flag_En .

Quand le Tx est desactivé ( B_En = 0) .
Je bouge un joystick ou un TOR .

Première boucle:

Mon flag est a 0 donc
Je dois activé mon Tx , attendre 80ms pour le stabilisé comme sur la DS et je met mon flag a 1 .

ensuite j'envoie les données .

deuxième boucle :

j'ai toujours un joystick de bougé
Mon flag est à 1
je fais tout de suite un Rfout (sans passé par la case pause de 80ms).

troisième boucle:
mon joystick est au point mort .
je met mon flag à 0 , si cela fais une seconde qu'il et au PM je désactive le Tx .
 

dje8269

Senior Member
Si tu restes bloqué sur RFin c'est qu'il y a un pb de transmission.
Oui exact . Mais je connais pas le cheminement exact du RFin . Peut etre pourras tu éclairer ma lanterne .

Le RFin est bloquant Ok! Mais comment se bloque t il au juste . Je m'explique . Le RFin attend ces 8 octets pour être validés en quelques sortes ; s'il ne reçois que 7 octets il n'est donc pas validé . Mais si je lui en envoie 7 autres . Est ce qu'il se débloqueras ? car le 1 octets de la deuxième salve sera peut être interpréter comme le 8 de la première salve non ?

allez un exemple :

le RFin recoit : 0-1-2-3-4-5-6 . soit (7 octets) . il est toujours bloqué car il lui en faut 8 .
Maintenant je lui renvoie 7 nouveaux octets .
le RFin recoit : 7-8-9-10-11-12-13.

Est ce que le fait de lui envoyer ca correspond comme s'il avait recu :
0-1-2-3-4-5-6-7 et ( 8octets) donc la il passe
8-9-10-11-12-13 ( 6octets) et la reste bloqué en attente de deux octets ?
 

jojojo

Senior Member
Mais si je lui en envoie 7 autres . Est ce qu'il se débloqueras ? car le 1 octets de la deuxième salve sera peut être interpréter comme le 8 de la première salve non ?
Non. Tiens, c'est trop court. Donc, je disais : Non.
 

dje8269

Senior Member
Ok merci Georges . Dommage, j'avoue que ca m'aurait arrangé lol .

Car si un octet était mangé , j'aurais fais deux ou trois envoie consécutifs, a la détection d'un changement de TOR . Ben je comprends pas trop alors pourquoi de temps en temps sa décorne a ce niveau la et pas avec les joysticks;
 

jojojo

Senior Member
Si ça peut te consoler, sur mon proto, je n'ais que 6 TOR qui fonctionnent. Jamais compris pourquoi, mais ... Je fais avec :(
 

dje8269

Senior Member
Bonjour à tous,

Oui ça me console un peu, je me dis que si quelqu'un d'aussi expérimenté que toi, n'as pas trouvé , je suis pas ridicule alors ;

J'ai tout de même un peu cherché ( mon coté tetu et combattant lol). j'ai donc fais deux petites modifs au programme avant de faire les test en réel ;

j'ai augmenté le temps de stabilisation du Tx lors de la première emission a 90ms au lieu de 80 . et juste pour le fun , j'ai déplacé l'enregistrement des TOR dans b0 après le Rfout, pour ne pas déranger mon b0 avant qu'il soit envoyé.

En réel si vraiment c'est gênant que ca ne fonctionne qu'une fois sur 10 , j'ai une solution de secours ; plutôt que d'utiliser les bit je pourrais utilisé les variables directement, c'est du gaspillage certes , mais de toutes façon je dois en envoyer 8 bytes obligatoirement, et j'en utilise que 4 pour le moment .


Code:
#PICAXE 20M2

'#################################################################################
'########################    Programme Emetteur V4.0   ###########################	
'#################################################################################

'##########################    configuration    ################################	
' B_ pour Broche, c'est le nom ou est branché le composant
' E_ pour Etat, c'est la valeur de la broche
' V_ pour variable, ou est enregistrée l'Etat de la broche

'b0 à b7 pour les infos envoyés
'b8 flag_EN
'b9 V_TOR


symbol B_BP		= PinB.5
symbol B_EN 	= B.6
symbol B_DONNEE 	= B.7
symbol B_Inter	= PinC.1

symbol flag_EN	= b8
symbol V_TOR	= b9
symbol V_Joystick = W13


dirsB = %11000000	'declare B.7 et B.6 en sortie


'##########################    Initialisation    ################################	

setfreq m4

V_TOR = b0

'#################################################################################
'##########################    Programme Principal    ############################	
'#################################################################################

do

readadc C.3,b1		' potar Av/ar Vhl/cam	PM : de 166 à 168
readadc B.0,b3		' Potar Dr/Ga Vhl		PM : de 103 à 105
readadc C.7,b5		' Potar Dr/Ga cam		PM : de 103 à 105

bit0 = B_Inter		' Activation de l'emetteur Vidéo
bit1 = B_BP			' Activation du mouvement camera

V_Joystick = b1+b3+b5	' Calcul de la position des joysticks ( PM moyen 375 +/4)



if V_Joystick < 372 or V_Joystick > 378 or  V_TOR <> b0 then	' on verifie qu'une commande est appuyée ou un changement d'etat d'un TOR


 	if flag_EN = 0 then 	' A chaque nouvelle activation on marque une pause de 80ms pour stabilisé le Tx
		high B_EN
		pause 90		' pause de 90ms
		flag_EN = 1		' Met le flag d'activation a 1
	end if
	
	time = 0			' remise a zéro du timer
 	
 else
 
 	if time > 1 then 		' Si les commandes sont au PM, pendant plus de 1s on eteind
 		low B_EN
 		flag_EN = 0		' Raz du flag
 	end if
 
end if

rfout B_DONNEE,(b0,b1,b2,b3,b4,b5,b6,b7) 		'envoi des données par RF seulement quand le Tx est activé

V_TOR = b0			' Sauvegarde des TOR

loop
 
Top