Bonjour à tous,
Je voudrais transmettre des données venant d'un capteur de température LM335 à l'aide d'un émetteur 433MHz. Par contre, il faut empaqueter les infos venant du capteur (à l'aide d'un PIC par exemple). Quelqu'un peut-il me donner un début de piste pour la programmation d'un PIC 16F84. J'essais de programmer en basic histoire que connaitre un peu ce langage.
Merci pour vos réponses.
denis
Bonsoir, pour commencer avec les pic : un incontournable
http://www.abcelectronique.com/bigonoff/
@+
salut foudefoot
Petites infos sur les modules Emission/Réception en 433 Mhz
- tu ne peut pas émettre à plus de 4200 bauds !
- ton module récepteur vas capté tout un tas de données parasite, je te conseil de créé une structure de donnée avec une valeur de Control
ex : xxxxxxxx xxxxxxxx xxxxxxxx
channel valeur crc
Avec pour crc = channel XOR valeur
pseudo code:
/!\ Ne pas utilisé les intéruptions UART, vue que tu li tout le temps !Code:do { do { channel = lecture_uart }while(channel != xx); valeur = lecture_uart crc = lecture_uart crc2 = channel XOR valeur }while(crc != crc2);
- pour se qui est de la lecture des valeurs (coté pic) utilise bien le module UART hardware.
Dernier truck: laisse tomber le basic (perte de temps), le langage C
Logiciel : mikroC (très répendu et dispose de plein de source en c), cxx5 + mplab (un peut plus vieux, moin utilisé)
Logiciel de simulation : Proteus
Don't forget : 16f84.pdf
Bonne chance !
16F84 TRES MAUVAIS CHOIX... Pourquoi? ton LM335 sort une tension proportionnelle a la temperature a hauteur de 10mV/°C. Hors, un 16F84 (obsolete), n'embarque aucun CAN integré. Je te conseille plutot de taper sur le 16F88, voir meme 12F675 si tu as pas d'autres E/S a traiter...
Ensuite, pour 25°C, tu auras 250mV soit une precision a iech si tu attaques ton CAN directement (soit avec reference = 5V soit avec reference exterieure a 2.56V mais jamais de reference VREF inferieure a 2.56V - interdit). Il te faudra passer par un ampli de gain = 10. Donc si tu desires avoir une mesure entre 0 et 50°C (cela te sonnera en sortie entre 0 et 5V en sortie de l'AOP). Et si tu utilise 9 bits de poids fort, tu pourras avoir directement une resolution de 0.1°C, le dernier bit (faible) te donnera le dernier digit de resolution (0 ou 5) sur ta mesure (résolution, pas precision, nuance).
Et la conversion binaire 16 bits vers BCD de tes 9 bits de poids forts (0 a 511) te permettra d'obtenir directement tes caracteres correspondant a la temperature sur 3 digits, le 4eme digit sera 0 ou 5 selon l'etat du bit de poids faible de ta conversion.
Pour la transmission, tu peux utiliser une trame en code manchester (methode de transmission a moyenne fixe) comportant un bitstart de 5ms, 1ms de 0 logique, deux octets d'autentification, et 2 octets correspondant a ADRESH et ADRESL de ton CAN qui seront transmis a la vitesse de 1ms par bit.
A la reception, tu peux effectuer plusieurs lectures de chaque bit recu et comparer statistiquement ton bit recu pour certifier ton bit.
Bref, tu as du travail pour y arriver. Je viens juste de finir une telecommande de centralisation de voiture selon le meme principe et un systeme de commande deportee HF pour un coffret selecteurs de jeux de lumiere "vintage".
Pour plus d'infos, voir le site de bigonoff...
Rebonjour à tous,
Tout d'abord merci à tous pour vos réponses.
Pour guillaume83 merci pour le lien c'est un site à recommander à toutes les personnes qui utilisent des PICs.
Pour neo_xnitro, je veux programmer en basic simplement pour connaître ce langage, c'est toujours intéressant de connaître un nouveau langage.
Pour franck-026, merci pour tous tes précieux conseilles, comme tu le dis, j'ai du travail pour y arriver. Je voulais prendre un PIC16f84 simplement par ce que j'en avais un sous la main, et je penser utiliser une formule de conversion du genre Uout = T X 0,01. J'aurais une température en Kelvin, mais peu importe, une température max n'ai qu'une valeur programmable!
Mais je vais passer en série middle range, avec CAN intégré, ce sera plus simple.
Enfin, si vous avez d'autres conseilles, je suis pronneur.
Encore merci à tous.
Denis
si ton projet coté emission de la temperature vers un autre PIC se reduit a juste une lecture analogique et un envoie de trame digitale, et que la consommation est precieuse, je te conseille de passer sur un 12F675 ou 12F683, qui est en DIP8, tu as 5 E/S et 1 MCLR. Tu vas utiliser la config AVEC quartz pour etre bien dans le timing de lecture des trames (4MHz de quartz) et il te restera 3 E/S qui seront utilisees dans ce sens:
- 1 entree configuree en analogique pour la lecture de la temperature en provenance de l'AOP gain 10
- 1 sortie de données qui va envoyer la trame de temperature (recopie securisee par clé d'appairage 16 bits de tes deux registres ADRESH et ADRESL)
- 1 sortie de commande qui permettra a ton module d'economiser de l'energie en coupant l'alimentation de ton module HF.
Et ton 12F683 passera entre deux envois en mode SLEEP, ce qui lui fera passer de 500µA de conso moyenne a 50µA de consommation en veille.
Tu pourras ensuite via une interruption reveiller ton PIC (si je ne raconte pas de betises on sait jamais) regulierement pour l'envoi de ton info. Mais bon, avec 4 piles NIMH 1.2V 2600mah, ca te laisse de l'autonomie meme si tu ne reste pas en SLEEP...
500µAh ca fait 12mA par jour, ca laisse environ 6 mois d'autonomie...
Ensuite ton recepteur recevant la trame et confirmant son autenticité soit par checksum soit par statistique en relisant le bit recu plusieurs fois, n'aura que a decoder ADRESH et ADRESL pour traiter la temperature a afficher.
Par contre, si manchester te rebute, tu peux utiliser un emetteur et un recepteur FM FSK qui permettront de te passer du code manchester, et tu auras une meilleure qualité de transmission pour un prix guere plus elevé.
Sinon, a la place de ton LM335 qui est une solution analogique, tu aurais pu emuler un bus one wire et communiquer avec un DS18S20 qui te fournit sur 16 bits la temperature etalonnee directement meme pour les negatifs, et ca te permet de ne plus avoir d'AOP. Seul le decodage de la trame de temperature change dans la forme des 16 bits. Ca serait plus reproductible avec cette methode.
Mais le 16F84A est obsolete mais neanmoins utilisable pour de petites applis purement logiques, laissant la place selon l'appli analogique a traiter a des PIC pluys recents et moins gourmands en energie
merci pour toutes ces infos.
A+
denis
