Platine test pour module radio AMB8636

dje8269 · Jul 31, 2015

Ps : avec hserout je n'ai rien du tout.

Pour le moment je voudrais me concentrer sur l'émission et la réception avant de parler de vitesse ou autre.
Sur le prototype j'étais à 20 infos (50ms grossomodo) par seconde est la réactivité était top. Je voudrais réussir soit à faire mieux , soit aussi bien , en renforçant la fiabilité . Je ne sais pas si un code correcteur d'erreur vaut le coup d'être introduis , si on accuse réception de l'intégrité de la trame

BESQUEUT · Aug 1, 2015

Amélioration de la qualité (1)

dje8269 said:
Sur le prototype j'étais à 20 infos (50ms grossomodo) par seconde est la réactivité était top.
Je voudrais réussir soit à faire mieux , soit aussi bien , en renforçant la fiabilité .

Vous souhaiter améliorer la qualité, ce qui à mons sens est une bonne chose !
Retenez une seule chose :

Il n'est pas possible d'améliorer la qualité
de quelque chose qu'on ne sait pas mesurer.

Pour être plus précis :

Toute action visant à améliorer la qualité peut conduire à trois résultats :
- aucune incidence,
- amélioration de la qualité,
- détérioration de la qualité.

En l'absence de critère objectif de mesure de la qualité, vous ne saurez jamais dans quel cas vous vous trouvez.

dje8269 · Aug 1, 2015

Bonjour ,

Trés belle phrase .... .

Désolé , du coup je suis rentré plus tard que prévu hier soir. Les recherches reprennent de plus belle aujourd'hui !
Ma première interrogation ? pourquoi ca ne fonctionne pas avec hserout ? mauvaise config ?

BESQUEUT · Aug 1, 2015

Content que vous approuviez...
Donc :
Précisez vos critères de performance, votre protocole, et quelles sont vos mesures, on verra comment tenter d'améliorer.
Je vois un nouveau critère jamais pris en compte pour le moment : ce que les joueurs appellent le "lag" et que je traduirais par "décalage"
A partir du moment où les données sont buférisées, il peut exister un décalage sensible entre le moment où les données sont produites et celui où elles sont restituées.
Avec une trame de 6 octets, un débit de 20 trames par seconde et un buffer de 120 octets, on peut avoir une seconde de décalage, voir plus si on considère qu'il y a aussi un tampon à la réception...

dje8269 said:
mauvaise config ?

Je ne vois que ça.

PieM · Aug 1, 2015

Sur le prototype j'étais à 20 infos (50ms grossomodo) par seconde est la réactivité était top. Je voudrais réussir soit à faire mieux , soit aussi bien

J'ai dit dans un autre post qu'on mélangeait un peu tout et je persiste à le penser.

Dans ce projet, il y a une fonction principale qui est le pilotage de l'engin , en mode normal ( radiocommande + vidéo) ou en mode dégradé ( perte liaisons radio / panne => mode autonome)
Tout le reste est accessoire ou gadgets. En particulier la télémesure.

donc il y a deux flux radio essentiels: la vidéo (sens VHL > TELCDE) et la commande moteurs (sens TELCDE > VHL). ces deux flux sont prioritaires sur tout.
La télémesure, elle (sens VHL > TELCDE) n'a rien à faire avec le reste hormis le partage du transceiver. mais la fréquence de la liaison n'a absolument pas à être la même que celle liée au pilotage.
Elle aurait très bien pu se faire sur un autre système E/R indépendant. (ce qui aurait été plus simple hormis les pb de radio)
ça veut dire que si on fait une mise à jour des mesures toutes les secondes, le flux prioritaire ne sera perturbé que 50ms (pour reprendre les mêmes chiffres) ttes les secondes. donc sans effet sur la réactivité du pilotage.

En résumé;

[Télécommande] .............................................................. [ VHL ]

VIDEO ===========mode normal===================> VIDEO
PILOTAGE ==========mode normal=================> PILOTAGE <========[ Module mode dégradé ]
TELEMESURE <-------------------------------------------- TELEMESURE

ça veut dire aussi que la gestion de la télémesure doit être séparée de la fonction pilotage, et que le module mode dégradé (feed back) doit envoyer le même type d'info que la liaison radio au module pilotage.
Ce qui permet d'orienter le choix du lieu de traitement des infos.

dje8269 · Aug 1, 2015

Concernant le "lag" , je parlerais peut etre plus de latence ! .

La latence doit etre la plus petite possible . Une seconde clairement c'est pas possible . Cela signifierai que entre l'action d'un joystick et la réaction du VHL il s’écoule une seconde !!!

BESQUEUT · Aug 1, 2015

dje8269 said:
Concernant le "lag" , je parlerais peut etre plus de latence ! .
La latence doit etre la plus petite possible . Une seconde clairement c'est pas possible . Cela signifierai que entre l'action d'un joystick et la réaction du VHL il s’écoule une seconde !!!

Nous sommes biens d'accord : quel protocole de mesure ?
Même question pour les autres critères ?

PieM · Aug 1, 2015

Pour continuer le #45, quel intérêt au hserin qui risque de perturber une liaison éventuelle I2C sur le même µC.
je ne comprends pas trop pourquoi on utilise pas le contrôle de flux qui semble exister: on mets le RTS sur interruption et on reçoit les donnés après l'envoi du CTS.

BESQUEUT · Aug 1, 2015

PieM said:
Dans ce projet, il y a une fonction principale qui est le pilotage de l'engin , en mode normal ( radiocommande + vidéo) ou en mode dégradé ( perte liaisons radio / panne => mode autonome)
Tout le reste est accessoire ou gadgets. En particulier la télémesure.
donc il y a deux flux radio essentiels: la vidéo (sens VHL > TELCDE) et la commande moteurs (sens TELCDE > VHL). ces deux flux sont prioritaires sur tout.
La télémesure, elle (sens VHL > TELCDE) n'a rien à faire avec le reste hormis le partage du transceiver. mais la fréquence de la liaison n'a absolument pas à être la même que celle liée au pilotage.

Jusque là je suis d'accord. et c'est d'ailleurs le sens de l'architecture que j'ai proposé.
Le flux VIDEO est clairement à part.

PieM said:
ça veut dire que si on fait une mise à jour des mesures toutes les secondes, le flux prioritaire ne sera perturbé que 50ms (pour reprendre les mêmes chiffres) ttes les secondes. donc sans effet sur la réactivité du pilotage.

Je ne comprends pas : on est sur des flux différents et pas dans le même sens : pourquoi y aurait-il perturbation ?

PieM said:
En résumé;

[Télécommande] .............................................................. [ VHL ]

VIDEO ===========mode normal===================> VIDEO
PILOTAGE ==========mode normal=================> PILOTAGE <========[ Module mode dégradé ]
TELEMESURE <-------------------------------------------- TELEMESURE

ça veut dire aussi que la gestion de la télémesure doit être séparée de la fonction pilotage, et que le module mode dégradé (feed back) doit envoyer le même type d'info que la liaison radio au module pilotage.
Ce qui permet d'orienter le choix du lieu de traitement des infos.

Pour être cohérent avec la télémesure, la flèche du flux VIDEO devrait être dans l'autre sens.
Je ne suis pas certain d'avoir compris :
En cas de perte de réception, vous envisagez un module (physique, pas simplement une fonction logicielle) qui se substitue au transceiver pour fournir des données au module de réception des données coté véhicule (µ N°3 dans le post N°107 de l'autre Thread). C'est bien ça ?

NB : nous ne parlons plus du test de l'AMB8636 mais bien de la conception du véhicule.
Ce serait mieux de faire ça dans le thread ad hoc. Peut-être pourriez-vous faire une proposition d'architecture physique ?

PieM · Aug 1, 2015

pourquoi y aurait-il perturbation ?

Le transceiver est en full duplex ? et aucune interférence possible dans les accès ?

En cas de perte de réception, vous envisagez un module (physique, pas simplement une fonction logicielle) qui se substitue au transceiver pour fournir des données au module de réception des données coté véhicule. C'est bien ça ?

Si j'ai bien compris le feed back va consister à enregistrer une multitude de données et les restituer après mise en forme de façon à pallier la défaillance du pilotage direct, jusqu'à retrouver (peut être) une liaison radio.
Si on sait faire tout ça sur le même µC que celui qui gère le fonctionnement normal de l'engin, pourquoi pas...

dje8269 · Aug 1, 2015

Pour continuer le #45, quel intérêt au hserin qui risque de perturber une liaison éventuelle I2C sur le même µC.

Après moultes config , je n'obtiens aucun résultats avec hserin et hserout ! . de plus si ca perturbe l'I²C , on laisse tomber .

Donc pour verrouiller mes tests , personne ne voit d’inconvénient présent ou futur sur l'utilisation de la liaison série avec serin / serout , si on débranche le câble de programmation ?

Dans ce projet, il y a une fonction principale qui est le pilotage de l'engin , en mode normal ( radiocommande + vidéo) ou en mode dégradé ( perte liaisons radio / panne => mode autonome)
Tout le reste est accessoire ou gadgets. En particulier la télémesure.
donc il y a deux flux radio essentiels: la vidéo (sens VHL > TELCDE) et la commande moteurs (sens TELCDE > VHL). ces deux flux sont prioritaires sur tout.

100% d'accord. On peut tout de même simplifier , en ne comptant pas le flux qui est completement a part ! . Le seul flux prioritaire est la commande du VHL

mais la fréquence de la liaison n'a absolument pas à être la même que celle liée au pilotage.

c'est clair !

ça veut dire que si on fait une mise à jour des mesures toutes les secondes, le flux prioritaire ne sera perturbé que 50ms (pour reprendre les mêmes chiffres) ttes les secondes. donc sans effet sur la réactivité du pilotage.

C'est bon aussi

ça veut dire aussi que la gestion de la télémesure doit être séparée de la fonction pilotage, et que le module mode dégradé (feed back) doit envoyer le même type d'info que la liaison radio au module pilotage.
Ce qui permet d'orienter le choix du lieu de traitement des infos.

Ca j'ai pas tout compris

je ne comprends pas trop pourquoi on utilise pas le contrôle de flux qui semble exister: on mets le RTS sur interruption et on reçoit les donnés après l'envoi du CTS.

??? Ben moi je comprends pas rien a ce RTS et CTS mais j'y travaille !

si vous voulez me faire faire des test allez y ! je suis OPEN

BESQUEUT · Aug 1, 2015

PieM said:
Pour continuer le #45, quel intérêt au hserin qui risque de perturber une liaison éventuelle I2C sur le même µC.

Pour le moment, on fait des tests. On verra bien si c'est plus performant ou pas. Reste que ce serait intéressant de savoir pourquoi ça ne marche pas.

PieM said:
je ne comprends pas trop pourquoi on utilise pas le contrôle de flux qui semble exister: on mets le RTS sur interruption et on reçoit les donnés après l'envoi du CTS.

Relisez le dernier programme publié : il tiens effectivement compte du RTS !
Relisez également le post #18 et la notice : il s'agit d'un Ready To Send et non d'un Request to Send...

Dans l'architecture que j'ai proposé, chaque sens est géré par un µ différent. La partie réception n'a pas encore été testée, mais oui il est probable que le CTS soit utile pour gérer le flux.

BESQUEUT · Aug 1, 2015

PieM said:
Le transceiver est en full duplex ? et aucune interférence possible dans les accès ?

Mes remarques sont dans le thread sur la conception du véhicule.

dje8269 · Aug 1, 2015

Voila ou j'en suis .

Déjà changer la led pour la mettre directement sur la broche RTS c'est nickel !
Je me suis donc amusé a changer les vitesses et les pauses et le débit !!!!. Qu'est ce que j'en ressort ! Bon pour vous , vous le saviez deja , mais pas moi ;

Par rapport au proto, ce n’est plus la vitesse du picaxe qui dicte le rythme des envois mais bien le transceiver . Le picaxe, je pense rempliera toujours plus vite le buffer du transceiver, qu'il n'a le temps de le vider . la fréquence de transfert sera donc fixé par le transceiver ! ( j’entends par la , mes 50ms entre deux trame ) .

En gros , on donne des infos au transceiver , et lui se débrouille pour les envoyer! ca c'est génial . Je pense que le gros avantages c'est que ca nous laisse beaucoup de temps si on veut faire des calculs ?

Cette pate RTS , pourrait donc etre branché sur une interrupteur, pour envoyer les infos , dés que possible ? ainsi on aurait aucun délais d'attente , et ce sera super optimisé ?

Si c'est bon je passe a la réception pour comprendre ce CTS :

Par contre je dois câbler sur le serin ? comme ceci ?

PieM · Aug 1, 2015

Relisez également le post #18 et la notice : il s'agit d'un Ready To Send et non d'un Request to Send...

désolé mais pas trop le loisir de dépouiller 40 pages de doc.
Mon intervention faisait suite simplement au soucis de maintenir la même réactivité lors de la conduite, qu'avec le proto. Soit une période de mise à jour de 50 ms maxi.
Mais pour y parvenir encore faut t-il avoir l'ensemble des traitement associés aux données reçues.
Quant à définir une architecture physique, je crois qu'il y a encore beaucoup d'inconnues tant au niveau matériel qu'au niveau des traitements pour l'envisager.

Petite remarque à cette occasion (à déplacer dans l'autre post) : les drivers moteurs ne se commandent pas en PWM. rien que ce type de détail conditionne l'architecture.
Encore une autre, je viens de remarquer qu'il y a toujours un joystick moteurs droit, et un moteurs gauche; j'ai dit ce que j'en pensais: c'est une hérésie sur le plan ergonomique.: Outre le fait que ça mobilise les deux mains, il est impossible de synchroniser l'action des deux mains sur une télécommande, donc impossible d'aller droit lors d'une accélération ou d'un ralentissement.

BESQUEUT · Aug 1, 2015

dje8269 said:
Cette pate RTS , pourrait donc etre branché sur une interrupteur, pour envoyer les infos , dés que possible ? ainsi on aurait aucun délais d'attente , et ce sera super optimisé ?

NON : mais vous pouvez avoir un inter pour choisir entre un envoi "aussi vite que possible" et un envoi "temporisé".
A noter que suivant la notice et suivant la réglementation, il est en principe interdit d'utiliser la fréquence "à fond" ...

dje8269 said:
Si c'est bon je passe a la réception pour comprendre ce CTS :

Par contre je dois câbler sur le serin ? comme ceci ?
View attachment 18456

Comprends pas pourquoi vous voulez changer de câblage pour le serin. Que ce soit hard ou soft, ça ne change rien. Par contre, vous pouvez déconnecter le RXD sur le module d'émission et le TXD sur le module de réception.

dje8269 · Aug 1, 2015

Cette pate RTS , pourrait donc etre branché sur une interruption, pour envoyer les infos , dés que possible ? ainsi on aurait aucun délais d'attente , et ce sera super optimisé ?

Je parlais d'interruption hard bien sur . pour ne pas utilisé un soft .

Comprends pas pourquoi vous voulez changer de câblage pour le serin

Il faut bien que je me branche sur la broche de serin ? ou toutes les broches peuvent servir de Serin ?

BESQUEUT · Aug 1, 2015

dje8269 said:
Je parlais d'interruption hard bien sur . pour ne pas utilisé un soft .

NON : dans ce cas, on n'aurait un envoi de données que quand le Transceiver passe de "saturé" à "non saturé" c'est à dire pas souvent...

dje8269 said:
Il faut bien que je me branche sur la broche de serin ? ou toutes les broches peuvent servir de Serin ?

Pour le hser..., les broches sont fixes puisque c'est matériel...
Pour le soft, la broche est définie par soft :
Pin is a variable/constant which specifies the i/o pin to use

J'en profite pour dire que la technique hard est en principe beaucoup moins gourmande en temps CPU et beaucoup plus réactive, en particulier à la réception. Donc c'est à privilégier chaque fois que c'est possible.
D'ailleurs, on se demande bien pourquoi les fabriquants mobiliseraient des transistors pour faire ça si ça ne servait à rien...

dje8269 · Aug 1, 2015

NON : dans ce cas, on n'aurait un envoi de données que quand le Transceiver passe de "saturé" à "non saturé" c'est à dire pas souvent...

Ok la led s’allume seulement quand le buffer est plein ! pas quand la transmission est en cours ! Donc mon idée est toute pourrie effectivement lol ;

J'en profite pour dire que la technique hard est en principe beaucoup moins gourmande en temps CPU et beaucoup plus réactive, en particulier à la réception. Donc c'est à privilégier chaque fois que c'est possible.

Je suis perdu , je dois la branchée ou la patte Tx de mon transceiver ?

BESQUEUT · Aug 1, 2015

dje8269 said:
Je suis perdu , je dois la branchée ou la patte Tx de mon transceiver ?

En hard, obligatoirement sur hserin
En soft : où vous voulez, donc pourquoi pas au même endroit...
Comme ça vous pouvez tester les deux possibilités sans rien changer au câblage.

hserin dispose d'une électronique spécifique pour la liaison série.
Mais c'est aussi une entrée normale, utilisable par serin pour recevoir les données par soft (bit bang mode).

dje8269 · Aug 1, 2015

Ok , je suis en train de cabler l'axe033 en mode i2c . ca prend un peu de temps, je dois rajouter une régulateur.

J'ai bientot finis .

Je vous montre schéma et programme a l'issu

dje8269 · Aug 1, 2015

Question :

L’écran est en 5V et le picaxe en 3.3V avec masse commune , a quel potentiel je dois mettre les résistance de pull-up de l'I²C ? 3.3V ou 5V ?

BESQUEUT · Aug 1, 2015

dje8269 said:
Question :
L’écran est en 5V et le picaxe en 3.3V avec masse commune , a quel potentiel je dois mettre les résistance de pull-up de l'I²C ? 3.3V ou 5V ?

Certainement pas en 5V, donc au mieux en 3,3V
Mais ça ne marchera probablement pas.
Il faudrait un convertisseur de niveau bidirectionnel-i2c

dje8269 · Aug 1, 2015

Bon sans parler de ca mon écran ne s'allume même pas ?

J'ai bine une tension de 5V qui rentre dans V+ et le 0V est branché au moins ;
J'ai mis le cavalier en J1 , mais c'est pour le mode I²C, il devrait quand même s’éclairer !
J'ai réglé le contraste de chaque cote , puis j'ai finis par le remettre au milieu de course
est ce que j'aurai loupé quelques choses ?

Mais ça ne marchera probablement pas.
Il faudrait un convertisseur de niveau bidirectionnel-i2c

Ah ben ca j'ai pas ! . il nous faut une solution de repli ?

Sur la partie réception . Le picaxe n'as besoin que du serin ? pour recevoir les données du transceiver . et il n'a besoin que du serout pour envoyer les données a l’écran ; on pourrait peut être faire comme ca ? croyez vous que ca pourrait le faire ?

BESQUEUT · Aug 1, 2015

dje8269 said:
Ah ben ca j'ai pas ! . il nous faut une solution de repli ?
Sur la partie réception . Le picaxe n'as besoin que du serin ? pour recevoir les données du transceiver . et il n'a besoin que du serout pour envoyer les données a l’écran ; on pourrait peut être faire comme ca ? croyez vous que ca pourrait le faire ?

A partir du moment où vous bricolez des modules 5V et 3.3V, ce serait bien d'avoir en stock les modules de conversion ad hoc.
Dans l'attente, passer en RS232 ne peut aider que si vous avez les modules d'adaptation ad hoc, par exemple un max3232 et un MAX232
Je ne vois qu'une solution dans les choses que vous êtes susceptible d'avoir en stock :
brancher deux servos via un ULN2803.
Mettez une belle aiguille blanche sur chaque. Ca permettra de valider la synchro avec les potars.
Et avec un protocole de test ad hoc, on pourrait même évaluer objectivement la "réactivité".
Avec un inter de choix de mode, on a aussi deux indicateurs analogiques : un pour le débit, un pour le taux d'erreur.
A la guerre comme à la guerre...

dje8269 · Aug 1, 2015

A la guerre comme à la guerre...

Lol

je n'ai pas de max232 de dispo à la maison ! pas de servo pas d'ULN2803 bref, pas grand chose.

A la limite j'ai je viens de regarder j'ai un max202 sur ma carte AXE091, peut etre la solution miracle ?

Dans tous les cas mon écran ne s’éclaire pas , c'est donc mal parti !

PieM · Aug 1, 2015

Le module AXE033 possède ses résistance de pull up. Donc dans ce cas reliées au 5V !
Sinon l'axe033 étant équipé d'un 18M2, avec des pullup reliés au 3.3V ça doit marcher, toutes les entrées étant en TTL.
J'ai des montages avec des composants 3.3V qui fonctionnent en I2C avec des Picaxes en 5V.
Cela n'est vrai qu'avec une liaison I2C qui est en collecteur ouvert.

dje8269 · Aug 1, 2015

Merci PieM, de ce petit coup d'espoir ! .

Mais apres lecture et relecture de la DS , je ne vois pas pourquoi il ne veux pas s'allumer !
J'ai tout bien soudé , même les broches A et K , qui ne devrait pas gêner ! .

Il parle d'une resistance sur RB , mais c'est sur la version AXE033B . moi je n'ai que la version AXE033 v2 avec un potar de contrast . j'ai donc rien mis sur RB .
La tension en entrée est de 5V , sur le 18M2 de 4.3V ( chute de tension de la diode de protection je suppose !).

Je suis a cours d'idée pour le voir s'allumer !

PieM · Aug 1, 2015

Attention! quand je dis de mettre des R de pullup au 3.3V ça veut dire qu'il faut enlever celles qui sont sur la platine!

Pour l'affichage faire une liaison entre les deux pins CLK: tu dois avoir qqchose qui s'affiche (l'heure) après réglage du contraste.

Besqueut said:
brancher deux servos via un ULN2803.

Heu ... peu de chance que ça marche !

dje8269 · Aug 1, 2015

Attention! quand je dis de mettre des R de pullup au 3.3V ça veut dire qu'il faut enlever celles qui sont sur la platine!

C'est grave si je les avait laissées ? ca aurait pus griller mon ecran ? car c'est ce que j'ai fais ! je n'aivais pas vu qu'elles étaient deja en place sur la platine AXE033 ! .

Pour l'affichage faire une liaison entre les deux pins CLK: tu dois avoir qqchose qui s'affiche (l'heure) après réglage du contraste.

Non rien ne s'allume ! avec en faisant une liaison sur ClOCK

Je dois rien brancher sur LCD ? ou RST ?

BESQUEUT · Aug 1, 2015

PieM said:
Heu ... peu de chance que ça marche !

Est-ce que ça une chance de marcher directement en 3,3 V ?
A part que le signal est inversé, pourquoi ça ne marcherait pas ?

dje8269 · Aug 1, 2015

Bon, si mon ecran est mort . pas trop de solution du coup .

Avec le câble de programmation on ne pourrait pas faire un sertxd

BESQUEUT · Aug 1, 2015

dje8269 said:
Avec le câble de programmation on ne pourrait pas faire un sertxd

Oui, pas de problème

dje8269 · Aug 1, 2015

C'est quand on crois comprendre , qu'o nse rend compte qu'on a rien compris ;

Je crois que la pause s'impose

BESQUEUT · Aug 1, 2015

dje8269 said:
C'est quand on crois comprendre , qu'on se rend compte qu'on a rien compris ;

Qu'est ce qui n'est pas clair ?
ZEEEEEEEN ! ça va bien se passsser....

dje8269 · Aug 1, 2015

déjà entre l’écran qui fonctionne pas ! . et ce maudit émetteur qui émet quand il veut !! .

je ne comprends pas pourqoi j'ai pas une emission toutes les secondes ! . ma led rouge clignote au même moment que la bleue , complétement aléatoirement .

Code:

[color=Green]'####################################   Initialisation   ####################################[/color]
[color=Blue]setfreq M8[/color]
[color=Purple]compteur [/color][color=DarkCyan]= [/color][color=Navy]0[/color]
[color=Blue]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]compteur
      [/color][color=Blue]serout [/color][color=Navy]0[/color][color=Black],[/color][color=Blue]N4800_8[/color][color=Black],[/color][color=Blue]([/color][color=Purple]compteur[/color][color=Blue])   [/color][color=Green]' On envoie la trame
      [/color][color=Blue]pause [/color][color=Navy]1000                    [/color][color=Green]' on marque une pause[/color]
[color=Blue]end if

loop[/color]

BESQUEUT · Aug 2, 2015

Merci de publier l'intégralité du programme à chaque fois !
Pourquoi diable être passé à 4800 alors que ça ne peut marcher qu'à 9600 ?

dje8269 · Aug 2, 2015

Bonjour ,

Pourquoi diable être passé à 4800 alors que ça ne peut marcher qu'à 9600 ?

?? ah bon ? ben c'etait pour mettre a la même vitesse le module et le picaxe

Code:

[color=Navy]#PICAXE [/color][color=Black]14M2[/color]

[color=Green]'####################################   Configuration   ####################################[/color]

[color=Blue]Symbol [/color][color=Black]BP [/color][color=DarkCyan]= [/color][color=Blue]C.3
Symbol [/color][color=Black]led [/color][color=DarkCyan]= [/color][color=Blue]C.1
Symbol [/color][color=Black]RTS [/color][color=DarkCyan]= [/color][color=Purple]pinB.2[/color]
[color=Blue]Symbol [/color][color=Black]CTS [/color][color=DarkCyan]= [/color][color=Blue]B.3
Symbol [/color][color=Black]compteur [/color][color=DarkCyan]= [/color][color=Purple]w13[/color]


[color=Green]'####################################   Initialisation   ####################################[/color]
[color=Blue]setfreq M8[/color]
[color=Black]compteur [/color][color=DarkCyan]= [/color][color=Navy]0[/color]
[color=Blue]pause [/color][color=Navy]1000[/color]
[color=Green]'####################################   Programme Principal   ####################################[/color]
[color=Blue]do

if [/color][color=Black]RTS [/color][color=DarkCyan]= [/color][color=Navy]0 [/color][color=Blue]then
      inc [/color][color=Black]compteur
      [/color][color=Blue]serout [/color][color=Navy]0[/color][color=Black],[/color][color=Blue]N4800_8[/color][color=Black],[/color][color=Blue]([/color][color=Black]compteur[/color][color=Blue])   [/color][color=Green]' On envoie la trame
      [/color][color=Blue]pause [/color][color=Navy]200                     [/color][color=Green]' on marque une pause[/color]
[color=Blue]end if

loop[/color]

BESQUEUT · Aug 2, 2015

dje8269 said:
Bonjour ,
?? ah bon ? ben c'etait pour mettre a la même vitesse le module et le picaxe

Houla !!! On n'est pas rendus...
1) Relisez #37
2) Allez boire un café
3) Relisez #37, ça peut pas nuire
4) Ca va ? (sinon : prenez un deuxième café...)

Sérieusement :
Mettez-vous dans la tête que le Picaxe ne voit que l'UART.
Ce qui se passe après dans le transceiver, vous ne le maitrisez pas directement.

Et l'UART fonctionne par défaut à ???
9600 bauds...

Si vous changez coté Picaxe, comment le Transceiver devines qu'il doit changer la vitesse de son UART ?

Il faut modifier la configuration du module...
Relisez #20...

Accessoirement, le raisonnement n'est pas bon : ça ne sert à rien de diminuer la vitesse coté UART sinon à détériorer la réactivité et à mobilisez le Picaxe plus longtemps que nécessaire. Si on a besoin de faire des calculs coté télécommande, une fois le Picaxe mis à fond, on peut augmenter la vitesse sur l'UART pour diminuer le temps consacré par le Picaxe à envoyer les données : il aura ainsi plus de temps pour les calculs.
Mais pour ça ... #20

dje8269 · Aug 2, 2015

Ok , j'ai exécuter vos conseils à la lettre . café relecture , puis relecture ;

Plusieurs questions tout de même .

Comment fait on pour maitriser l'envoi des infos par voie radio ? En gros il n'y as pas de broche Enable, si je veux pas qu'il émette je fais comment ?
Quand je mets sous tension. la led bleue de RTS s’éclaire très très furtivement a chaque envoie ? pourquoi ? elle est censé indiqué quand le buffer est plein ?
Faut-il un minimum de bit a envoyer ? car quand j'ecris :

serout 0,N9600_8,(compteur,0)

rien n'est transmis , ou du moins les leds ne s'allument pas ( bleue et rouge) .

PAr contre quand j'ecris :
serout 0,N9600_8,(compteur,0,0) la cadence est nickel et les led s'allume bien

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
Symbol [/color][color=Purple]compteur [/color][color=DarkCyan]= [/color][color=Purple]w13[/color]


[color=Green]'####################################   Initialisation   ####################################[/color]
[color=Blue]setfreq M8[/color]
[color=Purple]compteur [/color][color=DarkCyan]= [/color][color=Navy]0[/color]
[color=Blue]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]compteur
      [/color][color=Blue]serout [/color][color=Navy]0[/color][color=Black],[/color][color=Blue]N9600_8[/color][color=Black],[/color][color=Blue]([/color][color=Purple]compteur[/color][color=Black],[/color][color=Navy]0[/color][color=Blue]) [/color][color=Green]' On envoie la trame
      [/color][color=Blue]pause [/color][color=Navy]2000                                [/color][color=Green]' on marque une pause[/color]
[color=Blue]end if

loop[/color]

Platine test pour module radio AMB8636

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member