convertir adc en binaire

PICQC

New Member
Bonjour,
Je ne suis pas encore très familier avec PICAXE mais je compte bien apprendre cette bestiole. J'aimerais communiquer une petite information via laser depuis un o8me vers un autre micro contrôleur.



ce que je veux réaliser c'Est de convertir une valeur d'une pine ADC du 08m2 en un nombre binaire ensuite envoyer bit par bit ce nombre . JE sais que c'est possible mais je ne sais pas trop par où commencer.


Quelqu'un aurais la gentillesse de me donner un coup de pouce :)?
 

PieM

Senior Member
Bonjour,
Je ne suis pas encore très familier avec PICAXE mais je compte bien apprendre cette bestiole. J'aimerais communiquer une petite information via laser depuis un o8me vers un autre micro contrôleur.
ce que je veux réaliser c'Est de convertir une valeur d'une pine ADC du 08m2 en un nombre binaire ensuite envoyer bit par bit ce nombre . JE sais que c'est possible mais je ne sais pas trop par où commencer.
Quelqu'un aurais la gentillesse de me donner un coup de pouce :)?
Bonjour et bienvenue,

Quel est l'intérêt de cette transmission optique via un serout/serin par exemple ? Car cela suppose un alignement parfait entre émetteur et récepteur plus le risque de parasites...
Une mouche traversant le faisceau et c'est fichu.
Vu le prix des composants UHF, la radio est une solution plus sûre.
 

PICQC

New Member
Bonjour!

Oui en faite je dis laser mais laser dans un câble optique ��



Je dois lire une sonde température et une sonde de pression dans une forêt. Pas de lien radio et pas de lie. Cuivre possible.
 

PICQC

New Member
De plus, cet exercice m'aidera à mieux comprendre la transmission de bit et l'auto synchronisation des bits.


Picaxe a laire quand même simple, entre un language basic et dérivé de C++. Mais je ne connais pas encore sa mécanique, donc quelque piste devrait m'aider!
 

PieM

Senior Member
De plus, cet exercice m'aidera à mieux comprendre la transmission de bit et l'auto synchronisation des bits.


Picaxe a laire quand même simple, entre un language basic et dérivé de C++. Mais je ne connais pas encore sa mécanique, donc quelque piste devrait m'aider!
Si l'objectif consiste à programmer des Picaxes en UART ce n'est peut être pas la bonne façon de démarrer!!
Une fibre optique ? OK mais quels composants y a t-il à chaque bout. En principe il y a un émetteur (diode) et un récepteur.
Donc une transmission avec serin/serout est tout à fait possible sans rien inventer !

Pas trop compris pourquoi une transmission radio n'est pas possible...
 

PICQC

New Member
Salut, premièrement transmission radio d'après moi serait impossible. En 300 ou 450 mhz ou encore même en 900mhz on a une bonne pénétration dans une forêt par exemple. Du moins mieux qu'avec une bande en 2.4 ou 5.8ghz. Mais la topographie du terrain fait que les ondes seront absorbées par le sol et le reste par les obstacles (dans mon cas, les arbres). Et on parle de distance avoisinant le kilomètre. C'est pour ça aussi que je n'utiliserai pas de cuivre, la foudre pourrait endomager mes appareils en se déchargeant dans le long câble de cuivre.

Je n'est pas de pièce encore choisi, il y a plein de transmetteurs et de récepteurs sur mouser ou digikey ou aliexpress, dans le fond ce qu'il me faut c'est seulement le socket avec diode et de lautre côté le socket avec sa photodiode. Alors mon objectif serait de justement lire une valeur sur ADC du picaxe, ensuite convertir la valeur en binaire et par la suite prendre chaque valeur (01001110) et les transmettres par impulsion lumineuse. De lautre côté avec mon autre microcontrolleur je vais interprêter ces impulisons et recomposer le code binaire pour ensuite, avec un calcule redonner la valeur decimal.
 

PieM

Senior Member
Salut, premièrement transmission radio d'après moi serait impossible. En 300 ou 450 mhz ou encore même en 900mhz on a une bonne pénétration dans une forêt par exemple. Du moins mieux qu'avec une bande en 2.4 ou 5.8ghz. Mais la topographie du terrain fait que les ondes seront absorbées par le sol et le reste par les obstacles (dans mon cas, les arbres). Et on parle de distance avoisinant le kilomètre. C'est pour ça aussi que je n'utiliserai pas de cuivre, la foudre pourrait endomager mes appareils en se déchargeant dans le long câble de cuivre.

Je n'est pas de pièce encore choisi, il y a plein de transmetteurs et de récepteurs sur mouser ou digikey ou aliexpress, dans le fond ce qu'il me faut c'est seulement le socket avec diode et de lautre côté le socket avec sa photodiode. Alors mon objectif serait de justement lire une valeur sur ADC du picaxe, ensuite convertir la valeur en binaire et par la suite prendre chaque valeur (01001110) et les transmettres par impulsion lumineuse. De lautre côté avec mon autre microcontrolleur je vais interprêter ces impulisons et recomposer le code binaire pour ensuite, avec un calcule redonner la valeur decimal.
Aucune conversion à faire, les instructions serin et serout le font pour vous.
 

PICQC

New Member
okay, sauf que je dois envoyer bit par bit d'une certaine facon pour que l'autre mcu puisse le lire. Je ne peux pas envoyer une trame sans l'avoir décortiqué à ma facon.... à moins dutiliser 2 picaxe pour envoyer recevoir le data via serin serout et ensuite communiquer les donnés à mon autre MCU... mais encore là je me retrouve avec le même trouble. Sur ce contrôlleur je n'ais pas de port UART, rs232 485 etc... seulement i2c et spi.
 

MGU

Senior Member
Bonjour,

Si il n'y a pas de liaison cuivre, comment est alimenté le système , batterie et panneau solaire ?

MM
 

PICQC

New Member
Batteries oui, je pensais envoyer le data une fois par minute et le reste du temps en sleep mode pour l'économie .
 

PieM

Senior Member
okay, sauf que je dois envoyer bit par bit d'une certaine facon pour que l'autre mcu puisse le lire. Je ne peux pas envoyer une trame sans l'avoir décortiqué à ma facon.... à moins dutiliser 2 picaxe pour envoyer recevoir le data via serin serout et ensuite communiquer les donnés à mon autre MCU... mais encore là je me retrouve avec le même trouble. Sur ce contrôlleur je n'ais pas de port UART, rs232 485 etc... seulement i2c et spi.
Mais pourquoi faire compliqué ? Liaison RS232 entre 2 picaxes puis il suffit d'envoyer directement des trames en I2C entre Picaxe recepteur et le contrôleur...
 
Last edited:

BESQUEUT

Senior Member
De plus, cet exercice m'aidera à mieux comprendre la transmission de bit et l'auto synchronisation des bits.
Picaxe a laire quand même simple, entre un language basic et dérivé de C++. Mais je ne connais pas encore sa mécanique, donc quelque piste devrait m'aider!
Si le but c'est d'apprendre, commencez par une liaison cuivre de quelques mètres.
Un Picaxe à chaque bout :
- dans le premier, vous lisez votre ADC et vous envoyez les données, pas trop vite au début
- dans le deuxième, vous lisez et affichez pour contrôle soit sur un terminal série, soit sur un LCD.
Alors mon objectif serait de justement lire une valeur sur ADC du picaxe, ensuite convertir la valeur en binaire et par la suite prendre chaque valeur (01001110) et les transmettres par impulsion lumineuse. De lautre côté avec mon autre microcontrolleur je vais interprêter ces impulisons et recomposer le code binaire pour ensuite, avec un calcule redonner la valeur decimal.
Dès que vous avez exécuté un READADC ou un READADC10, vous disposez d'une représentation binaire de la tension mesurée.
Un simple SEROUT va convertir cette valeur binaire en une série d'impulsions électriques (suivant le protocole RS232).
Ces impulsions peuvent être lues par un SERIN (sur un autre Picaxe directement raccordé en cuivre) qui va en déduire la valeur binaire correspondante.

Je pense qu'il y a confusion entre "valeur binaire" et "valeur décimale"...

Dans un Picaxe, toutes les valeurs sont "binaires" au sens où elles sont composées d'une série de bits (8 ou 16 en l’occurrence)

C'est seulement la représentation de ces valeurs qui peut changer :
Si dans la mémoire du Picaxe, il y a 4 portes logiques avec les tensions : 5V 0V, 5V et 0V
on peut représenter ça en binaire sous la forme 1010
mais c'est aussi le nombre 10 (en base 10) ou A (en base 16)
ou bien le caractère N°10 de la table ASCII

Tout ceci n'est que de l'interprétation : la réalité physique ne change pas.
Envoyer une valeur sur un fil de cuivre, ce n'est pas autre chose que d'envoyer des bits successifs, et donc en réalité physique des tensions comparables à celles stockées en mémoire... 5V pendant X ms, puis 0V pendant X ms, etc...

Une fois ça pigé et maîtrisé, remplacer le fil de cuivre par une fibre optique est un détail de l'histoire.

Cela dit, je pense comme PieM que pour une liaison de 1km, même en pleine forêt, même avec du relief, un émetteur radio serait bien plus simple à mettre en oeuvre !
Un module LORA est donné pour 20 km. Ce n'est évidement pas garanti vu que nous ne connaissons pas votre contexte, mais ça devrait le faire !

Une fibre, c'est fragile ! Vous comptez l'enterrer ? Sinon, une branche ou un caillou tomber dessus, un animal se prendre les pattes dedans, et les rongeurs adorent boulotter le plastique...

Si j'ai bien compris, le volume de données à transmettre est très faible : vous pouvez donc utiliser une fréquence assez basse, qui sera très pénétrante.
Par ailleurs, le nombre de bits par seconde peut être très faible, et donc l'émission très fiable, ce qui n'empêche pas d'utiliser un code pour détecter les erreurs.

Pour info, les pompiers communiquent sur des dizaines de km, y compris en pleine forêt. La bande utilisée est le 40mHz, mais il faut disposer des autorisations ad hoc...

Au pire, si vous ne pouvez utiliser les bonnes fréquences, on peut imaginer des bonds plus courts avec un ou plusieurs relais intermédiaires.

Sur ce contrôlleur je n'ais pas de port UART, rs232 485 etc... seulement i2c et spi.
Elle est bien bonne ! C'est quoi ce contrôleur manchot ?
 
Last edited:

PieM

Senior Member
Besqueut said:
Elle est bien bonne ! C'est quoi ce contrôleur manchot ?
Un peu sourd et muet en plus ! ;-)

une solution GSM serait sans doute moins chère que de la fibre ....
 
Last edited:

PICQC

New Member
Oui la methode je bien compris au départ . Et le contrôleur utilisé est pourtant très bien. C'est un board webcontrol 32 bit de cainetworks. Pour mes besoins c'est génial, on peut créer un code basic dans un compilateur interne. Bref la machine n'est pas un problème je crois mais ce que jessaye de faire c'est de lire un capteur qui sera très loin. La radio je sais que c'est bon sauf que dans mon cas si on parle de 1 capteur c'est une chose mais sicon parle de 300 capteurs et si on utilise des radio de 1,5 watts je suis pas certain de la consommation énergétique à l'autre bout. Ça doit tenir sur batterie. Le mesh network serait bon mais je connais pas vraiment la technologie. Xibee offre je crois une architecture deja complète mais jai encore là peur de la conso et de la contention si on utilise plusieurs capteurs. Oui jai que la valeur dun capteur pression et la température à transporter. Avec un rafraîchissement d'environ 1 min interval.... l'idée de 2 picaxe avec une interconnexion i2c pourrais être une bonne solution. Faudrais je comprenne cette technologie d'ailleurs!!! Solutuon gsm == coût mensuel et consommation énergétique trop grande.
 

PieM

Senior Member
1 capteur, maintenant 300 ! ? Radio de 1.5W ? Je ne comprends plus grand chose...
 

BESQUEUT

Senior Member
Et le contrôleur utilisé est pourtant très bien. C'est un board webcontrol 32 bit de cainetworks.
Je n'en crois pas mes yeux :
Currently the RS232 and RS485/442 serial data ports provided by the hardware are not used by the firmware.

Cela dit, la datasheet hardware parle encore moins de SPI ou de I2C... Mais il semble qu'effectivement le nouveau firmware supporte I2C et SPI. Donc avec un Picaxe intermédiaire, c'est jouable.


Si on s'en tient au titre de votre thread, on est bien loin d'imaginer tout ça...
Si vous souhaitez obtenir de l'aide, je ne saurais trop vous conseiller d'ouvrir un nouveau thread en expliquant clairement vos objectifs :
- combien d'émetteurs,
- quelles distances entre les émetteurs,
- quelle distance entre l'émetteur et les récepteurs,
- quelle quantité de données pour chaque émetteur,
- quelle fréquence d'émission,
- etc...
 
Last edited:

PICQC

New Member
Je n'en crois pas mes yeux :
Currently the RS232 and RS485/442 serial data ports provided by the hardware are not used by the firmware.

Cela dit, la datasheet harware parle encore moins de SPI ou de I2C... Mais il semble qu'effectivement le nouveau firmware supporte I2C et SPI. Donc avec un Picaxe intermédiaire, c'est jouable.


Si on s'en tient au titre de votre thread, on est bien loin d'imaginer tout ça...
Si vous souhaitez obtenir de l'aide, je ne saurais trop vous conseiller d'ouvrir un nouveau thread en expliquant clairement vos objectifs :
- combien d'émetteurs,
- quelles distances entre les émetteurs,
- quelle distance entre l'émetteur et les récepteurs,
- quelle quantité de données pour chaque émetteur,
- quelle fréquence d'émission,
- etc...


JE vais regarder pour poster un autre sujet, avant je vais regarder la base de tout.


évidemment que c'Est pas la même chose qu'au début puisqu'ensemble on trouve de nouvelles avenues afin d'atteindre des buts.


merci pour ton aide
 

PICQC

New Member
1 capteur, maintenant 300 ! ? Radio de 1.5W ? Je ne comprends plus grand chose...
Je ne vois pas ce qui est compliqué. Le but de l'exercise au début était de faire communiquer 1 capteur, je soumets l'hypothèse d'en ajouter. Vraiment c'est assez simple.

Radio de 1.5w oui encore là un hypothèse j'ai pas de donnés pour dire que dans mon aplication il faudra 18 dbm de puissance ou 28dbm. Mais ce qui est certain c'est que si je veux envoyer du data sur plusieurs centaines de mètres avec des terrains accidentés, alors forcément un radio de quelque miliwatts ne sera jamais assez puissant à moins que tu me prouves le contraire. N'oubliez pas que je suis sur pile à l'autre bout. Pas de secteurs malheureusement en forêt.
 

PieM

Senior Member
Je ne vois pas ce qui est compliqué. Le but de l'exercise au début était de faire communiquer 1 capteur, je soumets l'hypothèse d'en ajouter. Vraiment c'est assez simple.

Radio de 1.5w oui encore là un hypothèse j'ai pas de donnés pour dire que dans mon aplication il faudra 18 dbm de puissance ou 28dbm. Mais ce qui est certain c'est que si je veux envoyer du data sur plusieurs centaines de mètres avec des terrains accidentés, alors forcément un radio de quelque miliwatts ne sera jamais assez puissant à moins que tu me prouves le contraire. N'oubliez pas que je suis sur pile à l'autre bout. Pas de secteurs malheureusement en forêt.
Effectivement si c'est simple, ce n'est pas compliqué de passer de 1 à 300 liaisons capteurs... :confused:
Le mesh network serait bon
en plus avec cette topologie !

Un module LoRa de qualité c'est 25 mW pour jusqu'à 25 km de portée en LOS.
 
Last edited:

PICQC

New Member
Justement je suis en forêt, il n'y a pas de LOS.

Et non si le modèle 1 capteur et fibre fonctionne, passer à 300 est un jeu d'enfant.
 

PieM

Senior Member
Justement je suis en forêt, il n'y a pas de LOS.
Et bien ça veut dire que la portée est réduite qd on est pas en LOS et que 1000 m est certainement possible avec un débit faible, plus facilement qu'en milieu urbain.

Et non si le modèle 1 capteur et fibre fonctionne, passer à 300 est un jeu d'enfant.
Si tu le dis... sans doute une grande expérience que je n'ai pas ... Mais je ne suis plus un enfant, ceci expliquant cela.
Il est vrai que comme tu n'hésites pas à créer ton propre protocole pour une simple liaison série, tout est possible.
Mais il m'avait semblé que quelques notions de base rappelées par Besqueut te semblaient un peu étrangères

300 capteurs qui vont communiquer avec quoi, via 300 fibres optiques ou 300 capteurs sur la même ?

As tu déjà utilisé un module lora sur picaxe?
Que ce soit sur Picaxe ou sur autre chose, c'est pareil; il communique en liaison série avec le µC. Je ne comprends pas.

En outre il y a une multitude de post sur le sujet dans le forum Picaxe.
 

PICQC

New Member
Si tu le dis... sans doute une grande expérience que je n'ai pas ... Mais je ne suis plus un enfant, ceci expliquant cela.
Il est vrai que comme tu n'hésites pas à créer ton propre protocole pour une simple liaison série, tout est possible.
Mais il m'avait semblé que quelques notions de base rappelées par Besqueut te semblaient un peu étrangères
okay, là tu comprends pas trop ce que je dis, je pense que je dis 2 ou 3 choses et ça te froisse litéralement. Mon but c'est d'échanger pas de reprendre ce qu'on se dit en essayant de montrer que l'un en connais plus qu'un autre ou encore de faire dévier l'idée vers autre chose. Le 300 capteurs avec 300 fibres oui et alors? Tu ne connais même pas mon projet pourquoi ça t'étonne ? Au premier plan c'est effectivement un jeu d'enfant. Mon système fonctionne actuellement avec 2 cartes wc32 avec une fibre un laser, je reçois les données avec oui un code basic qui suit exactement le procole que j'ai INVENTÉ . J'aurais aucun problème de foutre plusieurs fibres au réseau. Si c'était si simple j'aurais gardé cette carte mais question de coût et de consomation d'énergie j'avais pensé au Picaxe ou encore à l'arduino, mais bon à cause que je connais pas certaines chose ou encore que j'utilise un autre chemin je suis certainement un idiot ou je sais pas trop à toi de me le dire. Enfin bref, je pense qu'on peut arrêter le thread ici, i2c aurait été la façon idéale dans mon cas mais les 2 appareils ne fonctione qu'en master, alors je vais trouver une autre façon de réaliser ce que j'ai à faire.

merci

Patrick
 

dje8269

Senior Member
Bonjour à vous,

Intervention Avant que cela ne dégénère, car je sais OOhhhh combien il est difficile parfois de se faire comprendre, au travers d'un forum . Nous n'avons pas les expressions du visages, le ton de la voix et autres choses pour compléter nos paroles, qui peuvent parfois être du coté clavier interrogative , mais lue coté écran comme affirmative .

Sache qu'ici les experts trés qualifiés, cherche à t'aider au mieux et àte guider vers la meilleure solution. Maintenant si tu veux absolument de la fibre optique dans ton projet , OK .

Je te propose de faire des extractions de bit par décallage et maqsuage .

Un OCtet quelques qu'il soit sera stocké sous sa forme binaire:
Par exemple le chiffre 153 correspond à 10011001 en binaire .

Dans une boucle tu va masquer les 7 MSB(Most signifant bit, bit les plus significatatif) pour ne garder que le LSB ( Low signifiant bit, bit le plus faible).
Pour masque les 7 MSb on va utiliser un masque grace à la fonction "ET" & .

si on écrit :
10011001
&
00000001

On masque le 7 MSB car il seront toujours égale a 0 et le LSB sera toujours à la valeur initiale que l'on souhaite tester .
Donc ici on aura
00000001 soit 1 en décimale , soit un état haut, physiquement .

Et voila tu va pouvoir envoyer ton premier bit .

Maintenant pour le second on va faire exactement pareil , mais on ayant prit soin avant de décaler notre valeur d'un cran vers la droite pour mettre notre deuxiéme bit , à droite en LSB .
Donc :
10011001 >> 1 nous provoque un décalage à droite . ce qui donnera
01001100

Maitenant on masque les 7 MSB
011001100
&
00000001
ce qui donne
00000000 , et hop notre deuxieme bit a envoyer

etc .......

si tu fais correctement ta boucle t usort tes 8 valeurs en une seule boucle .

A toi de jouer !
 

BESQUEUT

Senior Member
Enfin bref, je pense qu'on peut arrêter le thread ici, i2c aurait été la façon idéale dans mon cas mais les 2 appareils ne fonctione qu'en master, alors je vais trouver une autre façon de réaliser ce que j'ai à faire.
1) Un Picaxe peut tout à fait fonctionner en slave, donc ce projet est tout à fait faisable,
2) Il me semble dommage d'abandonner dans ces conditions : nous ne faisons que tenter de répondre à votre demande, même si ça ressemble plus à un jeu de devinettes qu'à un véritable cahier des charges.
3) Il est vrai que nous aurions du commencer par répondre à la question posée. C'est maintenant chose faite grâce à dje.
4) Un peu d'humour ne nuit pas,
5) Si vous avez toujours besoin d'aide, merci de bien vouloir préciser votre cahier des charges en répondant aux questions posées en #16.
 
Last edited:

BESQUEUT

Senior Member
Je ne vois pas ce qui est compliqué. Le but de l'exercise au début était de faire communiquer 1 capteur, je soumets l'hypothèse d'en ajouter. Vraiment c'est assez simple.
En matière de communications et quel que soit le vecteur utilisé (cuivre, fibre optique, radio, tam-tam,...), il y a deux modes fondamentaux :
- point à point : un seul émetteur, un seul récepteur
- multipoints : un ou plusieurs émetteurs, un ou plusieurs récepteurs


Dans votre cas, je classerais la difficulté du projet en 4 classes :
- classe 1) 1 seul émetteur et un seul récepteur, séparés d'environ 1km,
- classe 2) quelques émetteurs, voisins, séparés d'un km du récepteur,
- classe 3) quelques émetteurs dispersés dans la forêt, un seul récepteur,
- classe 4) Des centaines d'émetteurs répartis dans toute la forêt, et toujours un seul récepteur.

L'environnement est le même dans tous les cas : en pleine forêt, avec un relief important, sans alimentation en énergie sur les émetteurs.

En classe 1) seul se pose le problème de la longueur de transmission. Suivant le vecteur utilisé, il peut être nécessaire d'utiliser des relais intermédiaires, encore appelés "répéteurs" ou "perroquets"

Dès la classe 2) de nouvelles difficultés apparaissent :
- en plus du message utile, il faut être capable d'identifier l'émetteur : donc la trame est plus longue
- les deux émetteurs peuvent parler en même temps et donc se brouiller. Il y a deux solutions : émettre ou envoyer les données aléatoirement : il y aura collision de temps en temps, mais suffisamment peu pour que la transmission reste fiable. Ou bien synchroniser les émetteurs pour qu'ils ne parlent pas en même temps.
- suivant la topographie, certains émetteurs peuvent servir de relais ; si c'est le cas, un protocole particulier doit être mis au point.
Le récepteur n'a qu'un seul canal à écouter : c'est le contenu des messages qui permet de faire la différence entre les émetteurs.

En classe 3) Si tous les vecteurs arrivent sur l'unique récepteur, il faut autant d'entrées que d'émetteurs. Il faut évidement que ce récepteur soit capable d'écouter simultanément tous ces émetteurs.

En classe 4) en plus de tout ce qui précède et en fonction de la fréquence des émissions souhaitées, on peut facilement saturer la bande passante :
- au dessus de 255 émetteurs, le code de l'émetteur fait au moins 2 octets,
- en radio, on ne peut pas émettre en permanence : un "duty cycle" de 10% est un maximum,
- il n'est pas rare d'utiliser des débits très faibles, comme 1200 bauds ou même 300 bauds,
- s'il faut 1s pour transmettre un message et qu'on ne peut émettre qu'une fois toutes les 10s, il faudra au moins 3000 s pour 300 émetteurs, soit une bonne heure !
 
Last edited:

BESQUEUT

Senior Member
Justement je suis en forêt, il n'y a pas de LOS.

Et non si le modèle 1 capteur et fibre fonctionne, passer à 300 est un jeu d'enfant.
Si on reste sur de la fibre optique et s'il faut 1km de fibre par émetteur, ça nous fait 300 km de fibre à
700 € les 300m
Si vous avez ce budget, merci de me contacter en mail privé : je suis à votre disposition pour réaliser votre projet.
 

PieM

Senior Member
Tu ne connais même pas mon projet pourquoi ça t'étonne ? Au premier plan c'est effectivement un jeu d'enfant. Mon système fonctionne actuellement avec 2 cartes wc32 avec une fibre un laser, je reçois les données avec oui un code basic qui suit exactement le procole que j'ai INVENTÉ . J'aurais aucun problème de foutre plusieurs fibres au réseau. Si c'était si simple j'aurais gardé cette carte mais question de coût et de consomation d'énergie j'avais pensé au Picaxe ou encore à l'arduino,
Une excellente chose, quand on est sur un forum, est de présenter son projet, son cahier des charges, et éventuellement l'état d'avancement.
Cela évite de jouer continuellement aux devinettes et de (faire) perdre son temps.
Je n'est pas de pièce encore choisi, il y a plein de transmetteurs et de récepteurs sur mouser ou digikey ou aliexpress, dans le fond ce qu'il me faut c'est seulement le socket avec diode et de lautre côté le socket avec sa photodiode.
permettait de douter d'une réalisation existante, et fonctionnelle.!

Et comme le problème ne se situe que par la consommation de la carte distante W32, il est nullement besoin d'un picaxe à la réception puisque le W32 sait déjà interpréter les bits à l'arrivée.

Pour le reste comme tu as inventé ton propre protocole qui gère également le synchronisme des infos transmises, il n'y a aucun problème; tu sais donc faire et ce en fonction des différentes topologies décrites par Besqueut. Donc effectivement, un jeu d'enfant....

En résumé, il suffit de traduire le code basic de la W32 émettrice existante en basic Picaxe.
 

PICQC

New Member
Okay merci, je vais regarder tout ça plus tard. Je vous reviens avec peut être plus de précision. merci pour l'entraide



Et j'ajouterais:

Une excellente chose, quand on est sur un forum, est de présenter son projet, son cahier des charges, et éventuellement l'état d'avancement.
Cela évite de jouer continuellement aux devinettes et de (faire) perdre son temps.
permettait de douter d'une réalisation existante, et fonctionnelle.!

Pour le reste comme tu as inventé ton propre protocole qui gère également le synchronisme des infos transmises, il n'y a aucun problème; tu sais donc faire et ce en fonction des différentes topologies décrites par Besqueut. Donc effectivement, un jeu d'enfant....
Je ne suis pas d'accord à présenter un projet au complet, dans certain cas oui, dans d'autre non. Ça reste dans le confidentiel et inutile à poster sur un forum internet visible par toute la population mondiale. On colle sur le 300 capteurs qui à été lancé comme ça comme pour supposer le fait qui pourrait y avoir élargissement du réseau, alors que la question initial n'était pas ça. Et perdre son temps c'est se qu'on fait, se lancer des pommes pourites et polluer le thread.

Le choix des composantes pour un projhet final hors breadboard n'est pas fait EXACTE. Mais un simple cordon de quelque mettre de fibre 9/125 ou encore de 1um avec un laser et une PR fonctionne très bien. Pas jolie, mais correct pour tester l'idée. Et ça se fait avec un câble de cuivre aussi et pulser +5vdc étant high et 0vdc étant low. Mais dans ce cas j'aurais besoin d'une mise à la terre commune. Donc 2 câbles.

Pour le protocole qui à l'aire à t'agacer lourdement:

Dans un premier temps l'état initiale est à 0 (low) donc aucune lumière, la carte qui envoie les bits, synchronise son hôte en envoyant une lumière durant 500ms, ensuite passe à une loop qui faite qu'envoyer son premier bit sois 0 ou 1 en utilisant son changement d'état et non son état:

i.e: 0 à 1 == High et 1 à 0 == low. J'utilise un temps d'attente entre chaques état ensuite je passe au bit 2 et 3 et ainsi de suite.

Côté récepteur je suis toujour en mode écoute, donc si je perçois une lumière de plus de 500ms alors c'est la gachette qui indique au code de passer en mode lecture des bits ce qui l'entraîne dans la routine #1. Je lis en premier l'état initiale du bit numéro 1. Exemple si je reçois 0, alors j'entre dans une routine qui va faire un choix, si j'ai encore 0 je recommance la loop indéfiniment mais si je reçois un 1 alors j'enregistre le bit 1 à high en mémoire et je passe au bit suivant. À linverse si je reçois un état initial de 1, alors j'entre dans une loop qui va aussi faire un choix, si je reçois un 1 je répète la loop indéfiniment mais si je recois un 0, alors j'enregistre le bit1 étant un 0 (low). Donc pas besoin de câble pour la synchronisation clock, tout se passe dans le code, après la réception de l'état initiale sois 0 ou 1 c'est là que la synchro se fait. En attendant que le changement de bit se fasse, ça permet de syncroniser la carte receptrice avec celle qui envoie l'information. C'est pas de la communication série ou très avancé et peut être même un peu casse gueule mais c'est un truc très lent qui fonctionne depuis déjà un certain temps en labo. Avec les bons délais de chaque côté on peut parfaitement synchroniser une carte avec l'autre puisque comme expliqué, la carte réceptrice attend le changement d'état pour passer au bit suivant. Il y a aussi une condition qui fait que si l'état du bit reste pareil plus de 500MS par exemple, on incrémente une variable qui m'indique que j'ai perdu un bit. Éxemple rupture de lien etc.

Ce n'est pas de la création de protocole mon affaire c'est juste une manière d'envoyer une mini information sous impulsion lumineuse depuis une autre machine. Un code morse appel ça comme tu veux bref. C'est très long envoyer 8bits dans mon cas c'est près de 7 secondes, sauf que je m'en ballance puisque les donnés sont renouvelés tous les minutes. J'aurais utilisé un autre moyen de communiquer mais la carte est limité dans mon cas et ce qu'il me restait c'était des inputs numériques qui reconnaissent seulement high ou low.

Si tu doute encore que mon projet fonctionne je t'invite à perdre ton temps sur un autre thread. Sinon merci pour l'ajout d'informations à ce thread.
 

PieM

Senior Member
Personne ne te demande le détail de ton projet mais un contexte global. Mais si passer de 1 à x capteurs ne te pose pas de problème alors tout est parfait.

C'est très long envoyer 8bits dans mon cas c'est près de 7 secondes, sauf que je m'en ballance puisque les donnés sont renouvelés tous les minutes.
Ouais effectivement! ça ne concurrence pas le sémaphore ...

Finalement, après quelques améliorations de ton codage et ton protocole qui me semble pas trop au point, vu le débit, tu aura inventé quelque chose qui existe depuis longtemps avec un débit de 2400 bauds sur picaxe et sécurisé.

Je me répète donc: puisque n'existe aucun problème de débit, ni d'adressage des infos, ni de gestion des collisions, tout étant déjà maitrisé, il suffit de traduire le code basic de la W32 émettrice existante en basic Picaxe.
je t'invite à perdre ton temps sur un autre thread.
Merci mais sans façon, je l'ai déjà perdu ici.
 

BESQUEUT

Senior Member
Pour le protocole :
Dans un premier temps l'état initiale est à 0 (low) donc aucune lumière, la carte qui envoie les bits, synchronise son hôte en envoyant une lumière durant 500ms, ensuite ...
Ce n'est pas de la création de protocole mon affaire ...
Si tu doute encore que mon projet fonctionne je t'invite à perdre ton temps sur un autre thread. Sinon merci pour l'ajout d'informations à ce thread.
Personne ne doute que vous parveniez à transmettre une information sur quelques mètres au travers d'une fibre optique.
Comme expliqué en #27, c'est la généralisation qui va vous poser problème !
Que vous ayez réinventé (en moins bien) quelque chose qui existe déjà, c'est votre affaire.
Si votre seul objectif est d'implémenter votre protocole, dje vous a donné une piste de départ et si vous le demandez, nul doute qu'une aide complémentaire vous sera donnée, d'autant que nous en savons maintenant un peu plus sur votre façon de procéder.

Sachez toutefois que le protocole RS232 peut être utilisé à des vitesses très basses si nécessaire. Sachez également qu'il existe dans ce protocole un bit de correction d'erreur. Sachez encore qu'il existe d'autre protocoles adaptés à différents vecteurs ; Manchester en particulier est très utile pour les transmissions par radio. En ce qui concerne la fibre optique, le risque de parasitage étant extrêmement faible, la détection d'erreur a moins d'intérêt. Par contre c'est quasiment indispensable en radio, et c'est pour cela qu'il existe des modules tout prêts (genre LORA) qui intègrent un puissant processeur capable de choisir la fréquence la moins polluée, et de transmettre de façon fiable les données.

Par contre, si l'objectif est de mener à bien un projet, y compris sur le plan économique, comprenant des dizaines ou des centaines d'émetteurs répartis dans une forêt, alors le problème du codage des bits est très secondaire. Pour faire les choses dans l'ordre, et après avoir répondu aux questions en #16, il faudra :
- choisir le vecteur approprié,
- choisir la topologie adaptée,
- choisir (ou créer) un protocole adapté à la topologie et au vecteur,
- et seulement alors choisir (et si vraiment c'est nécessaire créer) un encodage binaire répondant aux contraintes du protocole et des objectifs en particulier au niveau de la bande passante et de la fiabilité.

Nos posts s'étant croisés, je vais prendre connaissance des autres messages avant de poursuivre.
 
Last edited:

PICQC

New Member
Personne ne te demande le détail de ton projet mais un contexte global. Mais si passer de 1 à x capteurs ne te pose pas de problème alors tout est parfait.


Ouais effectivement! ça ne concurrence pas le sémaphore ...

Finalement, après quelques améliorations de ton codage et ton protocole qui me semble pas trop au point, vu le débit, tu aura inventé quelque chose qui existe depuis longtemps avec un débit de 2400 bauds sur picaxe et sécurisé.

Je me répète donc: puisque n'existe aucun problème de débit, ni d'adressage des infos, ni de gestion des collisions, tout étant déjà maitrisé, il suffit de traduire le code basic de la W32 émettrice existante en basic Picaxe.

Merci mais sans façon, je l'ai déjà perdu ici.
Moi j'ai jamais parlé d'invention de protocole. C'est toi qui en fait mention. J'ai seulement testé une idée avec impulsion lumineuse qui ou est inspiré en autre des protocoles existants mais que DANS MON CAS était une façon de procèder. Et inquiète toi pas je ne veux pas concurencer n'importe quoi et c'est lent j'en fait d'ailleurs mention. Mais je te donne un exemple très simple, si je veux aller prendre un verre avec toi en France et que je part du Canada, j'ai pleins doptions, avion de ligne, bateau, etc. Je pourrais prendre le petit bateau voir chaloupe qui oui sera plus long mais le but c'est d'aller prendre un verre, pas de transporter un coeur pour remplacer le tien qui devrait se faire à toute vitesse. Juste un simple verre, alors la notion temps n'hexiste pas et le bateau arrive au même résultat. Enfin on s'écarte du sujet.


tout étant déjà maitrisé, il suffit de traduire le code basic de la W32 émettrice existante en basic Picaxe.
Et la question initiale était jsutement un coup de main sur la translation de mon code avec le language picaxe avec ma question.


et ça nous a mené ici en passant par ton doute sur l'entier de mon projet:

je t'invite à perdre ton temps sur un autre thread.
Merci mais sans façon, je l'ai déjà perdu ici.

Belle perte de temps effectivement.:(
 

PICQC

New Member
Personne ne doute que vous parveniez à transmettre une information sur quelques mètres au travers d'une fibre optique.
Comme expliqué en #27, c'est la généralisation qui va vous poser problème !
Que vous ayez réinventé (en moins bien) quelque chose qui existe déjà, c'est votre affaire.


C'est d'ailleurs pourquoi la communication i2c m'intéresse...
 

PieM

Senior Member
Moi j'ai jamais parlé d'invention de protocole.
tu ne sais pas ce que tu écris alors!!
je reçois les données avec oui un code basic qui suit exactement le procole que j'ai INVENTÉ
Et la question initiale était jsutement un coup de main sur la translation de mon code avec le language picaxe avec ma question.
Ben bien sûr ! et ton code il faut le deviner et aller chercher les infos sur le matériel que tu as...
 

BESQUEUT

Senior Member
C'est d'ailleurs pourquoi la communication i2c m'intéresse...
Comme déjà dit, ce serait effectivement une façon de communiquer avec le webcontrol qui reçoit les données.
Un petit Picaxe à l'émission, et un autre à la réception , en mode Slave I2C, et le Webcontrol peut aller lire les données quand bon lui chante.

Par contre, il faut savoir que le bus I2C a été conçu par Philips pour faire communiquer les différents composants à l'intérieur d'un poste de télévision... donc sur de très faibles distances. Il existe différentes façons d'aller plus loin, mais franchement ce n'est pas fait pour transporter de l'info sur de longues distances.
Pour aller plus loin, le RS232 qui existe quasiment depuis les débuts de l'informatique a fait ses preuves.
Quand on veut aller loin sur du cuivre, on passe au RS485 qui est bien plus résistant aux parasites.
Le TCP-IP nécessite théoriquement 4 paires de fils et est limité à 100m.
En radio, le code Manchester est très utilisé car sa façon de coder les bits est très efficace sur ce vecteur.
Voilà un dégrossissage des couches de bas niveau.

Mais comme dit plus haut, une fois que l'on sait transporter des bits entre deux processeurs, des tas de questions interviennent :
- si plusieurs émetteurs, comment éviter que les messages se collisionnent, on du moins, comment faire avec ?
- comment identifier l'émetteur ?
- comment détecter une erreur de transmission ? Et si possible la corriger ?
- comment pallier aux limitations de portée du vecteur ?
- comment un récepteur unique peut-il écouter des dizaines, voire des centaines d'émetteurs simultanés ?
- et finalement, si beaucoup d'émetteurs, comment optimiser la bande passante pour que tout ce monde puisse communiquer avec des délais raisonnables ?

C'est ce qu'on appelle les couches de niveau intermédiaire ou de niveau haut. Et ça répond également à des protocoles, parfois normalisés, et souvent propriétaire...
 
Last edited:

PICQC

New Member
tu ne sais pas ce que tu écris alors!!


Ben bien sûr ! et ton code il faut le deviner et aller chercher les infos sur le matériel que tu as...
Sérieusement tu me fais perdre mon temps la. Arrêt stp et va embêter une autre personne. Le INVENTÉ en majuscule c'était pour reprendre ce que tu as dit précédemment pour te faire réfléchir... vas te lire de nouveau . Alors arrête de chercher les foutus problèmes . Et en quoi le matériel optique te serait-il important? Veux tu savoir la longueur donde de la lumière émise ? Sûrement que je t'en parlerais et tu trouverais quelque chose à dire de negatif ou non important comme le reste de tes posts ici.


Il y a des personnes intéressantes ici avec qui j'aimerais échanger entre autre besqueut mais j'ai toujours un de tes commentaires qui ne fait que virer en rond et dans le négatif. Alors stp va voir si je ne suis pas ailleurs à moins que tu ajoutes des choses importantes.
 
Top