Platine test pour module radio AMB8636

BESQUEUT

Senior Member
Voyez l'initiateur de flux (le Master dans le cas de l'I2C) comme un chef d'orchestre : c'est lui qui donne le tempo !
Par voie de conséquence, personne d'autre ne doit avoir son propre tempo, sinon c'est la cacophonie et non la symphonie.
C'est pour ça que c'est si important dans le schéma d'architecture de savoir qui a l'initiative de chaque flux. On peut avoir des flux successifs qui s'enchainent :
A a l'initiative et envoie des données à B
B reçoit les données de A et a l'initiative pour envoyer des données à C (en fait, il se cale sur le tempo de A et l'impose à C)
etc...
Mais si B reçoit aussi des données de C ou d'un autre, il est coincé entre le timing de A et celui du tiers, lequel est forcément différent.
Ce conflit est très difficile à gérer sur un µ monotâche, encore plus sur un Picaxe pour lequel les tâches de fond (I2C slave, background receive, SERVO, timers, interruptions, ...) souffrent de nombreuses incompatibilité.
 

dje8269

Senior Member
Le répéteur reçoit la trame, incrémente et la renvoie, puis attends 100 ms
Je viens d'enlever cette pause de 100ms , ca fonctionne aussi bien . grâce a l’absence de time out . le répéteur reste bloque sur son serin . sinon il enverrai beaucoup trop vite les trames .
 

BESQUEUT

Senior Member
Je viens d'enlever cette pause de 100ms , ca fonctionne aussi bien . grâce a l’absence de time out . le répéteur reste bloque sur son serin . sinon il enverrai beaucoup trop vite les trames .
Ce n'est pas l'absence du timeout qui empêche le répéteur de s’emballer.
C'est simplement qu'il se cale sur l'initiateur du flux. (c'est un bon musicien qui écoute son chef d'orchestre)
Vous pouvez maintenant (après avoir enlevé la pause inutile) mettre un timeout du moment qu'il est largement supérieur au temps entre deux trames, ceci afin de détecter une perte de com.
Le timeout sert a détecter les anomalies, pas à synchroniser un flux !
 

dje8269

Senior Member
Vous pouvez maintenant (après avoir enlevé la pause inutile) mettre un timeout du moment qu'il est largement supérieur au temps entre deux trames, ceci afin de détecter une perte de com.
Le timeout sert a détecter les anomalies, pas à synchroniser un flux !
Ok , très bien . je commence à saisir , la j'ai vraiment l'impression d'avancer . les explications, plus la pratique , rien de mieux , pour la compréhension.

Mais en rajoutant un time out , je force donc mon répéteur a envoyer une valeur même si il n'en as pas recu . attention je ne suis pas encore dans l'optique de simuler le fonctionnement réel, mais juste de comprendre , parfaitement . Car je pense que c'est la partie la plus essentiel de toute .
 

dje8269

Senior Member
OK donc , pouvez me dire si j'ai bon.

Avec un tel programme, je ne peux pas faire plus vite :

Répéteur:
Code:
[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])
                  
endif

loop[/color]
L'initiateur :
Code:
[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]) 
      
      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 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]
Dans cette configuration la, chacun attend de recevoir entierement son serin avant d'emettre . Cela a pour résultat , que dès qu'un serin est recu, on envoie la réponse tout desuite derriére et ceci a l'infini . Je suis conscient qu'il ne faut pas qu'il y est d'ereur d'envoi , sinon on reste bloqué sur un serin , etl'envoi ne sa fait qu'une seule fois ; C'est juste pour validé le principe .
 

dje8269

Senior Member
Une configuration :

initiateur sans sertxd :
Code:
[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]) 
      endif

      [/color][color=Green]'sertxd ("avant = ",#b0,"-",#b1,"   -----------   ")

      [/color][color=Blue]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=Green]'sertxd ("Apres = ",#b0,"-",#b1,13,10)
      [/color]
[color=Blue]loop[/color]
repeteur :
Code:
[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])
endif

loop[/color]
résultat à l'analyseru logique: En bleu branché sur la broche Tx du transceiver initiateur et en jaune sur la broche Tx du transceiver répéteur

essai.png
 

BESQUEUT

Senior Member
Dans cette configuration la, chacun attend de recevoir entierement son serin avant d'emettre . Cela a pour résultat , que dès qu'un serin est recu, on envoie la réponse tout desuite derriére et ceci a l'infini . Je suis conscient qu'il ne faut pas qu'il y est d'erreur d'envoi , sinon on reste bloqué sur un serin , et l'envoi ne sa fait qu'une seule fois ; C'est juste pour validé le principe .
NON : dans cette configuration, l'initiateur a encore le tempo à cause des sertxd qui se comportent comme des pauses.
Comme le répéteur n'a pas de pause (ou de sertxd) il reste capable de se synchroniser sur le chef d'orchestre.

On ne peut pas avoir une configuration symétrique dans ce type d'architecture. Il faut qu'un chef d'orchestre donne le tempo.

Ce que vous voulez faire correspond à une architecture "event driven" où tous le monde peut recevoir des messages à tout moment.
C'est du multitâche (collaboratif ou pas) et c'est difficile à programmer sur un µ, encore plus sur unPicaxe.
C'est pour ça que j'ai proposé de séparer les flux dans chaque sens sur des µ distincts pour rester dans le cadre d'une architecture linéaire.
 
Last edited:

BESQUEUT

Senior Member
Une configuration :
initiateur sans sertxd
Là, le chef d'orchestre est devenu fou : il bat la mesure tellement vite que plus personne n'arrive à le suivre.
Le reste est imprévisible.

A noter que dans un programme réel, on n'est pas obligé de mettre une pause pour donner le tempo : le reste des tâches à effectuer par l'initiateur peut suffire. C'est pour ça qu'il n'est pas indispensable de limiter son travail à tous prix.
 

dje8269

Senior Member
Là, le chef d'orchestre est devenu fou : il bat la mesure tellement vite que plus personne n'arrive à le suivre.
Le reste est imprévisible.
Je comprends pas .

Il attend tout simplement la réponse du repeteur avant de repartir a fond . En fait chacun repond tout de suite aprés avoir recu une info ; ce qui dans le principe , fait qu'il n'y aucun temps mort. a chaque info reçue , la réponse est immédiate des deux cotés.
 

BESQUEUT

Senior Member
Je comprends pas .

Il attend tout simplement la réponse du repeteur avant de repartir a fond . En fait chacun repond tout de suite aprés avoir recu une info ; ce qui dans le principe , fait qu'il n'y aucun temps mort. a chaque info reçue , la réponse est immédiate des deux cotés.
Suivant les aleas de transmission, chacun peut recevoir un message alors qu'il n'est pas à l'écoute. Il y aura des trames perdues.
Ce qui fait que ça marche avec la tempo de l'initiateur, c'est que le répéteur a le temps de se remettre à l'écoute avant qu'une nouvelle trame arrive.
Voir #207
 

dje8269

Senior Member
Donc l'augmentation de la vitesse du picaxe , et celle du debit de l'UART ne changeront rien . seul l'augmentation du l'UART interne au module diminuerais le temps entre deux émission ?
 

BESQUEUT

Senior Member
Donc l'augmentation de la vitesse du picaxe , et celle du debit de l'UART ne changeront rien . seul l'augmentation du l'UART interne au module diminuerais le temps entre deux émission ?
Ah : votre objectif est de "réduire le temps entre deux émissions"
Essentiellement oui.
Il reste 5ms à gratter à l'émission dans chaque sens à cause de la façon dont le buffer d'entrée est pris en compte,
effectivement, le temps mis pour remplir et lire les buffers via les UARTs à 9600 bauds,(soit 4 fois 7ms)
et sans doute un peu de temps pris par les Picaxes pour exécuter leurs programmes. Il faudrait mettre des pulsout à des endroits judicieux pour observer ça sur l'analyseur.

Passer à 19200 bauds sur l'UART permettrait de gratter 14 ms sur l'aller-retour pour des trames de 8 octets.
Mais ce n'est pas représentatif car les trames envisagées sont plutôt de 2 ou 3 octets. A peine 3 ms en aller-retour, et 1,5 ms en émission pour des trames de 2 octets, ce n'est pas nul, mais ça ne révolutionne pas le procédé.

Cela dit, votre chef d'orchestre est otage de son musicien : il ne peut lever le bras, que quand son violoniste a levé le sien.
Il pourrait émettre presque deux fois plus vite si il avait les mains libres.
 
Last edited:

dje8269

Senior Member
Mon objectif est de tester et de comprendre le fonctionnement de ces modules. En avançant petit à petit , je souhaite arriver à simuler, ce qui va se passer avec les vrais Infos.

Pour le moment le dialogue est pas mal. Ça communiqué dans les deux sens, même si j'ai pas assimilé toutes les subtilités j'y vois plus clair.

Maintenant je vais essayer d'émettre d'un côté , et de recevoir le plus vite possible, sans réponse , juste avoir le plus timing entre deux émissions, et Ue le message à la réception soit exact, bien évidemment
 

BESQUEUT

Senior Member
Maintenant je vais d'émettre d'un côté , et de recevoir le plus ire possible, sans réponse , juste avoir le plus timing entre deux émissions, et Ue le message à la réception soit exact, bien évidemment
L'initiateur, #206 est très rapide si on enlève le serin.
Au début, je suggère de laisser une petite pause pour mettre au point la réception.
Toute la difficulté est de traiter la trame reçue le plus vite possible pour se remettre à l'écoute avant qu'une nouvelle trame ne se présente.
Conservez le N° de la précédente trame reçue, et allumez une LED si la dernière trame reçue ne fait pas un de plus.
Vous pouvez alors diminuer la pause à l'émission jusqu'à ce que ça merdouille.

Le grand jeu est de savoir si une fois que ça a merdouillé, si ça peut repartir ou si ça reste merdeux...
(pas le droit d'éteindre et de rallumer le récepteur évidement)

L'analyseur logique est un merveilleux outil pour bien voir ce qui se passe. Je vous suggère de mettre un high juste avant le serin et un low juste après.
Vous pourrez ainsi visualiser à peu près le créneau pendant lequel le récepteur est apte à recevoir les données. Si la trame se présente avant, ben ça va merder...

Une fois qu'on arrive à gérer les emmerdements (que ça repart sans problème)
on peut compter le nombre de merdages pour n trames émises.
Pour connaitre à la réception le nombre de trames émises, il faut se baser sur w0.
Prévoir une variable pour compter le nombre de trames reçues conformes (depuis la trame N° X la dernière fois où on a fait le point)
Le nombre de trames perdues est la différence entre les deux.
Pour afficher le résultat, il faut faire un sertxd et pendant ce temps on ne compte plus les points évidement puisqu'on n'est plus à l'écoute en réception.

A noter que ce genre d'expérimentation ne teste pas les transceivers mais la qualité des programmes, et en l’occurrence, essentiellement du programme de réception.

A ce stade, vous êtes mur pour faire des tests d'éloignement.
 
Last edited:

dje8269

Senior Member
Je pense avoir un soucis indépendance avec l'analyseur logique . il me fait des rates qu'on il analyse !
Conservez le N° de la précédente trame reçue, et allumez une LED si la dernière trame reçue ne fait pas un de plus.
Vous pouvez alors diminuer la pause à l'émission jusqu'à ce que ça merdouille.
J'ai tout compris sur ce point la !

J'en suis la :

Initiateur :
Code:
[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
      
            high led
            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])
            low led
            
            pause [/color][color=Navy]100
      [/color]
[color=Blue]endif [/color]

[color=Blue]loop[/color]
Répéteur:
Code:
[color=Green]'####################################   Programme Principal   ####################################[/color]
[color=Blue]do
      
high led    
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]low led[/color]

[color=Blue]loop[/color]
Voici le résultat :
En bleu la led qui nous montre le serout de l'initiateur, et en jaune les données transmises .
en rouge la led du serin , et en vert les infos recues
analyseur.png

analyseur zoom.png
 
Last edited:

BESQUEUT

Senior Member
'en suis la :
très parlant
Juste pour info : c'es quoi la vitesse du Picaxe ? (le temps entre émissions ne correspond pas à une pause 100)
Par ailleurs, sans le numéro de trame, on pourrait avoir l'impression de recevoir des données un peu avant qu'elles ne soient émises...

On voit que le récepteur s'en tire sans problème. Il faut dire qu'il ne fait strictement rien. Attendons qu'il fasse quelque chose avec les trames reçues...
 
Last edited:

dje8269

Senior Member
Juste pour info : c'es quoi la vitesse du Picaxe ? (le temps entre émissions ne correspond pas à une pause 100)
Les picaxes sont 8Mhz , c'est donc une pause de 50ms

Par ailleurs, sans le numéro de trame, on pourrait avoir l'impression de recevoir des données un peu avant qu'elles ne soient émises...
Vous avez les numéros de trames a l’intérieur de celle ci en l’occurrence sur la photo zoom , on voit 225 et 226 . On pourrait croire qu'il a un déphasage de 180° et bien que la réception ce fait avant l’émission, mais c'est par ce que ca correspond a la trame d'avant .

Oui mais je n'arrive pas à diminuer ce temps mort ! un petit dessin mange pas de pain

analyseur test.png

ca peut paraitre obstiner ou idiot. Mais bon , je comprends pas pourquoi le délais entre deux émission est si long . et si je reduis la pause , pourquoi le serin ne tiens pas la route, on voit qu'il a le temps quand meme , il se tourne les pouces pendant que la courbe rouge est a l'etat haut .
 

BESQUEUT

Senior Member
je comprends pas pourquoi le délais entre deux émission est si long . et si je reduis la pause , pourquoi le serin ne tiens pas la route, on voit qu'il a le temps quand meme , il se tourne les pouces pendant que la courbe rouge est a l'etat haut .
Ce que vous marquez sur le dessin, ce n'est pas le délai entre deux émissions, mais le délai entre l'émission et la réception.
Comme dit plus haut, ce délai est utilisé par les transceivers pour faire leur travail en HF. Il commence 5 ms après que les données aient été reçues dans l'UART.
Mais rien n'empêche d'émettre plus souvent en diminuant la pause.
Il semble que vous ayez essayé, mais vous ne dites pas ce qui se passe dans ce cas.
Attention il y a un décalage entre le front montant rouge et le moment où le Picaxe est effectivement prêt à recevoir des données...

Avec ce programme qui ne fait rien, le Picaxe a effectivement tout le temps de recevoir des données. Faites lui faire quelque chose, genre vérifier le numéro de trame. Vous verrez se réduire le créneau haut rouge...
 

dje8269

Senior Member
Mais rien n'empêche d'émettre plus souvent en diminuant la pause.
Il semble que vous ayez essayé, mais vous ne dites pas ce qui se passe dans ce cas.
Au temps pour moi , j'étais justement en train de confirmer . avant de poster j'essaye plusieurs fois , des fois ca me permets de trouvé tout seul,et de mieux comprendre dans tous les cas .

Quand je diminue cette pause, ça merdouille ! et la ou je comprends pas ! car le serin a quand même le temps vu que justement je fais rien pour le moment .

Avec une pause de pause 80 ( soit une pause 40ms a 8mhz) .
analyseur.png

analyseur zoom.png

Il commence 5 ms après que les données aient été reçues dans l'UART.
Oui j'ai cru comprendre dans ceci dans la DS, par exemple faire partir la transmission après un certain nombre d'octets ! . voir même supprimer cette pause

Transmission starts after timeout: Transmission begins if no new character is detected within a configurable time period after receiving a character via UART. The timeout is
reset every time a character is received. It can be configured with the UART_Timeout parameter (see 11.4)
Avec ce programme qui ne fait rien, le Picaxe a effectivement tout le temps de recevoir des données. Faites lui faire quelque chose, genre vérifier le numéro de trame. Vous verrez se réduire le créneau haut rouge...
Sur le proto , j'avais simuler par une pause tout simplement, remplaçant le programme a venir .
 

BESQUEUT

Senior Member
Comme dit plus haut, il y a une décalage entre le front montant rouge et le moment où le Picaxe est effectivement prêt à recevoir des données.

Le graphique montre simplement que le transceiver de réception n'envoie plus la trame en une seule fois, mais probablement s'interrompt pendant la réception de la trame suivante en HF (tâche prioritaire selon la doc, et on comprends bien pourquoi) puis poursuit tranquillement le transfert des données sur l'UART.
Il ne faut pas oublier que le transceiver est aussi un µ monotâche...

En outre, le Picaxe reçoit clairement des données au moment où il n'est pas prêt... Une fois qu'il est déphasé, rien ne lui permet de se recaler, et il continue à perdre des octets...

Plutôt que les high/low d'émission (signal bleu), se serait bien d'avoir le signal de réception HF du transceiver de réception : LED_RX (broche 9)

Au lieu d'envoyer des zéros après le compteur, envoyez des caractères repérables ("A", "B", "C" ...)
que l'on puisse voir si des caractères sont perdus ou si c'est seulement un déphasage...
Par ailleurs, il semble que l'analyseur "rate" le premier octet et c'est pile l'octet significatif du compteur.
ce serait bien de zoomer un poil plus

Ce serait intéressant de voir si hserin ne fait pas mieux.
 
Last edited:

dje8269

Senior Member
Au lieu d'envoyer des zéros après le compteur, envoyez des caractères repérables ("A", "B", "C" ...)
que l'on puisse voir si des caractères sont perdus ou si c'est seulement un déphasage...
Par ailleurs, il semble que l'analyseur "rate" le premier octet et c'est pile l'octet significatif du compteur.
ce serait bien de zoomer un poil plus
Quand je zomm un peu plus on voit pas suffisament les courbes . voici un petit montage .

test avec "A", "B" etc ... et toujours pause 80 ( donc 40ms)
analyseur zoom.png

analyseur zoom3.png

Ce serait intéressant de voir si hserin ne fait pas mieux.
ok je test ca

Ca part encore plus en sucette avec hserin .
 
Last edited:

BESQUEUT

Senior Member
Si vous allumez d'abord l'initiateur, le récepteur prend le tran en marche.
tant que les trames arrivent en une seule fois, pas de blème : il est en phase

Si les trames arrivent en deux morceaux, il peut commencer par recevoir une fin de trame, disons 3 octets.
Ça lui suffit pas, alors il attends encore un peu.

Là le transceiver tente de lui fourguer 8 octets de plus.

Mais dès le cinquième, le Picaxe arrête les frais et baisse son flag (créneau rouge descendant)
Même s'il ne mets pas longtemps à revenir à l'écoute, il perds au moins un octet.
Mais impossible de savoir avec le programme actuel.
 
Last edited:

BESQUEUT

Senior Member
Ca part encore plus en sucette avec hserin .
??? qu'entendez vous par là ???
Programme de réception ?
Le programme ne fait rien : comment est-ce que ça peut être pire ?
Quand au graphique, le Picaxe ne peut pas influencer le transceiver : le graphique ne peut pas être différent !
A la limite sans Picaxe, le graphique doit rester le même !
 

dje8269

Senior Member
Dans quel ordre vous mettez sous tension les Picaxes ?
En general j'allume d'abord le répéteur et ensuite l’initiateur , pour démarrer la réception sur un envoi de l'initiateur .
J'ai essayé dans les deux cas . pas de différence a mon avis ! .

Mais impossible de savoir avec le programme actuel.
Si vous avez un petit programme a me proposer , je suis fana . vous m'aviez donné des indications sur un autre post , mais j'avais pas tout compris .

??? qu'entendez vous par là ???
Programme de réception ?
Le programme ne fait rien : comment est-ce que ça peut être pire ?
programme Hserin
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
hsersetup T9600_8[/color][color=Black], [/color][color=Navy]%10[/color]
[color=Blue]pause [/color][color=Navy]1000[/color]
[color=Green]'####################################   Programme Principal   ####################################[/color]
[color=Blue]do
      
high led    
hserin [/color][color=Purple]w0[/color]
[color=Blue]low led[/color]

[color=Blue]loop[/color]
analyseur.png

analyseur zoom.png
 

BESQUEUT

Senior Member
A part que le signal rouge est n'importe quoi vu que le programme est lui-même n'importe quoi, je ne vois pas ce qui a changé ?
A minima, reprenez le programme de la doc. Je ne comprends même pas que le compilateur accepte ça !

Pour le hsersetup :
- T9600_8 n'existe pas pour hsersetup ! c'est B9600_8
- vu que le signal est "TRUE", le bit 1 doit être à zéro (mais bon, c'est seulement pour le output...)
bit1 - invert serial output data (0 = ‘T’, 1 = “N”)

sur le zoom, les trames vertes sont entières. Il faudrait zoomer sur des trames successives partielles pour vérifier si des octets sont perdus.

Si le hserin marche, le mieux ce serait de recevoir un bon paquet de trames (disons une centaine) en background receive, puis de les restituer via des sertxd.
A priori, le réglage pour ça est :
hsersetup B9600_8,1

Suffit alors d'observer hserptr qui compte le nombre de caractères reçus.
Code:
do
   ptr=0
   hsersetup B9600_8,1
   do
       led=hserintflag
       hserinflag=0
   loop until hserptr>800

   ptr=0
   for b10=1 to 100
        sertxd (#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc,13,10)
   next b10
loop
 
Last edited:

dje8269

Senior Member
alors voila après vos corrections :

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
hsersetup B9600_8[/color][color=Black], [/color][color=Navy]%00[/color]
[color=Blue]pause [/color][color=Navy]1000[/color]
[color=Green]'####################################   Programme Principal   ####################################[/color]
[color=Blue]do
      
high led    
hserin [/color][color=Purple]w0[/color]
[color=Blue]low led[/color]

[color=Blue]loop[/color]
analyseur.png

analyseur zomm custo.png
 

dje8269

Senior Member
Votre programme m'annonce une erreur comme quoi le background receive ne fonctionne pas avec ce chip ?

Dans la boucle vous marquer hsersetup ? est ce normal . voulez que je mette le programme sur un 20X2?
Code:
do
   hsersetup B9600_8,1
   do
       led=hserintflag
       hserinflag=0
   loop until hserptr>800

   ptr=0
   for b10=1 to 100
        sertxd (#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc," ",#@ptrinc,13,10)
   next b10
loop
 
Last edited:

BESQUEUT

Senior Member
Votre programme m'annonce une erreur comme quoi le background receive ne fonctionne pas avec ce chip ?
Dans la boucle vous marquer hsersetup ? est ce normal . voulez que je mette le programme sur un 20X2?
Ça fait un moment que l'on dit qu'un M2 n'est pas adapté pour faire ce job...
Oui c'est normal que le hsersetup soit dans la boucle : c'est pour ré-initialiser hserptr
J'ai ajouté un ptr=0 pour être bien sur.

Attention, un 20X2 n'a que 128 emplacements mémoire au lieu de 1024.
Du coup, vous ne pouvez enregistrer que 16 trames de 8 octets

A ce sujet, puisque les trames feront 3 octets, 4 au pire, c'est non représentatif de travailler sur des trames de 8 octets.
Beaucoup de choses iraient 2 fois plus vite, sans même changer le baud-rate.
 
Last edited:

dje8269

Senior Member
Bonjour ,

Bon je vais laissez tomber , mes tentatives de compréhension . quand ça veut pas , ça veut pas .

Ce qui sort du picaxe émetteur pas de problème . c'est nickel, si je diminue la pause on voit clairement les données se rapprochées . En exagérant a titre d'exemple, je pourrais émettre sans pauses en continue donc !!. Sauf que le buffer du transceiver serai vite saturé .
Donc mettons une petite pause simulant un bout de programme , en sachant que ce picaxe n'auras pas grand chose a faire disons une pause de 20ms ( ce qui est énorme déjà) donc pause 40 à 8mhz . j'ai mis le chiffre "99" en guise de "qualifer si on le souhaite.

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[/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]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
      
            high led
            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=Navy]99[/color][color=Black],[/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=Blue])
            low led
            
            pause [/color][color=Navy]40    [/color][color=Green]'Simulation du programme qui s'écoule
      [/color]
[color=Blue]endif

loop[/color]
Voici le résultat :
analyseur.png

analyseur_zoom.png

Aucune erreur a déplorer .

Un petit mou en dessous des 0.4s, je sais pas trop pourquoi ! peut être quand le buffer était plein ! mais comme on mesure ce qui sort du picaxe je ne vois pas trop pourquoi , je n'en suis pas sur . Sinon impeccable . le timing est respecté.
 

BESQUEUT

Senior Member
Attention : vous ne pouvez pas choisir n'importe quoi comme qualifier !
Le qualifier ne peut pas apparaître dans un des autres octets, sinon ce n'est plus un qualifier !
Vous pouvez par exemple prendre 0 ou 255
Le compteur de trames devra être modifié en conséquence...
Les commandes SERVO ou PWM n'iront que de 1 à 254 ce qui ne devrait pas gêner.
Pour les TORs, vous ne pourrez en passer que 7 par octet, soit 14 sur 2 octets, ce qui est conforme au CDC.
En outre, voir #229 pour la longueur des trames

L'utilisation d'un qualifier est évidement antinomique avec l'objectif d'un débit maximal, et c'est pour ça que je l'ai écarté jusqu'à présent.
Mais si vous y tenez, il faut le faire correctement, sinon le remède est pire que le mal...
 
Last edited:

BESQUEUT

Senior Member
Un petit mou en dessous des 0.4s, je sais pas trop pourquoi ! peut être quand le buffer était plein ! mais comme on mesure ce qui sort du picaxe je ne vois pas trop pourquoi , je n'en suis pas sur . Sinon impeccable . le timing est respecté.
Ben c'est le job du RTS tout simplement...
Comme déjà dit, si vous cherchez la vitesse, la difficulté n'est pas à l'émission mais à la réception...
Vous pouvez supprimer la pause, et même augmenter la vitesse du Picaxe : vous n'aurez pas plus d'erreur.
Je ne vois d'ailleurs pas ce que vous entendez par "erreur" à ce niveau ?
Par contre, avec des trames de 4 octets(qualifier compris) vous simplifiez un peu le problème et vous êtes plus représentatif.
 

BESQUEUT

Senior Member
Bon je vais laissez tomber , mes tentatives de compréhension . quand ça veut pas , ça veut pas .
Je ne vois pas où est votre problème.
Le programme de réception marche très bien, sauf qu'il ne fait rien.
Les transceivers transmettent les données conformément aux specs.
Qu'est ce qui ne va pas ?
 

dje8269

Senior Member
Maintenant cote réception, ça se corse pour moi , et mon cerveau lent .

Je viens donc me ploter en sortie du transceiver( ou ce qui rentre dans le picaxe au choix)) . ainsi que sur une broche led du picaxe .
Sur le serin j'ai mis une time-out ( de 10ms soit pause 20 a 8Mhz) pour voir si le serin se tourne les pouces .
Je n'ai pas utilisé le qualifer .

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
      
high led    
serin [PLAIN][[/PLAIN][/color][color=Navy]20[/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]low led

loop[/color]
analyseur.png
On voit que cote émission pas de soucis . par contre coté réception ça tape dans les gamelles ! . On remarque aussi pas mal de pic sur la courbe rouge . En zoomant on devrait y voir plus clair .

analyseur_zoom_general.png

J'ai pris une partie sans bug et avec . comme c'est trop large , j'ai donc couper des parties au montage . dans la partie a gauche ou on peut voir deux trames complètes .( 74 et 75 pour la valeur de b0 )

On remarque que la courbe rouge passe a l’état haut tout de suite après ,donc le picaxe est prêt a recevoir , puis il attend 10ms ( timeout) et redescend ?, puis remonte etc .. Ceci trois fois de suite avant de recevoir la nouvelle trame .
Le serin se tourne donc les pouces . Il a été prêt trois fois a recevoir des données avant qu'on lui en propose !

Ma deduction, est donc que c'est le transceiver qui a mis du temps a lui fournir !
 

dje8269

Senior Member
Comme déjà dit, si vous cherchez la vitesse, la difficulté n'est pas à l'émission mais à la réception...
D'accord !
Vous pouvez supprimer la pause, et même augmenter la vitesse du Picaxe : vous n'aurez pas plus d'erreur.
Je ne vois d'ailleurs pas ce que vous entendez par "erreur" à ce niveau ?
Oui j'ai tester . j'entends erreur par le fait que les trames soit mal reconnues par exemple . mais vous avez raison c'est à la reception qu'il faut que je forunisse un effort!

Le programme de réception marche très bien, sauf qu'il ne fait rien.
Les transceivers transmettent les données conformément aux specs.
Qu'est ce qui ne va pas ?
Oui il fonctionne bien , mais pas vite .

A vide, sans traitement , sans rien , j'aurais juste voulus essayer de recevoir des données sans erreurs , le plus vite possible . pour voir , tester et surtout comprendre son fonctionnement
 

dje8269

Senior Member
Vous ne lisez manifestement pas mes messages. Voir en particulier #220 et suivants...
Désolé, je viens de le lire ! j'ai deux enfants a à la maison , qui m’empêche d’être concentre comme je le souhaiterais . lol .

Merci pour l'explication en #220 . Bon ça sert a rein que je continue tant qu'on aura pas accès aux réglages du module . car si j'innonde mon recepteur , il passe plus de temps a receptionner les infos qu'a les redistribuer, d'ou les trames imcompletes .

PLUS INTERNET !!!! Aïe !!
 

BESQUEUT

Senior Member
J'ai pris une partie sans bug et avec . comme c'est trop large , j'ai donc couper des parties au montage . dans la partie a gauche ou on peut voir deux trames complètes .( 74 et 75 pour la valeur de b0 )
Vous voyez des bugs là où il n'y en n'a pas.
On s'en fout du nombre d'octets par paquet.
Ce qui importe, c'est qu'il ne manque aucun octet d'un paquet au suivant.
Impossible a voir sur la schéma car vous avez coupé les paquets intermédiaires...
La courbe rouge est peu significative car on ne connait pas le décalage entre le front montant et l'état réellement prêt à recevoir.
Comme déjà dit, le programme de réception n'a strictement aucune influence sur la courbe verte.
Par contre ce serait intéressant d'avoir le signal de réception HF, mais ça, ça ne vous intéresse pas...
 

BESQUEUT

Senior Member
Bon ça sert a rien que je continue tant qu'on aura pas accès aux réglages du module .
Comme déjà dit, la modification des réglages des transceivers ne permettra qu'une optimisation marginale.
Ça n'empêche nullement de mettre au point un programme de réception digne de ce nom, en particulier en utilisant un µ plus adapté et le background receive.
 
Top