V0.5 : Discussions et avancement

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 :

V0.5 : Discussions et avancement

Messagepar Yaug » 06 Septembre 2013, 10:01

Bonjour à tous,

ce topic est dédié aux évolutions du protocole radio

Au programme de la version 0.5 :
- Trame de taille variable
- Application des améliorations de Zescientist sur le protocole
- Bit de sécurité ?
- Première couche de sécurité

Cette partie est amené à être complétée si l'on avance suffisamment rapidement, ou suite à des suites de tests.

Toute suggestion ou question est la bienvenue

Hot topics v0.5

Master
Nodes
RADIO
IHM
Mobile

Yargol
Messages : 162
Inscription : 23 Juillet 2013, 10:28

Re: V0.5 : Discussions et avancement

Messagepar Yargol » 09 Septembre 2013, 21:00

Quelqu'un a commencer des trucs sur le protocole 0.5 ? Histoire de voir si je peux avancer le master.
Ydle, c'est le projet domotique low cost, qui doit plaire à votre femme @Yaug

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

Re: V0.5 : Discussions et avancement

Messagepar Zescientist » 12 Septembre 2013, 10:33

Allez c'est partie, propositions des points à intégrer ou modifier :
- Trame de taille variable
- Révisions des temps hauts et bas des bits (voir ici)
- Bit de parité

Pour la sécurité, il faudrait au préalable choisir une solution dans ce topic.



Tout le code d'émission et réception est aussi à revoir sur le node et le master.
Actuellement, on mesure la durée de pulsations, ce qui :
- nous oblige à différencier le temps des 1 et des 0
- nous empêche donc de respecter le codage Manchester
- ne permet pas un débit fixe (et la possibilité de le modifier facilement pour jouer sur la distance de réception)
- bloque l'atmel/RPi pendant la mesure, et nous empêche d’exécuter des taches entre 2 mesures sous peine de rater le début de la prochaine mesure
- provoque donc des difficultés pour lire l'octet qui annonce la longueur de la trame à taille variable et agir en conséquence

Première proposition, la plus complexe (de loin) :
- on crée une SPLL (boucle à verrouillage de phase logicielle) qui va se synchroniser avec le signal reçu et corriger les éventuels décalages qui se créeraient au cours de la réception

Seconde proposition, réalisable rapidement :
- une fois les 32 alternances de bits du préambule réceptionnées, et un bit (ou octet) de start reçu, on estime que l'on est "synchronisé" sur le signal et on récupère les datas. Pas de correction de décalage donc


Dans les 2 cas, pour la réception de la trame, on ne mesure plus le temps d'une pulsation (temps haut = temps bas), mais on réalise un ensemble (4 ou 8) de mesures (samples) durant le temps d'émission d'un bit. On moyenne ensuite ces valeurs pour déterminer le bit en question (on évite ainsi les parasites) et on le place dans un tableau qui fait office de buffer.
Pour réaliser ces mesures, on peut se baser sur la comparaison entre 2 millis(). Entre 2 mesures, on a donc le temps de réaliser des tâches simples.


On aura donc 2 solutions pour mesurer la durée d'une trame à taille variable; soit on la détermine lors de la réception de l'octet complet, et on modifie le nombre de bits en attente en conséquence, soit on place tous les bits reçus au fur et à mesure dans un tableau buffer, et à la réception d'un bit ou octet de fin de trame, on regarde le contenu du tableau et on vérifie que la taille reçue correspond bien à ce qu'indiquait l'octet de taille.
El'Radioman

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

Re: V0.5 : Discussions et avancement

Messagepar Zescientist » 23 Septembre 2013, 21:18

Bonsoir,

Voila plusieurs jours que je travaille sur une sal***** d'éventuelle version 0.5 du code pour le traitement du signal reçu.
Les changements :
- Intégration de la trame variable (50%, elle est définie, mais non encore calculée automatiquement, j'envoie la valeur en "dur" pour le moment)
- Intégration d'un bit de parité (50%, pareil, il est définie, mais pas encore calculé automatiquement)
- Passage en véritable manchester 50/50
- La majorité du code (sauf la transmission) est devenu asynchrone, c'est à dire non-bloquant.
- Intégration d'une sPLL inspirée de la librairie VirtualWire qui se synchronise automatiquement sur la trame reçue

Malheureusement, je bloque sur le dernier point. Théoriquement, ça fonctionne à la perfection. J'ai 2 feuilles A4 recto-verso pleines de graph qui font preuves du fonctionnement de l'algo.

Dans la librairie originale, ils utilisent une interruption sur timer. Ainsi, toutes les x microSec, l'arduino lance une fonction, peut importe où il en était dans son code.
Cependant, dans un soucis de pouvoir porter le code sur Rpi, je suis passé outre l'interruption, via une petite fonction que j'ai créé qui vérifie s'il est temps de réaliser une nouvelle mesure de valeur en réalisant une comparaison de macros() (temps en microSec depuis le démarrage du Node). Cette fonction me renvoie n'importe quoi, et malgré pas mal de recherches, je ne trouve pas et je bloque.

J'ai donc comité le code sur le SVN, dans la librairie des nodes, sur la dénomination Ydle_v05 (c'est le fichier Ydle_v05.cpp qui nous intéresse).
Si certain(e)s veulent apporter un regard nouveau sur le problème, je suis preneur!

Normalement, la fonction pll() fonctionne au poil. C'est listenSignal() qui réalise des samples et les appels à pll() n'importe quand.

Merci à ceux et celles qui auront un peu de temps!
El'Radioman

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

Re: V0.5 : Discussions et avancement

Messagepar Yaug » 23 Septembre 2013, 22:12

A terme il va falloir exploiter au maximum les fonctions pour endormir les puces, ce système de micro vérification pour le signal ne va t-il pas à l'encontre de tels endormissements ?

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

Re: V0.5 : Discussions et avancement

Messagepar Zescientist » 23 Septembre 2013, 22:38

Non, ça ne change rien au principe actuel, à part améliorer la qualité. Il y a possibilité de mettre en pause tant qu'on utilise pas les interruptions.
El'Radioman

Yargol
Messages : 162
Inscription : 23 Juillet 2013, 10:28

Re: V0.5 : Discussions et avancement

Messagepar Yargol » 24 Septembre 2013, 10:59

Je viens de jeter un zyeux rapidement :shock:

Ydle_v05::Ydle_v05()
{
Ydle_v05 Ydle;
pinMode(pinRx, INPUT);
pinMode(pinTx, OUTPUT);
pinMode(pinButton, INPUT);
pinMode(pinLed, OUTPUT);
}

Pourquoi Ydle_v05 Ydle; ?

as tu essayer de passer ta variable t_start en volatile ?

A suivre....
Ydle, c'est le projet domotique low cost, qui doit plaire à votre femme @Yaug

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

Re: V0.5 : Discussions et avancement

Messagepar Zescientist » 24 Septembre 2013, 12:08

Yargol a écrit :Pourquoi Ydle_v05 Ydle; ?

as tu essayer de passer ta variable t_start en volatile ?

A suivre....


Je le fait ici, pour ne plus avoir à la faire dans le sketch.


Sinon, non je n'ai pas essayé. Je ne connais pas l'intérêt du type volatile. Je me renseigne de ce pas.
Merci
El'Radioman

Yargol
Messages : 162
Inscription : 23 Juillet 2013, 10:28

Re: V0.5 : Discussions et avancement

Messagepar Yargol » 24 Septembre 2013, 15:08

Je le fait ici, pour ne plus avoir à la faire dans le sketch.


Va falloir que je regarde le code de plus prês, mais en gros je vois même pas a quoi cela te sert :(
Ydle, c'est le projet domotique low cost, qui doit plaire à votre femme @Yaug

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

Re: V0.5 : Discussions et avancement

Messagepar Zescientist » 24 Septembre 2013, 15:53

Comme Ydle_v05 est une classe, je définie Ydle de la classe Ydle_v05, comme ça, dans le sketch, tout mes appels ressemblent à Ydle.getData(), Ydle.listenSignal()...
En fait, du dév C j'en ai fait en cours pendant 6 semaines, après c'est un peu de perso pour m'amuser sur arduino mais ça s'arrête là. Du coup, créé un sketch avec des fonctions basiques, pas de soucis, mais créer une librairie Ydle, c'était assez hard. Je me suis basé sur des exemples pris par-ci par-là pour la façon de coder. Ce qui a donné la librairie qu'on a là.

Autrement dit, il est possible qu'il n'y ait pas à instancier la classe comme ça. J'ai un peu plus d'expérience du java, et fait comme ça, ça y ressemble beaucoup :D
El'Radioman


Revenir vers « Protocole radio »

Qui est en ligne ?

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

cron