Platine test pour module radio AMB8636

BESQUEUT

Senior Member
avec le proto , j'envoie 8 octets toutes les 39/40 ms . preuve oscillo a l'appui . sur les 8 octets seulement 5 d'utiles , les 3 autres me servaient de séparation entre les données .
Donc 25 trames/s émises. C'est bien d'avoir contrôlé à l'oscillo, sauf que ce qui est important c'est combien sont effectivement utilisées ?
Pouvez-vous détailler le contenu de ces 5 octets, en particulier en corrélation avec les 2 modes de pilotage (avec et sans headtracker)
et les valeurs numériques mini et maxi transmises ?
 

dje8269

Senior Member
Je ne me souviens plus ce qui a posé problème pour la détection de perte de communication.
Peut-être pouvez-vous me rafraîchir la mémoire ou pointer sur les posts ad hoc ?
De mémoire, c'est plus ce qu'il faut faire en cas de perte de communication qui a posé problème, que la détection elle-même.
Ce sujet a traiter sur de nombreuses pages ;

En fait le point délicat c’était d'effectuer une tache , quand une commande était bloquée .

On utilisait le Rfin . qui est bloquante ; donc quand on reçois plus rien, le picaxe ne fait que attendre et rien d'autre!!!

la solution fut été complexe . Un picaxe dédié a la réception par RFin en esclave . Un autre picaxe en maitre recevait en hi2C les données de l'esclave. Quand l'esclave venait posé les données sur le maitre il met un flag . Si ce flag n’était pas recu pendant un certain temps c'est que le picaxe esclave n'avait pas mis a jour les données et donc était bloquer . Merci à PieM .

Je crosi me souvenir que d'autres solutions aurit pus etre envisagés , mais la partie hard était deja figés ; c'est pour ca , que je voudrais bien définir la meilleure façon de faire avant . Mais je pense qu'avec ces modules ca devrait etre plus aisé
 

BESQUEUT

Senior Member
??? je comprends pas tout . Lors de la création du proto ; j'effectue des test de conduite . au début des tests , la fréquence de mise à jour des infos était de 150ms . Les personnes qui connaissait rien du tout a la programmation , qui conduisait seulement le VHL , mon dit que c’était pas instantané la réaction . C'est ce que j’appelle le mou . quand vous tourner par exemple, vous sentez que la voiture ne réagit pas tout de suite , il faut attendre 150ms .
Par contre une fois la fréquence de mise à jour rabaissé a 50ms ( 40ms pour être précis) , j'ai eu que des remarques sur la réactivité ; Je précise que c’était des personnes extérieures au projet , donc totalement objectives . Mais moi même je sentais fortement cette latence de 150ms ; c'est pour cela que j'aimerais me rapproché des 50ms . voir même encore moins si on voit faire des moyennes ou autres pour le futur . par exemple ; car une méthode pour palier a des erreurs est aussi le moyennage ! d’après mes recherches dans le domaine .
Pour être objectif, il aurait fallu que ni vous ni les opérateurs ne connaissent la fréquence utilisée.
Par exemple, un autre expérimentateur tire un nombre au hasard et règle la fréquence à votre insu en fonction, puis vous confie le véhicule, strictement sans rien dire ou laisser paraitre. Le mieux est de passer par une trappe qui empêche que vous puissiez voir son visage.
Il note le numéro de l'essai et ce qu'il a réglé.

Vous, vous faites faire le test au pilote et vous notez ses impressions, en face du N° du test.

Ensuite on dépouille, ce qui n'est pas aussi simple que ça.

Et je réitère la question : Que se passe-t-il à 8 T/s ? à 10 T/s ? à 15 T/s ?
 

dje8269

Senior Member
Pouvez-vous détailler le contenu de ces 5 octets, en particulier en corrélation avec les 2 modes de pilotage (avec et sans headtracker)
et les valeurs numériques mini et maxi transmises ?
Vous parlez bien du proto ?

Il y avait b0 et b1 ( les deux cotes a cotes) , pour les TOR .
b3 pour le moteur ( josytick de gauche , mouvement haut/bas ) valeur adc allant de 0 à 255 ( 30 à 220 en fait grosso modo)
b5 pour la direction ( joystick de droit, mouvement gauche/droite) pareil que pour le moteur valeur ADc allant de 0 a 255
et b7 pour la camera (joystick de gauche, mouvement droite/gauche) valeur ADC aussi .
 

BESQUEUT

Senior Member
Ce sujet a traiter sur de nombreuses pages ;

En fait le point délicat c’était d'effectuer une tache , quand une commande était bloquée .

On utilisait le Rfin . qui est bloquante ; donc quand on reçois plus rien, le picaxe ne fait que attendre et rien d'autre!!!

la solution fut été complexe . Un picaxe dédié a la réception par RFin en esclave . Un autre picaxe en maitre recevait en hi2C les données de l'esclave. Quand l'esclave venait posé les données sur le maitre il met un flag . Si ce flag n’était pas recu pendant un certain temps c'est que le picaxe esclave n'avait pas mis a jour les données et donc était bloquer . Merci à PieM .

Je crosi me souvenir que d'autres solutions aurit pus etre envisagés , mais la partie hard était deja figés ; c'est pour ca , que je voudrais bien définir la meilleure façon de faire avant . Mais je pense qu'avec ces modules ca devrait etre plus aisé
Dans le genre tordu, c'est puissant !

Mais bon, avec un timeout, le serin n'est pas bloquant. Et on pourrait aussi utiliser le background receive.
Donc un seul Picaxe peut faire ça sans aucun problème, par exemple tout bêtement en utilisant l'option address du serin.
 

BESQUEUT

Senior Member
Vous parlez bien du proto ?
Il y avait b0 et b1 ( les deux cotes a cotes) , pour les TOR ..
Oui c'est ça. Il y a 16 TOR ?
Il doivent être mis à jour avec la même réactivité que le pilotage ?
Tout les combien de temps ils sont susceptibles de changer ?

Suivant la position d'un inter, il est possible qu'il n'y ait pas d'info pour la caméra. C'est bien ça ?
 

dje8269

Senior Member
Oui c'est ça. Il y a 16 TOR ?
Il y en avait 9 , que j'a ireduis a 8 pour rentrer sur un seul octet ; b1 était la en secours au cas ou j'en ai besoin . Et vous savez , j'ai finis par rajouter 2 TOR j'etais a 11 ( avec un inter pour activer le back et un autre pour le Headt racker).

Il doivent être mis à jour avec la même réactivité que le pilotage ?
Non , ca c'est la partie cool . seul le pilotage de l'engin requiert le maximum de réactivité et un peu pour le pilotage de la caméra aussi. Le reste n'est pas prioritaire .

Tout les combien de temps ils sont susceptibles de changer ?
Pas souvent, impossible a dire , il s'agit d'allumer la video, ou de piloter la camera , ou d'allumer les phares par exemple . aucune réactivité nécessaire . je propose de faire comme j'avais fais sur le proto . A savoir d'envoyre les infos seulement quand y touche ! . pour cela il faudra détecter un changement .

Suivant la position d'un inter, il est possible qu'il n'y ait pas d'info pour la caméra. C'est bien ça ?
En fait deux interrupteurs . Un BP , pour piloter la camera disons en mode rapide (avec retour en position initiale) .
et un inter a bascule , permettant de passer en mode surveillance , et de piloter la camera d'un autre façon . ( sans retour en position initiale)
 

dje8269

Senior Member
Actuellement je m'entraine avec ces modules ;

Voici une erreur qui surviens de temps en temps amis rarement , genre 1 fois sur 100 aprox .
la pause en emission est de 100ms.

188-0-65-66-67-68-69-70
0-65-66-67-68-69-70-190
191-0-65-66-67-68-69-70
|
|
|
|
214-0-65-66-67-68-69-70
0-65-66-67-68-69-70-216
217-0-65-66-67-68-69-70
On voit bien que la première valeur a sauter , créant ainsi un décalage et la première valeur de la trame suivante se retrouve a la fin de la précédente .
Y'aurai-t-il un moyen d’empêcher le fait de raté la première valeur ?
 

BESQUEUT

Senior Member
Je propose 3 octets : b1,b2 et b3

Si b1<30, alors b2 et b3 contiennent les TOR
Si 30<b1<180 alors b1 est la direction, b2 la vitesse et b3 la camera
Si b1>180 : ce que vous voulez pour usage ultérieur...

Ce qui nous fait 15 octets par trame, soit 40 T/s à 4800 bauds avec un duty à 100% (impossible à cause des télémesures et des retry)
20 T/s à 50%
10 T/S à 25 %

Et je réitère la question : Que se passe-t-il à 8 T/s ? à 10 T/s ? à 15 T/s ?
 

BESQUEUT

Senior Member
... Mais moi même je sentais fortement cette latence de 150ms ; c'est pour cela que j'aimerais me rapproché des 50ms . voir même encore moins si on voit faire des moyennes ou autres pour le futur . par exemple ; car une méthode pour palier a des erreurs est aussi le moyennage ! d&#8217;après mes recherches dans le domaine .
Il y a un protocole bien plus simple pour les tests en double aveugle :
C'est le Picaxe qui tire au hasard un nombre à chaque essai et règle sa fréquence en fonction. Il mémorise le réglage effectué.

Vous faites n essais en notant vos observations en face du numéro d'essai.
A la fin, le Picaxe vous dévoile quel réglage il a fait pour chaque essai.

Le moyennage est une méthode de barbare aussi bien pour "adoucir" la direction (cas du headtracker en particulier) que pour pallier aux erreurs de transmission.
Il est bien plus performant de travailler en différentiel.
Dans ce cas, il est possible de piloter l'engin avec un seul octet par trame !
Mais ça n'a pas un intérêt grandiose à cause des 12 octets que rajoute le transceiver...

Quand je dis méthode de barbare, c'est au sens où ça conduit à consommer encore plus de bande passante alors qu'en fait il y a moins d'information utile.
Au contraire, la méthode différentielle profite du fait qu'il y a moins d'information utile pour diminuer la bande passante.

Il y a plein de raisons pour utiliser le moins possible de bande passante, en plus de la légalité et de l'échauffement :
- en cas de difficultés de transmission, le transceiver peut être réglé pour réitérer sa transmission. Mais évidement la bande passante est dégradée,
- on peut aussi diminuer la vitesse à 2400 voire 1200 bauds pour porter plus loin et/ ou récupérer une perte de communication.
- plus le duty/cycle est faible, moins il y a de probabilité d'être parasité,
- en particulier, avec un duty à 100% la moindre parasite est fatale,
- plus le duty cycle est important et donc plus la bande passante est importante, plus il est difficile de recevoir les données.

C'est pour ça qu'il faut raisonner dans l'autre sens :

- de quelle bande passante avez-vous réellement besoin au minimum ? (et non au maximum ce qui ne veut rien dire, sauf si vous vendez des abonnement Internet...)
 
Last edited:

dje8269

Senior Member
Je propose 3 octets : b1,b2 et b3

Si b1<30, alors b2 et b3 contiennent les TOR
Si 30<b1<180 alors b1 est la direction, b2 la vitesse et b3 la camera
Si b1>180 : ce que vous voulez pour usage ultérieur...
Le hic quand on parle du proto et du VHL futur , c'est qu'on s'embrouille nous même. La vous me parlez du futur , alors que je ai decrit le proto !

Le futur les 2 joysticks avec leurs 4 direction seront utilisés . contre seulement 3 avec le proto .

Perso , pour une fois , c'est moi qui vais ralentir les choses , comme quoi, vous avez un effet positif sur moi lol . La chose ne serait pas très différente du proto . sauf que de temps a autres on peut rajouter une trame pour les TOR ;. et du temps pour la réception de la télémétrie ;

PieM avait bien décrit cela ;
Dans le sens télecommande -> VHL
un flux prioritaire sur tous , et qui doit être le plus fréquent possible . les mouvements du VHL . avant arrière droite gauche . rien que ca je ne sais pas combien d'octet il faudra. certainement 2 pour les deux valeurs analogiques des potars des joysticks .
A partir de la , de temps en temps, on envoie une deuxième trame avec les TOR et les options.

Dans le sens VHL -> télécommade :

La priorité est faite sur la réception des données de mouvement du VHL . puis de traitement des TOR, puis de l'envoie d'infos sur la télémétrie de temps en temps
 

BESQUEUT

Senior Member
Le futur les 2 joysticks avec leurs 4 direction seront utilisés . contre seulement 3 avec le proto .
Selon #128 du thread principal :
mode conduite : seulement 2 valeurs : direction et vitesse

mode camera : 2 valeurs H et V + le zoom + "réglage du contraste ou luminosité ou sensibilité"

Pas sur qu'il faille régler la luminosité 10 fois /seconde... Pas sur qu'il y ait 256 niveaux de zoom...

Je maintiens que 3 octets/trame suffisent, 1 seul en mode différentiel.


Quoi qu'il en soit, le but de ce thread est de tester les transceivers.
Pour ça, on a besoin de savoir à peu prêt combien d'octets on doit envoyer dans chaque sens et à quel fréquence pour que les tests soient représentatifs.
On a aussi besoin de l'architecture.

Où en êtes vous question architecture ?
Et je réitère la question : Que se passe-t-il à 8 T/s ? à 10 T/s ? à 15 T/s ?
 
Last edited:

dje8269

Senior Member
mode conduite : seulement 2 valeurs : direction et vitesse
Oui j'ai beau reflechir ,la tout de suite, je ne vois que ca !

mode camera : 2 valeurs H et V + le zoom + "réglage du contraste ou luminosité ou sensibilité"
Su qui nous fait 4 octets !

Pas sur qu'il faille régler la luminosité 10 fois /seconde...
no c'est sur , vous avez raison . mais autant que ca fasse partie de la même trame que les commandes !

Je maintiens que 3 octets/s suffisent, 1 seul en mode différentiel.
Oui c'est pas loufoque ! mais par 3 octets/s ; mais par trame non ?

Où en êtes vous question architecture ?
C'est à dire, pour le moment rien de figé !

Votre idée est séduisante avec un µC pour l&#8217;émission et un autre pour la réception .

Et je réitère la question : Que se passe-t-il à 8 T/s ? à 10 T/s ? à 15 T/s ?
Ben plus on as de trame par seconde meilleur est la réactivité ; Je maintiens qu'a 50ms on a l'impression que ca reagis immediatement , et qu'a 150 ms on sent un leger mou ! . entre les deux on sent moins le mou plus on a de trame !

PS : avertissez quand vosu allez dormir !
 

BESQUEUT

Senior Member
Je maintiens qu'a 50ms on a l'impression que ca reagis immediatement , et qu'a 150 ms on sent un leger mou ! . entre les deux on sent moins le mou plus on a de trame !

PS : avertissez quand vosu allez dormir !
Bon ben disons 140 ms puisque qu'on ne commence à sentir le mou qu'à 150 ms...

Je vous assure qu'il faut faire des tests objectifs.
Mais allons dormir d'abord...
 

PieM

Senior Member
Avec l'immense respect que j'ai pour Georges et PieM, ce problème de duty cycle, est , de mon point de vue , un faux problème ; De part le fait , que la législation ben voila quoi !!!
C"est vrai que quand on dépense plus de 300&#8364; dans des transceivers non équipés de saut de fréquence pour assurer une com permanente, on peut s'assoir sur la règlementation! Et comme cette règlementation est destinée à partager la fréquence dans le respect des autres, on va pas s'embêter avec ça! Un peu lamentable de lire ça dans un forum...
(Cet avis mettant fin à toute intrusion de ma part sur le sujet.)
 

dje8269

Senior Member
Bonjour,
C"est vrai que quand on dépense plus de 300&#8364; dans des transceivers non équipés de saut de fréquence pour assurer une com permanente, on peut s'assoir sur la règlementation!
Il aurait fallu le savoir ! un lien pour en trouver ?

destinée à partager la fréquence dans le respect des autres, on va pas s'embêter avec ça
reprenons ton exemple de la route . les policiers mettant les sirènes/gyro roule bien plus que 130km/h sur autoroute . c'est un peu le même principe !
Ca n'avait pas déranger avec le proto ?
même l'emetteur vidéo sera hors des clous a mon avis !
Mais je le redis ce n'est pas forcement a être employé en France .

(Cet avis mettant fin à toute intrusion de ma part sur le sujet.)
Je le déplore fortement, mais je m'en doutais :D .

Je suis le premier impacté étant donné que ton expérience et ta vision des choses m'aurait été d'une grande aide . Surtout que la on ne parle que des transceiver, il y as tellement de truc a faire après ! N&#8217;hésite pas a faire une intrusion si le c&#339;ur t'en dis, une fois que la ranc&#339;ur envers moi sera retombée et l&#8217;énervement face à ma bêtise supportable ! Si on ne peut même plus avoir de désaccord, sans que quelqu'un sen aille c'est moche !
 

BESQUEUT

Senior Member
On voit bien que la première valeur a sauter , créant ainsi un décalage et la première valeur de la trame suivante se retrouve a la fin de la précédente .
Y'aurai-t-il un moyen d&#8217;empêcher le fait de raté la première valeur ?
C'est juste que le Picaxe en réception n'est pas assez rapide.
Avec un duty cycle raisonnable (voir #170, qui va dans le même sens que PieM et d'autres...)
et un Picaxe rapide, ça ne devrait plus se produire.

En outre, tel que le transceiver de réception est configuré par défaut, le CTS n'est pas pris en compte.
Voir notice au paragraphe 11.15 CfgFlags, valeur par défaut 512
ce qui signifie que seul le 9ième bit est monté, ce qui valide l'allumage de la LED d'activité RF.
Avec le logiciel et le câble ad hoc, on devrait pouvoir améliorer ce point.

Toujours avec ce logiciel, il est est possible de gagner 5ms de réactivité sur l'UART à l'émission.


Si je trouve un peu de temps, je vais ouvrir un thread pour évaluer ce qui est réellement nécessaire question réactivité.
Ça pourra être utile à d'autres, et de toutes façons je ne supporte pas les croyances irrationnelles.

... quand on dépense plus de 300&#8364; dans des transceivers non équipés de saut de fréquence pour assurer une com permanente,... cette règlementation est destinée à partager la fréquence dans le respect des autres,...
Evitons de polémiquer, mais il me semble que ces transceivers peuvent faire pas mal de chose pour éviter de monopoliser la fréquence :
- j'ai déjà dit qu'un duty cycle de 100% est stupide, et qu'il vaut mieux une bande passante la plus faible possible (#170)
- si j'ai bien compris, l'étalement de spectre par saut de fréquence sert à libérer régulièrement chaque fréquence pour que les dispositifs qui ne savent pas le faire puissent communiquer dans les créneaux laissés vacants. Ceci n'est pas automatique avec ces transceivers, mais peut être programmé.
- en outre, la fonction CCA (11.22) permet de s'assurer que la fréquence est libre avant d'émettre.
 
Last edited:

dje8269

Senior Member
C'est juste que le Picaxe en réception n'est pas assez rapide.
Avec un Duty cycle raisonnable
D'accord ; merci ! . car hier soir après notre discussion j'ai quand même essayé de rajouter un "qualifer" histoire de maitriser le départ d'une trame ; ben j'ia même pas reussis . rien ne s'affichait lol ;

Sans parler de duty cylce ou même de vitesse : je vous propose de réfléchir a un programme , permettant de réalisation un dialogue entre nos transciever ? pour simuler les comm dans un sens et dans l'autre ! Ensuite il faudrait tester la perte de com ! .

Voulez-vous que je mette sur plaque d'essai deux picaxe pour transceiver ? genre double coeur ? c'est la classe de dire ca , ca fait trés vendeur, PieM rigolerais !. système de communication double-coeur mdr
 

BESQUEUT

Senior Member
Sans parler de duty cylce ou même de vitesse : je vous propose de réfléchir a un programme , permettant de réalisation un dialogue entre nos transciever ? pour simuler les comm dans un sens et dans l'autre ! Ensuite il faudrait tester la perte de com ! .

Voulez-vous que je mette sur plaque d'essai deux picaxe pour transceiver ? genre double coeur ? c'est la classe de dire ca , ca fait trés vendeur, PieM rigolerais !. système de communication double-coeur mdr
1) Valider une architecture (merci de désigner chaque µ et chaque flux par un numéro, ce qui facilite les explications...)
2) schéma de câblage,
3) plaques d'essais ou véroboard,
4) objectifs
5) programmes
6) Câble et logiciel de réglage des transceivers,
7) optimisation des réglages et des programmes

Si vous voulez juste tester la perte de com, c'est faisable sur la plateforme actuelle :
- ajoutez le champ address sur le serin, ainsi qu'une sub-routine qui allume une LED et/ou envoie un sertxd
- de temps en temps, éteignez l'émetteur.
 
Last edited:

dje8269

Senior Member
Si vous voulez juste tester la perte de com, c'est faisable sur la plateforme actuelle :
- ajoutez le champ address sur le serin, ainsi qu'une sub-routine qui allume une LED et/ou envoie un sertxd
- de temps en temps, éteignez l'émetteur.
La réaction n'est pas celle attendu

En effet on reste bloqué une fois la sous routine effectuée ?

Programme emission inchangé:
Code:
[color=Navy]#PICAXE [/color][color=Black]14M2[/color]

[color=Green]'####################################   Configuration   ####################################[/color]
[color=Blue]Symbol BP [/color][color=DarkCyan]= [/color][color=Blue]C.3
Symbol led [/color][color=DarkCyan]= [/color][color=Blue]C.1
Symbol [/color][color=Purple]RTS [/color][color=DarkCyan]= [/color][color=Purple]pinB.2[/color]
[color=Blue]Symbol CTS [/color][color=DarkCyan]= [/color][color=Blue]B.5[/color]
[color=Green]'####################################   Initialisation   ####################################[/color]
[color=Blue]setfreq M8
pause [/color][color=Navy]1000[/color]
[color=Green]'####################################   Programme Principal   ####################################[/color]
[color=Blue]do

if [/color][color=Purple]RTS [/color][color=DarkCyan]= [/color][color=Navy]0 [/color][color=Blue]then
      inc [/color][color=Purple]w1
      [/color][color=Blue]serout B.3[/color][color=Black],[/color][color=Blue]T9600_8[/color][color=Black],[/color][color=Blue]([/color][color=Purple]b0[/color][color=Black],[/color][color=Purple]b1[/color][color=Black],[/color][color=Red]"A"[/color][color=Black],[/color][color=Red]"B"[/color][color=Black],[/color][color=Red]"C"[/color][color=Black],[/color][color=Red]"D"[/color][color=Black],[/color][color=Red]"E"[/color][color=Black],[/color][color=Red]"F"[/color][color=Blue])
      pause [/color][color=Navy]100[/color]
[color=Blue]endif

loop[/color]
Programme reception :

Ajout d'une adresse de sous-routine en cas de dépassement de time-out .
La sous routine effectue un clignotement d'une led .
puis devrait revenir au programme principal, et re-clignoter si rien n'est reçu ?

Si je rallume l&#8217;émetteur , la réception est encore bien , mais quand je ré-eteins la sous routine ne se lance pas .

reception:
Code:
[color=Navy]#PICAXE [/color][color=Black]14M2[/color]

[color=Green]'####################################   Configuration   ####################################[/color]
[color=Blue]Symbol BP [/color][color=DarkCyan]= [/color][color=Blue]C.3
Symbol led [/color][color=DarkCyan]= [/color][color=Blue]C.4
Symbol [/color][color=Purple]RTS [/color][color=DarkCyan]= [/color][color=Purple]pinB.2[/color]
[color=Blue]Symbol CTS [/color][color=DarkCyan]= [/color][color=Blue]B.5[/color]


[color=Green]'####################################   Initialisation   ####################################[/color]
[color=Blue]setfreq M8
pause [/color][color=Navy]1000[/color]

[color=Green]'####################################   Programme Principal   ####################################
      [/color]
[color=Blue]do

      serin [PLAIN][[/PLAIN][/color][color=Navy]150[/color][color=Black], alerte[/color][color=Blue][PLAIN]][/PLAIN][/color][color=Black],[/color][color=Blue]B.1[/color][color=Black],[/color][color=Blue]T9600_8[/color][color=Black], [/color][color=Purple]b0[/color][color=Black],[/color][color=Purple]b1[/color][color=Black],[/color][color=Purple]b2[/color][color=Black],[/color][color=Purple]b3[/color][color=Black],[/color][color=Purple]b4[/color][color=Black],[/color][color=Purple]b5[/color][color=Black],[/color][color=Purple]b6[/color][color=Black],[/color][color=Purple]b7

      [/color][color=Blue]sertxd ([/color][color=Black]#[/color][color=Purple]b0[/color][color=Black],[/color][color=Red]"-"[/color][color=Black],#[/color][color=Purple]b1[/color][color=Black],[/color][color=Red]"-"[/color][color=Black],#[/color][color=Purple]b2[/color][color=Black],[/color][color=Red]"-"[/color][color=Black],#[/color][color=Purple]b3[/color][color=Black],[/color][color=Red]"-"[/color][color=Black],#[/color][color=Purple]b4[/color][color=Black],[/color][color=Red]"-"[/color][color=Black],#[/color][color=Purple]b5[/color][color=Black],[/color][color=Red]"-"[/color][color=Black],#[/color][color=Purple]b6[/color][color=Black],[/color][color=Red]"-"[/color][color=Black],#[/color][color=Purple]b7[/color][color=Black],[/color][color=Navy]13[/color][color=Black],[/color][color=Navy]10[/color][color=Blue])

loop[/color]

[color=Black]alerte:[/color]
[color=Blue]for [/color][color=Purple]b17 [/color][color=DarkCyan]= [/color][color=Navy]0 [/color][color=Blue]to [/color][color=Navy]5
      [/color][color=Blue]high led
      pause [/color][color=Navy]200
      [/color][color=Blue]low led
      pause [/color][color=Navy]200[/color]
[color=Blue]next  

return[/color]
 

BESQUEUT

Senior Member
Le timeout me semble un peu court, mais ce n'est pas ça le problème.
la doc n'est pas très claire, mais il semblerait que address corresponde à un GOTO et non à un GOSUB.
(et bien évidement RevEd ne fourni pas d'exemple...)
Voir par exemple ce thread : serin+address
Donc il faudrait faire un truc du genre :
Code:
do
BOUCLE:
      serin [150, alerte],B.1,T9600_8, b0,b1,b2,b3,b4,b5,b6,b7

      sertxd (#b0,"-",#b1,"-",#b2,"-",#b3,"-",#b4,"-",#b5,"-",#b6,"-",#b7,13,10)

loop

alerte:
for b17 = 0 to 5
      high led
      pause 200
      low led
      pause 200
next  

GOTO BOUCLE ' J'ai horreur des GOTO, mais là : pas le choix !
 

BESQUEUT

Senior Member
Ben ça à l'air pas mal : LCD I2C 3V
Ça doit pas être si facile à mettre en oeuvre, mais sur le papier, c'est censé marcher directement sur le Picaxe en I2C.
 

dje8269

Senior Member
Ça doit pas être si facile à mettre en oeuvre, mais sur le papier, c'est censé marcher directement sur le Picaxe en I2C.
Oui, car ca m&#8217;étonnait aussi que ce soit si facile . Car les caractères sont déjà configurer apparemment . si vous me validez je vais en prendre une poignée

Que pensez vous d'une platine de réception comme ceci ? pour commencer

Platine test recepteur 2 picaxe.png
 

BESQUEUT

Senior Member
MàJ
Je sais pas si ça vous conviendrais, j'essaye de faire du mieux que je peux .
Ben c'est pour vous avant tout !
Mes remarques dans le thread ad hoc.

Ben oui : c'est le même que sur la boutique FTDI. Par contre, je déconseille la prise DB9 qui peut prêter à confusion avec un cordon RS232/15V
Un petit connecteur à 3 broches avec détrompeur mâle + femelle
prends moins de place sur le CI et fait tout aussi bien l'affaire, tout en coûtant bien moins cher.
 

BESQUEUT

Senior Member
Je ne les ai pas vues !
Là c'est fait...

Ce qui est important, c'est de bien identifier ce que fait chaque µ, en particulier sur les liens serie, I2C et SPI, et qui est à l'initiative de chaque flux.
De cette façon, les tests pourront être conduits dans des conditions représentatives :
- taille et fréquence des trames représentatives,
- flux I2C simultanés susceptibles de perturber la réception des données,
- flux d'information sur le niveau HF si retenu,
- mécanismes fail-safe
 
Last edited:

dje8269

Senior Member
Bonjour,

Je suis toujours en train de m'entrainer et de tester ces modules, car c'est le c&#339;ur du système . c'est la partie qui devra être le plus optimiser . j'ai rencontré tellement de problème avec le proto la dessus , que je ne voudra pas refaire les même erreurs .

Avant de passer a la seconde de mes tests , a ssavoir recevoir sur un picaxe et emettre avec un autre . Je souhaite comprendre ce fameux CTS .

J'ai donc creer deux programmes .

1 programme disons "répéteur" , qui recoit une donnée la modifie et la re-envoie .
le second programme: envoie une donnée au repeteur et l'affiche avant transformation . puis recoit cette donnée transformée et l'affiche .

Pour résumé , j'envoie une donnée a répéteur que j'affiche , le répéteur la reçoit, la modifie, et la re-envoie, puis je kla receptionne et la re-affiche apres transformtion .

MA question : ou mettre un CTS ?

Répéteur:
Code:
[color=Navy]#PICAXE [/color][color=Black]14M2[/color]

[color=Green]'####################################   Configuration   ####################################[/color]
[color=Blue]Symbol [/color][color=Purple]BP [/color][color=DarkCyan]= [/color][color=Purple]pinC.3[/color]
[color=Blue]Symbol led [/color][color=DarkCyan]= [/color][color=Blue]C.1
Symbol [/color][color=Purple]RTS [/color][color=DarkCyan]= [/color][color=Purple]pinB.2[/color]
[color=Blue]Symbol CTS [/color][color=DarkCyan]= [/color][color=Blue]B.5[/color]
[color=Green]'####################################   Initialisation   ####################################[/color]
[color=Blue]setfreq M8
pause [/color][color=Navy]1000[/color]
[color=Green]'####################################   Programme Principal   ####################################[/color]
[color=Blue]do
      
serin B.1[/color][color=Black],[/color][color=Blue]T9600_8[/color][color=Black], [/color][color=Purple]b0[/color][color=Black],[/color][color=Purple]b1[/color][color=Black],[/color][color=Purple]b2[/color][color=Black],[/color][color=Purple]b3[/color][color=Black],[/color][color=Purple]b4[/color][color=Black],[/color][color=Purple]b5[/color][color=Black],[/color][color=Purple]b6[/color][color=Black],[/color][color=Purple]b7[/color]

[color=Blue]if [/color][color=Purple]RTS [/color][color=DarkCyan]= [/color][color=Navy]0 [/color][color=Blue]then
      inc [/color][color=Purple]w0
     
            [/color][color=Blue]serout B.3[/color][color=Black],[/color][color=Blue]T9600_8[/color][color=Black],[/color][color=Blue]([/color][color=Purple]b0[/color][color=Black],[/color][color=Purple]b1[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Blue])
            pause [/color][color=Navy]100
      [/color]
[color=Blue]endif

loop[/color]
Programme afficheur :
Code:
[color=Navy]#PICAXE [/color][color=Black]14M2[/color]

[color=Green]'####################################   Configuration   ####################################[/color]
[color=Blue]Symbol [/color][color=Purple]BP [/color][color=DarkCyan]= [/color][color=Purple]pinC.3[/color]
[color=Blue]Symbol led [/color][color=DarkCyan]= [/color][color=Blue]C.4
Symbol [/color][color=Purple]RTS [/color][color=DarkCyan]= [/color][color=Purple]pinB.2[/color]
[color=Blue]Symbol CTS [/color][color=DarkCyan]= [/color][color=Blue]B.5[/color]


[color=Green]'####################################   Initialisation   ####################################[/color]
[color=Blue]setfreq M8
pause [/color][color=Navy]1000[/color]

[color=Green]'####################################   Programme Principal   ####################################[/color]
[color=Purple]b0 [/color][color=DarkCyan]=[/color][color=Navy]0[/color]
[color=Purple]b1[/color][color=DarkCyan]=[/color][color=Navy]1[/color]

[color=Blue]do

      if [/color][color=Purple]RTS [/color][color=DarkCyan]= [/color][color=Navy]0 [/color][color=Blue]then
                        
                  serout B.3[/color][color=Black],[/color][color=Blue]T9600_8[/color][color=Black],[/color][color=Blue]([/color][color=Purple]b0[/color][color=Black],[/color][color=Purple]b1[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Black],[/color][color=Navy]0[/color][color=Blue])
                  pause [/color][color=Navy]100
      
      [/color][color=Blue]endif

      sertxd ([/color][color=Red]"avant = "[/color][color=Black],#[/color][color=Purple]b0[/color][color=Black],[/color][color=Red]"-"[/color][color=Black],#[/color][color=Purple]b1[/color][color=Black],[/color][color=Red]"----------------"[/color][color=Blue])

      serin [PLAIN][[/PLAIN][/color][color=Navy]100[/color][color=Blue][PLAIN]][/PLAIN][/color][color=Black],[/color][color=Blue]B.1[/color][color=Black],[/color][color=Blue]T9600_8[/color][color=Black], [/color][color=Purple]b0[/color][color=Black],[/color][color=Purple]b1[/color][color=Black],[/color][color=Purple]b2[/color][color=Black],[/color][color=Purple]b3[/color][color=Black],[/color][color=Purple]b4[/color][color=Black],[/color][color=Purple]b5[/color][color=Black],[/color][color=Purple]b6[/color][color=Black],[/color][color=Purple]b7

      [/color][color=Blue]sertxd ([/color][color=Red]"Apres = "[/color][color=Black],#[/color][color=Purple]b0[/color][color=Black],[/color][color=Red]"-"[/color][color=Black],#[/color][color=Purple]b1[/color][color=Black],[/color][color=Navy]13[/color][color=Black],[/color][color=Navy]10[/color][color=Blue])
      
loop[/color]
résultat :
avant = 0-1----------------Apres = 1-1
avant = 1-1----------------Apres = 2-1
avant = 2-1----------------Apres = 3-1
avant = 3-1----------------Apres = 4-1
avant = 4-1----------------Apres = 5-1
avant = 5-1----------------Apres = 6-1
avant = 6-1----------------Apres = 7-1
avant = 7-1----------------Apres = 8-1
avant = 8-1----------------Apres = 9-1
avant = 9-1----------------Apres = 10-1
avant = 10-1----------------Apres = 11-1
avant = 11-1----------------Apres = 12-1
avant = 12-1----------------Apres = 13-1
avant = 13-1----------------Apres = 14-1
avant = 14-1----------------Apres = 15-1
avant = 15-1----------------Apres = 16-1
avant = 16-1----------------Apres = 17-1
avant = 17-1----------------Apres = 18-1
avant = 18-1----------------Apres = 19-1
avant = 19-1----------------Apres = 20-1
avant = 20-1----------------Apres = 21-1
avant = 21-1----------------Apres = 22-1
avant = 22-1----------------Apres = 23-1
avant = 23-1----------------Apres = 24-1
avant = 24-1----------------Apres = 25-1
avant = 25-1----------------Apres = 26-1
avant = 26-1----------------Apres = 27-1
avant = 27-1----------------Apres = 28-1
avant = 28-1----------------Apres = 29-1
avant = 29-1----------------Apres = 30-1
avant = 30-1----------------Apres = 31-1
avant = 31-1----------------Apres = 32-1
avant = 32-1----------------Apres = 33-1
avant = 33-1----------------Apres = 34-1
avant = 34-1----------------Apres = 35-1
avant = 35-1----------------Apres = 36-1
avant = 36-1----------------Apres = 37-1
avant = 37-1----------------Apres = 38-1
avant = 38-1----------------Apres = 39-1
avant = 39-1----------------Apres = 40-1
C'est donc parfait , disons que le fonctionnement est conforme a mon attente.

Vous remarquerez que je n'ai aps de timeout sur le serin du répéteur , sinon le resultat est eratique . Si j'en met un ,soit il incremetne deux fois soit pas du tout , et des fois ca tombe juste . sans time out , cela me permet de bien cadencé mes envois et mes recetion .

N'y aurait-il pas une fonction pour synchroniser des transceiver?
 

dje8269

Senior Member
Autre chose ,

On regle le transceiver par logiciel, mais il me semble qu'on puisse le faire sans ?

En injectant les données directement dans les registres au démarrage non ?


11 User settings
The non-volatile settings listed in the following table canbe modified by means of specific commands in the configuration mode (CMD_SET_REQUEST, see 10.6) of the module
or by using the Windows software "ACC V3". These parameters are stored permanently in the module's flash memory.
Mais je ne me risquerai pas a changer la config , sans l'appui de quelqu'un qui connait !
 

BESQUEUT

Senior Member
Je souhaite comprendre ce fameux CTS .
Relisez #178
On regle le transceiver par logiciel, mais il me semble qu'on puisse le faire sans ?
En injectant les données directement dans les registres au démarrage non ?
OUI, au démarrage ou plus tard
Mais je ne me risquerai pas a changer la config , sans l'appui de quelqu'un qui connait !
Même en supposant que vous trouviez quelqu'un capable de vous conseiller dans ce domaine, imaginez ce qui va se passer si suite à une erreur du programme vous ne modifiez pas le registre prévu ?
Par contre le programme ad hoc est forcément exempt de bug grossier. Donc vous pouvez l'utiliser sans crainte. En outre, il permet la mise à jour du firmware.
 

dje8269

Senior Member
Relisez #178
Merci

Même en supposant que vous trouviez quelqu'un capable de vous conseiller dans ce domaine, imaginez ce qui va se passer si suite à une erreur du programme vous ne modifiez pas le registre prévu ?
Par contre le programme ad hoc est forcément exempt de bug grossier. Donc vous pouvez l'utiliser sans crainte. En outre, il permet la mise à jour du firmware.
En cas de probléme il y a une commande reset d'aprs ce que j'ai cru comprendre. Ils ont prévus les mecs comme moi lol

J&#8217;aurais juste voulus tester en augmentant le baud-rate !.

Afin d'essayer de diminuer le temps de pause après un serout, pour voir le résultat .

A l'analyseur logique , le temps d'une trame dure 8 ms .mais le temps entre deux trame, ca la ou le bat blesse .
 

BESQUEUT

Senior Member
1 programme disons "répéteur" , qui recoit une donnée la modifie et la re-envoie .
le second programme: envoie une donnée au repeteur et l'affiche avant transformation . puis recoit cette donnée transformée et l'affiche .
C'est toujours la même question : qui a l'initiative du flux ?
Le problème, c'est que le répéteur introduit une pause 100 dans son cycle de réception. C'est un miracle que ça marche...
Dès que vous ajoutez quoi que ce soit (genre un timeout) forcément des trames sont perdues...
je ne vais pas vous demander de dessiner un chronogramme : c'est trop professionnel...
 
Last edited:

dje8269

Senior Member
je ne vais pas vous demander de dessiner un chronogramme : c'est trop professionnel...
Roohhhh l'ironie . mdr .

Moi je veux bien le faire , mais je ne serais pas quoi dessiné. Dans le coté professionnel, j'entends par la que vous demandez des choses que seul un pro a l'habitude faire, car c'est son métier . Moi j'apprends par test successif ;

Je pense que j'ai plus de chance d'y arriver en faisant 1000 tests , plutôt que de réfléchir a ce qu'il faut faire et ne faire que 5 test . Un peu comme une vache qui s&#8217;électrocute dans un pré . Ben imaginez que je suis la vache lol . je vais m&#8217;électrifier 1000 fois avant de trouver la sortie ; tandis que vous, vous réfléchissez en suivant le fil , et vous trouvez la sortie sans vous electrifiez ;
 

BESQUEUT

Senior Member
Ben c'est facile de comprendre que :
l'émetteur envoie une trame toutes les 100ms
Le répéteur reçoit la trame, incrémente et la renvoie, puis attends 100 ms

Donc à la trame suivante, à peine il est à nouveau en réception qu'il se prends une nouvelle trame dans la figure...
Heureusement qu'il y a des tampons à l'émission et à la réception.
Mais même avec ça, si le répéteur ne vide pas le tampon assez vite, il va y avoir saturation...
Le miracle, c'est qu&#8217;apparemment il y arrive. Ça doit être limite et c'est pour ça qu'au moindre changement vous perdez des trames.

Mais pourquoi diable mettre une tempo dans un programme de réception ?
Ah oui : vous avez déjà répondu : par habitude...
Bon, ben... bonne électrocution...
 

dje8269

Senior Member
Le miracle, c'est qu&#8217;apparemment il y arrive. C'est doit être limite et c'est pour ça qu'au moindre changement vous perdez des trames.
Oi vous avez raison , au moindre changement dans n'importe quel timing, ca met la zizanie !

Mais pourquoi diable mettre une tempo dans un programme de réception ?
?? il n'y as pas de tempo pour la réception ? seulement pour l&#8217;émission !

Comment faire ce même programme plus proprement , et le plus rapidement , c'est a dire qu'il fonctionne sans pause ou la plus petite possible?

bonne électrocution...
Aïeee

Je cois que la pause est obligatoire a cause du sertxd qui prend du temps non ? donc a l&#8217;analyseur logique sans sertxd, peut etre que mes résultats seraient plus parlants ;
 
Top