FrSky Smart Port RPM and Temperature Sensor

Le RPM et capteur de température FrSky Smart Port a été conçu pour fonctionner avec le systèmes FrSky Smart Port (sans blague !? ), il peut mesurer la vitesse de rotation des moteurs brushless de 1000 ~ 30,000rpm et des températures de -20 à 250 degrés Celsius. Fonctionne avec d'autres capteurs FrSky Smart port, y compris le variomètre, tension de lipo, GPS, capteurs de courant et de vitesse et peuvent être utilisés en même temps.
L'installation est facile, il suffit de connecter le capteur à 2 fils quelconques sur le moteur brushless par le câble JST fourni, puis branchez le câble de port intelligent dans le récepteur permis de port intelligent. 2 sondes de température sont fournis qui sont branché sur le circuit imprimé de sorte que vous pouvez utiliser une seul ou les deux. Fixez le capteur de température à votre ESC pour profiter de tous les avantages et la tranquillité d'esprit de ce produit fantastique.

S'il vous plaît noter: Le capteur RPM / température FrSky intelligente Port est uniquement compatible avec FrSky Smart Port récepteurs activés comme le X8R, X6R et X4R.

Caractéristiques:
• Mesure le RPM de 1000 ~ 30,000rpm
• Mesure la température de -20 ~ 250 ° C
• Indicateur d'état LED
• Bouton poussoir facile mis en place

Spécifications:
Tension de fonctionnement: 4 ~ 10V
Gamme de tension des fils moteur: 2 ~ 12S (7,4 ~ 44.4V)
Plage de mesure du RPM: 1000 ~ 30000
Plage de mesure du capteur de température: -20 ~ 250 ° C
Dimensions: 29 x 20 x 2 mm
Poids: 8g

Ma question est, peut on l'utiliser uniquement pour les sondes de température à votre avis ?

Oui bien sûr.

Bonjour,

J'ai eu beaucoup de mal à étalonner le capteur RPM sur mon Trex-600 ESP. En fait il m'a fallu passer par un petit programme LUA pour calculer les tours du rotor principal. Peut-être qu'avec la version 2.1.1 ce sera plus facile.
Il manque justement à Frsky un capteur RPM optique ou magnétique.

Le problème - majeur - de ces capteurs sPort, est qu'ils sont uniquement utilisables dans un contexte 'FrSky'
(Le sPort est ni 'normé', ni standard (contrairement à des tas de protocoles connus et utilisables sans 'royalties', il est totalement privé) et encore moins documenté.)
L'achat de ces capteurs et modules enferme dans un environnement.
(Les développeurs sont même obligés de signer un accord 'NDA'.)

Curieux - et très malsain - pour une société qui - au départ - a misé sur l'opensource, pour…insensiblement, bloquer le total…

Tu es sûr de cela ???
Car il y a d'autres constructeurs qui fabriquent des capteurs compatible S.Port (SM-Modellbau, N2 Industries LLC, etc...).

D'ailleurs N2 prévoit un capteur de débit de carburant !
http://n2-industries.com/on-the-bench-for-the-future.html

LapinFou a écrit:Tu es sûr de cela ???

oui,
Ce n'est pas parce que # constructeurs construisent, que le protocole est ouvert.
(Il signent un 'NDA' !)
Il n'y a qu'a voir les déclarations 'aigre-doux' de développeurs OpenTX :
* Authors (alphabetical order)
* - Andre Bernet <…>
* - Andreas Weitl
* - Bertrand Songis <…>
…)
sur le sujet du sPort.:
"Unfortunately FrSky does not provide documentation of the FrSky S.Port protocol to everyone but only so selected developers after the sign an NDA.
We have not seen the official documentation (and of course not signed and NDA).[…] "
(https://code.google.com/p/telemetry-convert/wiki/FrSkySPortProtocol)

D'ailleurs, facile. Testons. Comment interfacer un module capteur sPort sur autre chose :
ex. :
- un contrôleur de vol.
- un "intégrateur" (pour un affichage OSD)
…euh
Réciproquement, comment récupérer des informations de capteurs aux normes I2C sur un RX via sPort ?

FrSky, après avoir joué l'ouverture et installation de sa base, joue (?) un jeu très…perso. ($£€…)
Ce qui l'éloigne de la philosophie OpenTX (opensource).

OK.

T'es complètement à côté de la plaque, y'a à ma connaissance déjà au moins 6 fabricants tierce partie qui fabriquent des capteurs compatibles smart port, ce qui est vraisemblablement plus que n'importe quel autre système RC.

Pour ce qui est de la doc il suffit d'envoyer un mail à FrSky leur présentant ce que tu souhaites développer et ils te l'enverront. Ils te feront peut-être signer un NDA, mais c'est pas pour rendre "difficile" l'utilisation de leur bus, c'est simplement pour que les demandes doivent passer par eux et donc qu'ils puissent savoir qui a l'intention de l'utiliser et pour quoi. Les autres fabricants de radios font exactement la même chose.

Et si ça t'embête de demander, vu le nombre de projets open source qui l'utilisent (contrairement à d'autres...) t'as même déjà tout sous la main pour ne pas avoir besoin de la doc.

elj4Taranis a écrit:Le problème - majeur - de ces capteurs sPort, est qu'ils sont uniquement utilisables dans un contexte 'FrSky'
(Le sPort est ni 'normé', ni standard (contrairement à des tas de protocoles connus et utilisables sans 'royalties', il est totalement privé) et encore moins documenté.)
...

J'aimerais bien connaitre les protocoles normés, standards, connus et sans royalty auxquels tu penses ?

elj4Taranis a écrit:... D'ailleurs, facile. Testons. Comment interfacer un module capteur sPort sur autre chose :
ex. :
- un contrôleur de vol.
- un "intégrateur" (pour un affichage OSD)
…euh
Réciproquement, comment récupérer des informations de capteurs aux normes I2C sur un RX via sPort ? ...

Ce n'est pas très difficile, je l'ai fait moi-même, sans signer de NDA simplement en regardant les projets open source existant sur le sujet : https://frskytaranis.forumactif.org/t1291-arduimu-v3-gps-s-port

Plusieurs contrôleurs de vol ont déjà mis en œuvre une sortie s.port dans leur soft pour pouvoir les brancher directement sur la prise s.port du récepteur et envoyer des données télémétriques à l'émetteur.

Un affichage sur un OSD, ça existe déjà et le code est disponible : http://diydrones.com/forum/topics/osd-for-frsky-smart-port-telemetry-based-on-minimosd-extra

Kilrah a écrit:T'es complètement à côté de la plaque,

merci

Sans doute me suis-je mal exprimé. J'ai dit :
- que le sport était basé sur un protocole privé. Sauf erreur, c'est bien le cas.
- qu'inventer un nouveau protocole de com est une façon de fermer, alors qu'il existe des protocoles documentés.
- que FrSky, n'a pas diffusé ses protocoles, ce qui empêche potentiellement une utilisation croisée :
Comment je branche un module sPort sur un pixhawk ? Si tu as la solution, fais le moi savoir.
Comment utiliser sur un RX FrSky, un GPS néo ? Même question (dans l'autre sens).

Com (protocoles), ouverture ou privatisation
# positions concernant les protocoles de com. (du plus ouvert, au plus fermé) :
- on se conforme aux normes
- on se conforme aux standards (un standard de fait, n'est pas une norme)
- on invente - et on publie les spécifications
- on invente - et on garde 'secret' (ou sous 'NDA')
- on ne dit rien du tout, même sur demande

Kilrah a écrit:c'est pas pour rendre "difficile" l'utilisation de leur bus, c'est simplement pour que les demandes doivent passer par eux

Exactement la démonstration du degré d'ouverture.

A contrario, si j'ai un capteur I2c, bus-can, Nmea, sBus,… je suis libre d'acheter un composant chez l'un, un autre ailleurs. (parce qu'ils sont 'ouverts', ou - au moins documentés de telle sorte que l'on puisse interfacer.)
Juste ce que je voulais mettre en évidence.
Et je répète : ce choix est malsain et contraire à l'idée d'open source. Et ce n'est pas parce que d'autres fabricants de 'radio' ont des démarches privatives identiques que cela justifie pour autant de 'fermer'.

Le problème de ces modules c'est que l'option choisie par FrSky est loin d'être la plus ouverte possible.
C'est même le contraire d'une volonté d'interopérabilité.
Après, on peut toujours considérer que "la liberté, c'est le choix de sa prison"

Maintenant, si je peux acheter - à coût pas trop élevé - un convertisseur de protocole sport-i2c (et/ou d'autres), là, je veux bien changer d'avis
Car, si on me dit :
- il existe des contrôleurs de vol avec un sport, je dit : dommage, pas les miens (des pixhawk)
- tu peux faire toi-même, je dis "non merci", je veux trouver 'sur étagère'

elj4Taranis a écrit:
Car, si on me dit :
- il existe des contrôleurs de vol avec un sport, je dit : dommage, pas les miens (des pixhawk)
- tu peux faire toi-même, je dis "non merci", je veux trouver 'sur étagère'

Ca existe (£35, ~ 50€) : http://www.droneshop.biz/radio-gear/telemetry/taranis-mavlink-apm-pixhawk-telemetry-adapter.html

elj4Taranis a écrit:...Maintenant, si je peux acheter - à coût pas trop élevé - un convertisseur de protocole sport-i2c (et/ou d'autres), là, je veux bien changer d'avis ...

Un convertisseur s.port-i2c, ça ne veut rien dire.

i2c est un protocole qui définit la couche de communication (câblage et comment circule les données entre les nœuds) mais pas ce qui y circule. s.port est un protocole qui définit ce qui circule (quel est le format des données qui circulent et comment les esclaves répondent aux requêtes du maître) sur la couche de communication (tout bêtement du série 8 bit à 57600 bauds).

Si tu avais dit, un convertisseur nmea -> s.port ou MAV-Link <-> s.port, alors d'accord, là ça aurait du sens mais pas i2c -> s.port, ni can-bus <-> s.port. Je ne connais pas les spécifications du S-Bus (pas le sbus de Futaba mais le Smart-Bus ou Saia-Burgess Bus) alors je ne peux pas me prononcer à son sujet.

elj4Taranis a écrit:- que le sport était basé sur un protocole privé. Sauf erreur, c'est bien le cas.

En effet.
Par contre:

elj4Taranis a écrit:- qu'inventer un nouveau protocole de com est une façon de fermer, alors qu'il existe des protocoles documentés.

c'est pas parce que le protocole est nouveau que c'est forcément une volonté de fermer, ça peut simplement être qu'il n'y a pas de protocole documenté adapté à l'application.

elj4Taranis a écrit:
- que FrSky, n'a pas diffusé ses protocoles, ce qui empêche potentiellement une utilisation croisée
[...]
Le problème de ces modules c'est que l'option choisie par FrSky est loin d'être la plus ouverte possible.
C'est même le contraire d'une volonté d'interopérabilité.

Tu as dû louper le passage de mon post mentionnant 6 fabricants qui font des capteurs compatibles, dont l'intéressant Anysense qui sait croiser 8 systèmes de télémétrie différents dont le smart port. Vu que tu veux du "sur étagère" ca peut t'intéresser.

elj4Taranis a écrit:
Comment je branche un module sPort sur un pixhawk ? Si tu as la solution, fais le moi savoir.

Tu peux acheter le traducteur dont Sacre100 t'a donné le lien, ou le construire toi même (le code est open source).

elj4Taranis a écrit:
Comment utiliser sur un RX FrSky, un GPS néo ? Même question (dans l'autre sens).

Tu peux aller voir d'un côté dans le code de cleanflight et de l'autre dans le code d'OpenTX comment c'est fait, en 1h tu devrais avoir compris.

C'est marrant, d'un côté tu dis vouloir des capteurs tierce partie "sur étagère" et de l'autre tu parles d'interfacer des capteurs I2C ou CAN, qui nécessiteraient forcément le développement d'un adaptateur pour la partie matérielle et d'un programme pour la conversion. Or les 2 options sont précisément à ta disposition, donc je vois pas le problème..

Tu as raison, j'aurais du dire : interfacer/utiliser.
(au sens de dire qu'il est possible d'utiliser des PWM sur un sBus.)
Ce qui me fait râler, c'est que - pour ne prendre qu'un exemple - le hub sPort est organisé autour d'un stm32 F103C, qui dispose de ports standards (I2C, SPI,…) donc des 'ponts' devraient être possibles avec de la bonne volonté d'ouverture de la société.
En fait, le mauvais choix terminologique est impardonnable si je me souviens que de formation de base, je suis ingénieur "électronique, systèmes asservis et informatique"

Mais le problème n'est pas sur le choix malheureux des mots, c'est sur la possibilité - ou non - de connaître le protocole, pouvoir l'utiliser et trouver des 'ponts' qui permettent d'utiliser des données issues de capteurs déjà sur le marché
A priori le "Taranis Mavlink APM Pixhawk Telemetry adapter" (merci pour l'info) est une partie de la réponse [je le citerai dans le manuel !], mais cela renforce l'idée que la bonne démarche (actuelle) est d'acheter des capteurs pour le pixhawk et en faire profiter la Taranis, pas l'inverse…
Si je veux acheter des capteurs FrSky - il m'est indispensable de pouvoir envoyer les données issues des capteurs FrSky vers le contrôleur de vol.
Là, si tu as un lien …

En fait, dès que j'ai un transfert d'information bi-directionnel, je n'ai plus rien à dire, car j'ai mon bonheur

Et pour répondre a Kilrah : non, je n'ai pas envie de regarder dans le code !
La réponse de Sacre 100 me convient mieux : j'achète des capteurs pour mes pixhawk et je les réinjecte vers la Taranis.

elj4Taranis a écrit:
Si je veux acheter des capteurs FrSky - il m'est indispensable de pouvoir envoyer les données issues des capteurs FrSky vers le contrôleur de vol.
Là, si tu as un lien …

Aha, c'est ça que tu cherches, ça aurait été plus simple de le dire dès le départ plutôt que de te plaindre.

Bref en effet dans ce sens là ça n'existe effectivement pas... mais ce n'est pas une question d'ouvert/fermé, c'est simplement que personne ne s'est apparemment jamais intéressé à le faire. Toute l'info est là pour par contre.

elj4Taranis a écrit:...
Ce qui me fait râler, c'est que - pour ne prendre qu'un exemple - le hub sPort est organisé autour d'un stm32 F103C ...

De quel hub s.port parles-tu, car justement avec le s.port, il n'est plus nécessaire d'avoir un hub ?

elj4Taranis a écrit:... ports standards (I2C, SPI,…) ...

I2C, c'est 4 fils (SDA, SD, plus la masse et le +), SPI, c'est 6 fils (SCLK, MOSI, MISO, SS, plus la masse et le +), Frsky a fait le choix d'utiliser des câbles servo standard avec 3 fils seulement (signal, + et -), c'est pas plus mal, ça simplifie vraiment la vie.

CAN aurait pû être un bon candidat (3 fils, signal, masse et le +) avec une vitesse de communication plus élevé mais la transmission radio entre le récepteur et l'émetteur (down-link) aurait-elle supporté une telle vitesse tout en permettant une transmission suffisamment fiable et rapide entre l'émetteur et le récepteur (up-link).

A mon avis, le problème ne se résume pas à l'utilisation ou non d'un standard, Frsky a fait un choix, même s'il ne l'a pas publié, son protocole est connus, plusieurs fabricants produisent des capteurs et plusieurs amateurs ont réalisé leur propre solution et en ont publié le code, que demander de plus.

elj4Taranis a écrit:... la bonne démarche (actuelle) est d'acheter des capteurs pour le pixhawk et en faire profiter la Taranis, pas l'inverse …

Deux remarques, je n'ai pas vraiment vu sur le net de capteur pixhawk mais bon je n'ai pas vraiment cherché non plus. Ensuite, je n'ai pas vu non plus de spécifications d'un protocole qui permettraient à des capteurs de se connecter aisément au pixhawk. Au contraire, il me semble que c'est le pixhawk qui se plie aux spécifications définies par les capteurs et que son soft est adapté de cas en cas en fonction du capteur.

Autrement dit, si je comprend bien le pixhawk, ne peuvent être utilisés que des capteurs connus du pixhawk dont le soft a été adapté pour eux. Si on le souhaite, le pixhawk peut reproduire les données de ces capteurs sur une sortie série en utilisant le protocole MAV Link. Et cette sortie peut être récupérée et transformée en s.port mais aussi en Hott de Graupner, ou ex-bus Jeti ou ..., peu importe.

elj4Taranis a écrit:... Si je veux acheter des capteurs FrSky - il m'est indispensable de pouvoir envoyer les données issues des capteurs FrSky vers le contrôleur de vol. ...

Dans ce sens, que dire. Tout d'abord, le pixhawk a-t-il une entrée pour de tels capteurs ? Il semble que non excepté pour les capteurs Hott de Graupner et encore, je ne sais pas si c'est opérationnel ou pas. Toutefois, si pixhawk  à publié une interface standard qui s'appuie sur un couche physique de son choix (i2c, can, SPI, sbus ou autre, peu importe) et qui définit le contenu des messages qu'il sait traiter, développer un convertisseur s.port -> pixhawk ne pose aucun problème.

A noter que le protocole Hott est très similaire au protocole de Frsky (half-duplex 8 bits sur un seul fil à 19'200 baud avec un maître qui interroge chaque capteur à son tour). Les messages sont différents mais ils ont été décodés en quelques heures à l'instar du protocole s.port.

A ma connaissance, il n'y a que Jeti qui a publié ses protocoles. Ils sont tout à fait similaires à ceux de Frsky ou Graupner (comunication série 8 ou 9 bits sur un seul fil à 9'600 bauds, 125 ou 250 kbauds selon la version) mais là aussi, le contenu des messages est propre à Jeti.

Kilrah a écrit:

elj4Taranis a écrit:
Si je veux acheter des capteurs FrSky - il m'est indispensable de pouvoir envoyer les données issues des capteurs FrSky vers le contrôleur de vol.
Là, si tu as un lien …

Aha, c'est ça que tu cherches, ça aurait été plus simple de le dire dès le départ plutôt que de te plaindre.

Bref en effet dans ce sens là ça n'existe effectivement pas... mais ce n'est pas une question d'ouvert/fermé, c'est simplement que personne ne s'est apparemment jamais intéressé à le faire. Toute l'info est là pour par contre.

Comme je l'ai dit plus haut, pour autant que le pixhawk aie une entrée idoine pour cela et que l'info soit disponible côté pixhawk mais il me semble que ce n'est pas le cas.

Kilrah a écrit:Aha, c'est ça que tu cherches, ça aurait été plus simple de le dire dès le départ plutôt que de te plaindre. Bref en effet dans ce sens là ça n'existe effectivement pas...

Comme si j'avais fait mystère des besoins.
Je ne me plains pas, je constate que je ne peux utiliser.
Ce qui est totalement différent.

Je veux un 'truc' utilisable, non fermé, publié.
Le sPort, n'est pas publié, n'est pas ouvert.
Ah, oui, mais, si vous montrez patte blanche et que vous donnez des gages…
Yes, un mode de fonctionnement justement, que je refuse.

Tout a été dit.
J'ai deux choix :
- Je peux utiliser des capteurs (& protocoles standards) a/c de mes pixxhawk, qui publient tout ce qui les concerne.
* Je fait. (Et je prend la solution 'pont' qui me permet d'utiliser ailleurs, mes investissements initiaux.)
- Je ne peux utiliser des capteurs sPort (pour des raisons de confidentialité,…)
* J'évite. (En fait, il faudrait sans doute être stupide pour choisir une solution plus fermée qu'une autre, non ?)

Point barre
Sauf si… et jusqu'à ce que des ponts réciproques existent.
Mais auparavant, choisir des capteurs spécifiques FrSky est une hérésie. (Sauf à juger l'investissement comme jetable.)

elj4Taranis a écrit:
Je ne me plains pas, je constate que je ne peux utiliser.

Ben bien sûr, suffit de les brancher à ton récepteur FrSky... ce pourquoi ils ont été conçus.

Si ton problème est que tu ne peux pas prendre un capteur de courant FrSky et le brancher sur ta Pixhawk pour qu'elle puisse lire le courant consommé n'a rien à voir avec ouvert ou fermé. La Pixhawk a son capteur standard, donc personne s'est amusé à ajouter le support pour un autre, d'ailleurs lequel, y'a 10 fabricants et formats différents? Tout comme dans l'autre sens:

elj4Taranis a écrit:
- Je peux utiliser des capteurs (& protocoles standards) a/c de mes pixxhawk, qui publient tout ce qui les concerne.  

OK, et ils sont documentés soit, mais c'est pas pour autant que tu pourras prendre ton capteur pixhawk et le brancher sur un récepteur Futaba.

Si tu veux des ponts rien ne t'empêche d'en concevoir! Tout le monde s'est contenté des solutions "qui vont ensemble" jusque là, suffit que quelqu'un se lance

Sacre100 a écrit:

elj4Taranis a écrit:... […] - le hub sPort est organisé autour d'un stm32 F103C ...

De quel hub s.port parles-tu, car justement avec le s.port, il n'est plus nécessaire d'avoir un hub ?

"pas nécessaire"… Cela dépend.
Quand on prend un 'capteur' température (par exemple) [le nom 'capteur' est un peu ambigu], il faut le hub [nom également ambigu] - a priori - pour l'utiliser (ou un autre intermédiaire).
Parce que le hub n'est pas la 'prise multiple' suggérée par le nom, c'est en fait une unité de traitement pour les éléments connectés de type simple - dépourvus de moyen de communiquer.
Il suffit de l'ouvrir

Tu mélanges apparemment les 2 systèmes (ancien - D - hub) et smart port.
En smart port on a des "capteurs" intelligents.

Kilrah a écrit:Ben bien sûr, suffit de les brancher à ton récepteur FrSky... ce pourquoi ils ont été conçus.

C'est ce que je conteste (comme finalité), le fait qu'ils ne soient conçus que pour…

Mais, c'est bien d'admettre que c'est particularisé, privatisé, non universel.

Brisons la.
Il n'y a aucun intérêt à débattre si les prémisses de raisonnement ne sont pas les mêmes.

Toi, tu dis : ah ben, ils sont connectables sur le RX Taranis.
Moi, je dis: je veux des capteurs universels.

Divorce

Mais ne fait pas prendre des vessies aux gens pour des lanternes.
Il y a une nuance entre des capteurs utilisant des protocoles standards et d'autres restreints à un environnement.

elj4Taranis a écrit:Moi, je dis: je veux des capteurs universels.

Et moi je dis que pour qu'il y ait des capteurs universels ça ne suffit pas que quelqu'un en conçoive et diffuse les specs, il faut ensuite que les autres l'adoptent... ce qu'en général personne ne fait (et ne souhaite faire) actuellement pour raisons diverses qu'elles soient techniques ou commerciales.
De nouveau quiconque voudrait utiliser les capteurs smart port (comme l'anylink) pourrait le faire.

Le problème n'est pas où tu le vois.

Kilrah a écrit:

elj4Taranis a écrit:Moi, je dis: je veux des capteurs universels.

Et moi je dis que pour qu'il y ait des capteurs universels ça ne suffit pas que quelqu'un en conçoive et diffuse les specs, il faut ensuite que les autres l'adoptent... ce qu'en général personne ne fait (et ne souhaite faire) actuellement pour raisons diverses qu'elles soient techniques ou commerciales.

Le problème n'est pas où tu le vois.

Excellent exemple.
À méditer.

J'ai des standards ouverts et adoptés.
La preuve, mes pixhawk les comprennent. (Ce n'est pas pixhawk qui définit !, il utilise ceux établis, ouverts.)

Et toi, tu me propose le 15e standard, non universel, masqué.
Excellent comme contre raisonnement