Aller au contenu


Photo
- - - - -

Meilleure technologie RF pour la communication de données ?


9 réponses à ce sujet

#1 azerty136

azerty136

    Nouveau membre

  • Membres
  • 6 messages

Posté 17 novembre 2015 - 11:55

Bonsoir,

 

Je travaille sur un projet avec un ami: Une main robotique contrôlé à distance (RF). Nous utilisons les flex sensor pour les mouvements de la main (une peu comme ça: http://www.instructables.com/id/Arduino-Wireless-Animatronic-Hand/) etun MPU-6050 pour l’accélération du bras.

Du coup, je cherche le meilleur moyen de transférer des données, j'ai un module bluetooth un Wifi et des émetteur-récepteur 433Mhz mais je peux utiliser d'autres moyens de communication.

Ma question:"Quelle technologie RF la plus sûr pour le transfert de données ?".

Merci de votre réponse, 

Et bonne réflexion.

 



#2 cocothebo

cocothebo

    Membre passionné

  • Membres
  • PipPipPip
  • 341 messages
  • Gender:Male

Posté 18 novembre 2015 - 06:20

Salut,

 

Il faut, je pense, un peu plus préciser ton projet.

Un contrôle à distance peut en exagérant aller de quelques mm (style nfc) à des milliards de km (contrôle à distance d'une sonde voyager ;))

 

De même, qu'appelles tu sureté de transfert de données? C'est de la sureté de fonctionnement (un lien qui est stable, peu perturbé, peu sujet aux parasites) ou de la sureté style n'importe qui peut pas parler avec mon recepteur (authentification et potentiellement chiffrement des données)?

 

Il faut aussi te poser la question du débit qui te sera nécessaire (les tranceiver 433MHz ont souvent un débit très faible comparé à du Bluetooth/Wifi par exemples).

 

Bon courage!



#3 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 18 novembre 2015 - 07:03

En plus, comme élément de choix, je rajouterai:

 * le temps de réponse. Très faible en bluetooth (si bien configuré), et plus élevé en WiFi (jusqu'à plusieurs dizaines de millisecondes)

 * la "charge logicielle" : en WiFi, tu es obligatoirement obligé d'intégrer toute la couche IP dans ton contrôleur, ce qui n'est pas forcément simple, mais qui est plus souple. D'autres liaisons (bluetooth ou autre) sont beaucoup plus simples à mettre en oeuvre, et transportent une simple liaison série point à point.

 

Leon.


BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#4 Donpi

Donpi

    Habitué

  • Membres
  • PipPip
  • 154 messages

Posté 30 novembre 2015 - 09:47

La couche IP par contre garantie la qualité du message, car le controle de flux se fait directement à ce niveaux.



#5 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 30 novembre 2015 - 07:13

Oui, mais tu peux faire BEAUCOUP plus simple que IP pour garantir :

* la bonne transmission des données (répétition en cas de perte)

* la non corruption des données

Même inventer son propre protocole pour faire ça, si tu n'as que des besoins simples (liaison point à point mono-application), c'est parfaitement faisable, je l'ai déjà fait sur des liaisons séries non fiable (radio).

 

Chercher à faire de l'IP à tout prix n'est pas toujours une bonne solution.

L'IP peut être une bonne solution dans pleins d'applications, surtout si tu as beaucoup de données à échanger, ou beaucoup de types de données à échanger, ou si tu veux utiliser des protocoles applicatifs déjà basés sur IP.

 

Leon.


BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#6 cocothebo

cocothebo

    Membre passionné

  • Membres
  • PipPipPip
  • 341 messages
  • Gender:Male

Posté 30 novembre 2015 - 10:17

Oui utiliser IP ici, c'est presque comme chercher a tuer des moustiques à coup de fusil.

 

D'après la description sommaire du projet, ce n'est pas un réseau qui est nécessaire, juste transmettre des données d'un point A à un point B, A et B parfaitement connus.

Je dirai quelque chose de très proche d'un UART (sans fil) qui nécessite (peut être)un certain niveau de QoS, au minimum une certaine résilience.

 

IP est plus orienté réseau sans connaissance du chemin entre les deux points de communication. Et de toute façon ne permet pas du tout de faire du QoS, IP est un protocole non fiable qui ne permet de vérifier la corruption des données, ni la perte de paquet, bref IP ça sert juste à essayer de faire aller un paquet de donnée de A à B.

En revanche certes si on reste sur le modèle OSI, ICMP qui est encapsulé dans IP (et donc devrait pratiquement être une nouvelle couche) permet de réaliser du cette gestion d'erreur. Et pour la QoS, la c'est plus sur l'infrastructure qu'il faut être capable de différencier les flux et de permettre de prioritiser certains flux, et il faut alors étiqueter chaque paquet pour pouvoir savoir quoi en faire (par exemple MPLS le fait).

 

 

Bref tout ça pour dire et revenir au fait qu'il faudrait mieux définir la problématique pour savoir si tel ou tel protocole est plus adapté qu'un autre.

 

Cocothebo



#7 azerty136

azerty136

    Nouveau membre

  • Membres
  • 6 messages

Posté 30 novembre 2015 - 10:41

Merci de toute vos réponses et désolé la lenteur de ma réponse, 

 

Alors, effectivement je me rend compte que je devrait plus décrire mon projet. 

Alors, tout d'abord, j'ai besoin de fiabilité puisque en fait, je vais envoyer les données de 5 valeurs analogiques les unes après les autres, donc si j'ai une données n'est pas reçu ou émis, cela va décaler toutes les données. Mais effectivement je trouvé ça lourd d'utiliser la WIFI car il est composé d'énormément de protocole (20% je crois). 

Enfin, je ne l'avais pas dit mais je veux envoyer des données d'un point A à un point B (et pas le sens inverse).

Mais Leon, comment inventer un protocole ?

Encore merci de vos réponses.



#8 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 01 décembre 2015 - 06:45

Si tu te bases par exemple sur une liaison série (module bluetooth utilisé en liaison série), alors tu peux transmettre une "trame" facile à coder et décoder, qui contient successivement:

* un mot de 2 à 5 octets, toujours le même, servant de préambule, permettant de détecter le début de ta trame

* tes données, toujours dans le même ordre

* un octet de contrôle d'erreur de type checksum ou CRC

* un mot de fin de 1 octet, toujours le même

 

Le récepteur vérifiera tout ça :

* il attend le préambule avant de commencer à décoder. C'est ça qui va permettre de synchroniser le décodage.

* il vérifie qu'il n'y a pas d'erreur grâce au checksum ou CRC

* il vérifie la présence du mot fin

Seulement si ces conditions sont remplies, alors il considère les données reçues comme valides.

 

Leon.


BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#9 Donpi

Donpi

    Habitué

  • Membres
  • PipPip
  • 154 messages

Posté 01 décembre 2015 - 07:27

Tout est très vrai,

je dirais juste :

 

Si c'est un projet amateur / personel, par besoin de réinventer la roue, mais pourquoi pas.

Si c'est un projet professionel, surtout pas réinventer la roue car trop cher.

 

A+



#10 Donpi

Donpi

    Habitué

  • Membres
  • PipPip
  • 154 messages

Posté 01 décembre 2015 - 04:43

J'ai reçu ça dans une newletter si ça t'interesse .

 

https://www.cooking-...900-915-433-mhz

 

22km tu vas déjà un bout





Répondre à ce sujet



  


0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users