Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Portier Audiophone bifilaire (200m)
Bonjour Paulfjujo et le forum,
Comme tu aimes à le dire, je plussoie ; et moi je suis Basque
Ceci étant, je fais confiance à Temps_x, et on pourra toujours utiliser le HT9170B comme outil de maintenance externe
Euh, ça c'est pour le décodage, non?
Non pas du tout : A mon humble avis, distance trop longue pour un bus RS485.
Le fullduplex nécessite de pouvoir bloquer électroniquement le bouclage audio micro/HP de la même platine. Dans mon schéma de principe, c'est par mixage du signal direct du Bus (+ micro parasite!) avec le signal micro parasite mis en oppo de phase, avant amplification vers le HP.
C'est de base ce que font (faisaient!) certains des IC spécialisés évoqués, d'autres, souvent plus élaborés, utilisant la technique voice-switch (série TEA10xx) ; je sais qu'on voit encore du CS6422 chez les chinois, mais le matou échaudé que je suis...
Je ne sais pas si cela peut être réalisé par le PIC (préamplification micro et amplification HP exclues bien sûr).
Si oui, on gagnera encore au plan du Hardware, voire des réglages..
Bus sur une paire de fils de cuivre monobrin 8/10èmes.
A+
paulfjujo a écrit :Le module HT9170B à l'avantage d'être un juge de paix et permet de verifier/qualifier la reception du signal DTMF correct
Comme tu aimes à le dire, je plussoie ; et moi je suis Basque
Ceci étant, je fais confiance à Temps_x, et on pourra toujours utiliser le HT9170B comme outil de maintenance externe
paulfjujo a écrit :on trouve pas mal d'autres exemple basé sur l'algo de Goertzel
Euh, ça c'est pour le décodage, non?
paulfjujo a écrit :tu pensais à une liaison Audio numérique ? ... RS485
Non pas du tout : A mon humble avis, distance trop longue pour un bus RS485.
Le fullduplex nécessite de pouvoir bloquer électroniquement le bouclage audio micro/HP de la même platine. Dans mon schéma de principe, c'est par mixage du signal direct du Bus (+ micro parasite!) avec le signal micro parasite mis en oppo de phase, avant amplification vers le HP.
C'est de base ce que font (faisaient!) certains des IC spécialisés évoqués, d'autres, souvent plus élaborés, utilisant la technique voice-switch (série TEA10xx) ; je sais qu'on voit encore du CS6422 chez les chinois, mais le matou échaudé que je suis...
Je ne sais pas si cela peut être réalisé par le PIC (préamplification micro et amplification HP exclues bien sûr).
Si oui, on gagnera encore au plan du Hardware, voire des réglages..
paulfjujo a écrit :caractéristiques de ton câble ?
Bus sur une paire de fils de cuivre monobrin 8/10èmes.
A+
Portier Audiophone bifilaire (200m)
Bonjour Babar64, paulfjujo, et tout le forum,
Content de te revoir d'aplomb
Il manquait bien une personne à l'appelle, maintenant que tu es là... le compte y est
Comme j'ai presque terminé l'algorithme de remplissage par diffusion, qui fonctionne en QuickBasic, reste plus cas l'écrire en ASM... après je vais enfin pouvoir m'attaquer au décodage DTMF en ASM
Peut être ouverture d'un post sur décodage et codage DTMF en ASM..... on va on trouvé un paquet des HT9170B sur LBC
On verras comment ça fonctionne une fois mon idée écrite, on pourras l'appeler algorithme DTMF de Temps-x
A+
Babar64 a écrit :Source du message A nouveau sur les rails après un arrêt en gare hospitalière pour Reset
Content de te revoir d'aplomb
Babar64 a écrit :Source du message Je vois que le brain-storming Fanstaspicien n'a, lui, pas pris de pause
Il manquait bien une personne à l'appelle, maintenant que tu es là... le compte y est
paulfjujo a écrit :Source du message Temps-X nous l'a promis !
Comme j'ai presque terminé l'algorithme de remplissage par diffusion, qui fonctionne en QuickBasic, reste plus cas l'écrire en ASM... après je vais enfin pouvoir m'attaquer au décodage DTMF en ASM
Babar64 a écrit :Source du message Ceci étant, je fais confiance à Temps-x, et on pourra toujours utiliser le HT9170B comme outil de maintenance externe
Peut être ouverture d'un post sur décodage et codage DTMF en ASM..... on va on trouvé un paquet des HT9170B sur LBC
On verras comment ça fonctionne une fois mon idée écrite, on pourras l'appeler algorithme DTMF de Temps-x
A+
Portier Audiophone bifilaire (200m)
Bonjour à tous,
Merci de vos encouragements ; ça fait du bien.
Je me rends compte que j'ai donné un mauvais pdf du schéma STREET ; voila le bon :
Pour tout regrouper, je remets aussi le schéma HOME :
Désormais, les schémas, hardwares et les affectations de ports des PIC sont fixés.
Je vais donc pouvoir reprendre les documents (Descriptif Fonctionnel, Ordinogramme, etc.) avec les bons référencements (labels et numérotation des composants).
A suivre donc.
Merci de vos encouragements ; ça fait du bien.
Je me rends compte que j'ai donné un mauvais pdf du schéma STREET ; voila le bon :
Pour tout regrouper, je remets aussi le schéma HOME :
Désormais, les schémas, hardwares et les affectations de ports des PIC sont fixés.
Je vais donc pouvoir reprendre les documents (Descriptif Fonctionnel, Ordinogramme, etc.) avec les bons référencements (labels et numérotation des composants).
A suivre donc.
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Portier Audiophone bifilaire (200m)
- paulfjujo
Expert- Messages : 2597
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
Bonsoir,
Ayant un Arduino-pro-mini sous la main
J'ai testé un decodeur DTMF (avec lib pour Arduino : #include "Goertzel.h")
Apres quelqgues déboires , et quelques modifs mineures, j'ai enfin pu compiler le tout ..
et le tester avec VENEA-NET Generateur (sortie carte SON PC)
le niveau de sortie PIC18F etant trop bas ..(mais OK pour le HT9170B)
il faut un niveau > 2,8V cr cr pour detecter ...
dans le programme , il y a ce parametre qui me chagrine .. et que j'ai du modifié
suite au test prealable de 100 valeurs lues sur l''entree A0
L'autre parametre
qui sert à priori à recentrer les valeurs sur la mediane ADC ( 1024/2)
mais qui me parait OK, QUE SI le signal varie de 0 à VCC !
hors ce n'etait pas mon cas ...
Pour cet usage (detection software ) ,il me parait essentiel qu'un preampli soit necessire pour que le signal DTMF soit centré ( sur 512)
et presente une amplitude cr cr de > 3V ...
(Le HT9170B a un ampli incorporé et un gain auto ) niveau signal <0,5V cr Cr
au final, cela parait jouable
si la fiabilité est au rendez vous ...
car on a pas la souplesse du decodeur Hardware
il va falloir user du potar de reglage et parametres softwares !
il n'y a plus qu"à
transposer cet algoritm soft Arduino .....en MPLAB XC8 pour PIC18F27K42 ...
ou une version ASM utilisable dans un environnement C ..
à moins d'ecrire toute l'appli en ASM 100% ...
bedit problem ...
un dernier petit test ..
....c'est presque OK
ATTENTION dans cet exemple
le MCU est CONSTAMENT à l'ecoute sur L'entree A0 pour pouvoir detecter le code
il ne fait rien d'autre ..
Ayant un Arduino-pro-mini sous la main
J'ai testé un decodeur DTMF (avec lib pour Arduino : #include "Goertzel.h")
This code is a basic implementation of a DTMF decoder for detecting the 16 character
DTMF code from the analog pin A0 and gives the decoded output by checking for all the
Upper and lower tones in the DTMF matrix and gives us the corresponding number by turning
on the corresponding digital bit for the numbers 0-9 and by Serially printing the rest of
the characters.
This work is entirely based on the Kevin Banks code found at
http://www.embedded.com/design/embedded ... -Algorithm
so full credit to him for his generic implementation and breakdown.
The Goertzel algorithm is long standing so see
http://en.wikipedia.org/wiki/Goertzel_algorithm for a full description.
It is often used in DTMF tone detection as an alternative to the Fast
Fourier Transform because it is quick with low overheard because it
is only searching for a single frequency rather than showing the
occurrence of all frequencies.
* THIS CODE IS Made/modified by "Mian Mohammad Shoaib" and Released into the public domain.
* for any querries related to the code feel free to ask at
MMSHOAIB8452@GMAIL.COM
Apres quelqgues déboires , et quelques modifs mineures, j'ai enfin pu compiler le tout ..
et le tester avec VENEA-NET Generateur (sortie carte SON PC)
le niveau de sortie PIC18F etant trop bas ..(mais OK pour le HT9170B)
il faut un niveau > 2,8V cr cr pour detecter ...
dans le programme , il y a ce parametre qui me chagrine .. et que j'ai du modifié
suite au test prealable de 100 valeurs lues sur l''entree A0
Code : Tout sélectionner
//const float threshold = 2000; //minimum tone amplitude to be considered we can change it for more senstivity
// ???? avec ADC 10 bits -> 1024 !!!
const float threshold = 300; // nettement reduit, en fonction des valeurs lues dans le test ADC
L'autre parametre
Code : Tout sélectionner
//#define ADCCENTER 512 // pour un signal de Vcc alim cr cr
#define ADCCENTER 100
qui sert à priori à recentrer les valeurs sur la mediane ADC ( 1024/2)
mais qui me parait OK, QUE SI le signal varie de 0 à VCC !
hors ce n'etait pas mon cas ...
Pour cet usage (detection software ) ,il me parait essentiel qu'un preampli soit necessire pour que le signal DTMF soit centré ( sur 512)
et presente une amplitude cr cr de > 3V ...
(Le HT9170B a un ampli incorporé et un gain auto ) niveau signal <0,5V cr Cr
au final, cela parait jouable
si la fiabilité est au rendez vous ...
car on a pas la souplesse du decodeur Hardware
il va falloir user du potar de reglage et parametres softwares !
il n'y a plus qu"à
transposer cet algoritm soft Arduino .....en MPLAB XC8 pour PIC18F27K42 ...
ou une version ASM utilisable dans un environnement C ..
à moins d'ecrire toute l'appli en ASM 100% ...
bedit problem ...
1209.00<LF>697.00<LF> Touch=1<LF>.
1336.00<LF>697.00<LF> Touch=2<LF>.
1477.00<LF>697.00<LF> Touch=3<LF>.
1209.00<LF>770.00<LF> Touch=4<LF>.
1336.00<LF>770.00<LF> Touch=5<LF>.
1477.00<LF>770.00<LF> Touch=6<LF>.
1209.00<LF>852.00<LF> Touch=7<LF>.
1336.00<LF>852.00<LF> Touch=8<LF>.
1477.00<LF>852.00<LF> Touch=9<LF>.
1209.00<LF>941.00<LF> Touch=*<LF>.
1336.00<LF>770.00<LF> Touch=5<LF>.
1633.00<LF>697.00<LF> Touch=A<LF>.
1633.00<LF>770.00<LF> Touch=B<LF>.
1633.00<LF>852.00<LF> Touch=C<LF>.
1633.00<LF>941.00<LF> Touch=D<LF>.
1209.00<LF>697.00<LF> Touch=1<LF>.
1336.00<LF>697.00<LF> Touch=2<LF>.
1477.00<LF>697.00<LF> Touch=3<LF>.
1209.00<LF>770.00<LF> Touch=4<LF>.
1336.00<LF>770.00<LF> Touch=5<LF>.
1477.00<LF>770.00<LF> Touch=6<LF>.
1209.00<LF>852.00<LF> Touch=7<LF>.
1336.00<LF>852.00<LF> Touch=8<LF>.
1477.00<LF>852.00<LF> Touch=9<LF>.
1209.00<LF>770.00<LF> Touch=4<LF>.
1336.00<LF>941.00<LF> Touch=0<LF>.
1477.00<LF>941.00<LF> Touch=#<LF>.
1633.00<LF>697.00<LF> Touch=A<LF>.
1633.00<LF>770.00<LF> Touch=B<LF>.
1633.00<LF>852.00<LF> Touch=C<LF>.
1633.00<LF>941.00<LF> Touch=D<LF>.
un dernier petit test ..
Detection DTMF vai algo GOERTZEL , version :20221128
Init functions Goertzel
1209.00 697.00
1336.00 770.00
1477.00 852.00
1633.00 941.00
A0 input : ADC 10-bit (default) :
Test Analog input sur 100 mesures :
A0=384
A0=371
A0=365
A0=360
A0=356
A0=352
A0=351
A0=348
A0=345
A0=343
A0=340
A0=337
A0=334
A0=330
A0=327
A0=324
A0=321
A0=318
A0=315
A0=312
A0=308
A0=304
A0=301
A0=297
A0=293
A0=289
A0=286
A0=282
A0=279
A0=275
A0=271
A0=267
A0=263
A0=259
A0=256
A0=252
A0=248
A0=245
A0=242
A0=238
A0=234
A0=231
A0=228
A0=225
A0=223
A0=221
A0=220
A0=218
A0=217
A0=216
A0=215
A0=214
A0=212
A0=213
A0=213
A0=213
A0=214
A0=214
A0=215
A0=215
A0=216
A0=217
A0=218
A0=219
A0=220
A0=222
A0=223
A0=224
A0=226
A0=227
A0=227
A0=229
A0=230
A0=231
A0=232
A0=233
A0=234
A0=235
A0=235
A0=235
A0=235
A0=235
A0=234
A0=234
A0=233
A0=233
A0=232
A0=230
A0=229
A0=227
A0=225
A0=223
A0=221
A0=219
A0=218
A0=216
A0=214
A0=211
A0=209
A0=207
sur 100 samples, Mini=207 Moyenne=256 Maxi=384
1209.00<LF>697.00<LF> Touch=1<LF>.
1336.00<LF>697.00<LF> Touch=2<LF>.
1477.00<LF>697.00<LF> Touch=3<LF>.
1209.00<LF>770.00<LF> Touch=4<LF>.
1336.00<LF>770.00<LF> Touch=5<LF>.
1477.00<LF>770.00<LF> Touch=6<LF>.
1209.00<LF>852.00<LF> Touch=7<LF>.
1336.00<LF>852.00<LF> Touch=8<LF>.
1209.00<LF>770.00<LF> Touch=4<LF>.
1336.00<LF>941.00<LF> Touch=0<LF>.
1477.00<LF>941.00<LF> Touch=#<LF>.
1633.00<LF>697.00<LF> Touch=A<LF>.
1633.00<LF>770.00<LF> Touch=B<LF>.
1633.00<LF>852.00<LF> Touch=C<LF>.
1633.00<LF>852.00<LF> Touch=C<LF>.
....c'est presque OK
ATTENTION dans cet exemple
le MCU est CONSTAMENT à l'ecoute sur L'entree A0 pour pouvoir detecter le code
il ne fait rien d'autre ..
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Portier Audiophone bifilaire (200m)
Bonjour à tous,
A y regarder avec du recul, on n'est plus vraiment sur un simple audiophone, mais plutôt une télécommande filaire bidirectionnelle à protocole DTMF sur 16 canaux (en fait 14), pouvant accessoirement véhiculer de l'audio.
Son côté bidirectionnel pourrait-il poser un problème potentiel d'éventuelles collisions d'ordres, comme par exemple quand on va actionner la commande d'ouverture du Portail : émission du son "1" par le PIC HOME à destination du PIC STREET qui le décode (ABCD=0001). En effet, dès réception et décodage côté STREET, le Portail s'ouvre, et aussitôt le capteur de position va détecter cette ouverture : émission du son "*" (étoile) par le PIC STREET à destination du PIC HOME qui le décode (ABCD=1011) pour affichage du Led "Portail Ouvert"...
Par ailleurs, l'émission sur le BUS par le PIC STREET, est également "reçue" (et donc décodé) par lui-même (auto-écoute) . Idem pour le PIC HOME
Il y a un côté serpent qui peut se mordre la queue qui m'interpelle...
Me fais-je des idées?
A+
A y regarder avec du recul, on n'est plus vraiment sur un simple audiophone, mais plutôt une télécommande filaire bidirectionnelle à protocole DTMF sur 16 canaux (en fait 14), pouvant accessoirement véhiculer de l'audio.
Son côté bidirectionnel pourrait-il poser un problème potentiel d'éventuelles collisions d'ordres, comme par exemple quand on va actionner la commande d'ouverture du Portail : émission du son "1" par le PIC HOME à destination du PIC STREET qui le décode (ABCD=0001). En effet, dès réception et décodage côté STREET, le Portail s'ouvre, et aussitôt le capteur de position va détecter cette ouverture : émission du son "*" (étoile) par le PIC STREET à destination du PIC HOME qui le décode (ABCD=1011) pour affichage du Led "Portail Ouvert"...
Par ailleurs, l'émission sur le BUS par le PIC STREET, est également "reçue" (et donc décodé) par lui-même (auto-écoute) . Idem pour le PIC HOME
Il y a un côté serpent qui peut se mordre la queue qui m'interpelle...
Me fais-je des idées?
A+
Portier Audiophone bifilaire (200m)
- paulfjujo
Expert- Messages : 2597
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
Babar64 a écrit :Bonjour à tous,
A y regarder avec du recul, on n'est plus vraiment sur un simple audiophone, mais plutôt une télécommande filaire bidirectionnelle à protocole DTMF sur 16 canaux (en fait 14), pouvant accessoirement véhiculer de l'audio.
Son côté bidirectionnel pourrait-il poser un problème potentiel d'éventuelles collisions d'ordres, comme par exemple quand on va actionner la commande d'ouverture du Portail : émission du son "1" par le PIC HOME à destination du PIC STREET qui le décode (ABCD=0001). En effet, dès réception et décodage côté STREET, le Portail s'ouvre, et aussitôt le capteur de position va détecter cette ouverture : émission du son "*" (étoile) par le PIC STREET à destination du PIC HOME qui le décode (ABCD=1011) pour affichage du Led "Portail Ouvert"...
C'est là qu'intervient Le PIC pour regulariser les échanges , via l'intermediare de tempo et une progression de type phase -pas
Par ailleurs, l'émission sur le BUS par le PIC STREET, est également "reçue" (et donc décodé) par lui-même (auto-écoute) .
Idem pour le PIC HOME
Il y a un côté serpent qui peut se mordre la queue qui m'interpelle...
Me fais-je des idées?
non, si on fait une commande en boucle ouverte .. (sans verification)
L'auto ecoute , à mon avis est inutile ,car l'ordre arrivera à destination ,avant que celui qui emet l'ordre ne puisse controler que le code emis est correct
par contre , je verrai plutot l'utilisation d'un protocole d'echange ,
pour que le destinataire renvoie ce qu'il a lu
pour confirmer Est-ce bien cet ordre là que j'ai reçu ?
on dispose des 2 codes DTMF non utilisé C et D
l'emetteur envoyant alors le code 'D' (par exmple) pour confirmer ou 'C' pour infirmer
en cas d'affirmation ,le recepteur peut alors engager la commande
et renvoyer ensuite l'etat resultant de ladite commande ..
en cas d'infirmation ,commande annulée.
un temps enveloppe maxi etant defini englobant toute action et retour d'action, pour revenir à un etat connu
si probleme .
nota : un code binaire particulier ex: 0x55 ou 0xAA emit dans un laps de temps donné ,
pourrait aussi servir de code d'echange , via la commande ecriture RAZ bus (etat bus 0 ou 1) et lecture Etat Bus
simili "telegraphe chape " ou UART à 300bds
à cogiter:
Faut-il definir un PIC MAITRE (en principe HOME ?) pour avoir une priorité sur le PIC STREET ?
celui qui Permet ou Refuse l'acces du BUS , pour des echanges d'info.
L'acces au bus ne doit pas pouvoir etre bloqué plus de x sec maxima :timeout sur le blocage (RAZ) du bus
par une action PIC HOME ou PIC STREET
A+
A+[/quote]
Portier Audiophone bifilaire (200m)
Bonsoir paulfjujo et à tous,
Pour avancer dans le concret, je lance la fabrication des cartes (JLCPCB).
Derniers points : le chronogramme et l'ordinogramme ; ça avance
A+
Cette idée pose plusieurs questions, notamment l'allongement du traitement de l'ordre ; une gestion plus lourde du blocage du Bus ; le traitement de la réponse OK de l'émetteur... la seule difficulté risquant d'être rencontrée étant que le DTMF reçu ne puisse pas être décodé à réception. A mon sens, c'est donc cette éventualité qu'il faut gérer, or le HT9170B récepteur le peut par sa sortie DV (pin15) en entrée RB0 du PIC (DTMF_OK). Je pense donc que, si l'idée reste séduisante, mettre en place un tel protocole est trop lourd et pas vraiment nécessaire.paulfjujo a écrit :Utilisation d'un protocole d'échange (...) via codes DTMF non utilisés C et D
Je n'en vois pas l'intérêt, dans la mesure où HOME n'est de toute façon pas Maître du Bus quand on sonne au portail.paulfjujo a écrit :Faut-il définir un PIC MAITRE
Bien sûr! Ce blocage du BUS (à 0v) n'est là que pour la désactivation des HPs et micros le temps de l'envoi du DTMF (mode silencieux, donc). sans ce blocage, les sons DTMF seraient audibles, ce qui n'est d'ailleurs pas gênant en soi : c'est juste une question de confort qui pourrait même être supprimée... mais on la garde!paulfjujo a écrit :L'accès au bus ne doit pas pouvoir être bloqué plus de x sec
Pour avancer dans le concret, je lance la fabrication des cartes (JLCPCB).
Derniers points : le chronogramme et l'ordinogramme ; ça avance
A+
Retourner vers « Le forum Fantas-PIC »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 34 invités