Protocole radio V 0.1

Tout ce qui est en rapport avec le développement du protocole radio
Avatar de l’utilisateur
Yaug
Administrateur
Messages : 1466
Inscription : 19 Juillet 2013, 17:09
Localisation : Moselle
Contact :

Protocole radio V 0.1

Messagepar Yaug » 22 Juillet 2013, 15:14

Dans la version 0.1, le protocole radio utilisé est basé sur une trame Home Easy : 32 bits de signal encodé selon le Codage de Manchester

Ces 32 bits sont découpés de la manière suivante :
- 7 bits ID émetteur
- 7 bits ID cible
- 3 bits types de données
- 1 bit de signage
- 14 bits de données

Ces 32 bits sont entourés par des verrous :
- 1 verrou de 2,5 ms
- 1 verrou de 9,9 ms


Ce protocole est amené à évoluer et à être modifier.
Il s'agit actuellement de ne pas trop se prendre la tête dessus, mais si vous avez des suggestions, je suis à l'écoute pour améliorer tout ça.
Il faut garder à l'esprit que plus le signal est court, moins on a de risque de perte d'information.

Avatar de l’utilisateur
Yaug
Administrateur
Messages : 1466
Inscription : 19 Juillet 2013, 17:09
Localisation : Moselle
Contact :

Re: Protocole radio V 0.1

Messagepar Yaug » 23 Juillet 2013, 14:20

Modification du découpage du signal, on adopte la version suivante :

7 bits ID emetteur
7 bits ID cible
3 bits types de données
1 bit de signage
14 bits de données


Cela permet désormais de cibler qui on veut contacter (dans la v1, le master), de spécifier quel type de données on transmet, et d'envoyer 14 bits de données.

Ce protocole n'est pas figé, il est amené à évoluer, donc si vous avez des suggestions n'hésitez pas.

Zescientist
Messages : 360
Inscription : 23 Juillet 2013, 16:38
Localisation : Arques

Re: Protocole radio V 0.1

Messagepar Zescientist » 25 Juillet 2013, 14:04

Au fait, des verrous de 2,5 et 9,9 secondes, ça fait pas un peu beaucoup? :lol:
El'Radioman

Zescientist
Messages : 360
Inscription : 23 Juillet 2013, 16:38
Localisation : Arques

Re: Protocole radio V 0.1

Messagepar Zescientist » 03 Août 2013, 09:06

Histoire de voir les différents changements qui auront lieux, voici les diagrammes de la V0.1 du protocole RF.

Image

Et en ligne :

Image
El'Radioman

Avatar de l’utilisateur
Uggy
Messages : 8
Inscription : 18 Août 2013, 23:33

Re: Protocole radio V 0.1

Messagepar Uggy » 22 Août 2013, 22:34

Yaug a écrit :Ce protocole est amené à évoluer et à être modifier.
Il s'agit actuellement de ne pas trop se prendre la tête dessus, mais si vous avez des suggestions, je suis à l'écoute pour améliorer tout ça.


Salut,

-Est ce qu'il serait envisageable d'utiliser du RS232 (UART) pour passer, du texte a envoyer... a un signal binaire ?

Comme le résultat peut avoir des suites longues de que des 0 ou que des 1, et que ceci risquent de faire perdre la synchro, il faut utiliser (comme dans la version actuelle) le fameux "code de manchester"...

- Est ce qu'il serait envisageable d'envoyer le code de manchester généré... sur du RS232(UART) comme par exemple décrit dans ce document http://www.quickbuilder.co.uk/qb/articl ... _RS232.pdf

Question subsidiaire: est ce qu'il est prévu que le master (Rasp) envoi lui aussi des données ? (Faut que je regarde le code) Si oui, il utilise les GPIO pour parler a l'emetteur 433 ? Si oui, vu qu'il n'est pas temps réel, est ce qu'il sera capable de respercter parfaitement les temps pour les 1 et les 0 ? est ce que ceci ne vas faire par exemple chuter les taux de réussite des envoi de paquets (ou affecter la distance) ?

Avatar de l’utilisateur
Yaug
Administrateur
Messages : 1466
Inscription : 19 Juillet 2013, 17:09
Localisation : Moselle
Contact :

Re: Protocole radio V 0.1

Messagepar Yaug » 22 Août 2013, 22:59

pour le UART, aucune idée, c'est à réfléchir et c'est une option envisageable.

Pour le master, oui il envoie des messages c'est déjà le cas), et il n'a aucun problème avec le temps réel :twisted:
Je l'expliquais lors du dernier aPIro encore, le raspberry pi ne gère pas le temps réel parfaitement, il le simule, mais pour les applications qu'on a actuellement, cela ne pose aucun problème.

Zescientist
Messages : 360
Inscription : 23 Juillet 2013, 16:38
Localisation : Arques

Re: Protocole radio V 0.1

Messagepar Zescientist » 22 Août 2013, 23:08

Salut,

Actuellement on ne travaille pas en mode synchroniser sur une horloge, donc on a pas de problème à ce niveau. De plus, on utilise déjà Manchester.
Concernant le UART je ne comprends pas trop ce que tu veux faire. Te brancher en UART sur un ATmel et retranscrire ce que tu lui envois pour qu'il le transforme en RF? Si c'est ça, j'y ai pensé, pour installer un clavier type désactivation d'alarme, et cela est possible.

Pour les prochaines versions, on compte ajouter une longueur variable à la trame, travailler avec des octets pour transmettre de la data directement au format ISO ou UTF-8.

Il est possible de s'adapter au même protocole que tu fournis pour repasser sur du UART en sortie de l'atmel ou du Rpi réception des trames RF, on extrait que la data comme dans ta d'oc, on la coupe en octets dans un buffer puis on balance. Y as-tu un intérêt spécial?

Le Rpi envois des trames via les gpio. C'est même grâce à ça qu'on transmet l'identifiant qu'utilisera la Node lors de sa première connexion. Pour éviter la perte de paquets, au moment de l'émission, il me semble que l'on passe le Rpi dans un mode particulier avec priorité sur le programme. Je ne suis pas encore au point sur ce côté du projet ^^

Un ACK permettra par la suite de renvoyer les trames qui n'ont pas été reçues.
Le véritable problème est et restera la distance du aux modules low-cost et low-quality que l'on utilise pour le moment.
Optimiser au max, on devrait pouvoir atteindre 20m max avec des murs en obstacles je pense. Le top serait alors un réseau mesh mais ultra-difficile à gérer...
El'Radioman

Avatar de l’utilisateur
thiklop
Messages : 303
Inscription : 22 Juillet 2013, 13:20
Contact :

Re: Protocole radio V 0.1

Messagepar thiklop » 22 Août 2013, 23:09

Si le fait de ne pas être temps réel pose un problème on pourra envisager de tester l'utilisation de Xenomai (dont j'avais déjà parlé), Ce n'est pas du tout user-friendly à l'installation mais si on garde le RPi comme master on pourrait si cela est nécessaire proposer Ydle sous la forme d'une image de carte SD toute configurée avec ce patch.

Je pense qu'on pourra garder cette idée si le temps réel est nécessaire.
Le wiki avec tous les bons tutos : http://wiki.ydle.fr/doku.php?id=accueil

Avatar de l’utilisateur
X@v
Messages : 7
Inscription : 22 Août 2013, 12:59
Contact :

Re: Protocole radio V 0.1

Messagepar X@v » 23 Août 2013, 21:15

Yaug a écrit :Modification du découpage du signal, on adopte la version suivante :

7 bits ID emetteur
7 bits ID cible
3 bits types de données
1 bit de signage
14 bits de données


En lisant la description du protocole je me faisais la réflexion suivante:
7bits, en informatique c'est pas facile a représenter. En prenant 8bits, on peut facilement coder ça en hexadecimal qui permettrait de lire l'adresse des éléments plus facilement pour le débugage...
Retrouvez la dernière version de RPi-Monitor sur http://rpi-experiences.blogspot.fr

Avatar de l’utilisateur
Uggy
Messages : 8
Inscription : 18 Août 2013, 23:33

Re: Protocole radio V 0.1

Messagepar Uggy » 23 Août 2013, 22:15

Pour le master, oui il envoie des messages c'est déjà le cas), et il n'a aucun problème avec le temps réel


Ok.. par "aucun" problème, entend tu que quelquesoit les niveaux de charge du Rasp, tu n'as constaté aucun écart dans le timing de l'envoi des séquences (les micros secondes sont respectées) ?
Ou est ce que l'ecart de timing est si faible qu'il ne pose jamais problème ? ou autre ?

Pour etre franc , en fait j'ai peur que ceci affecte le % de reussite de reception des trames, ou + directement la portée d'emmission. C'est pouquoi j'essaye de comprendre... ;)


Actuellement on ne travaille pas en mode synchroniser sur une horloge, donc on a pas de problème à ce niveau.


Oui mais j'imaginais que le timing devait être rigoureux pour que justement, on puisse décoder les 1 et les 0 de manchester avec + de précision.
Si les timings ne sont pas bons, vu qu'on a pas d'horloge, ca peut faire baisser le taux de reception.. (enfin je pense).



Il est possible de s'adapter au même protocole que tu fournis pour repasser sur du UART en sortie de l'atmel ou du Rpi réception des trames RF, on extrait que la data comme dans ta d'oc, on la coupe en octets dans un buffer puis on balance. Y as-tu un intérêt spécial?


Ca me semblait + facile a comprendre, + "standard", + adaptable (vu que "standard")...


Pour éviter la perte de paquets, au moment de l'émission, il me semble que l'on passe le Rpi dans un mode particulier avec priorité sur le programme. Je ne suis pas encore au point sur ce côté du projet ^^


Ok.. Si tu retrouves avant moi, je veux bien .. ;)



Le véritable problème est et restera la distance du aux modules low-cost et low-quality que l'on utilise pour le moment.


Entièrement d'accord.
C'est là qu'il faut travailler tous ensemble pour améliorer la portée... d'ou mes questions ;)

Merci

A+


Revenir vers « Protocole radio »

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 0 invité

cron