convertir adc en binaire

BESQUEUT

Senior Member
Oui je vais relire tout ça, j'ai toujours un truc qui vire en rond qui m'empêche de me concentrer. Dsl je vais reprendre depuis le début .
Pour ne pas être en reste devant l'ami dje, voici une autre approche (testée sur simulateur) :
Code:
[color=Navy]#Picaxe [/color][color=Black]08M2[/color]
[color=Blue]symbol [/color][color=Purple]Temperature[/color][color=DarkCyan]=[/color][color=Purple]b0[/color]
[color=Blue]symbol [/color][color=Purple]LeBit[/color][color=DarkCyan]=[/color][color=Purple]bit9

w7[/color][color=DarkCyan]=[/color][color=Purple]Time[/color]

[color=Blue]do
      random [/color][color=Purple]w7
      Temperature[/color][color=DarkCyan]=[/color][color=Purple]w7
      [/color][color=Blue]sertxd ([/color][color=Navy]13[/color][color=Black],[/color][color=Navy]10[/color][color=Black],#[/color][color=Purple]Temperature[/color][color=Black],[/color][color=Red]" "[/color][color=Blue])
      [/color][color=Purple]Lebit[/color][color=DarkCyan]=[/color][color=Purple]bit7 [/color][color=Black]: [/color][color=Blue]gosub [/color][color=Black]Ecrirebit
      [/color][color=Purple]Lebit[/color][color=DarkCyan]=[/color][color=Purple]bit6 [/color][color=Black]: [/color][color=Blue]gosub [/color][color=Black]Ecrirebit
      [/color][color=Purple]Lebit[/color][color=DarkCyan]=[/color][color=Purple]bit5 [/color][color=Black]: [/color][color=Blue]gosub [/color][color=Black]Ecrirebit
      [/color][color=Purple]Lebit[/color][color=DarkCyan]=[/color][color=Purple]bit4 [/color][color=Black]: [/color][color=Blue]gosub [/color][color=Black]Ecrirebit
      [/color][color=Purple]Lebit[/color][color=DarkCyan]=[/color][color=Purple]bit3 [/color][color=Black]: [/color][color=Blue]gosub [/color][color=Black]Ecrirebit
      [/color][color=Purple]Lebit[/color][color=DarkCyan]=[/color][color=Purple]bit2 [/color][color=Black]: [/color][color=Blue]gosub [/color][color=Black]Ecrirebit
      [/color][color=Purple]Lebit[/color][color=DarkCyan]=[/color][color=Purple]bit1 [/color][color=Black]: [/color][color=Blue]gosub [/color][color=Black]Ecrirebit
      [/color][color=Purple]Lebit[/color][color=DarkCyan]=[/color][color=Purple]bit0 [/color][color=Black]: [/color][color=Blue]gosub [/color][color=Black]Ecrirebit
      [/color]
[color=Blue]loop[/color]


[color=Black]EcrireBit:
     [/color][color=Blue]sertxd ([/color][color=Black]#[/color][color=Purple]leBit[/color][color=Black],[/color][color=Red]" "[/color][color=Blue])
     return[/color]
c'est près de 7 secondes, sauf que je m'en ballance puisque les donnés sont renouvelés tous les minutes. .
Là est le nœud du problème :
- autant on peut ne pas tenir compte du délai (du débit, de la bande passante, c'est la même chose...) à titre expérimental,
- autant dans la vraie vie, avec tout plein d'émetteurs, des tas de données, l'encapsulation et les limites juridiques des émissions radio, non seulement on ne s'en balance plus, mais alors plus du tout, mais même c'est en général la pierre d'achoppement d'un projet !

Pour info, vous atteignez un peu mieux que 1 baud sur une fibre optique.
En 1982, le Minitel faisait 1200 bauds en voie descendante et seulement 75 bauds en voie montante. C'était tout juste utilisable, mais rapidement critiqué pour sa lenteur...
Autre point de repère, il est possible d'atteindre
2,56 térabits par seconde sur une ligne de fibre optique longue de 160 kilomètres soit 2 560 000 000 000 bauds

L'ami PieM est un peu bourru, mais c'est un excellent technicien, avec une longue expérience. Il va droit au but, et le dit sans délicatesse. Mais s'il donne un avis, vous pouvez le croire sur parole : tôt ou tard vous serez confronté au problème soulevé !
 
Last edited:

jojojo

Senior Member
Je ne devrais pas, mais ...
On a évoqué le cuivre, la fibre, le hertzien, le tam-tam ... Manque plus que les signaux de fumée ...

En tentant (difficilement ...) d'extraire un cahier des charges, des différents posts ci-dessus, je me dis que l'on vogue un peu dans l'inconnu.

Histoire de voir, question : Y a-t-il du réseau GSM, sur site ? Car, si oui, pour +/- 2€/mois par site de "captationdonnées-émission" (vois pas comment le dire autrement), et 0 € pour le site de réception (un modem GSM FALCON en prépayé, il n’émettra jamais), et hop, problème résolu.

Sinon, en 869Mhz pas cher et performant, il y a Radiometrix, qui fait des trucs pas mal (j'ai une liaison "maison" de niveau de puits de la pâture de ma jument, à près de quatre kilomètres de chez moi, avec, dans la foulée, un niveau de batterie de la clôture électrique). Juste penser a bien travailler les antennes.

Dans les deux cas de figure, un simple panneau solaire de moins de 1 mètre carré, suffit amplement a maintenir la batterie en état correct, sous réserve de ne pas abuser de la transmission.

Ceci étant, franchement, le protocole de communication est carrément le dernier truc à analyser. On veut du lent, sans chichi, ça passera dans tout !

Le dernier truc qui me gêne, c'est l'évocation de la "confidentialité" du projet. Ben tiens ! Là, rire. Si, si...

Enfin, ce que j'en dis, hein ...

Une bonne soirée à toutes et tous.

Georges.
 

PICQC

New Member
Bon je viens de repasser de long en large la discussion.


Quelque prise de becs pour un rien. Enfin, si on reprend du début, ce que je demandais c'était une piste pour simplement convertir une lecture de l ADC d'un picaxe en binaire ensuite envoyer le tout sous forme d'impulison. PAs un code complet et prémâcher, non seulement une piste comme en #25 et comme besquet a montré aussi. Sauf qu'en discutant je réalise que l'idée de mettre 2 picaxe en communication (peut-être bien radio avec LoRa ou autre) et ensuite envoyer les trames i2c sur mon webcontrol serait une bonne idée. On va oublier le 300 capteurs, je crois qu'on s'est tous perdu dans ça, et on ne parle pas de budget non plus. Je ne parle pas de confidentialité top secrète, seulement je ne veux pas étaler mon projet entier sur un forume publique, en privé c'est une meilleur approche dans ce cas précis. Mais si je vous résume l'ensemble de mon idée, alors voici quelque infos :


- À la base j'ai un Wc32. Petite carte sur pic32 avec une caractéristique que j'aime bien : un compilateur basic read/write via internet. Trouvez l'équivalent... jai pourtant cherché.
- J'aimerais recevoir une lecture de température et aussi la pression baro de quelque endroits en forêt. On parle dans le monde réel de peut être 50 - 60 endroits différentes. (300 capteurs était seulement à titre de référence a un élargissement du réseau)
- J'ai pensé au GSM, au cuivre, au radio, à la fibre à la châine humaine ;) GSM au Canada c'est pas donné et c'est energivore aussi. Cuivre, alors on se trouve avec problème de parasitage oui mais aussi foudre etc. La fibre je pensais que c'était la chose la plus efficace compte tenu de ses caractéristiques (faible perte, aucunement affectable par la foudre, presque sans problème d'interférence/parasites. Et ici c'est pas dispendieux la fibre. Aux USA on peut avoir ça pour quelque $. Enfin la rido je croyais que c'était impensable, mais vous croyer tous que ce serait la façon la plus efficace. Et j'aime bien cette approche.
- Je ne tiens pas à garder mon modèle de transmission/réception déjà évoqué plus haut. C'était mon point initiale avant de penser à l'approche sans-fil.
- J'aimerais utiliser les donnés que durant quelque mois durant l'année afin de collecter les données. Donc pile et non panneau solaire avec génératrice et tout le matos.


L'idée de mettre 2 picaxe en communication radio et ensuite envoyer les trames i2c sur mon webcontrol serait peut-être un point de départ. Alors faudrait que je regarde un module radio à tester, ensuite on pourra penser à sa communication entre picaxe et radio. Par la suite le picaxe qui recevera les données radio pourra communiquer via (i2c peut-être) au webcontrol. Le module LoRa est incroyablement puissant à ce que je peux en déduire. Peut-être un bon point de départ?

Il faut penser à l'ajout de capteurs future si le concepte focntionne. Alors un mode infra serait à mon avis plus simple que le mode Mesh. Est-ce que je me trompe? La lourde tâche serait je pense côté récepteur qui devra comme l'a dit besqueut. Le recepteur devra connaitre la provenance de chaque émetteur et voir entretenir une certaine synchronisation de tout ce bordel.


Si j'ai froissé quelqu'un dans mon post ou si je ne suis pas claire ou encore vague svp me le faire savoir. J'aimerais juste qu'on parle franchement sans aller trop loin!



Merci et sans racune PieM
 

BESQUEUT

Senior Member
L'idée de mettre 2 picaxe en communication radio et ensuite envoyer les trames i2c sur mon webcontrol serait peut-être un point de départ. Alors faudrait que je regarde un module radio à tester, ensuite on pourra penser à sa communication entre picaxe et radio. Par la suite le picaxe qui recevera les données radio pourra communiquer via (i2c peut-être) au webcontrol. Le module LoRa est incroyablement puissant à ce que je peux en déduire. Peut-être un bon point de départ?

Il faut penser à l'ajout de capteurs future si le concepte focntionne. Alors un mode infra serait à mon avis plus simple que le mode Mesh. Est-ce que je me trompe? La lourde tâche serait je pense côté récepteur qui devra comme l'a dit besqueut. Le recepteur devra connaitre la provenance de chaque émetteur et voir entretenir une certaine synchronisation de tout ce bordel.
Pour ce qu'on sait de votre projet, c'est ce qui me semble le plus adapté.
Par contre, entre mode infra et Mesh et pour la répartition des tâches entre émetteur, réseau et récepteur, il faudrait en savoir plus sur la topologie.
Si beaucoup d'émetteur proches entre eux, on peut les relier en cuivre au Picaxe émetteur et de là passer en LORA pour aller au Picaxe récepteur, lequel mets à disposition sa mémoire via I2C pour que le Webcontrol puisse lire les datas quand il en a envie.

Si le cuivre pose problème, on peut utiliser des petits modules Radiometrix apacher comme indiqué par jojojo.
Chacun émet au hasard, par exemple une fois par heure, avec bien sur son identifiant.
Bien sur il y a un risque de collision, mais statistiquement c'est très peu probable :
- a condition que la durée de l'émission soit courte,
- donc que le volume de données soit faible,
- et que le protocole utilisé soit efficace (disons... un peu mieux que 1 bit par seconde...)

Pour se donner une idée : avec 1 octet pour la température, 2 pour la pression, 1 pour l'identifiant, deux pour le préambule et 1 pour le checksum, ça nous fait dans les 7 octets par trame, soit 56 bits et une bonne minute à 1 baud...
S'il y a 60 émetteurs, ça va collisionner méchamment...

Mais à 300 bauds, on passe 4 trames par seconde. Même avec 60 émetteurs, la probabilité de collisionner est inférieure à 1/240 soit, 0,4 % ==> ça me semble nettement plus raisonnable.

Le Picaxe émetteur écoute et s'il reçoit une trame valide la retransmet, par LORA en un seul bond de 1 ou plusieurs km.

Le module LORA n'est pas à proprement parler "puissant" au contraire, la puissance émise est plutôt faible ! Du coup, la consommation électrique est remarquablement modérée. C'est la qualité du dialogue (géré par de puissants processeurs à chaque bout) et la sensibilité du récepteur qui permettent une portée exceptionnelle. Comme pour toute installation radio, il faut des antennes de bonne qualité et une excellente prise de terre.
Ces performances exceptionnelles ont une contrepartie : il ne faut pas raisonner comme si c'était un simple fil de cuivre ou une fibre optique... Il faut lire la doc et choisir une des options prévues. Idem si plusieurs modules doivent communiquer en réseau. Comme chaque module tente d'optimiser la liaison, on peut obtenir les meilleurs résultats (si c'est bien paramétré) ou les pires (si on ne paramètre pas, ou si on paramètre mal...)
Mais un paramétrage satisfaisant ne peut être réalisé que si on connaît bien le contexte, donc si on a bien défini le cahier des charges, donc voir les remarques déjà formulées...

Autre remarque : si vous lisez ceci/, vous constatez qu'il y a deux familles de modules différents selon que l'on veut faire du P2P (point à point) ou du WAN (réseau).
Donc ce que vous investirez en temps et en argent si vous commencez avec un seul émetteur sera perdu dès que vous tenterez d'utiliser plusieurs émetteurs...
A ce stade, vous commencez peut être à comprendre pourquoi ce genre de remarque :
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.
a fait réagir notre ami PieM...
 
Last edited:

BESQUEUT

Senior Member
Manque plus que les signaux de fumée ...
Excellente idée ! D'autant qu'on doit pouvoir trouver des spécialistes en la matière au Canada.
Et on peut émettre simultanément sans interférences...
Tu pourrais nous faire un chti programme Picaxe pour le récepteur ?

Le pire, c'est que ça existe quasiment !
Les pompiers des Landes ont dépensé des sommes non négligeables (voir dernière ligne de l'article...) pour équiper la forêt de pins de caméras de surveillance sensée détecter les fumées suspectes...
Bon... pour le moment, ça coûte un peu cher d'envoyer l'hélico à chaque fois qu'un 4x4 en vadrouille soulève un peu de poussière...
:confused:
 
Last edited:

PICQC

New Member
a fait réagir notre ami PieM
. Hors contexte, je ne parlais pas ici d'une infra sans fil. Je sais très bien que ça pourrait devenir complexe d'ailleurs j'en fais référence dans un des premiers posts avec le mesh et la contention.

Je sais aussi que le LorA nest pas puissant avec ses 0.025w ce qui donne quoi 12-13 dbm? Je le trouve puissant dans sa technologie. Conso, portée etc.


Topologie, ça serait à valider mais un mode 1 récepteur avec ses émetteurs partout en forêt. Rien de hybride.

Je comprends que si je projette dans une utilisation future d'utiliser plusieurs capteurs alors j'aurai besoin de mettre en place la bonne communication effectivement .

Reste que pour tester le tout je pourrais faire communiquer 2 picaxe avec des modules lora dans un endroit similaire au mien et voir la pénétration des ondes. Qu'en pensez vous?



Et au Canada nous sommes aussi en 2016:) les ours et les amérindiens sont chose du passé voir les années 1600...haha
 
Last edited:

BESQUEUT

Senior Member
.Reste que pour tester le tout je pourrais faire communiquer 2 picaxe avec des modules lora dans un endroit similaire au mien et voir la pénétration des ondes. Qu'en pensez vous?
Oui, c'est un bon début, mais partez dès le départ sur des modules LoraWan (un poil plus chers) même si vous n'utilisez pas la fonction Wan au début.
Vous pouvez aussi tester en parallèle les modules indiqués en #42, beaucoup moins chers, et peut être suffisants ?

Comme déjà vu dans un autre thread, le mieux pour ça c'est d'émettre des trames comprenant :
- l'identification de l'émetteur (même si c'est tout le temps le même : c'est pour plus tard...)
- un numéro d'ordre sur 2 octets.
Au début, on émet doucement et on vérifie qu'il ne manque pas trop de trames.
Puis on augmente la vitesse et/ou la distance jusqu'à perdre des trames.

L'idéal est de mettre au point un petit programme de réception qui donne directement :
- le nombre de trames reçues par minute,
- le taux de trames manquantes.

Si vous disposez de 2 Picaxes et d'un bout de fil, vous pouvez déjà écrire ça en attendant de recevoir vos modules...
(Pour simuler les problèmes de transmission, il suffit d'interrompre le fil...)

Un autre essai à faire serait de vérifier que le Webcontrol est bien capable de lire un Picaxe via I2C ou SPI.

Autre remarque :
- je veux bien croire que la température varie un peu au sein d'une même forêt en fonction de l'ensoleillement, de l'humidité, de la pédologie et du couvert végétal,
- mais pour la pression, à part l'altitude, tous les capteurs devraient donner la même chose ? Que cherchez vous à mesurer ?

Et au Canada nous sommes aussi en 2016:)
Ah ??? mince alors ! C'est pas comme dans Murdoch ???
 
Last edited:

BESQUEUT

Senior Member
Je commande 2 picaxe , je pense que des 28x2 serait un bon point de départ?
OUI : ils font en particulier partie des 4 Picaxes qui supportent les commandes RFIN & RFOUT nécessaires pour utiliser le code Manchester. En outre, il faut impérativemet un X2 à la réception pour pouvoir utiliser hi2csetup en mode slave
Eventuellement, vous pouvez aussi prendre un résonateur qui permet de passer la vitesse de 8 Mhz à 64 Mhz. Mais c'est à priori incompatible avec I2C.

Très chers, mais plus petits et faciles à mettre en oeuvre il y a aussi les modules PICAXE-28X2/
(Dans ce cas, prendre le module AXE 201 (64 Mhz) et non le AXE 200 (32 Mhz))

Si vous ne l'avez pas déjà, ne pas oublier le PICAXE-USB-Download-Cable/

Une fois la solution validée, il sera possible de passer sur des Picaxes moins coûteux en fonction de la technique retenue.
 
Last edited:

BESQUEUT

Senior Member
Pour le quartz, bof ...

RFIN et RFOUT repasse le truc en 4Mhz, donc ...
Le problème n'est pas là, mais plutôt dans le I2C slave qui ne semble pas compatible avec 64 Mhz, mais la doc n'est pas très claire sur ce sujet.

Le programme de réception contiendra des tas d'instructions en plus du RFIN, et devra le faire le plus vite possible pour être à nouveau disponible pour recevoir les données.
Du coup, avoir un processeur rapide n'est pas du tout négligeable.

En outre, il s'agit d'une phase expérimentale : donc on se donne les moyens d'expérimenter. 1 € de plus pour un résonateur (et non un quartz) si on pense à le commander avec le Picaxe, ce n'est pas grand chose.
Par contre, le jour où on en a besoin, on est content de l'avoir.

Je ne comprends pas comment tu peux savoir qu'augmenter la vitesse ne sert à rien alors que le programme n'est pas encore écrit ?
 

jojojo

Senior Member
Je ne comprends pas comment tu peux savoir qu'augmenter la vitesse ne sert à rien alors que le programme n'est pas encore écrit ?
Ben, je lis...

Voir #31. Hé non, ça ne concurrence pas le sémaphore, ça ne met même pas en danger ce bon vieux code morse.

Et, pas de réponse (bon, je ne relis plus, là, mais ...)concernant une couverture GSM de la zone.

Et, pourquoi sommes nous toujours dans l'obligation d'extraire un vrai CdC, aux "forceps" ?

Et, oui, je maintiens, augmenter la vitesse, dans ce contexte, ne va pas servir à grand chose, si l'on retient la solution radio (va savoir ...?).
Le picaxe en RX va passer 99% de son temps en écoute, donc, bloqué sur un RFIN (d'ailleurs, même si c'était possible, être bloqué à 4 Mhz, ou à 64Mhz, je ne vois pas bien la différence, non ?).

Ce thread est mal parti.
Quelques jours de réflexion/analyse, sur les besoins PRÉCIS du projet, à l'ancienne, bloc-note crayon, nous permettraient d'être efficaces et constructifs. Là, c'est une perte de temps. Normalement, cela me fâche peu, et je me contente de ne pas intervenir. Mais, si l'on y rajoute une pointe de parano, sur la "confidentialité" de la chose, là ... A moins d'une liaison basée sur le boson de Higgs, ou les chaines quantiques, je ne vois pas vraiment le souci.

Une chaine acquisitions/transmissions de données ne relève pas de la magie. Juste des besoins clairs, soigneusement analysés.
Zou, au boulot !

Georges.

Edit: A tout hasard, de bonnes info's, ici :

http://www.picaxeforum.co.uk/showthread.php?26699-HABAXE2-a-LoRA-based-High-Altitude-Balloon-Tracker-Project
 

BESQUEUT

Senior Member
Ben, je lis...

Voir #31. Hé non, ça ne concurrence pas le sémaphore, ça ne met même pas en danger ce bon vieux code morse.

Et, pas de réponse (bon, je ne relis plus, là, mais ...)concernant une couverture GSM de la zone.

Et, pourquoi sommes nous toujours dans l'obligation d'extraire un vrai CdC, aux "forceps" ?

Et, oui, je maintiens, augmenter la vitesse, dans ce contexte, ne va pas servir à grand chose, si l'on retient la solution radio (va savoir ...?).
Le picaxe en RX va passer 99% de son temps en écoute, donc, bloqué sur un RFIN (d'ailleurs, même si c'était possible, être bloqué à 4 Mhz, ou à 64Mhz, je ne vois pas bien la différence, non ?).
Après réception de la trame, le Picaxe a quand même un peu de taf pour alimenter les différentes variables. Mais en fait on ne sait pas s'il descend à 4Mhz uniquement pour recevoir la trame et repasse immédiatement à fond pour traiter les données, ou s'il reste à 4Mz jusqu'au bout du traitement de la commande. C'est d'ailleurs curieux ces 4Mhz : à ma connaissance, la fréquence de base d'un X2 est de 8 Mhz ???
En outre, le Manchester n'est utile que dans le cas de modules "bruts".
Avec des modules LORA, on est plutôt sur du hserin et les choses sont différentes !
Ce thread est mal parti.
Quelques jours de réflexion/analyse, sur les besoins PRÉCIS du projet, à l'ancienne, bloc-note crayon, nous permettraient d'être efficaces et constructifs. Là, c'est une perte de temps. Normalement, cela me fâche peu, et je me contente de ne pas intervenir. Mais, si l'on y rajoute une pointe de parano, sur la "confidentialité" de la chose, là ... A moins d'une liaison basée sur le boson de Higgs, ou les chaines quantiques, je ne vois pas vraiment le souci.

Une chaine acquisitions/transmissions de données ne relève pas de la magie. Juste des besoins clairs, soigneusement analysés.
Zou, au boulot !

Georges.

Edit: A tout hasard, de bonnes info's, ici :

http://www.picaxeforum.co.uk/showthread.php?26699-HABAXE2-a-LoRA-based-High-Altitude-Balloon-Tracker-Project
OUAIP : dans l'ensemble je suis d'accord...
Reste que l'ami PICQC semble progresser progressivement, et en particulier envisage d'acquérir des Picaxes. La discussion n'aura donc pas été totalement stérile.
La remarque sur le résonateur était plus pour le "au cas où..." M'étant trouvé plusieurs fois en panne de ce truc à 1 €, je préfère anticiper.
Après, c'est juste une question de statistiques. Si chaque émetteur envoie une trame par minute, alors on peut simuler 60 émetteurs en envoyant une trame/s.
Si on met 1/10s pour traiter une trame, on a une chance sur dix de rater la suivante.
Si on va 8 fois plus vite, le risque n'est plus que de 1/80 ce qui est quand même assez différent.
Si on veut simuler 300 émetteurs, à vue de nez, la différence de vitesse sera sensible.
Mais on peut aussi prendre le problème dans l'autre sens, et aboutir à une conclusion genre : pour 300 émetteurs, et pour une probabilité inférieure à 1% de trames perdues, chacun doit émettre au plus une fois toutes les x heures...
Mais M. PICQC n'en est pas encore là... wait and see...

Excellent lien : srnet est une pointure dans le domaine !
 
Last edited:

jojojo

Senior Member
C'est d'ailleurs curieux ces 4Mhz : à ma connaissance, la fréquence de base d'un X2 est de 8 Mhz ???
Page 197 de la doc en anglais :"This command only fonctions at 4 Mhz, M2 and X2 parts automatically use the internal 4Mhz resonator for this command".


Et si l'on attendait plutôt un bon CdC, de l'auteur de ce fil ?

Georges.
 
Top