Transmission de signaux tout ou rien par Bluetooth

[j.f.]

Salut,

J'ai cherché s'il existait des dispositifs peu onéreux et de petite taille (pas plus gros qu'un mini dongle USB et intégrant une pile), permettant la transmission de signaux tout ou rien par Bluetooth. Je n'ai rien trouvé.

Le but est simple : transmettre des impulsions de quelques kHz maxi vers un PC ou un Pocket PC... But = tachymétrie et odométrie.

J'ai trouvé quelques systèmes de télémesure (température, pression, etc.) très encombrants et en fait sans intérêt dans mon cas.

Auriez vous connaissance de l'existance de modules miniatures transmettant juste une information tout ou rien ? (aucune intention de tenter la programmation d'un microcontrôleur et la réalisation d'un transmetteur)

 

[wintereivax]

Salut,

Alors à froid comme cela, je ne pense pas que cela existe "tout fait". Ou alors en prenant une solution peut-être plus évoluée et en le simplifiant. J'imagine que des solutions de transmissions "bluetooth" doivent exister en automatisation, et peut-être cela serait possible de brancher un autre module dessus...

Par contre, cela pourrait être un projet "rapide" pour les cadors de ce forum. Sans trop rentrer dans la programmation/réalisation, il y a des chip qui font une interface "facilitée" entre le protocole bluetooth et un port RS232 classique, ce qui fait un truc rapide à programmer en évitant tout le bordel du protocole bluetooth, ainsi que le driver coté PC. A l'époque, j'avais bossé avec le lmx9820 de National Semiconductor. J'arrête le HS la

Bonne continuation, Xavier

 

[Sébastien37]

Salut

As-tu regardé sur Lextronic ?

Un exemple de module bluetooth chez eux :
http://www.lextronic.fr/P1106-module-hy ... 03ala.html

 

[jms]

il existe des dongle BT sur port usb, ça ne ferait pas l'affaire ?

 

[j.f.]

Ben non, malheureusement, ce type de module ne convient pas puisque c'est juste un émetteur récepteur avec un CODEC, et que ce n'est pas autonome.

Ce que je cherche, pour résumer, c'est un produit fini avec juste une entrée tout ou rien. Ou un truc genre capteur de proximité (magnétique, opto...) sans fil.

Un dongle ne va pas non plus : c'est juste un émetteur récepteur piloté via le bus USB. C'est à ça que j'ai pensé au début, mais a priori on ne peut pas l'utiliser seul, sauf à émettre en tout ou rien (façon Morse aux tout début de la TSF). Dans ce cas, c'est inexploitable par un récepteur Bluetooth puisqu'il n'y a pas de vraie communication.

Le genre de truc que je recherche existe :

http://velocomputer.com/faces/mainpage. ... sor3_6.jsp

Une bidouille, mais c'est bien trop gros !!!!

http://www.electronics-lab.com/projects ... index.html

 

[romain_cvra]

Salut,

Tu as déjà regarder du coté des modules zigbee?

A mon avis, tu aurais meilleur temps de calculer ta tachymétrie et ton odométrie. Directement ou il y a le capteur. Puis de transmettre la valeur finale via un module sans fils. Se sera bien plus précis et plus rapide!

Je suis pas sur que tu trouve un module sans fils qui puisse transmettre des puls au khz. Sur tout que ces modules font divers vérification pour être sur de pas avoir perdu de l'information en route...

A+

 

[pierrepmx]

Il y a des modules série bluetooth.

Par exemple, à 19€ :

http://www.eikonsite.it/products/blueto ... LL240.aspx

Ce module-ci a des GPIO, mais je ne vois pas d'infos pour leur programmation.
C'est le site d'un intégrateur/(fabriquant ?), pas juste un revendeur, ils devraient pouvoir offrir des infos techniques intéressantes. Ils sont en Italie.

Sinon, utiliser en mode RS232 transparent, avec un simple µC (ça commence en 8 broches avec un PIC12 ou un MSP430).

Défaut: c'est pas du "tout fait". Rédhibitoire dans ce cas ?

Les avantages collatéraux sont :
- permet de traiter les impulsions en local et de n'envoyer que des infos synthétiques.
- évite la perte d'impulsion due à des défauts de transmission (erreur qui est cumulative).
- fonctionnement indépendamment du PC maître (mode autonome), si cela a un sens dans ton application.

De plus, la liaison peut être exploitée de façon bidirectionnelle, si nécessaire.

P.S. C'est comme les moteurs d'avance de fraiseuse: ça chauffe pas

 

[pierrepmx]

PS Je partais du principe que tu développais le soft ad'hoc sur le PC ou le Pocket PC.

Aussi, le module en question a également la liaison audio Bluetooth. Ce peut donner des idées.

 

[j.f.]

Merci pour ce lien, mais après avoir lu les docs, cherché sur le chipset utilisé, etc., ça coince toujours.

Manifestement, le module est livré avec un firmware destiné à en faire un câble RS232 immatériel. Ce n'est pas ça que je recherche.

Ce que j'aurais voulu, c'est un truc dans ce genre, mais avec juste une entrée. Quand j'ai vu les 8 PIO, je me suis dit "c'est bon", oui, mais sans firmware pour dire quoi envoyer quand on les titille, ça semble cuit. 500 pièces pour faire flasher autre chose...

Il me semble qu'on peut faire de la transmission minimaliste via RS232 sans passer par Rx/Tx, juste avec les RTS et CTS, et lire l'état "de l'autre côté". Je n'ai même plus les bouquins là dessus. Ils sont partis il y a longtemps à la poubelle.

Dans mon cas, si ce n'est pas du "tout fait", c'est rédhibitoire. Même faire un cicuit imprimé pour souder dessus un truc au pas de 1 mm, c'est un problème !

Tout ce que je suis capable de faire, c'est envoyer un signal tout ou rien à une entrée, et écrire le soft sous Windows qui exploite les impulsions reçues par un port Bluetooth.

En fouinant sur le net, j'ai trouvé des modules plus faciles, comme celui ci (antenne intégrée) :

http://www.goodluckbuy.com/serial-bluet ... rs232.html

 

[coredump]

En bluetooth ca sera forcément un port série, je ne pense pas qu'il existe un autre profil utilisable.
Donc uC obligatoire au bout d'un dongle bluetooth uart, ou passage par rts/cts, mais la c'est pas garanti (comme avec les dongles USB) si le dongle n'implemente pas tout.

En usb on est moins embété, il existe le profil HID qui permet des entrées sorties simples.

EDIT: il existe aussi un profil HID en bluetooth, donc reste a trouver un device utilisable.

 

[j.f.]

Je viens de regarder la gestion des ports com sous windows. Je ne l'avais encore jamais fait, et la dernière fois que je me suis intéressé aux com. série, c'était il y a 20 ans, sous DOS, en assembleur, avec l'écriture d'un gestionnaire d'interruptions, lecture des ports etc. (en fait, j'avais triché, écrit en C, fait une compilation intermédiaire en assembleur puis optimisé).

Le système Windows émet bien un évenement pour le changement d'état de la "ligne" CTS : EV_CTS, qu'il s'appelle, d'ailleurs.

Donc je crois qu'il est possible de faire de la communication tout ou rien en utilisant juste ce signal depuis un module comme celui que tu as mis en lien.

Comme Windows CE est un système temps réel, j'imagine que compter ces évennements ou mesurer l'intervalle de temps qui les sépare expoiterait toute la précision de l'horloge du Pocket PC.

Ne reste plus qu'à faire une expérience :

- écrire un programme sur le PC de bureau pour faire changer d'état le CTS du port série associé à un dongle Bluetooth

- écrire un programme sur le Pocket PC pour récupérer les évenements CTS et les compter

Manque de bol, impossible de remettre la main sur ce foutu mini dongle depuis que madame a eu l'idée stupide de nettoyer le bureau ! Une semaine que je le cherche.

Mais concernant ces petits modules pour communications série, il y a une info que je n'ai pas trouvée ou pas comprise. Ils sont programmables par le port série. OK. Ils gardent leurs paramètres une fois déconnetés, et leur alimentation coupée. OK. mais est-ce qu'ils gèrent tout seuls la connection au récepteur distant sans besoin d'un µC derrière pour leur dire quoi faire ? Je suppose que oui, mais comme tu peux le constater, j'ai beaucoup moins de difficultés avec le soft qu'avec le hard !

La doc est quand même très minimaliste...

EIDT : zut !

en voilà un qui a essayé de communiquer comme ça (récupérer l'état de CTS sur un PPC). Il n'y est pas arrivé, WinCE ne réagit pas. Curieux, quand même, la doc dit le contraire (message spécifique)

http://www.pcreview.co.uk/forums/com-po ... 43795.html

 

[coredump]

Ca arrive souvent que le device bluetooth (ou USB) ne gére pas du tout le RTS/CTS. En fait il y a un uC dessus, qui tourne une pile bluetooth. Ils gerent donc tout seul la phase de pairing.

A premiere vue les manettes bluetooth pour PS3 ou Wii sont une base de choix pour les bricoleurs. A voir...

 

[j.f.]

C'est assez logique puisque c'est un contrôle matériel de flux.

Cependant, les docs Windows indiquent que le système le gère.

Les petits modules ont ces entrées / sorties. Reste à savoir si les dongles et autres périphériques transmettent et reçoivent ces signaux au système. Malheureusement, dongle perdu...

ca vaut quand même la peine d'essayer, ça ne semble pas très difficile à programmer.

Je testerai dans quelques temps :

- émetteur = PC + dongle

- émetteur = PC avec bluetooth intégré

- récepteur = PPC (c'est ce qui m'intéresse)

L'idée m'est venue en comparant mon énorme et ultra moche Terratrip 303+ avec le Pocket. Sa télécommande (filaire) est presque aussi grosse que le Pocket. Donc je voyais un émetteur Bluetooth au cul du capteur de vitesse du compteur (c'est un ILS avec des aimants), et un Pocket avec un soft ultra simple, scotché sur la planchette à côté du road book, et permettant à la fois les affichages, les remises à zéro, corrections etc. juste à portée de main. Voire même un truc intégré avec GPS. Sur Pocket, mais aussi sur tablette WinCE ou TabletPC.

Un projet plus complexe et directement en relation avec l'usinage, mais nécessitant des µC : règles de mesure et tachy sans fil, avec émetteurs Bluetooth, et affichage sur tablette tactile. Ca serait pas cool, un truc comme ça ? Là, on pourrait réellement se passer de la visu, ne mettre que les règles sur les machines, et utiliser un seul dispositif d'affichage facilement paramétrable pour le tournage, le fraisage, la rectification, etc., parfaitement personnalisable, en sélectionnant la machine dans un menu ou une liste déroulante. Soft sans grande difficulté, mais bloutouffisation des règles hors de portée pour moi !

 

[freedom2000]

Merci pour ce lien, mais après avoir lu les docs, cherché sur le chipset utilisé, etc., ça coince toujours.

Manifestement, le module est livré avec un firmware destiné à en faire un câble RS232 immatériel. Ce n'est pas ça que je recherche.

Ce que j'aurais voulu, c'est un truc dans ce genre, mais avec juste une entrée. Quand j'ai vu les 8 PIO, je me suis dit "c'est bon", oui, mais sans firmware pour dire quoi envoyer quand on les titille, ça semble cuit. 500 pièces pour faire flasher autre chose...

Il me semble qu'on peut faire de la transmission minimaliste via RS232 sans passer par Rx/Tx, juste avec les RTS et CTS, et lire l'état "de l'autre côté". Je n'ai même plus les bouquins là dessus. Ils sont partis il y a longtemps à la poubelle.

Dans mon cas, si ce n'est pas du "tout fait", c'est rédhibitoire. Même faire un cicuit imprimé pour souder dessus un truc au pas de 1 mm, c'est un problème !

Tout ce que je suis capable de faire, c'est envoyer un signal tout ou rien à une entrée, et écrire le soft sous Windows qui exploite les impulsions reçues par un port Bluetooth.

En fouinant sur le net, j'ai trouvé des modules plus faciles, comme celui ci (antenne intégrée) :

http://www.goodluckbuy.com/serial-bluet ... rs232.html

Salut,

Je m'étais intéressé à des modules similaires pour faire une serrure codée déclenchée par mon téléphone portable... Mais seule la pile UART est fournie sur ce device.
Ceci dit pour ce que tu veux faire ça m'a l'air plutôt simple :
- tu colles un PIC devant ce module qui fait l'interface avec tes capteurs et gère l'UART
- tu crées une petite appli PC qui ouvre un port COM (celui de ton dongle bluetooth) et hop tu communiques

JP

 

[pierrepmx]

Salut j.f.

je ne sais pas en détail ce que fait un Terratrip 303, mais après un rapide tour sur Google, je vois que ça doit être dans un habitacle de voiture.

Ça veut dire qu'il y a quand même un peu de place (c'est pas comme sur un vélo, par ex.)
L'IRDA n'est pas intégré dans le Pocket PC ?

Comme coredump l'a dit, RTC/CTS est très probablement la gestion du fifo en entrée du µC, et seules les datas sont envoyées.


Si tu veux tricher avec des composants classiques (mais un µC serait bien plus facile), il faut générer le framing, c'est à dire une suite d'imulsions avec le bon timing.
Ceci simule l'envoi d'un signal série au bon format.

Il faut que je révise, mais une simple impulsion (à la longueur très précise de 9 fois la durée d'un bit, puis délai d'au moins 1 bit) devrai suffire .
La valeur reçue sera 0x00, ce qui est sans importance.

Mais attention au retard du au buffering/timout dans le FIFO et la pile Bluetooth. Par contre, pas de perte de data si on reste en dessous de la fréquence max (Fonction du débit de l'uart).

Précision sur la durée de l'impulsion requise: meilleure que 1/2 bit length (attention à : température, jitter du à alim mal stabilisée ou parasites électromagnatiques).

Si 9600 8N1:

Bit length env 10.35µs.
Précision meilleure que 5µs.
Impulsion = 9 bits = 93.18µS.
Attente (pour le stop bit) mini: 10.35. Preféré: 20µs.
Total: 115µs -> fmax = 870Hz.


Pour le fun, 8N1, à l'ancienne:
si tu prends du CMOS ou un NE555, le RC peu être fait par un 10 tours, ou deux ajustables en série, dont l'un d'une valeur 1/10ème (le 10 tours du pauvre). Un condo plastique "correct" est requis. Régler pour avoir une réception d'un "0" à chaque impulsion.

Je n'ai pas essayé, alors... use at your own risk

Je me suis fendu d'un petit dessin :

 

[pierrepmx]

Je voulais essayer avec un générateur de signal carré (autour de 500Hz pour du 9600bds), mais pas moyen de remettre la main sur mon interface série/USB.
Tant pis, ce ne sera pas pour ce soir...

 

[pierrepmx]

Bon, ben j'ai essayé.
Et ça marche.

À 535Hz, valeur théorique pou 9600,8N1, on reçoit 0x00 en boucle.
Vers 610Hz, c'est interprété comme 0x80.
Il vaut mieux une impulsion impiulsion trop courte que trop longue:
on garde le stop bit.

Si tu fais un simple générateur de pulse sur ton capteur, et que tu règle la longuer de l'impulsion pour lire 0xF0, tu es "au milieu" de la plage.

Les variations de durée de l'impulsion (vieillissement, température) feront varier la valeur, mais ne généreront pas de "frame error".
Comme la seule information qui t'intéresse est la "présence" de l'octet, pas son contenu, c'est OK comme ça.

Par contre, la répétition de l'impulsion ne doit pas dépasser la fréquence max correspondant à la période d'une trame complète.
(9600bds -> fmax 850Hz = 51000t/mn, s'il y a une seule impulsion par tour, ça laisse de la marge ! De plus, il est toujours possible de monter à 115200bauds)

Donc, si 9600,8N1: impulsion positive 45 à 50µs.
Signal électrique: Valeur "repos": de -12 à 0V, et "impulsion", de +5 à +12V (la norme est théoriquement +/- 8-12V, mais dans la réalité, ça marche souvent en 0/5V). La tension négative est récupérable sur DTR (ou un autre signal similaire).

 

[j.f.]

Si j'ai bien compris, tu envoies une impulsion qui couvre le bit de start, tout ou partie des bits de données, et laisse tranquile le bit de stop ?

L'utilisation d'un 555 ne pose pas problème si on dispose d'une grosse alimentation. Automobile = ok.

Il y a aussi dans ce cas des solutions bidouille comme le détournement d'un kit mains libres en envoyant un signal audio FSK.

En revanche,ça fait perdre tous les avantages de l'autonomie d'une puce Bluetooth alimentée par piles boutons, et émettant de temps en temps un signal pour cjhercher une communication avec un client. C'est le cas du vélo qu'on voit plus haut, et le cas d'u capteur placé sur la roue avant d'une moto ; mon 600TTR est également équipé d'un trip que je remplacerais bien par un PPC. Capteur actuel tout petit planqué derrière la fourche, sur le support d'étrier de frein, liaisopn filaire qui me gonfle.

Je me méfie quand même de "l'impossibilité" d'exploiter les signaux RTS et CTS lue sur un forum. Sur ces forums informatiques, des réponses sont très souvent données par des gens n'ayant jamais touché à WinCE, et écrivant des énormités qui sont prises pour argent comptant, et copiées/collées à l'infini sur le net. Toujours pas remis la main sur ce dongle, va falloir que j'en achète un autre...

 

[BBenj]

Ici également un module bluetooth: http://www.futurlec.com/Bluetooth.shtml
Gère l'UART, SPI et même USB. 20$.

 

[pierrepmx]

Si j'ai bien compris, tu envoies une impulsion qui couvre le bit de start, tout ou partie des bits de données, et laisse tranquile le bit de stop ?

Exactement.

À 9600,8N1 tant que l'impulsion est comprise entre 11µs et 90µs, ça marche.
La valeur renvoyée passera de 0xFF à 0x00.
Si tu connais le coef de température du condo du monostable, tu peux même t'en servir comme thermomètre d'ambiance.

Au sujet de l'alim et du circuit d'entrée:

Il est peut-être bien possible d'alimenter le circuit à partir du +/12V présent sur la RS232 du module Bluetooth, donc d'utiliser ses piles bouton de façon indirecte.
Il vaut alors mieux faire un circuit très peu gourmand en courant.

Si le système (partie fixe) est alimenté sur la batterie (auto ou moto), la consommation n'est plus un problème. Et plus de piles à recycler...

À noter que dans ce système, pour chaque octet, on met en branle tout le "binz" de la transmission Bluetooth (dans certains cas, quelques octets peuvent quand-même être regroupés dans une seule trame).
Sur le vélo, j'imagine que le calculateur est intégré au capteur et qu'il n'envoie qu'une actualisation toutes les 1 ou 2 secondes.
L'émission doit alors être bien plus économique en énergie.

Le capteur est connecté au Tera, donc tensions déjà présentes sur l'ILS (12V? dépend de ce qu'il y a à l'intérieur de la boîte).
Si le système doit pouvoir fonctionner même si le 'trip" est éteint, il faut le prévoir. Pas difficile, mais pas forcément trivial, par ex. si diodes de protection inverses en parallèle vers masse et 12V (alors non alimenté) dans le circuit d'entrée du Terra.

Logiquement, le RTS/CTS généré à l'autre bout de la liaison (côté PPC) représente le remplissage des buffers locaux dans la chaîne (handshake "attente/reprise"), et pas une recopie directe de l'état physique des broches côté module Bluetooth.
(Mais à vérifier, je ne connais pas le cas particulier du Bluetooth.)


Ça sert à quoi ce "Terra" ? Pour les rallyes, annoncer les virages ou quelque chose comme ça ?

 

[j.f.]

Terratrip est une marque d'odomètre. Dans le principe, c'est exactement la même chose en bien plus complet et bien plus lisible que les petits bidules Sigma pour vélos (et motos).

C'est certes utilisé en Rallye, mais pas seulement, loin de là. On les voit généralement montés par paire siur les véhicules de rallye raid. Mais ce n'est qu'un petite partie des utilisations.

- randonnées 4x4 au road book ; les road books étant rédigés avec des indications de ditance à parcourir, de directions à prendre, de repères visuels, etc. il vaut mieux avoir un système précis, facile à remettre à zéro, et utilisable par le passager avant.

- travaux publics. Je n'en ai jamais vu n'étant pas de la partie, mais je sais que c'est très utilisé : mesure des distances parcourues par exemple sur chantier autoroutier

- agriculture

Si tu veux voir ce que c'est dedans :

http://www.cambouis.com/bidouille/diver ... entree.htm

http://www.cambouis.com/bidouille/diver ... mmande.htm
http://www.cambouis.com/bloc-notes/2006 ... -06-02.htm

Quelques tests de branchement direct su le capteur de vitesse d'origine d'un véhicule :

http://www.cambouis.com/bloc-notes/2006 ... -06-03.htm

un test de raccordement direct, sans utiliser les modules spéciaux (chers et inutiles dans ce cas précis) vendus à cet effet :

http://www.cambouis.com/bloc-notes/2006 ... -06-12.htm

et le genre de monstruosité que c'est dans un véhicule :

http://www.cambouis.com/bloc-notes/2007 ... -07-14.htm

Ces photos montrent purquoi ça serait bien d'avoir quelques chose de plus discret et moderne !

Il existe des machins plus petits pour motos. Par exemple MOD7CE (j'en ai un sur le TTR) qui semble avoir abandonné les petits pour motos de TT, Brantz, DTMS, D6TM, Mestrac...

Sur 4x4, le système à 555 irait bien. Pas sur moto (pas de batterie, et trop encombrant et fragile)

D'ailleurs, prochaine applet pour WinCE : une calculette de cicuit à 555. Allez hop. On commence ce soir. Je venais juste de finir un truc pour calculer la distance d'un orage et un autre pour calculer la chute des corps (le coup de la pierre jetée dans un puits). Je ne savais pas trop quoi faire, c'est tout trouvé.

 

[j.f.]

Après moult recherches, j'ai trouvé la confrmation que les signaux ne question ne peuvent gérer que les communications au niveau matériel, et ne sont en aucun cas "on the air".

Testé aussi un peu au niveau logiciel...

Quel bazar ! On est loin des COM1/COM2 gérés par interruption.

Je suis arrivé à ouvrir des ports sur PC et Pocket, mais je n'ai pas pu tester les communications faute de logiciel genre hyperterminal pour Pocket. Ca existe, mais rien trouvé de gratuit ou sous forme de sources. C'est manifestement réservé à des applications très particulières comme la gestion de routeurs par WiFi. Et en plus, c'est cher.

Par ailleurs, je n'ai pas encore trouvé de document simple sur le WiFi. Manifestement, la liaison se fait en duplex : côté Pocket, il y a un port entrant et un port sortant. En plus, on ne peut pas réserver de port (ou j'ai loupé quelques chose), et il faut passer par une routine énumérateur de ports, et ouvrir le ou les bons.