Décodeur de locomotive multifonctions

[laurentr]

Bonsoir à tous
 Quitte a bien faire je pense qu'il faut “pousser” un peu plus loin sur différents axes que j expose ci après.
En terme de coût pour une fabrication industrielle finalement le delta sera surtout sur les composants mis en œuvre principalement

Premier point: la régulation de tension: on le voit tout de suite cela chauffe ce qui est contre productif à ce qui est recherché.
Point de salut sans un convertisseur DcDc pour éviter le phénomène.
Il y en a beaucoup de différentes marques avec des caractéristiques aussi très hétérogènes.
Un choix peut être opéré.
Mon dévolu irait volontiers sur un MPM3510A
C est un cousin de celui présent sur les Arduino Nano Every avec une entrée plus haute en tension jusqu'à 36v en entrée et 1.2A en sortie.
4 composants basiques autour est on a une régulation solide sur le 5v.
Son seul inconvénient va été sont prix.( proche de 5€)

Point 2 :
Plus discutable mais le 328p… est “un peu hasbeen”…
Pour le même prix de CPU et tout aussi compatible nous avons les AVR de générations plus récentes ( séries d Avr0/1/2 et leur cousins Megatiny) qui vont aussi offrir plus de possibilités et de capacités avec un prix et une dispo similaire sinon meilleure!
On a l'embarras du choix.
Disons un avr32dd32 par exemple ou un atmega4808 en 32 broches sont de bons candidats.
L intérêt du 32 broches est la portabilité au travers toutes les familles. En cas de manque de place il faudra descendre en broches au sacrifice de ressources hardware. Ou à l inverse monter vers 48 mais la toutes les déclinaisons ne seront pas disponibles.
Si 32Ko de flash sont "étroits" on pourras passer à 64Ko.
Les librairies MEGACOREX, DXCORE  et MEGATINYCORE appelleront facilement la prise en charge de ces puces.


Point 3
Comme je l'avais indiqué dans mes échanges avec “le Belge” il est possible de basculer de la lib NMRA vers celle d Aiko Pra ( AP Dcc library ) optimisée pour ce hardware ( séries 0/1/2 AVR ou MEGATINY)

Elle n'est pas aussi complète en revanche pour Railcom, Consist mode … mais ça peut être là une opportunité collective de l'enrichir.

Point 4
Les dimensions d un décodeur sont normalisées en interface 21MTC ou Plux22
En gros 15x30 mm maxi ( dim max des versions sonores…)
Donc sans le son on peut aussi cibler cet encombrement.

Pour tenir le challenge un passage en 4 couches sera de mise pour le routage …
Mais la encore rien d'insurmontable .

Point 5
Pont en H… je préconise  un TB67H450 qui conviendra même aux modèles les plus gourmands  à piloter
Sinon des demi ponts à sélectionner et au pire celui déjà sélectionné.

Point 6
Choisir des Mosfet compacts pour la gestion des I/O


Tout cela combiné doit offrir une solution robuste

Alors oui cela aura sûrement aussi un coût plus élevé surtout en faible volume mais on parle aussi d un élément plus abouti techniquement.

Qu'en pensez vous ?

Laurent

[lebelge2]

Laurent, j’ai déjà fait des essais avec un convertisseur Dc/Dc avec des résultats très mauvais.
- Pendant le CutOut du signal RailCom, le booster met sa sortie en court-circuit donc l’entrée du conv.Dc/Dc est aussi en court-circuit, il réagit très mal !
- Les conv.Dc/Dc exigent un condensateur à leurs entrées, ce qui dégrade (lisse) le signal, la détection ABC est difficile, voir impossible.

J’en suis revenu à une régulation classique (78xx05) mais il faut limiter la consommation du microprocesseur, c’est pourquoi je n’utilise plus l ‘Atmel 32u4 (Pro Micro). Retour au 328p du Pro Mini.

Bien à vous.

[laurentr]

Bonsoir

Retour intéressant au demeurant sans présager du test.

Apres il y a convertisseur DC/DC et DC/DC!
En la matière plus il "hache" vite et plus il peut être "petit en dimension.
Privilégiez les versions > 1Mhz.

Les plus compacts intègrent pratiquement tout en un seul composant. Ex le MP3510A dont je parlais précédemment

Certains sont équipés de broche ENABLE, pas tous, donc cela peut aussi être un indicateur à considérer.

Quels modèles as tu testé?

Comme indique il faut en effet "juguler" la conso du 5V au stricte nécessaire et dans ce cas alors un LDO peut "encore "convenir" si VIN reste contenu.

A titre d'exemple un AVR0 type 4809 @16Mhz tirera jusqu'au 15mA sous 5V

On peut alors relayer les sorties via des MOSFET pour piloter des leds (+résistances directement depuis le VIN via le MOSFET)  et le pont en H sans excès à ce niveau.

Un équivalent du MIC5233-5V doit tenir la route.
Ce n est pas le choix qui manque:
https://www.mouser.fr/c/semiconductors/power-management-ics/voltage-regulators-voltage-controllers/ldo-voltage-regulators/?input%20voltage%2C%20max=24%20V~~55%20V&mounting%20style=SMD%2FSMT&number%20of%20outputs=1%20Output&output%20voltage=5%20V&package%20%2F%20case=SOT-223-5~~SOT-223-6%7C~SOT-23-5~~SOT-23-6&polarity=Positive&instock=y&rp=semiconductors%2Fpower-management-ics%2Fvoltage-regulators-voltage-controllers%2Fldo-voltage-regulators%7C~Package%20%2F%20Case%7C~Input%20Voltage%2C%20Max


Pour ce qui est du signal DCC et de son exploitation en entrée il faut peut être revoir aussi le montage proposé.
En PJ la solution que j'exploite avec succès. ( Voir cartes LABO présentées sur le forum)

A noter que la résistance de PULLUP peut être supprimée ainsi que l'arrivée +5V à l'entrée du MOSFET si on active le PULLUP sur la PIN du CPU ce qui fait gagner de la place!.

Pour ce qui est de l'ABC la encore voici un montage qui peut servir la cause.

Alors oui ca commence à faire "du monde à caser" mais le "bon" résultat est à ce prix.


Laurent

[laurentr]

Bonsoir

Intéressante mise en perspective des éléments.
Et merci pour cette contribution constructive.

Quelques observations ( constructives )

Le
Schéma en mode pdf serait un plus notable
Notamment pour diagnostic des ponts de mesure sur le pcb par exemple

Le railcom gagnerait à être fusionne avec la lib d aiko pour être efficient et portable. ( aiko indique ou ajouter les conditions pour y parvenir mais plus sûrement sur les AVR série 0 et AVR Dx et Megatiny qui disposent de la compatibilité avec les ressources  « évent »  et CCL)

Si Trimarco , bobynco  ou Thierry passent par la et qu ils se sentent inspirés … leur apport talentueux  à ce niveau serait topissime ! Mais tout autre talentueux développeur peut aussi contribuer!

Si j ai bien compris le sens des choses, le pilotage du pont en H sera verrouillé selon la polarité détectée en analogique et la tension au moteur sera alors proportionnelle à la tension appliquée sur l entrée du pont en H en sortie du pont de diodes.

On perd alors le bénéfice  du hachage PWM du moteur et du rendement ( supérieur ) qu il peut apporter  ( dont traitement BEMF)
Peut être l ajout d une lecture de tension en sortie  du pont de diodes et son exploitation peut améliorer les choses?.

Dans les deux cas de toute façon on a besoin que le cpu ( peu importe le modèle ) tourne pour exécuter le code .
Ce qui exclu que cela fonctionne sous  6v an analogique en gros puisque c est le seuil de fonctionnement de la régulation de tension du montage
Il faudrait alors lire la plage 6-v25v ( a minima)( via pont diviseur ) et la convertir puis l’exploiter
Pourquoi 25 alors que nous n exploiterions que en gros 6-16v
Et bien parceque  c est le haut de la plage dcc et Qu en conséquences en mode d hybridation Dcc et analogique  on combine sur le plus contraignant.( donc la tension la plus haute succeptible d être percue)
Si maintenant on veut une plage plus étendue par sécurité histoire de mieux protéger l entrée du CPU plusieurs solutions: diode transil ou tvs et ou pont pour couvrir une plage plus généreuse

Inconvénient sur les impacts de la résolution.  la conversion qui n est pas via les ADC totalement linéaire et qui peut aussi garder un seuil trop bas qu il faudrait par tranche de tension coefficienter pour « booster » le niveau de sortie.

Je ne vois pas trop d’autres alternatives…

A vos avis donc!?

Je verrai toujours bien un nano every à la place du nano et de son 328p… on gagne tellement avec c est un peu dommage de s en priver.

Laurent


 

[trimarco232]

Bonsoir

Intéressante mise en perspective des éléments.
Et merci pour cette contribution constructive. merci @ lebelge2

Quelques observations ( constructives )

Le
Schéma en mode pdf serait un plus notable
Notamment pour diagnostic des ponts de mesure sur le pcb par exemple
pareil : lebelge2 ?


Le railcom gagnerait à être fusionne avec la lib d aiko pour être efficient et portable. ( aiko indique ou ajouter les conditions pour y parvenir mais plus sûrement sur les AVR série 0 et AVR Dx et Megatiny qui disposent de la compatibilité avec les ressources  « évent »  et CCL)
à vue de nez , cela ne me paraît pas compliqué

Si Trimarco , bobynco  ou Thierry passent par la et qu ils se sentent inspirés … leur apport talentueux  à ce niveau serait topissime ! Mais tout autre talentueux développeur peut aussi contribuer!

Si j ai bien compris le sens des choses, le pilotage du pont en H sera verrouillé selon la polarité détectée en analogique et la tension au moteur sera alors proportionnelle à la tension appliquée sur l entrée du pont en H en sortie du pont de diodes. c'est la façon la + simple

On perd alors le bénéfice  du hachage PWM du moteur et du rendement ( supérieur ) qu il peut apporter  ( dont traitement BEMF)
Peut être l ajout d une lecture de tension en sortie  du pont de diodes et son exploitation peut améliorer les choses? ça risque de faire beaucoup de taf pour peu d’intérêt : qui se lancerait dans une réalisation en DiY d'un décodeur RC , ABC , son , I2C , pour finalement le faire tourner en analogique ?

Dans les deux cas de toute façon on a besoin que le cpu ( peu importe le modèle ) tourne pour exécuter le code .certes 
Ce qui exclu que cela fonctionne sous  6v an analogique en gros puisque c est le seuil de fonctionnement de la régulation de tension du montage
Il faudrait alors lire la plage 6-v25v ( a minima)( via pont diviseur ) et la convertir puis l’exploiter
Pourquoi 25 alors que nous n exploiterions que en gros 6-16v pareil : en diY , on doit pouvoir s'accomoder de cette limitation
Et bien parceque  c est le haut de la plage dcc et Qu en conséquences en mode d hybridation Dcc et analogique  on combine sur le plus contraignant.( donc la tension la plus haute succeptible d être percue)
Si maintenant on veut une plage plus étendue par sécurité histoire de mieux protéger l entrée du CPU plusieurs solutions: diode transil ou tvs et ou pont pour couvrir une plage plus généreuse

Inconvénient sur les impacts de la résolution.  la conversion qui n est pas via les ADC totalement linéaire et qui peut aussi garder un seuil trop bas qu il faudrait par tranche de tension coefficienter pour « booster » le niveau de sortie.

Je ne vois pas trop d’autres alternatives…

A vos avis donc!?

Je verrai toujours bien un nano every à la place du nano et de son 328p… on gagne tellement avec c est un peu dommage de s en priver.
amha l'idéal serait d'utiliser un mcu genre megatiny en UQFP 20 , avec juste 3 fils pour téléverser , et le rajouter sur la cate , tu peux faire ça , quite à passer en 4 couches et 0402 

Laurent

[laurentr]

Bonsoir à tous

Bonsoir Marc

Je m’y suis déjà collé ! Mais je vais reprendre pour plus d efficacité et optimiser avec tous les sous éléments hardware à placer.

L’heureux élu est l AVR32DD20 qui est un excellent candidat.
Il est en balance avec les Megatiny X6 et X7 en resp 20 et 24 broches mais plus laborieux pour la gestion de certains « trucs ».
Attention en 20 broches les brochages entre DD et Megatiny sont Différents donc cpu non substituables!
Juste au dessus on a la gamme des AVR en 28 broches à peine plus encombrant et on gagne quelques ressources ( dont un timer B) et dans le
panier commun on passe à 32 broches pour à peine plus de place occupée sur le PCB.

0402 oui en dessous c est plus chère et faut encore que ça passe ds les dissipations avec les valeurs
Cote condo pour la partie « haute tension » c est 0805 mini et ça peut descendre aussi en 0402 côté basse tension et petite capa sinon 0603 ou à nouveau 0805

Quitte à pousser plus loin j intégrerai volontiers quelques éléments:

Connecteur 21MTC ou PLUX22, des Mos pour séparer le cpu des I/O des consommateurs
A voir donc aussi selon la place la partie RC et ABC
Mais dans tous les cas j exclue le son sur le même PCB car je limite volontairement à 16mm*30mm ( selon la norme c est la place max d un décodeur donc pour nous exploitable sans devoir descendre trop bas dans la miniaturisation des composants.
A voir pour une extension SUSI ( qui est un I2C) pour laquelle la norme en allemand n'est pas traduite !! Mais qui serait un plus « inédit en DIY ». ( en offrant la compatibilité avec les platines de loc qui s appuient dessus ( exemple LSM).
Si on a de la place à voir si on peut glisser un autre connecteur pour partir vers le DF player … A défaut des pads feront le job
Of course 3 plots pour la prog +5v Gnd et UDPI

Simple , y a plus qu'a !

En revanche pour gagner en place le recours à un convertisseur Dc Dc comme le MP3510A ( oui ce et en gros 6 euros ) me
Semble être un must have! J ai quelques doutes sur un LDO petit format type Sot23 par exemple et la chaleur en cas de charge du montage, surtout dans le spectre haut des tensions d alim …
Le pont H est bien. Perso j opte pour le TB67H450 dont le brochage est identique et les caractéristiques très similaires à celui utilisé ici avec un seuil  d utilisation des 4,5V.

Bon le temps de m y pencher un peu plus dans quelques jours et on devrait pouvoir sortir un « DIY »plutôt sympa. 

Pour ce qui est des conditions que tu soulèves Marc je pense que s aligner sur la norme permet de s affranchir d « emmerdes » à tout va…
Et puis si tu es full dcc only il y  aura Tjr une fois ou tu auras envie que cela tourne en analogique … alors autant faire ça bien pour le coup.
Ça ne coûtera pas la blinde sans trop augmenter la complexité  donc ne pas se priver me paraît être la bonne voie. (Sauf saturation de l’espace dispo pour tout caser!)
Si ce n est pas utilisé (soft et paramétrage ) au moins le hard est là et cela peut être réutilisé sans lourde modif.

Laurent

[trimarco232]

oui , mais là tu pars dans une réalisation du type commercial , tu vas perdre tout le monde d'un forum DIY en route, et tu t'approcheras du prix d'un lokpilot en restant loin de ses performances et de sa fiabilité
pour être cohérent avec un soft gratuit , forcément basique même s'il est joliment écrit , il faut un hardware du même niveau
donc amha , regarder ce qu'il y a chez jlcpb (par exemple ATTINY1616-MNR) , et prendre un maximum de composants "basic"
alors au lieu de faire , comme tu as appris : schéma → PCB → BOM , faire BOM → PCB → schéma !

[Dominique]

tout a fait d'accord : c'est comme cela que LaBox est née!

[laurentr]

En effet c est une autre approche.

A voir ou se situe "l'optimum" et les compromis.
Par exemple sur le TINY1616 on aurait le PWM sur le Timer A, le décodage DCC sur le Timer B0 et le B1 pour millis()... le hic si on a besoin d un timer supplémentaire ( comme semble l indiquer Aiko dans les commentaires de la librairie) pour Railcom on est trop court ( ou pour d autres usages)
On doit alors monter vers un AVR en 28 ou 32 broches pour  disposer de ces ressources en plus. Donc selon le cahier des charges retenu on doit cibler le CPU.

En la matière pour du DIY la fabrication est industrielle donc il reste surtout la partie soft à injecter post assemblage à priori avec un ATMEL-ICE ou un "bricolage" pour transformer un nano en programmateur. ( la solution ATMEL ICE reste préférentielle mais elle coute déjà a elle seule le prix d un lockprogrammer ESU!). Cela réduit déjà un peu le champs de pratiquants prêt à suivre ( mais des commandes groupées sont possibles)

Donc il faut déjà se chasser de l'esprit que DIY = cout faible. Sans chasser l'idée de contenir le prix de la réalisation il y a un ticket d entrée à assumer et un cout marginal à trouver. L amortissement ne peut se faire que sur un volume.

Si on dresse la cahier des charges en quelques lignes on a:
encombrement max 16x30 mm
connecteur normalisé PLUX22 ou 21MTC
composants dispo en volume à prix modéré

Egalement à "trancher" à ce stade:
support Railcom?
support ABC?
support I2C/SUSI?
compatibilité analogique?
extension pilotage module son type DFPlayer?
Autres...


Laurent

[laurentr]

On en vient du coup à trancher entre un décodeur (pseudo) DIY basic et une version plus complète en terme de couverture technique et fonctionnelle.

J ai oublie dans le cahier des charge la mesure et le traitement de la BEMF.

Ltr

[trimarco232]

En effet c est une autre approche.

A voir ou se situe "l'optimum" et les compromis.
Par exemple sur le TINY1616 on aurait le PWM sur le Timer A, le décodage DCC sur le Timer B0 et le B1 pour millis()... le hic si on a besoin d un timer supplémentaire ( comme semble l indiquer Aiko dans les commentaires de la librairie) pour Railcom on est trop court ( ou pour d autres usages)
On doit alors monter vers un AVR en 28 ou 32 broches pour  disposer de ces ressources en plus. Donc selon le cahier des charges retenu on doit cibler le CPU.
nope : If TCD is used as the millis timer - which is the default on any part that has a type D timer (in order to keep the timers that are more readily repurposed available

En la matière pour du DIY la fabrication est industrielle donc il reste surtout la partie soft à injecter post assemblage à priori avec un ATMEL-ICE ou un "bricolage" pour transformer un nano en programmateur. ( la solution ATMEL ICE reste préférentielle mais elle coute déjà a elle seule le prix d un lockprogrammer ESU!). Cela réduit déjà un peu le champs de pratiquants prêt à suivre ( mais des commandes groupées sont possibles)
et re nan : j'ai fait mon téléverseur /déboggeur avec un convertisseur usb-série (que tout le monde a , auquel j'ai juste ajouté une diode , ce que tout le monde peut faire

Donc il faut déjà se chasser de l'esprit que DIY = cout faible. Sans chasser l'idée de contenir le prix de la réalisation il y a un ticket d entrée à assumer et un cout marginal à trouver. L amortissement ne peut se faire que sur un volume.
tu n'auras pas de volume sans avoir fait la démo du bon fonctionnement de quelque proto : après , tu pourras tout envisager , mais un prix contenu restera un avantage déterminant

Si on dresse la cahier des charges en quelques lignes on a:
encombrement max 16x30 mm
connecteur normalisé PLUX22 ou 21MTC
composants dispo en volume à prix modéré
pour l'instant , ne pas se focaliser sur ces connecteurs : le + de l'ouvrage de lebelge2 , c'est une connectique adhoc qui permet de raccorder un module son et des afficheurs LCD , on peut garder cette exigence
 
Egalement à "trancher" à ce stade:
support Railcom? c'est l'objet du topic
support ABC? pareil
support I2C/SUSI? voir ci-avant
compatibilité analogique? à ta guise
extension pilotage module son type DFPlayer? voir ci-avant
Autres... ...


Laurent

[laurentr]

Bonjour

Ca libère en effet quelques perspectives plus favorables ( couts, dispo, souplesse,...)

On a donc sur le MEGATINY1616 /1617 une distribution telle que ceci:
TIMER A0 PWM
TIMER BO Traitement du signal DCC via lib d AIKO PRAS
TIMER B1 Traitement Railcom à intégrer dans la lib
TIMER D0 Millis()

RX/TX sur ports par défaut
TWI/I2C sur ports par défaut

Reste a voir ou placer la distribution des autres usages (sorties leds principalement), entrées DCC, mesure BEMF, mesure Vin, ABC, extension DFPlayer,....
On serait plus à l aise sur le 1617 mais je vais voir comment proposer une solution sur le 1616 qui est dispo plus facilement.

Reste la question du régulateur de tension... J ai une nette préférence pour un DC-DC qui évitera toute chauffe. Visons compact ( les DLO sont aussi massifs)
Dans ce qui est dispo (LCSC/JLBPCB) pour les plages de tensions qui nous intéressent et pouvant sortir par exemple 500mA on décolle vite au niveau du prix ( ex LT3502) et il faut ajouter les composants autours. ( self, diode, condo, résistances,...)
Le MPM3510A ( oui, encore lui) fait économiser sur la self, gagne en compacité pour le groupe de composants et permet de sortir jusqu'à 1,2A.
Cela peur s avérer pratique pour piloter des accessoires (servo, ampli HP, ecrans, ...) sans avoir (trop) à se soucier du contexte. Inconvénient il faut le passer en pre commande et son prix plus legerement plus élevé couvre toutefois les bénéfices acquis et rend gagnant je pense sur le delta a mettre en œuvre.
Apres il y a peut être quelques candidats alternatifs mais il faut les trouver... Vos suggestions sont bienvenues.

Laurent

[laurentr]

On doit se rapprocher de quelque chose comme cela.

Mais surement a optimiser encore.
Il reste la partie MOS et sorties à traiter

Laurent

[trimarco232]

- pour le dc/dc et les mosfets , comment font les fabricants de décodeurs ?
- il n'y a pas besoin de Rx ; le Tx sert au railcom , mais il faut peut-être y accéder pour le débogage : si tu as une place qui traîne pour une pastille ...
- pour l'emplacement des entrées et sorties , je dirais qu'il faut les mettre sur des pastilles , de manière à pouvoir migrer facilement vers un connecteur normalisé par la suite
- pour le DFPlayer , (à vérifier) , on peut prendre une des sorties AUX en software serial (je crois qu'il n'y a pas besoin de Rx) : voyons comment lebelge2 a procédé
- pour l'I2C pareil , on fera en software (je vérifie que ça existe) , donc 2 sorties AUX banalisées ; bien entendu , si les lignes I2C et le Tx alternate sont dispos en AUX , on pourra utiliser les périphériques SERIAL et I2C hardware
- enfin , à faire tant , on peut envisager une interface pour un power-pack maison , dont la conception (et la réalisation) pourra être allégée puisque piloté par le MCU du décodeur ...

[laurentr]

j ai en effet sélectionne nativement les pines hard pour le TX/RX et SDA/SCL donc pas trop besoin de chercher a se compliquer les choix ( pas besoin du MUX)

on se garde le RX pour les "au cas ou" a defaut on l utilisera comme I/O supplementaire.

j ai encore à ajouter les dual mosfet pour les I/O ce que font bcp de fabricants ( dual mosfet en taille mini  sur comp à 6 broches souvent alignes) avec sur le V+ ( bleu) des décodeurs des tensions élevées et un pilotage depuis le MCU en "basse tension".

Pour les 5V il y a de tout... par exemple DOER and HEASLE a développé son propre circuit multi fonctionnalités

Pour le Power Pack ca sera hors du 16x30 mais on se servira utilement du DC-DC 5V pour charger ensuite donc disposer d'un +5V robuste est positif

Encore un peu a moudre donc