Transmission via module 433 MHZ, pouvez vous m'aider a résoudre un probleme?

[invite0c63d48f]

Bonjour,

Je travail depuis quelque temps, non sans douleur, a la mise en œuvre d'une communication sans fil entre deux Microcontrôleurs, a l'aide d'émetteurs / transmetteurs Low Cost 433 MHZ.

ce genre:

Pièce jointe 241107

Le but est de transmettre des données sur une distance d'environ 40 Mètres entre les deux cartes.

J’envoie mes données via l'uart, en appliquant un codage Manchester sur mes données avant envoi.

J’ai fait mes essais avec un baud rate compris entre 600 et 2400 avec deux stops bits (qui ont semblé donner de meilleur résultat qu'un seul), sachant que mes deux µc Atmel dispose d'un Quartz pour arrivé a la meilleure précision.

Composition d'une trame, qui doit envoyer 4 octets utiles, soit 8 octets encodés Manchester, a recevoir toutes les secondes.: (magnifique représentation )
Pièce jointe 241109

J’alimente mon Émetteur en 12V, comme l'autorise la datasheet. Tous deux sont dotés d'une antenne de 17CM .

Mais voilà, malgré cela, transmettre 8 octets / secondes a plus de 3 M me semblent compromis, j'ai très peu de trames qui arrive décodées avec un CRC correct. Mon code attend les bits de synchro (0xaa), et une fois l'ack reçu, place les 8 prochains bits dans un tableau, les décode, et vérifie le CRC.

La première étape, les bytes de synchros sont déjà bien difficilement passés. Si je fais une capture avec mon analyseur logique, du signal a la sortie de mon microcontrôleur émetteur, et sur le rx de mon module récepteur 433Mhz, je remarque que systématiquement, l'état haut est plus cours de quelques microsecondes, quelque soit le baud rate choisie. Ce qui a pour effet des États haut plus bref, et états bas plus longs que le signal original. Ce n'est pas flagrant, le signal semble très fidèle au premier coup d'oeil. Exemple @2400bps:
Pièce jointe 241112
Pièce jointe 241113

On voit le décalage de quelques microsecondes, et on voit que le décodeur de mon analyseur logique fait exactement la même erreur que mon µC a priori, il décale les bits... et ne comprend plus rien!

Alors j'en arrive enfin a la partie questions, voyez-vous, du coté configuration du uart, diverses options qui me permettrais de sécuriser mes données et la synchro Emetteur / récepteur? Que me conseillez-vous de mettre en oeuvre pour réussir ma transmission? Mon Approche de la mise en oeuvre et du problème et t'elle la bonne?

Merci à ceux qui auront la patience de me lire et de me comprendre
-----

[invitee05a3fcc]

Remet tes PJs ..... elles ne passent pas !
PS : un lien WEB sur tes modules de transmission ?

[invite0c63d48f]

Étrange j’arrive a les voir. Il n’est pas possible d’éditer le message? Si un modérateur passe par la merci de remettre les PJs Si possible!
PJ 1:
20131204_202822.jpg
PJ2:
trame.png
PJ3&4 :
scan1.png
capt2.png

Les modules sont des ultras lowcost chinois Made In Ebay

[Biname]

Bit stuffing tu connais ?

[A voir en vidéo sur Futura]

[invite01fb7c33]

Pour que ça puisse fonctionner correctement il manque pas mal de chose.
Le codage doit être tel qu'il y a autant de bits à 1 et à 0 dans la trame sur une longueur maximum d'une quinzaine de bits.
Par exemple tu codes tes données sur un nibble et dans un octets tu mets un nibble et son complément.
Il faut des octets (environ 5 à 10ms) de préambules 0x55 pour donner assez de temps au récepteur pour se caler.
Ensuite il faut générer une synchro, un octet 0xFF pour forcer la détection d'un bit de stop, suivit par un octet 0x00h qui crée l'équilibrage des bits et qui ne peut pas être confondu avec le codage en nibble.
Ensuite tes octets de données. Pas besoin de bit de parité avec le codage en nibble qui crée déjà une redondance.


Pas de temps mort entre les octets constitutifs d'une trame.

[invite0c63d48f]

Fanbang, c'est ce que fait déjà mon encodage des octets "Manchester like». (Après peut être que je me trompe, je découvre ça sur le tas, pour répondre à mon projet)
Mon préambule est composé de 3 x (0x55), ce qui fait 12 ms d'après mon Analyseur logique.

Par contre!!!!

Pas de temps mort => j'avais pensé le sens contraire, pour résoudre mes problèmes de synchronisation, je viens de supprimer les délais, aussi court soit -il.

J’envoie maintenant à la suite de mon préambule

(0xfe) //certainement aucune utilité, c'est pour test. Trouvé pendant les recherches sur le bit stuffing avant ton post
(0x7f) //idem
(0xff)
(0x00)

Et mon témoin de synchronisation sur mon récepteur s’affole, ça reçoit du CRC valide à tout va!! Je teste sur la distance maintenant! Je n'aurais jamais beaucoup de donner à transférer, 8 bits valides /seconde suffiront.

Dois-je privilégier la vitesse de transmission (donc plus de répétition par seconde, plus de chance qu'une trame valide arrive) ou diminuer pour tenir de grande distance?
Enfin, je pose la question pour la forme (et parce qu'il semble que tu as résolu mon problème rapidement alors que ça fait des jours à chercher la petite bête, je suis un peu frustré ) je ferai le test en situation sinon.

en tout cas toujours de bons conseils ici c'est un plaisir.

@Biname :non, mais Lecture intéressante, même si cela manque de concret encore pour moi. merci

[invite01fb7c33]

Je n'ai pas réussi à identifier la marque et le modèle de tes circuits 433MHz. Mais ils ont une vitesse de transmission optimum qui se situe environ à la moitié de la vitesse de transmission maximum de la datasheet.

[invite0155ce91]

Pour info j'utilise exactement ces mêmes modules pour de la communication série entre deux pics, à une vitesse de 2400 bauds et tout fonctionne (tester en maison à deux étages d'intervalles).

Par contre, si tu ne l'as pas déjà fait, il faut intégrer une antenne de 17cm (λ/4) sur chaque module, il y a une pastille dédiée.

[invite3c199cf9]

Ça me paraît bien compliqué tout ça.
Personnellement, j'utilise 2 tranceivers à 2,4 GHz, UART configurés à 9600 bd/s.
La transmission consiste en des chaînes de caractères terminées par une somme de contrôle de ces caractères.
A la réception, si la somme de contrôle correspond au message, le module renvoie OK.
Dans le cas contraire, le module émetteur renvoie le message (3 tentatives).
Et ça fonctionne très bien.

[invite0c63d48f]

Fanbang, pour 1,5 $ je n’ai pas le droit non plus de connaitre la «marque»-

Francois06, j'ai bien soudé une antenne 17cm. tu as fait un test de distance en extérieur sans obstacle?

lpt1com2 oui mais dans mon cas, le prix de mes modules 433 mhz est imbattable, et j'ai besoin de transmettre très peu de données, de façon unidirectionnel. Ce module rempli parfaitement cette fonction avec les conseils reçu sur ce post. Les données ne sont pas critique. Tu as un lien vers tes modules?

[invite3c199cf9]

Fanbang, pour 1,5 $ je n’ai pas le droit non plus de connaitre la «marque»-

Francois06, j'ai bien soudé une antenne 17cm. tu as fait un test de distance en extérieur sans obstacle?

lpt1com2 oui mais dans mon cas, le prix de mes modules 433 mhz est imbattable, et j'ai besoin de transmettre très peu de données, de façon unidirectionnel. Ce module rempli parfaitement cette fonction avec les conseils reçu sur ce post. Les données ne sont pas critique. Tu as un lien vers tes modules?

J'utilise ces modules: http://fr.mouser.com/ProductDetail/R...bPM26YyuzQGyK9
Ils sont probablement plus chers que les tiens et on ne peut pas changer le débit, qui est fixe à 9600 bd/s.
Mais l'avantage d'une liaison bidirectionnelle, c'est que tu as la confirmation que l'ordre ou le message que tu as envoyé a bien été reçu.

[invite0155ce91]

Non je n'ai pas encore testé en extérieur, mais en théorie, si l'antenne est bien dimensionnée, ça devrait fonctionner jusqu'à 150m dans un terrain vague sans obstacle (un champ par exemple), et jusqu'à 100m dans un environnement urbain sans obstacle.

[RISC]

Salut,

Regarde cette note d'application pour le PIC12LF1840T48A .
Ce chip intègre un CPU + transceiver RF pour du 433 ou 868 MHz. La note d'application te donnera peut-être des idées au niveau protocole.

a+

[invite0c63d48f]

Bon, 2 étages d'un immeuble sans aucun problème, je suis plutôt étonné. je pense donc que la finalité du projet, 40m en pleine campagne sera atteints sans aucune difficulté. le temps ne me permet pas des tests en extérieur pour le moment

Ce sujet est donc Résolu! pour information, sur ce type de module lowcost, le baudrate de 2400 me semble un très bon compromis

me reste plus qu'a régler un problème de thermocouple fou lorsque j'alimente ma carte avec une batterie, régulé par un lm7805 , alors que je n'ai aucun soucis de relevé lorsque j'alimente avec une autre source.. Mais cela fera certainement l'objet d'un autre topic ou d'une correction logiciel barbare.