Page 85 sur 91

Re: Le poseur de mines RUBIS

Publié : 30 oct. 2017 00:01
par olgemaba
Cet homme est fou,, :shock: :respect:
Bravo jack !! :Up:

Re: Le poseur de mines RUBIS

Publié : 24 nov. 2017 12:20
par coaxial
trouvé une image qui pourras t'être utile peut-être

http://servimg.com/image_preview.php?i=146&u=11012744
avec LE Général De Gaulle , ( pas sur que ce soit le Rubis )
https://servimg.com/view/19759506/31

ORIGINE STE ANCIENS COLS BLEUS http://www.anciens-cols-bleus.net/t1087 ... mines-fnfl

Re: Le poseur de mines RUBIS

Publié : 30 déc. 2017 22:52
par Jacky-Soum
Bonjour tout le monde ! ;)

Maintenant que Noël est passé et, en attendant la Saint Sylvestre, avant de mettre à jour ce dossier qui a pas mal progressé depuis Octobre, je remercie Coaxial pour ses recherches. :Up:

Cependant, je dois lui préciser que d’une part je connais toutes les photos présentées sur ces liens et, d’autre part, certaines ne représentent effectivement pas le RUBIS ; la 1ére présente la JUNON, autre bâtiment FNFL, un « 600 tonnes » contemporain du RUBIS avec lequel il y a en effet beaucoup de ressemblances, mais aussi des différences !
Les plus visibles sur cette photos sont le largueur « insuffisante » pour le RUBIS, une seule rangée de dalots au pied de la muraille et une scie à filets lisse !
Et la photo avec le Général De Gaulle concerne la CURIE, bâtiment Anglais prêté aux FNFL et que notre ami Guy a construit en modèle navigant. ;)

Maintenant, revenons à nos moutons et, pour commencer, je vous fais part d’un problème qui aurait pu être fatal au RUBIS si j’avais utilisé un type de batteries autre que les LiFe ! :Oo:

Pour comprendre les causes, il faut se rappeler d’un incident que le RUBIS a subit à Goudargues en 2016, relaté ici : viewtopic.php?f=6&t=1120&start=720#p63959

Lors de la 2eme navigation de la journée, il y avait eu une entrée d’eau, causée apparemment par un manque de graisse dans les étambots, qui avait noyé la partie avant après avoir traversé le sous-marin d’un bout à l’autre.
De retour à la base, j’avais procédé à un grand nettoyage de la partie avant et au remplacement de 2 servos qui n’avait pas apprécié le bain forcé. Et tout avait fonctionné à nouveau correctement.

Jusqu’à cet été, où j’ai remarqué lors des charges avant navigation qu’un élément de la batterie principale était toujours plus déchargé que les autres et mettait donc plus longtemps à s’équilibrer.
Et comme à chaque fois il remontait au top, je me suis dit qu’il attendrait bien la fin de saison avant de subir une investigation.
Mais, 2 jours avant le salon de Sedan, les 14 et 15 Octobre, lors de tests de fonctionnement avant recharge, l’alimentation du RUBIS bascule sur la batterie de secours, et le contrôle immédiat de la batterie principale me donne un élément à zéro Volts ! :evil:
Bon, pas de panique, s’il est vraiment mort, je le shunte pour le salon et, de toute façon, je commande tout de suite un jeu de batterie de rechange ; et je tente quand même une recharge de l’élément défectueux avec mon alimentation.

Là, miracle, l’élément prend la charge et je fini l’équilibrage avec le chargeur, ce qui me permets d’assurer le salon, en constatant toutefois que l’élément tend à se décharger hors utilisation.

Au retour, je démonte la batterie principale et, là, j’ai une sueur froide ! :woow:
L’élément défectueux est fendu, comme on peut le constater sur cette photo !

Image

Vu sous cet angle, on remarque la déformation de l’élément, ainsi que des traces d’échauffement.
Image

Lors du démontage de la batterie, j’ai compris ce qui s’était passé : quand l’eau s’est baladée dans le sous-marin en Aout 2016, quelques gouttes ont réussi à pénétrer dans l’emballage de la batterie et provoquer une légère oxydation sur l’extrémité d’un élément, qui s’est propagée petit à petit jusqu’à produire une « liaison dangereuse » entre le plot central et le corps de l’élément. Cela s’est traduit dans un premier temps par une décharge lente de l’élément, d’où l’état de déséquilibre que j’avais constaté.
Puis, le phénomène a pris de l’ampleur, jusqu’à provoquer l’échauffement et l’éclatement de l’élément qui s’est produit, heureusement, sans dégâts collatéraux et, sans non plus mettre complétement hors d’usage l’élément ! :woow:

Là, je me dis que j’ai sans doute bien fait de prendre des LiFe plutôt que des LiPo, sachant l’instabilité de ces dernières et leur prédisposition à s’enflammer ! :Oo:

Voici donc la nouvelle batterie en place, qui va m’obliger à refaire la pesée du RUBIS !
Car, n’étant pas du même fabriquant, les éléments sont plus lourds et ajoutent 84 gr au sous-marin !

Image

Ce problème étant réglé, les travaux ont repris avec la fabrication des 2 poupées de manœuvre, usinées dans du rond de PVC.
On a, à gauche sur cette photo, la poupée avant et, à droite, la poupée arrière inachevée, ainsi que les paliers réalisés dans du rond de laiton.

Image

La différence essentielle entre les 2 poupées réside dans leur mode de commande : celle placée à l’avant peut être entrainée soit par le guindeau de l’ancre, soit par un carré de manœuvre lié au guindeau, sur lequel s’emboitent 4 bras métallique. Ce carré n’est pas encore réalisé.
Celle placée à l’arrière ne peut être manœuvrée qu’à la force des bras et comporte donc en partie haute les 4 trous carrés recevant les bras de manœuvre.

Image

Elles sont aussitôt mise en place et je leur ai trouvé une utilité fonctionnelle : elles permettent de manœuvrer les crocs de remorquage !
Image

Voyons tout de suite comment ça marche, en retournant le pont arrière.
La poupée est à gauche et le croc à droite et, entre les deux, on a une tige de laiton.

Image

A la base de la poupée se trouve une pièce de laiton percée d’une lumière dans laquelle la tige de laiton est engagée.
Image

Cette tige a une forme de manivelle et on comprend aisément que la rotation de la poupée sur quelque degrés va entrainer la rotation de la tige, ce qui est visible sur cette photo.
Image

A l’autre extrémité, la tige forme un levier qui est pris dans la base pliée du verrou du croc.
On distingue le ressort de rappel du verrou, noyé dans la graisse et retenu sur le verrou par un épingle à tête de couturière.

Image

La conséquence de la rotation de la tige, entrainée par la poupée, est visible sur cette photo : le verrou du croc est rentré, libérant ainsi le croc….
Image

…Ce qu’on vérifie en retournant le pont avec les 2 photos suivantes ; ici poupée prête à la manœuvre, le verrou est visible en position « croc verrouillé »…
Image

… Et là, poupée tournée de quelques degrés, le verrou n’est plus visible car escamoté : le croc est libre.
Lors du relâchement de la poupée, le ressort de rappel du verrou ramène le mécanisme au repos car il est suffisamment costaud pour ça.
Pour le moment et faute de temps, seul le croc arrière est fonctionnel ; celui de l’avant recevra le même mécanisme lors d’un autre démontage de la coque…

Image

Parallèlement à la mise en place des poupées, j’ai (enfin) installé les antennes basses.
Ici, à l’avant, elles « habillent » la scie à filets. La partie visible des antennes est réalisée en élastique afin de rendre le tout moins fragile lors d’un accrochage accidentel.

Image

Pour l’arrière, j’ai dû étudier de très près plusieurs photos pour réaliser le portique conforme à l’original car celui figurant dans le dossier de plans est celui du Saphir.
J’ai recyclé les poulies réalisée initialement pour l’avant et remplacées ensuite car trop petites. Les antennes sont fixées sur le portique à l’aide de petits crochés en laiton, faciles à décrocher pour l’ouverture du sous-marin, et le portique est relié par des élastiques à la base via les poulies. Ainsi on risque moins de casser quelque chose en se prenant les mains dans les antennes…

Image

La partie centrale montre un croisement de fils et une grande quantité d’isolateurs ; ceux-ci sont réalisés dans du rond de bois de diamètre 5 mm teinté et verni et il y en a 40 en tout.
Remarquez en haut à droite le petit bras isolant placé contre la 1ére perle sur l’antenne basse et le brin de liaison avec l’antenne haute.

Image

Vu sous cet angle, pour le plaisir des yeux, il ne manque que l’équipage pour reproduire la scène visible sur une photo présente dans le dossier historique…
Image

Après les « travaux qui se voient », je suis passé à ceux « qui ne se voient pas » mais qui sont bien utiles au bon fonctionnement du RUBIS. :Up:

La carte de répartition des commandes disposée à l’avant, dont je remets une photo, ne remplissait pas complétement son rôle, à cause d’une trop grande simplification du schéma.
Image

J’avais des petits défauts de fonctionnement et, surtout, une consommation permanente de courant préjudiciable à l’autonomie. Elle recevait de nombreux connecteurs et était en lien avec le décodeur Multi-Prop que j’avais l’intention de remplacer par une carte ARDUINO.

La nouvelle carte de répartition des commandes avant comporte un CI supplémentaire qui améliore grandement le fonctionnement et supprime la consommation permanante de courant. Elle compte aussi moins de connecteurs du fait d’une liaison groupée avec la carte ARDUINO disposée en dessous.
Image

Pour ceux que cela intéresse, voici le schéma de principe des commandes des moto-réducteurs de mâts et de portes de TLT qui est intégré à la carte de répartition des commandes avant.
Image

Et le schéma du circuit imprimé. Les connecteurs des servos Ballast et voie 4 (barres de plongée avant) sont disposés sous la carte.
Image

Désormais, une carte ARDUINO « mini » remplace le module Multi-Prop avec des fonctionnalités que le module ne permet pas. :Up:
On a à gauche les 4 connecteurs des servos de largage des mines ; en bas le connecteur blanc relie les lignes de programmation de l’ARDUINO au connecteur DB15 de liaison avec le rack technique.
On a ensuite les 3 connecteurs des servos, de vanne 3 voies, de la pompe Kavan des auxiliaires et de tir des torpilles avant.
Enfin, en haut à droite, le connecteur de liaison avec le connecteur DB15 de liaison avec le rack technique amène les principales commandes. Et quelques fils regroupés sur un connecteur établissent la liaison avec la carte de répartition située juste au-dessus.

Image

En effet, le module Multi-Prop ne permet pas de régler la course des servos, ni d’en inverser le sens !
Hors, pour le mouillage des mines et pour « normaliser » le sens des commandes sur la radio, j’ai dû installer 1 pignon inverseur sur les groupes de largage arrière gauche et avant droit. Bien sûr, cela fonctionne, mais avec une perte de couple et un jeu supplémentaire ! Et l’obligation de limiter « manuellement » la course des servos de largage !
Enfin, les 4 servos étaient alimentés en permanence, ce qui là aussi réduisait l’autonomie du RUBIS et exposait à un largage accidentel suite à un parasite par exemple !

Je vous présente aussi le schéma de principe de cette carte ARDUINO.
On remarque à gauche les 4 lignes de commande tout ou rien d’autorisation de largage des mines, issues du module Multi-Switch ; ce sont elles qui pilotent directement les 4 transistors disposés à droite, qui fournissent l’alimentation 6 Volts aux servos. Cette alimentation est contrôlée par une sortie ARDUINO, via les 2 transistors disposés en haut à droite.

Image

Ainsi que le schéma du circuit imprimé…
Image

Avec la carte ARDUINO, les courses sont réglées au mieux, les pignons inverseurs vont être supprimés très prochainement et les servos ne sont alimentés que lorsque les commandes (prévues à cet effet) d'autorisation de largage sont activées sur la radio, ce qui élimine le risque de largage accidentel.
Enfin, la carte gère aussi l’alimentation 6 Volts de la partie avant : celle-ci n’est active que lorsque l’ARDUINO a reçu un train complet et valide d’informations « Multi-Prop » en provenance de la radio. Donc, en cas de perte de la liaison radio, toutes les fonctions auxiliaires sont mises hors tension, ce qui évite là aussi des mouvements intempestifs, tel un tir de torpille !!! :Up:

Maintenant, j’attends une amélioration météo pour un passage au bassin afin de corriger la pesée car j’ai une navigation prévue dans 2 semaines !
Et il y a encore beaucoup à faire en « travaux visibles », équipements du pont, bouée téléphonique, etc…, et en « travaux invisibles » tel que les ballasts de compensation du poids des mines qui permettront le largage en plongée !

Mais ce sera l’année prochaine ! :bave:

Cordialement de Jacky-Soum :trinque:

Re: Le poseur de mines RUBIS

Publié : 31 déc. 2017 10:39
par Pablo
:o Cet homme nous étonnera toujours...
Que dire, sinon :applaudi: et comme dirait la Vénus de Milo : "Les bras m'en tombent"...

Re: Le poseur de mines RUBIS

Publié : 02 janv. 2018 00:22
par Rackham
Trop fort ce Jack :Up:

Re: Le poseur de mines RUBIS

Publié : 07 janv. 2018 23:33
par olgemaba
Moi qui pensais que ce soum etait terminé! En fait , avec jack, faut jamis croire quoi que ce soit !!! :lol: suis toujours autznt ébahi !
:Up:

Re: Le poseur de mines RUBIS

Publié : 10 janv. 2018 00:01
par peyo
Je me joins au tonnerre d’applaudissement! :Up:
Bravo pour cette superbe réalisation qui allie technique embarquée et une qualité maquette!

Pourrais-tu nous en dire un peu plus sur la manière dont tu as procédé pour remplacer le Multi Prop par l'Arduino (au niveau du programme notamment)?
En particulier quelle est la forme des signaux en entrée du MultiProp,en provenance du récepteur? S'agit-il d'un PWM classique? Mais dans ce cas comment gérer "l'adressage"?

J'imagine assez bien la forme de tes signaux de sortie mais c'est plus flou pour l'entrée...

J'aimerai bien mettre en place quelque chose de ce type dans mon soum pour la commande du bloc de distributeurs de la commande des aériens mais je ne sais pas encore bien comment gérer cela... :frust:

Merci d'avance!

Peyo

Re: Le poseur de mines RUBIS

Publié : 11 janv. 2018 18:57
par Jacky-Soum
Bonjour à tous et merci pour vos commentaires ! :respect:
peyo a écrit :….
Pourrais-tu nous en dire un peu plus sur la manière dont tu as procédé pour remplacer le Multi Prop par l'Arduino (au niveau du programme notamment)?
En particulier quelle est la forme des signaux en entrée du MultiProp, en provenance du récepteur? S'agit-il d'un PWM classique? Mais dans ce cas comment gérer "l'adressage"?
…..
Merci d'avance!
Peyo
Pour répondre à Peyo, je dois reconnaitre que je me suis inspiré de ce que notre ami Stephd a posté il y a déjà quelques temps ici : viewtopic.php?f=10&t=2956

Mais je vais développer un peu, car cela peut donner des idées, tout en démystifiant un peu la chose ! :ugeek:

Petit rappel sur le codage standard de nos radios : chaque voie est codée sous la forme d’un créneau dont la durée varie de 1 à 2 ms en fonction de la position des manches, la position « neutre » générant un créneau de 1,5 ms. L’émetteur range les voies l’une derrière l’autre, en commençant par la voie 1 et en finissant par la 8eme (ou la 4eme dans le cas d’une radio 4 voies…), pour former un train comptant au maximum 8 créneaux, toujours suivis d’un « silence » d’environ 4 ms.
Ensuite, il recommence le cycle au début, de telle sorte que le temps séparant le début de 2 trains est de l’ordre de 20 ms. En conséquence, le message envoyé par l’émetteur se répète toute les 20 ms, chaque voie étant scrutée et codée à chaque cycle.

Au niveau de la réception, c’est le « silence » de 4 ms qui permet de détecter le début du message et de synchroniser le décodage ; il ne reste plus alors qu’à aiguiller chaque voie au fur et à mesure de leur arrivée vers une sortie distincte du récepteur sur laquelle on vient brancher un servo, qui est donc « rafraichi » au rythme du train reçu, à savoir toute les 20 ms.
Bien sûr, dans le cas d’une radio 4 voies, le silence est plus long, à savoir environ 12 ms de façon à respecter le rythme de 20 ms.

Voyons maintenant comment cela se passe avec un module « Multi ». ;)
Il y a déjà un point important à connaitre : au niveau de l’émetteur, les cartes de codage « Muliti-Prop » 4 inters + 4 potentiomètres et « Multi-Switch » 6 inters + 2 potentiomètres, ou « Multi-Switch 16 » sont rigoureusement identiques ! Pour s’en convaincre, il suffit de les regarder et on constate que le circuit est prévu pour recevoir des interrupteurs à la place des potentiomètres !

Et pour cause !
Elles codent les signaux de la même manière, à savoir, un train de 8 créneaux « standards » rangés dans l’ordre, de la voie « multi n° 1 » à la voie « multi n°8 », à raison d’une « voie Multi » par cycle de 20 ms.
La seule différence entre un interrupteur à 3 positions et un potentiomètre est que le 1er ne connait que les positions 1 ms quant il est poussé vers l’avant, 1,5 ms au neutre et 2 ms quant il est tiré vers l’arrière, alors que le potentiomètre fait varier la valeur de façon continue d’une extrême à l’autre.
A noter qu’un interrupteur raccordé sur une voie « classique » à la place d’un manche produit exactement le même effet ! :Up:

La carte se contente donc de mettre bout à bout les 8 créneaux générés par les commandes du module « Multi », en y ajoutant un créneau « non conforme » de 0,940 ms qui va servir au niveau du décodeur à reconnaitre le début du train, le tout au rythme d’une « commande Multi » par cycle de 20 ms.
Ce qui veut dire qu’à la réception, le décodeur « Multi » attend de voir arriver le créneau « non conforme » de 0,940 ms qui lui permet de se synchroniser pour décoder ensuite le 1er créneau du cycle, qui arrive 20 ms plus tard.
Lorsque ce créneau arrive, il est orienté vers la 1ere sortie du décodeur « Multi » puis, 20 ms plus tard, lors de la réception du cycle suivant, le créneau reçu est envoyé vers la 2eme sortie du décodeur et ainsi de suite jusqu’au 8eme créneau.
Ensuite, le décodeur attend le créneau « non conforme » de 0,940 ms suivant, pour recommencer un nouveau cycle.

Donc, chaque sortie du décodeur « Multi » est mise à jour tous les 9 cycles (8 cycles pour 8 voies + 1 cycle de synchronisation) soit 9 X 20 ms = 180 ms. Voilà pourquoi les voies issues des modules « Multi » sont plus lentes que les voies « normale » ! ;)

Voyons maintenant comment traiter le problème avec une carte ARDUINO.
La fonction « pulseIn() » répond tout à fait à l’objectif à atteindre : elle scrute une entrée de la carte jusqu’à voir un passage de l’état bas à l’état haut, par exemple, et nous donne une valeur exprimée en µsecondes du temps écoulé entre les deux changements d’état, ce qui correspond à la largeur du créneau, avec la possibilité de limiter dans le temps cette scrutation, ce qui s’avère utile en cas de perte radio !
Car si au bout de 30 ms par exemple (soit 1,5 cycles), on n’a pas détecté le créneau attendu, c’est qu’il y a un problème et on décide alors de mettre le système en position de sécurité, en coupant, par exemple, l’alimentation de certains équipements afin d’éviter des problèmes plus sérieux !

Dans le programme que j’ai développé, il y a deux boucles distinctes qui utilisent cette fonction.
Dans la 1ere boucle, on attend le début du tout 1er cycle : c’est celui qu’on doit détecter après la mise en marche de la radio ou après une anomalie de réception (perte de portée, parasite….).
Chaque créneau reçu est « mesuré » par comparaison avec la valeur de 940 µs : quant la valeur reçue est « <= » à 940, c’est qu’il s’agit du créneau de synchronisation et on valide le début du cycle ; on attend ensuite dans une « sous-boucle » les 8 créneaux suivant, que l’on compare individuellement aux valeurs extrêmes possibles, à savoir 1 ms minimum et 2 ms maximum (avec, bien sûr, une petite marge de sécurité !)
Là, il y a 2 cas possibles :
- Soit 1 des créneaux reçus est en dehors des valeurs mini – Maxi, ce qui s’apparente à une réception parasité : on revient alors à la boucle de détection du créneau de synchro.
- Soit les 8 créneaux reçus sont conformes : dans ce cas, on sort de cette boucle, en positionnant un « drapeau » qui signale la bonne réception du 1er cycle. Ce « drapeau » est une simple case mémoire pour laquelle on définit deux états distincts, liés au déroulement du programme : soit tout va bien et on le met à « 1 », soit il y a un problème, et on le met à « 0 ». Il peut ensuite être utilisé ailleurs dans le programme.

La deuxième boucle reprend la structure de la 1ere, mais avec le rangement des valeurs de chaque créneau reçu dans un tableau de données au fur et à mesure de leur arrivée , à condition, bien sûr, qu’ils soient conformes, pour qu’ils puissent être utilisée dans une autre partie du programme.
Car si un créneau reçu n’est pas conforme, ou si le temps impartit à la fonction « pulseIn() » est dépassé, c’est qu’il y a un problème de réception ; le « drapeau » de 1er cycle est remis à « 0 » et on retourne à la 1ere boucle du programme.

Comme il se passe 20 ms entre chaque détection d’un créneau, on a le temps de faire autre chose !
Dans le cas présent, on rafraichit les 8 sorties correspondantes aux 8 voies « Multi » avec les valeurs précédemment rangées dans le tableau, ce qui permet aux servos de fonctionner correctement.
Pour piloter 1 servo, il suffit de positionner à « 1 » la sortie concernée, ce qui correspond au début du créneau, d’attendre le temps égal à la durée du créneau reçu à l’aide de la fonction « delayMicroseconds() », puis repositionner la sortie à « 0 », ce qui marque la fin du créneau.
Mais attention !
Tant que le 1er cycle correct n’est pas intégralement reçu, les valeurs rangées dans le tableau peuvent être incohérentes et poser un problème au servo correspondant !

Pour éviter ce souci, j’utilise un second drapeau qui est positionné à « 1 » lorsque le cycle reçu est complet et remis à « 0 » en cas de problème de décodage.
Ensuite, dans une autre partie du programme, j’utilise ce drapeau pour activer ou désactiver la sortie qui pilote l’alimentation 6 Volts des servos !

Voilà globalement la structure du programme de mon ARDUINO ; il y a en plus quelques bidouilles de mise en forme des créneaux, entre autre la limitation des courses des servos de largages des mines et l’inversion de sens pour deux d’entre eux, ainsi que la prise en compte des 4 entrées d’autorisation de largage qui, lorsqu’elles ne sont pas valides, forcent la durée du créneau de commande du servo correspondant à « 0 » (il n’y a donc pas de créneau généré en sortie) et coupe en même temps l’alimentation du servo concerné (économie d’énergie oblige !)

Maintenant, vous savez presque tout sur le programme ARDUINO de décodage « Multi-Prop » ! ;)
Et on peut facilement extrapoler ce programme pour un décodage « Multi-Switch » ! :Up:

Il suffit simplement de comparer la durée des créneaux reçus avec des seuils mini et Maxi correspondants aux 3 positions d’un interrupteur pour activer ou non des sorties de la carte, sur lesquelles on vat brancher des lampes, des relais, des motoréducteurs…
Par exemple, si la durée du créneau reçu est « > » à 1900 µs, cela correspond à un inter en position « tirée » (2000 µs), on met donc à « 1 » une sortie qui va, par exemple, allumer une lampe, et on met cette sortie à « 0 » si le test est faut, c'est-à-dire si la durée est « < » à 1900 µs, ce qui est le cas lorsque l’inter est à la position « neutre » (1500 µs) ou en position « poussée » (1000 µs).
Donc, avec les tests qui vont bien, on peut activer ou désactiver 2 autres sorties en exploitant les 2 autres positions de l’inter !
Pas mal quand même, non ?? ;)

Cordialement de Jacky-Soum :trinque:

Re: Le poseur de mines RUBIS

Publié : 15 janv. 2018 01:25
par peyo
Merci beaucoup pour ces précieuses explications! :Up:

Sais-tu si le principe est identique sur les systèmes multi-switch sur les radios d'autres marques ou au contraire s'il varie de l'une à l'autre?

Dans mon cas:
émetteur: GRAUPNER MC19
récepteur: GRAUPNER SMC19
module multiswitch emission: Nautic expert 16 canaux (Réf. N° 4108) -> je ne l'ai pas et il est en stock épuisé partout où je l'ai trouvé en vente... mais on peux le remplacer partiellement par programmation de l'émetteur.
Sinon je me demande s'il est possible de le remplacer par son équivalent Robbe, plus facile à trouver, mais je n'ai pas la réponse: https://www.tecnimodel.com/accessoires- ... -8084.html
module multi-switch réception: décodeur Graupner 2-16K NAUTIC Expert (Réf. N° 4159) -> je ne l'ai pas non plus mais je compte bien le remplacer par l'Arduino.

Dernière question Jacky: comment mesures-tu les signaux émis et reçu dans ta phase de rédaction/mise au point du programme? D'une part pour comprendre les signaux reçus en entrée et d'autre part pour contrôler que les signaux que tu génères avec l'Arduino sont bien conformes à ce que tu souhaites faire? Tu disposes d'un oscilloscope?

Merci d'avance!

Peyo

Re: Le poseur de mines RUBIS

Publié : 15 janv. 2018 12:45
par Jacky-Soum
peyo a écrit :Merci beaucoup pour ces précieuses explications! :Up:
Y a pas de quoi, le forum est fait pour ça ! :Up:

Sais-tu si le principe est identique sur les systèmes multi-switch sur les radios d'autres marques ou au contraire s'il varie de l'une à l'autre?
Non, malheureusement, je n'ai jamais eu de radio "grospneux" (comme dit Pierrot ! :mrgreen: ) entre les mains, mais je me doute que le principe doit être très proche ! ;)
peyo a écrit :....Sinon je me demande s'il est possible de le remplacer par son équivalent Robbe, plus facile à trouver, mais je n'ai pas la réponse...
Il est clair que si le principe est le même, ça doit marcher, mais je n'ai pas fais le test ; peut être que si quelqu'un a le matos.... :roll:
peyo a écrit :.....je ne l'ai pas non plus mais je compte bien le remplacer par l'Arduino.
C'est clair qu'à partir du moment qu'on connait le principe, l'ARDUINO peut faire le boulot... :Up:
peyo a écrit :Dernière question Jacky: comment mesures-tu les signaux émis et reçu dans ta phase de rédaction/mise au point du programme? D'une part pour comprendre les signaux reçus en entrée et d'autre part pour contrôler que les signaux que tu génères avec l'Arduino sont bien conformes à ce que tu souhaites faire? Tu disposes d'un oscilloscope?

Merci d'avance!

Peyo
Oui, bien-sur! :Up:
J'ai investis il y a quelques années dans un oscillo à mémoire numérique qui est indispensable pour bricoler l'électronique ! ;)

Cordialement de Jacky-Soum :trinque: