Test de fiabilité (radio) RERIN-SEROUT

jojojo

Senior Member
Edit:Shame on me ! SERIN-SEROUT, bien sûr !
Hello, comme promis, le pendant de la chose, sur IRIN et IROUT.

Préambule TRES IMPORTANT :
Si vous utilisez des modules AUREL, AM, en 433, il est IMPERATIF de "bufferiser", entre la sortie RX, et l'entrée PICAXE, avec deux portes CMOS type trigger, cd4093 en série.
Sinon, AUCUN FONCTONNEMENT CORRECT n'est possible !
J'avais déjà eu ce type de problème de "propreté" du signal, avec certaines instructions picaxe, là, c'est flagrant:
IRIN s'en fiche totalement. PAS SERIN !

Trace du dessus, sans les 4093, trace du dessous, avec :

scope.jpg

Pas beau, le bricolage, mais :
cd4093.jpg

Voilou, fin du préambule.

Donc, ça peut fonctionner.
pour "coller" au plus près aux tests Manchester, huit octets sont à transmettre, et on voit ce qui reste de bon à l'arrivée.

Première constatation, sans analyse, juste "à l'oeil", des octets de préambule(qualifier) sont impératifs.
Un seul est insuffisant, des erreurs persistent. Trois, ça ne change pas (sur 1000 trames), donc, va pour deux qualifier.

Deuxième constatation (logique), le taux d'erreur est quasi proportionnel à la vitesse. Donc, on se limite à 600Bds.

Troisième constatation (c'est là que ça 'creuse', par rapport aux IRIN), si les qualifier's assurent un checksum correct, il masquent un autre souci :
Les trames perdues ... Et il y en a !

Code du TX:
Code:
#picaxe 14M2
SetFreq M4
For w13=1 to 1001


Serout B.1,0,("X","Y",$55,$AA,$55,$AA,$55,$AA,$55,"N")'600bds, 
pause 500

Next w13

Serout B.1,0,("X","Y","EOT----N")'600bds,
1001 trames sont transmises (1000 sont exploitées, la première est forcément perdue, voir le traitement PC)
La dernière ligne trame ne sert qu'a informer le PC que le job du TX est fini.

Code du RX, la vitesse de transfer série vers le PC a du être baissée à 4800 (compatibilité, avec le 600Bds de la liaison TX-RX)
Code:
#picaxe 40X2	
SetFreq M4
Do

'	
Serin A.0,0,("X","Y"),b0,b1,b2,b3,b4,b5,b6,b7	'600, deux ident's
	
Serout A.2,T4800_4,(b0,b1,b2,b3,b4,b5,b6,b7)	'via max232
debug							'donc, le 'T4800

Loop
Ce que fait le PC:

Code:
SetSys(_DateFormat, "D(D1/M1/Y1)")
	Dim Data as String
	Dim Chaine1 as String   
	Dim Chaine2 as String
	Dim cpt As Long 
	Dim cpt2 as Long 
	
	Dim Checksum As Long 
	Dim Manquantes as Long
	A_Recevoir=1000
	
	Fichier=FileQUnique 
	If FileQ("c:\tempo\logger.txt",_Exists)=0 Then
		   FileOpen(Fichier,"c:\tempo\logger.txt",_Write)
		   FileWrite(Fichier,"Test RS232")
		   FileClose(Fichier)
	End If
	CommOpen(1,4800,100,0,8,1,_NoParity)
    Loop

		Loop
		If CommQ(1)[_CQ_Readpending] Then  
			
			data=commRead(1,1)
			
			Exit Loop
			
		End If
		End Loop
	

	
		If data<>"N" Then
			chaine1=chaine1+NumToStr(Asc(data))+" "
			chaine2=Chaine2+data
			Checksum=Checksum+Val(NumToStr(Asc(data)))
		Else
			If Instr(Chaine2,"EOT")<>0 Then
				Exit Loop
			End If
		    
			FileOpen(Fichier,"c:\tempo\logger.txt",_Append)
		    cpt=cpt+1
			print chaine1;: print checksum 
			If Checksum <>850 Then
				cpt2=cpt2+1
				FileWrite(fichier,Chaine1 +"  Erreur Checksum"+time$)
			Else
				FileWrite(fichier,Chaine1 +"                 "+time$)
			End If
			FileClose(Fichier)
			chaine1=""
			chaine2=""
			Checksum=0
		    
		End if
        
	End Loop 
	Manquante=A_Recevoir-cpt 
	
	FileOpen(Fichier,"c:\tempo\logger.txt",_Append) 
	
	
	FileWrite(fichier,NumToStr(cpt)+" Lignes contrôlées") 
	FileWrite(fichier,NumToStr(cpt2)+" Erreur(s) Ckecksum")
	FileWrite(fichier,NumToStr(Manquante)+" Lignes manquées")
	FileClose(Fichier)
Un peu "brut de décoffrage", mais, ça fonctionne bien.

Et, le résultat :
(post suivant, deux PJ max, comme d'hab !)
 
Last edited:

jojojo

Senior Member
Suite, donc, avec le mouchard :
View attachment loggerrs232.txt

Vous pouvez aller directement à la fin, hein !

Donc, 458 trames transmises (très correctement, certe, zéro erreur), sur 1000.

Ce qui nous donne un petit 46%. Pas top, mais utilisable.
Si vous retournez voir la colone de droite du logger RFIN, vous constaterez aisément (en regardant les secondes), qu'aucune trame ne manque. Là, c'est top.

Conclusion perso (et discutable, bien-sûr):

- On peut transmettre de façon fiable un ordre de télécommande (et en le répétant minimum 3 fois), via SERIN, en utilisant ... Un 08M2, et un CD4093.
Ca ne peut que marcher.

- On peut transmettre de façon fiable la même chose (sans devoir le répeter), via RFIN, en utilisant juste un 14M2.

Voilou.
Bonne soirée à tous (et toutes).
 
Last edited:

PieM

Senior Member
A faire un test de ce type, il est dommage de ne pas suivre les recommandations de nos amis anglo-saxons sur le sujet et dont nous avions déjà parlé;
A une époque j'avais écrit :

Concernant la transmission de données via les modules 433, il y a un minimum à respecter si on veut avoir une chance de récupérer les bonnes données à une distance correcte.
Tout a été dit sur le site anglais et explicité par Westaust et Manuka.
Il est illusoire de vouloir transférer une donnée sans avoir auparavant émis un préambule destiné à "réveiller" le récepteur, et le mettre en état de recevoir le bit de start de la trame utile.

Ce préambule est de la forme SEROUT PinTX, N1200, ($55, $55, $55, $55, $55) .
Ne pas utiliser $AA, $AA ... qui n'assure pas une continuité de 0 et de 1: le premier bit et le dernier se trouvant au même niveau que les bits de start et de stop.

Après il faut attendre l'équivalent de la durée de 10 bits avant d'envoyer la suite, c'est à dire environ 16 ms à 600bauds, 8 ms à 1200, et 4ms à 2400 bauds.
donc : pause 8 dans l'exemple.
Seulement ensuite vient la transmission de la donnée réelle, précédée d'une chaîne de validation pour la réception:
SEROUT PinTX, N1200, ("ABC", b0, b1)

pour la réception, la syntaxe sera :
SERIN PinRX, N1200, ("ABC"), b0, b1

Je pense aussi qu'il y a confusion entre préambule, qui est une chaine envoyée avant, et l'identifiant qui fait partie des données utiles transmises.
Le préambule n'est pas décodé à la réception.
 
Last edited:

jojojo

Senior Member
Ok, Piem.
Je n'utilise ici, aucun préambule. Juste les "qualifiers" (plus clair, en anglais).
Pour ce type de test, ça me semble assez inutile, non ?
Vu que je transmet 1000 trames de data, je veux bien en perdre une au réveil du RX. (sur les 400 et des de perdues, pas grave).
Sauf, si tu me dis que l'instruction Serin se "rendort" lors d'une pause de 500ms (délais entre deux trames, envoyées par le TX, dans le test)?
Pourtant, il n'y a pas de TimeOut, ici, hein !

Ou, alors, c'est uniquement au niveau hardware du module RX (Il est illusoire de vouloir transférer une donnée sans avoir auparavant émis un préambule destiné à "réveiller" le récepteur, dis-tu).

Je suis ouvert à cette hypothèse, (hum ...), mais ... Comment fait donc le même RX, pour se réveiller plus tôt, en Manchester, qu'en RS ?
Ya un truc, là, non ?

Donc non, on ne parle pas du module HF, mais bien du picaxe.
Ce préambule est de la forme SEROUT PinTX, N1200, ($55, $55, $55, $55, $55) .
Ne pas utiliser $AA, $AA ... qui n'assure pas une continuité de 0 et de 1: le premier bit et le dernier se trouvant au même niveau que les bits de start et de stop.


Après il faut attendre l'équivalent de la durée de 10 bits avant d'envoyer la suite, c'est à dire environ 16 ms à 600bauds, 8 ms à 1200, et 4ms à 2400 bauds.
donc : pause 8 dans l'exemple.


Si les anglais le disent ...
Je veux bien les croire, mais ...
Dans les tests ci-dessus, je ne suis absolument pas ce protocole.(et les info's passent)

Comme je ne suis pas borné (têtu, si, hein ;) ), je vais tenter cette méthode (demain, fatigué, ce soir), soit ;
- Serout pin x.x , $55,$55,$55,$55
- pause de 16ms
- Serout pin x.x, (qualifiers), trame

(1000 fois, bien-sûr ...)

Bonne nuitée.
 

jojojo

Senior Member
Tout compte fait, non, ce truc me tracasse, Piem.
Ma méthodologie, (pour pas être emm..dé avec des détails) sur ces coups là, c'est de remplacer, au début des tests, le couple TX-RX, par deux bouts de fil. Ce que j'ai fait.
Bien-sûr, ça baigne.
Et ... C'est là qu'est l'os, non :
Il est illusoire de vouloir transférer une donnée sans avoir auparavant émis un préambule destiné à "réveiller" le récepteur, et le mettre en état de recevoir le bit de start de la trame utile.

Donc, par voie radio, il faut (faudrait ?) "réveiller" le coté RX ? Et pas par voie filaire ?...
Je veux bien tout écouter, mais, là, j'avoue ne pas comprendre (bon, je sais, mon dernier neurone, aussi :( )

Edit: Hum ... Je vois peut-être. Le compil attend la durée d'un bit start, plus ou moins aléatoire, par voie radio ? (perturbation ?).
Mais, le risque persite, durant la fameuse pause, de l'apparition d'une autre 'perturbation, non ?
 
Last edited:

PieM

Senior Member
Bonjour jojojo,

je ne fais que reprendre les conseils de nos amis anglais. Personnellement j'ai toujours vu une très grande amélioration de la transmission en utilisant cette méthode.
Je n'ai pas recherché les posts d'origine qui doivent remonter à 2 ou 3 ans ...
Après, dire le pourquoi du comment ...
A mon avis, la trame de préambule est destinée avant tout au module RX, car ce dernier n'est pas totalement transparent vis à vis du début de la transmission.
Concernant le Manchester, rien ne dit que l'implémentation codage / décodage faite par le Picaxe avec RFOUT / RFOUT, n'est que du codage décodage pur... Les puces codeurs décodeurs Manchester ajoutent des bricoles pour fiabiliser la transmission. Et c'est le cas du NKM2401 qui est utilisé au niveau du firmware par le picaxe:

Because the NKM2401 provides preamble, Manchester Encoding and uses CRC
error checksum codes, the wireless link will be more reliable and give greater range
than a direct ‘serout’ control of a wireless module.

En outre il faut compter aussi sur les différences entre modules AM 433.

Si le manchester impose la transmission de blocs de 8 bytes, ce n'est pas le cas de serout /serin, pour lequel il est conseillé au contraire de faire des envois successifs, et éventuellement d'utiliser une fréquence d'horloge plus importante sur le picaxe serin afin de réduire le temps de traitement des bytes reçus qui eux ne sont pas en raw comme dans le Manchester.

dernier truc; l'utilisation du timeout avec du serin wireless ne marche pas, car la moindre réception parasite pendant le timeout met fin à celui-ci.
Je crois qu'il est difficile de comparer deux technologies différentes si on ne respecte pas les contraintes de chacune d'entre elles.
 

jojojo

Senior Member
A faire un test de ce type, il est dommage de ne pas suivre les recommandations de nos amis anglo-saxons sur le sujet

Bon, dont acte.

Le prog TX de ce matin :
Code:
#picaxe 14M2
SetFreq M4
For w13=1 to 1001

Serout B.1,0,($55,$55,$55,$55)
pause 16
Serout B.1,0,("X","Y",$55,$AA,$55,$AA,$55,$AA,$55,"N")'600bds, 
pause 500

Next w13

Serout B.1,0,("X","Y","EOT----N")'600bds,
Rien de changé, coté RX et mouchard, bien évidemment.

Le logger:
View attachment logger.txt

Il ne manque plus que 39 lignes, et il y a une erreur checksum.

Ca semble donc effectivement meilleur.
Mon souci, c'est que je ne vois toujours pas pourquoi ...
$55 ?=? Amphétamine à Pic ? :rolleyes:

J'aimerais faire un test plus poussé (100.000 trames, par exemple, mais, un peu la flemme, là ...)

Je crois qu'il est difficile de comparer deux technologies différentes si on ne respecte pas les contraintes de chacune d'entre elles.

Là, Piem (et c'est assez exceptionnel), je ne partage pas ton avis.
Dans la "vrai vie", on se retrouve souvent avec un CdC dont les contraintes sont difficilement compatibles avec la(les) technologie(s) dispo('s).
C'est bien en comparant, que l'on finit par trouver une solution qui "a des quates". Et les quates, hein ;)

A plus, pour d'autres aventures ...

Edit:
Si un modérateur voulait bien corriger l'erreur dans le titre du post, cela me ferait plaisir.
It will be fine, if a moderator will be able to correct title of this thread. Thanks.
 
Last edited:

PieM

Senior Member
Là, Piem (et c'est assez exceptionnel), je ne partage pas ton avis.
Dans la "vrai vie", on se retrouve souvent avec un CdC dont les contraintes sont difficilement compatibles avec la(les) technologie(s) dispo('s).
C'est bien en comparant, que l'on finit par trouver une solution qui "a des quates". Et les quates, hein ;)
Nous sommes bien dans ce cas:
le CdC ici consiste à envoyer des infos d'un Picaxe à l'autre, avec une techno liée aux types de Picaxes utilisés et en wireless AM 433.
donc soit en techno serin/serout soit en RFout / RFout.

La techno Rfout impose de transmettre 8 bytes de données brutes (pas de #b1) même si on n'en a pas besoin. Et d'utiliser un Picaxe supportant cette instruction, ou utiliser des composants externes type NKM2401. C'est une contrainte.
Serout/serin en wireless impose pour sa fiabilisation à utiliser une certaine procédure purement logicielle . En quoi celle ci est-elle une contrainte ? Dans le timing ? Pas certain que Rfout/Rfin soit plus rapide ... !

On sait de toute façon que la fiabilité est meilleure en Manchester. mais quand on a des picaxes compatibles et que la fiabilité maxi est exigée !

Bon dimanche ... :)
 

jojojo

Senior Member
Serout/serin en wireless impose pour sa fiabilisation à utiliser une certaine procédure purement logicielle

Heu ... Le 4093 ...?
 

jojojo

Senior Member
Tu m'as fait penser à un truc, tiens :
Pas certain que Rfout/Rfin soit plus rapide

Donc, j'ai vérifié
1000 trames en RFIN : de 17.01.38 à 17.10.40 => +/- 9'
1000 trames en SERIN: de 11.17.02 à 11.26.54 => +/- 10'

Un poil mieux (10%) pour RFIN.
 
Top