Jump to content
F4HJH

Contrôle d'un périphérique en I2C (PA, LPF, ...)

Recommended Posts

F4HJH
Il y a 6 heures, F6EHJ a dit :

Si vous entendez les relais c'est que ça commute normalement...
Que voulez-vous dire par " il ne se passe rien  d'autre ?"

@F6EHJ Gérard, j'entends bien un ou de relais passer d'un état à l'autre, mais les filtres BPF n'ont aucune incidence sur la réception, même chose pour le relais d'antenne et même chose pour le PA.

Il y a 6 heures, F6EHJ a dit :

Actuellement vous arrivez à commander les sorties 1 à 3 et 8 à 13. Il y en a d'autres ?
J'avais cru comprendre qu'il n'y avait qu'un seul PCA...16 sorties ne suffisent pas ?

Je n'en n'ai aucune idée, à priori non d’après la maigre documentation

 

Il y a 3 heures, F6ITU a dit :

Ah que ce digitalwrite est agréable comparativement aux émissions sérielles en big endian... 🙂 

@F6ITU Marc : Je confirme !! 😊

Il y a 3 heures, F6ITU a dit :

@ christophe : est-il certain que tous les esclaves I2C on bien été découverts ? je ne cesse d'utiliser le petit scanner de bus du playground Arduino qui est très pratique 

En principe oui, j'avais fait une recherche pour collecter les valeurs des registres en fonction de l'état (bande, RX/TX, ...) 

Citation

Recherche en cours...
Equiment I2C trouve a l'addresse 0x1A  !
Equiment I2C trouve a l'addresse 0x20  !
Equiment I2C trouve a l'addresse 0x50  !
Fini

Je viens de changer les valeurs de l’adresse du PCA9555 (0x1A puis 0x50) : il ne se passe rien. (aucune commutation de relais)

Nous ne devrions pas être très loin...

 

Share this post


Link to post
F6ITU

oui heu.. mais encore... comment dire...

"'entends bien un ou de relais passer d'un état à l'autre, mais les filtres BPF n'ont aucune incidence sur la réception, même chose pour le relais d'antenne et même chose pour le PA."

sur un SDR, les filtres en réception, dans des conditions normales d'exploitation, sont peu ou prou équivalente à uriner dans un stradivarius. Je défie qui que ce soit de faire la différence entre "avec filtre" et "sans filtre" a partir d'adc 14 bits et sans un oeuil rivé sur un instrument de mesure. Donc c'est normal a priori. Surtout d'ailleurs si l'on ne teste que les passe-bas.

Ce qui ne l'est pas, c'est entendre des relais qui cliquettent et les antennes qui ne commutent pas (quant au PA, je déclare forfait, il faudrait préciser quel relais est excité avec le soft, quel menu de PowerSDR, car il y a autant de configurations possibles que de promesses dans un programme électoral). 

A mon avis, le mieux serait déjà d'injecter un signal en entrée avec un géné de bruit, géné HF ou mieux encore, un VNA, et voir ce qui se passe en sortie ou sur le parcours supposé du signal. C'est bourrin et efficace. Surtout à une époque ou l'on trouve des analyseurs de spectre chinois à moins de 70 euros,  des vectoriels à 48 et des oscilloscopes numériques 100 MHz avec calcul de FFT à moins de 200 euros. Ce ne sont pas des instruments très sérieux (surtout les analyseurs), mais ils sont tout de même capables d'indiquer graphiquement quel filtre est en usage, avec une grande précision en fréquence (pas en amplitude, car la dynamique est assez pourrie, mais pour ce genre de test, ça ne sert à rien) 

... au pire, ça peut s'emprunter 😄 

le scan I2C tend à prouver qu'il y a 3 esclaves... y-a-t-il un afficheur  sur le boitier ? il peut être piloté de cette manière. Si oui, ca laisse sous-entendre qu'il y a au moins deux autres décodeurs. L'un est connu et situé du coté de l'ampli, reste à trouver l'autre. S'il n'y a pas d'afficheur, ben on n'est pas dans la .... ça signifie que l'on a à faire à trois étages différents, qu'il faut déjà cerner avant d'envisager de pondre du code.

Si je m'appelais F4HJH, comme ça, je pense que je prendrais ma plus belle plume numérique et j'enverrais un SOS à destination de DC9OE sur le forum CQ-NRW.

http://forum.powersdr.de/viewforum.php?f=40

il lit l'anglais et bien entendu l'Allemand. Et il répond pédagogiquement et avec pas mal de patience à toutes les questions (sauf celles qui laissent entendre que son projet n'est pas open... ça le froisse :- )))  )

Amicalement

Marc

 

 

 

 

Share this post


Link to post
F6EHJ
il y a 13 minutes, F4HJH a dit :

Recherche en cours...
Equiment I2C trouve a l'addresse 0x1A  !
Equiment I2C trouve a l'addresse 0x20  !
Equiment I2C trouve a l'addresse 0x50  !
Fini

Christophe,
Les essais que vous avez fait avec l'adresse 0x20 fonctionnaient...
Je ne retrouve pas dans la doc cette adresse compte tenu que le 1er quartet est fixe et égal à 0100 (4) et le second, compte tenu du cablage de A0, A1 et A2 au Vdd devrait être égal à 1110 (E) tout au moins en mode écriture (1111/F en lecture); soit 0x4E pour l'adresse I2C.
Par expérience je sais que parfois l'Arduino fait " sa sauce" et on ne retrouve pas ( à un bit près) la valeur attendue. Le scan I2C est alors fort précieux.
 

Vous pouvez essayer le petit programme ci-joint (pour bien comprendre ce que vous faites) :

 


//**************************************************************************
// Include
#include <Wire.h>//lib I2C

//**************************************************************************
//Definition variables
byte com;
byte data0;
byte data1;
//**************************************************************************

void setup() {


  Wire.begin();
}

//**************************************************************************
//modifier les valeurs de com, data0 et data1 pour tester les différents relais
void loop()
{
com=B00100000; // le bit 5 à 1 permet d'écrire sur Port 0; le bit 4 à 1 permet d'écrire sur Port 1
//com=B00010000 pour Port 1 (pour exemple)
data0=B00000001;//bit 0 port 0 actif
//data0=B00000010;//bit 1 port 0 actif (pour exemple)
data1=B00000000;//Port 1 inactif

load();
}
  //****************************************************************
//S/P chargement PCA9555
  void load()
  {
    Wire.beginTransmission(0x20);//adresse I2C réputée correcte (essayer d'autres si nécessaire)
    Wire.write (com);// Chargement mot atténuateur
    Wire.write (data0);// Chargement mot atténuateur
    Wire.write (data1);// Chargement mot atténuateur
    delay(300);
    Wire.endTransmission();
  }
  //----------------------------------------------------------

Share this post


Link to post
F4HJH
Il y a 21 heures, F6EHJ a dit :

Vous pouvez essayer le petit programme ci-joint (pour bien comprendre ce que vous faites)

Bonjour Gérard,

j'ai chargé le code dans l'arduino connecté à "la boi-boite" en I2C : Il ne se passe rien...

J'ai également cherché d'autres périphériques I2C (à l'aide de l'arduino, puis des outils I2Cdetect), je n'en vois pas d'autres.

J'ai utilisé I2Cdump et fait quelques manip RX / TX sur quelques bandes :

1817764324_Slection_017.png.703d8fb2c485b91cdc6ca5a6a07f5db6.png

Cela nous donne une autres représentation des valeurs lues.

Pour le moment, seule la librairie PCA955 de Nicoverduin fonctionne pour les 8 premières adresses. J'ai aussi testé les valeurs "unused"

Il y a 21 heures, F6ITU a dit :

A mon avis, le mieux serait déjà d'injecter un signal en entrée avec un géné de bruit, géné HF ou mieux encore,

Bonjour Marc,

j'ai fais des essais avec une sortie d'une RedPitaya avec 5 mw suffisants pour exiter le PA. Pour les essais, j'ai connecté un wattmètre qui dispose de plusieurs calibres jusqu'à 10 Watts.

J'ai un gene HF, un Oscillo 2 * 200 MHz et un Analyseur de spectre Rigol à ma disposition, donc je ferais des essais sur les filtres plus tard.

Il y a 21 heures, F6ITU a dit :

y-a-t-il un afficheur  sur le boitier ?

Non ! 

 

Il y a 21 heures, F6ITU a dit :

Si je m'appelais F4HJH, comme ça, je pense que je prendrais ma plus belle plume numérique et j'enverrais un SOS à destination de DC9OE sur le forum CQ-NRW.

http://forum.powersdr.de/viewforum.php?f=40

C'est une bonne idée, mais pour le moment je ne peut pas m'inscrire sur le forum : j'ai des erreurs php sur la page d'inscription, et un captcha me pose des questions idiotes auxquelles je ne sais répondre = je suis coincé pour le moment.

 

 

Share this post


Link to post
F6EHJ

Bonsoir Christophe,
C'est un peu compliqué à distance...
73 QRO

Gérard

Share this post


Link to post
F6ITU

si j'ai bonne mémoire, la question "antispam" concerne

- soit le bled d'origine de Jörg, et la réponse est donc Wüpperthal 

- soit le nom du site et la réponse est saure.org (google translate is your friend ob sie kein Teuton sprechen)

le php est assez zarbi en effet. Ca passe avec des accidents avec mon chrome, mais la page est nickel sous Firefox. 

Marc

Share this post


Link to post
F8EBL
Il y a 2 heures, F6ITU a dit :

soit le bled d'origine de Jörg, et la réponse est donc Wüpperthal 

Ou peut être Wuppertal ?

Mais faut avouer que ça fait assez joli avec un "ü" et un "h".😜

Il y a 2 heures, F6ITU a dit :

le php est assez zarbi

C 'est une Lapalissade !

Grüße aus Burgund !

f8ebl

  • Message intéressant 1

Share this post


Link to post
F6ITU

alors ça, c'est un coup bas... ça me rappelle mes profs de teuton... :- D 

Et pis c'est pas ma faute si les Allemand décident d'un coup que "vallée" ne prend plus de h. 

oui oui... wuppertal, sans umlaut et sans hache. je le copierais 100 fois et le déclinerais sur tous les modes

Moin Moin aus Alpen

Marc

Share this post


Link to post
F4HJH

In welchen Ort wohnt der Administrator?

😶 Wüpperthal

You have provided an invalid answer to the question !!

In welchen Ort wohnt der Administrator?

😕 Wuppertal

Your account has been created

@F6ITU  Marc, @F8EBL Merci à vous deux

 

Il y a 22 heures, F6EHJ a dit :

Bonsoir Christophe,
C'est un peu compliqué à distance...
73 QRO

Gérard

Bonsoir Gérard, 

oui à distance ce n'est pas facile. Je vais me tourner vers les OM d'outre Rhin.

J'alimenterai le sujet ici pour en faire profiter tout le monde.

 

 

Share this post


Link to post
F4HJH

Bonsoir,

en attendant, le sujet est à suivre ici  forum.powersdr.de

 

Wir werden diese Black Box demistifizieren !  😃

Share this post


Link to post
F6ITU

bonjour

je suis tout ça avec attention. La réponse donne quelque espoir.

Cette histoire d'excitation moins élevée n'est  pas franchement quelque chose de difficile à résoudre. Un ampli op ou un mmic devrait résoudre la question. 

73'

Marc

Share this post


Link to post
F4HJH

Pour information Mise à jour de l'image de la carte SD (Stemlab Charly 25 ICI )

Bon, cela fonctionne avec la RP 16 bits, j'ai retrouvé l’émission. :-) (la version beta : l'ampli ne sortais rien)

J’espère qu'Edwin va m'aider à piloter ce PA/BPF en I2C A suivre donc...

Share this post


Link to post
F4HJH
Posted (edited)

Quelques nouvelles.

Edwin du groupe Allemand Charly 25 (Concepteur du module) m'a mis sur une bonne piste que j'aurais pu voir moi même...

Quelques bouts de code pour arduino ont étés publiés ICI, ces sketchs pour Arduino Mega permettent de tester le module : BPF, et autres.

Je n'ai pas testé tous les sketchs... 

Le seul à piloter le PA et le relais d'antenne est ici : Charly_25AB_Tester_V1_2.ino

Donc il me reste à utiliser mes neurones pour me concentrer sur ce code, comprendre le contrôle de la chaîne d’émission/réception (côté antenne TX + 2 RX) et revenir ici donner les résultats et adaptations à venir. 😐

Edited by F4HJH

Share this post


Link to post
F6ITU

Bravo pour ce bel exemple de ténacité :- ) 

Ceci étant, cette aventure montre à quel point il est primordial, dans le monde des transceivers en général, et de l'open source en particulier, de s'intéresser à l'orthodoxie des bus de service et des protocoles d'échange avant même que de se pencher sur les performances intrinsèques d'une chaîne de réception ou d'émission. (et ça, ça ne se devine pas lorsque l'on se frotte à ces appareils pour la première fois de sa vie)

- il faut la volonté de Christophe pour s'attaquer à ce genre de corvée -ce qui n'est pas le cas de tous les porteurs d'indicatifs, à commencer par moi ;- ))

- ces interprétations de protocole font nécessairement appel à des forks déviants,( impossibles à "merger"  sur le master originel) et des modifs particulières sur les interfaces "client" des sdr ainsi pilotés -ou pire, a des éditions spécifiques du soft, autrement dit à une "propriétarisation" qui ne veut pas porter ce nom, dans le seul but de rendre captif l'usager. Le B.... que ça va être pour utiliser du C25 avec LinHPSDR, KissKonsole ou Quisk... il faut se taper l'écriture de toute l'adaptation d'interface. Plus je lis leur code, plus je suis admiratif du travail de Pavel Denim et de son respect des contraintes hpsdr (lesquelles d'ailleurs sont parfois discutables, mais elles font force de loi).

donc bravo au carré en raison de tout ça :- ) 

Marc

 

 

  • Merci ! 1

Share this post


Link to post
F4HJH
Posted (edited)

Bonsoir,

Merci @F6ITU Marc pour les encouragements (c'est toujours plaisant à lire 😊)

A mon tour de partager,  j'ai enfin écrit un bout de code en version 1 qui permet de contrôler le PA et BPF en I2C.

HamlalC25Module_control_Basics_V01.ino

Cette version de base permet de sélectionner la bande via un codeur optique, pour les tests le PTT est commandé via le switch du codeur optique.

Il faut que je passe à la réalisation , je je documente un peu et que je publie sur Github.

En attendant, si comme moi vous êtes équipé du "pack RedPitay avec son PA C25", on peut (enfin) utiliser la version native de powerSDR et l'OS de Pawel Denim (Open source).

Je vais peut être me lancer dans une version avec afficheur LCD  et du coup économiser des E/S PWM et augmenter les possibilités (atténuateur, ...)

[EDIT] Ah j'oubliais.... prévu pour être utilisé sur un arduino UNO

Edited by F4HJH
  • Message intéressant 1

Share this post


Link to post
F4HJH
Posted (edited)

Bonjour,

j'ai posté un peu trop rapidement le code ... car pas testé les commandes I2C. Qui pourrais se douter que le code du groupe Charly 25 ne fonctionne pas avec mon module PA/BPF ? 

Pas moi, et j'ai eu tort.

En réalité, lorsque l'on compare (ce que je n'avais pas fait) les codes publiés, on a par exemple pour l'activation du BPF sur 80m:

Charly_25_RX_BPF_Board_Tester_V1_2 :
I2CCommandString[2] |= 1 << 5;

Charly_25LC_Tester_V1_2 :
I2CCommandString[1] = I2CCommandString[1] | B00001000;

Charly_25AB_Tester_V1_2 :
I2CCommandString[1] = I2CCommandString[1] | B00100000;

On a donc des commandes différentes... 😶 pour des matériels à priori différents car il n'est pas indiqué la compatibilités des matériels et de leurs versions.

Entre temps, j'ai d'ailleurs repris le code que @F6EHJ  Gérard a publié ici mais  j'ai du mal à faire le lien (voir ci-dessous) entre les données que j'ai récupéré (i2c dump, i2c detect, ...) et ce qu'il faut envoyer et dans quel ordre...

Par exemple :

// Test 80m RX 
com=B00010001; 
data0=B00000000;
data1=B00010100;
load();

// Test 80m TX 
com=B00010001;
data0=B00011110;
data1=B00010100;
load();

Ce que j'avais relevé avec les outils I2C :

Device data address option Band PTT OFF
Value (Hex)
PTT ON
Value (Hex)
0x20 0 w 80m 0x2000 0x2030
0x20 1 w 80m 0x0020 0x3020

Puis encore :

  DECIMAL HEXADECIMAL BINAIRE
  0 1 0 1 0 1
80m RX 00 20 0 14 00000000 00010100
80m TX 30 20 1E 14 00011110 00010100

A suivre donc ....

Edited by F4HJH

Share this post


Link to post
F6ITU

pfffff, c'est le b... m'nadjudant. 

Je suis admiratif devant tant de stoïcisme, d'abnégation et de persévérance... 😄  ça m'aurait déjà donné des envies de meurtre tout ça. 

Je ne sais plus si j'avais posé la question, mais avez vous un petit analyseur logique genre "clone Saleae" 

https://bit.ly/31woxAO

c'est top pour vérifier les dialogues I2C et les états réels des sorties sans avoir à sauter de broche en broche avec une sonde de scope (8 canaux, vision d'un seul coup d'oeil de la sortie parallèle) 

Marc

(y'a pas, un sdr "full band", ça se mérite.... gniarf gniarffff) 

 

Share this post


Link to post
F6EHJ

Christophe,
Vous ne lâchez pas l'affaire....bravo..!
Reprenez la data sheet du 9555 et vous devriez y voir plus clair.

- Dans le Setup, il faut définir le sens de fonctionnement du 9955, ici les deux registres port 0 et port 1 sont en sortie :

    Wire.beginTransmission(0x20);//adresse I2C réputée correcte 
    Wire.write (0x006);// adresse du registre de configuration de sens des ports
    Wire.write (0x00);// Chargement direction données port 0 tout en output
    Wire.write (0x00);// Chargement direction données port 1 tout en output 
    Wire.endTransmission();

-Dans le programme proprement dit, 
Le chargement des données s'effectue via la subroutine "load" que j'ai envoyée précédemment ( j'ai rectifié le déroulement)
 //****************************************************************
//S/P chargement PCA9555
  void load()
  {
    Wire.beginTransmission(0x20);//adresse I2C réputée correcte 
    Wire.write (com);// Chargement mot de configuration (sélection du port : 0x02 = port 0 / 0x03 =port 1
    Wire.write (data);// Chargement port 
    Wire.endTransmission();
  }
  //---------------------------------------------------------
 

Exemple : je veux configurer en 80m RX (selon dernier tableau)
Le contenu du port 0 est égal à 0, celui du port 1 à 00010100 (0x14)
Le code correspondant sera donc :

//-------------------------------------
// port 0

com=0x02; // adresse port 0
data=0x00; // contenu port 0
load(); chargement

//Port 1
com=0x03; //adresse port 1
data=0x14 //contenu port 1
load(); //chargement 
//------------------------------------

Ca devrait marcher....!
Il doit être possible d'envoyer  la valeur des deux ports à la suite également avec l'adresse 0x02 mais c'est à vérifier (je n'ai pas ce chip sous la main pour faire un essai).

A suivre,
73
Gérard

Share this post


Link to post
F4HJH
Il y a 3 heures, F6ITU a dit :

Je ne sais plus si j'avais posé la question, mais avez vous un petit analyseur logique genre "clone Saleae" 

Bonjour Marc,

non, pas pour le moment. En tant que "futur connaisseur" du bus I2C, je pense que je vais m'équiper 😊

 

Il y a 3 heures, F6EHJ a dit :

Ca devrait marcher....!
Il doit être possible d'envoyer  la valeur des deux ports à la suite également avec l'adresse 0x02 mais c'est à vérifier (je n'ai pas ce chip sous la main pour faire un essai).

Merci beaucoup Gérard ! Je viens rapidement de faire un test avec les valeurs hexadécimales = > il se passe des choses (on entend les relais).

Il me reste à comprendre la logique et passer les bonnes valeurs en hexadécimal, nous sommes sur la bonne voie. 😉

 

Il y a 3 heures, F6EHJ a dit :

    Wire.beginTransmission(0x20);//adresse I2C réputée correcte 
    Wire.write (0x006);// adresse du registre de configuration de sens des ports
    Wire.write (0x00);// Chargement direction données port 0 tout en output
    Wire.write (0x00);// Chargement direction données port 1 tout en output 
    Wire.endTransmission();
 

Pour mieux comprendre :

Le setup permet la configuration du périphérique, Wire.write (0x006) (=> registre de config des ports - Ok)

Par contre, pour le sens des ports : pour le port0 ou le port1 on a la même commande ?  deux fois à la suite Wire.write (0x00);

Cela signifie que c'est une séquence ? 

Si j'ai compris :

Lorsque l'on sélectionne le registre de configuration (Setup) , la séquence de données attendues par le PCA9555 sont : config direction port 0 puis  config direction port 1

Lorsque l'on ne sélectionne pas le registre de configuration (Load) , la séquence de données attendues par le PCA9555 sont  : Selection du Port -> puis -> Données du port

C'est bien cela ?

Share this post


Link to post
F6EHJ
Posted (edited)

Christophe,
On avance..!

 

"Pour mieux comprendre :

Le setup permet la configuration du périphérique, Wire.write (0x006) (=> registre de config des ports - Ok)

Par contre, pour le sens des ports : pour le port0 ou le port1 on a la même commande ?  deux fois à la suite Wire.write (0x00);

Cela signifie que c'est une séquence ? "

L'accès à la direction des 2 ports se fait par le registre situé à l'adresse 0x06
On écrit dans l'ordre la direction de chaque bit du port 0, puis la direction de chaque bit du port 1

Par exemple, si je souhaite que le port 0 ait ses 4 premiers bits en entrée et le port 1 ses 2 derniers bits en entrée, je vais écrire :
 

    Wire.beginTransmission(0x20);//adresse I2C
    Wire.write (0x006);// adresse du registre de configuration de sens des ports
    Wire.write (0x0F);// Chargement direction données port 0 bits 0 à 3 en entrée, 4 à 7 en sortie (b00001111)
    Wire.write (0xC0);// Chargement direction données port 1 bits 0 à 5 en sortie, bit 6 et 7 en entrée (b11000000)
    Wire.endTransmission();

Dans votre cas, la déclaration du sens des port se fait une fois pour toute puisqu'ils seront toujours en sortie (sauf erreur de ma part). Il est donc possible de faire cette configuration une seule fois et donc dans le setup du programme.

Tout ce qui va changer pendant l'exécution du programme va se trouver dans la boucle (loop) du programme.
Pour ce faire, on n'agit que sur le contenu des registres 0x02 (port 0) et 0x03 (
port 1).
La "séquence" va constituer à chaque changement de bande à :

 

- définir l'adresse du port à charger dans la variable com 

- définir la valeur à charger dans le port dans la variable data (ces deux variables seront déclarées en début de programme comme il se doit (byte com;     byte data;)

- appeler la subroutine de chargement (load en l'occurence ici)

Si je rassemble tout ça...

byte data;
byte com;

// ne pas oublier les "include" (Wire....)
//*******************************************************************************************
void setup() // ci dessous ce qui concerne les filtres mais il y a bien d'autres choses dans le setup généralement..

{

    Wire.beginTransmission(0x20);//adresse I2C réputée correcte 
    Wire.write (0x006);// adresse du registre de configuration de sens des ports
    Wire.write (0x00);// Chargement direction données port 0 tout en output
    Wire.write (0x00);// Chargement direction données port 1 tout en output 
    Wire.endTransmission();
}

//*******************************************************************************************
void loop()
{

//votre programme de scrutation ici
//Suivant la méthode de changement de bande (poussoirs, tactile, par le transceiver), 
// l'évènement qui signale qu'une demande de changement de bande est émise 
//va déclencher plusieurs tâches (mise à jour de l'affichage, commutation des filtres...)
//La bande sélectionnée va donc activer la tâche correspondant à la bonne fréquence et aux bons pack de filtres
//Ce n'est que supposition car je n'ai pas le soft mais ça marche comme ça généralement (dans mes montages c'est sur..!!)

}

//*******************************************************************************************

//S/P chargement PCA9555


  void load()
  {
    Wire.beginTransmission(0x20);//adresse I2C réputée correcte 
    Wire.write (com);// Chargement mot de configuration (sélection du port : 0x02 = port 0 / 0x03 =port 1
    Wire.write (data);// Chargement port 
    Wire.endTransmission();
  }

//*******************************************************************************************

A suivre
73
Gérard

Edited by F6EHJ
  • Merci ! 1

Share this post


Link to post
F4HJH

@F6EHJ Gérard merci beaucoup ! Je commence enfin à comprendre le fonctionnement global.

Je pense que le code à utiliser est le tiens, à présent il faut savoir quoi envoyer.

Pour mémoire j'avais relevé ceci  :

C25_HAMLAB_PCA9555_PCA9557_releve_I2C.png.c25a9945274540c9489668fa14de0fe5.png

A noter que j'ai relevé l'adresse 0x20 et les ports 0, 1, 2 et 3 (2 et 3 étant la recopie de 0 et 1) = Doit-ton conclure qu'il faut utiliser 4 ports ? (2 pour U1 et 2 pour U2 ?)

J'ai enfin démonté le module pour enfin vérifier de quoi il est fait :

C25_HAMLAB_PCA9555_PCA9557_comp.thumb.jpg.b89d2664c0e31758a02f27908ba3780f.jpg

 

Et les datasheet :

U1 : PCA9557D puis U2 : PCA9555D

Je vais vérifier le câblage.

 

Share this post


Link to post
F4HJH

Je viens de trouver des informations intéressantes....

1/ Je refais un scan du bus I2C, et je trouve ceci :

Scanning...
I2C device found at address 0x1A  !
I2C device found at address 0x20  !
done

I2C slave scanner
   reserved adress
.  no slave detected
X  slave detected


   0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
0                          .  .  .  .  .  .  .  . 
1  .  .  .  .  .  .  .  .  .  .  X  .  .  .  .  . 
2  X  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
3  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
4  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
5  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
6  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
7  .  .  .  .  .  .  .  .  .  .  .  . 

2 devices found on the bus

Donc, nous avons deux périphériques...

2/ J'ai finalement démonté le module C25 hamlab, et voici comment les choses sont câblées :

1869872339_C25_HAMLAB_PCA9555_PCA9557_RevEng.thumb.png.ed9b5fbd1ed6e590c40fd238467818fe.png

  • Nous avons un PCA9555A (U2) à l'adresse 0x20, puis un PCA9557A (U1) à l'adresse 0x1A
  • U2 à l'adresse 0x20 est connecté aux module ULN2803 pour la commande de relais
  • U1 à l'adresse 0x1A est connecté à deux résistances (IO 0_1 et IO 0_7) qui pilotent.... le PA à mon avis

 

Donc, cela ne pouvais jamais fonctionner tant que je n'avais démonté le module. 

Le code de Gérard @F6EHJ est à mon avis le bon qu'il faut arriver à compléter avec le pilotage de U1 sur les IO 1 et 7. 

Share this post


Link to post
F6EHJ
Posted (edited)

Christophe,
Ca s'éclaircit un peu mais pas toujours facile de déchiffrer.
Les adresses sont OK et pour  le 9557 on a bien A0=0, A1=1 (en l'air a priori) et A3=0 ce qui fait bien 0x1A en considérant la partie fixe telle que décrite dans la DS.
Reste à savoir ce qu'il faut faire des sorties 1 et 7 (PA ?) c'est à confirmer en suivant les pistes du CI.

Pour U2 le 9555 il y a donc  2 ULN2003 U3 et U4 car il y a 16 sorties.
En suivant les sorties des ULN2003 on va trouver les relais correspondants et les bandes correspondantes. A partir de la c'est facile de générer la commande qui va bien.
Mais je ne sais pas comment tu articules tout ça....Utilises-tu le soft existant ? Comment se fait le changement de bande ? Le passage en émission ?
Encore pas mal de questions..
Je ne comprends pas ton tableau avec 2 fois 2 valeurs par bande pour PTT ON/OFF...Pourquoi 2 valeurs  et pourquoi une valeur spécifique en Réception et une autre en Émission ?
A suivre
73
Gérard

Edited by F6EHJ
Complément

Share this post


Link to post
F4HJH
il y a 14 minutes, F6EHJ a dit :

Mais je ne sais pas comment tu articules tout ça....Utilises-tu le soft existant ? Comment se fait le changement de bande ? Le passage en émission ?
Encore pas mal de questions..

Bonjour Gérard,

Pour vérifier la présence des deux périphériques I2C (PCA9555 et PCA9557) j'ai connecté un arduino sur le bus I2C du module (module relié à rien d'autre)

Le tableau, je l'avais renseigné à l'aide de commandes I2C depuis la RedPitaya connectées en I2C au module.

J'ai relevé les commandes directement en SSH depuis la RedPitaya à l'aide de commandes i2cget qui elle même est commandée par PowerSDR (version "fermée").

Il va falloir continuer à suivre les pistes au moins pour le PCA9555A (facile : depuis les ULN2803 on va pouvoir trouver) Pour le PA cela va être une autre histoire car le PCB est du type multicouche et je vais avoir du mal à suivre les pistes...

Avec deux IO, on devrais s'en sortir à coup de I2C sniffer je pense.

A suivre...

Share this post


Link to post
F4HJH
Posted (edited)

Suite de l'avancée du reverse-engineering ...

image.png.f8811a5009c990f73aaa354159d889ce.png

Pour le PCA9557A, je n'ai rien trouvé pour le moment, mais avec deux IO, on ne va pas s’embêter.

Voici deux photos du module face / arrière :

 

HAMLAB_C25_FACE.thumb.JPG.e61d74976f8cf4edc381c3f45f8fa2b0.JPG

 

Edited by F4HJH

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...