Go Down

Topic: Proyecto: digitalización locomotora LGB años 40. (Read 3563 times) previous topic - next topic

victorjam

Sep 11, 2017, 03:37 pm Last Edit: Oct 26, 2017, 08:59 pm by victorjam
Hola chicos.

Tengo un amigo que tiene una maqueta de tren escala H0  con dos locomotoras, con sus vias y cambios. Digamos que el juguete es de los años 60 y claro es totalmente analógico: velocidad de la locomotora controlada por reostato, cambios por interruptores y manejados por transformadores de corriente alterna, uso de bombillas.., os podeis imaginar. El caso es que funciona pero con sus pegas, la mas gorda, que solo puede controlar una locomotora ya que la otra hará los mismo, al controlar la tensión de la via.



El caso que hablando sobre como digitalizarla estuve mirando un poco como son las maquetas modernas y como se hace el control: protocolo DCC, decoders y boosters, con lo que pensandolo bien, se hacia caro y nada divertido.

Así que lo siguiente que queda es, como no, Arduino.

He pensado en saltarme el protocolo DCC, aunque he visto por ahí cosejas y sé como funciona, pero como es algo nada comercial, nos lo "inventamos" y será más fácil de hacer.

Para la locomotora simplemente tengo que controlar la velocidad y la dirección que pienso hacerlo con un puente H basado en el L298H. En teoría el motor de la locomotora que más consume es de 1.8A, así que muy justo, pero creo que se puede poner en "puente" los dos drivers y ya tenemos 4A. Las luces de momento siempre estaran encendidas, al igual que la chimenea de humo (si, echa humo).

Ahora viene mi duda existencial. Para controlar remotamente la locomotora he pensado en hacerlo de forma inalámbrica, con lo que hay me pilla justo en conocimientos ya que soy mas partidario de los cables, pero en este caso es necesario.

Al final, la idea se queda en:

Un "mando a distancia" o "estación de control". Tengo un Mega y una pantalla LCD táctil muertas de risa y había pensado en usarlos como estación de control.

Dos locomotoras, con controles de velocidad y dirección, opcionalmente podemos controlar las luces, quizás el humo y también algún sonido.

Una caja tonta, para el control de los cambios de via, semáforos y otras cosas. Esté tendrá un poco mas de circuiteria.

Un total de 4 nodos, con un maestro (mando) y tres esclavos.

Y ahora es cuando os pido recomendación. No he controlado nunca nada de manera inalámbrica y no sé por cual de las tecnologias "comunes" decantarme:

WiFi con ESP2866
Bluetooth con HC05
Radio con NRF24L01

La distancia no es problema porque la maqueta está en su patio y no tiene mas de 4x4 metros... y los tuneles que hay no llegan al metro de longitud. El problema lo veo en tener varios nodos y como comunicarlos entre si.

¿Cúal creéis que será más fácil de implantar y cúal recomendáis?

surbyte

Te aclaro que las 3 son buenas opciones

1. WiFi con ESP2866  -> de las mejores opciones, podrias controlarlo con el movil
2. Radio con NRF24L01-> tmb es buena opción si pensaras en mas locomotoras.
3. Bluetooth con HC05-> puedes controlarlo con el movil. Solo un Serial para enviar datos

Ahora veamos tema consumos:
1. nRF24L01 es el que menos consume
2 y 3 los pongo juntos porque realmente no se. Supongo que HC05 consume menos que el ESP.
(verificarlo)

Con el ESP01 por ejemplo podrias enlazarlo usando algo como Blynk.cc y tendrías una maravilla de interfaz con poco esfuerzo.





PeterKantTropus

No se si pretendes desarrollar algo o ir a lo seguro y  que salga funcionando. En teoría se podría  sumar una componete alterna a la tensión DC  y luego mediante filtros de banda, optoaclopadores, y amplificadores operacionales, separar la componente Ac de comunicación en la locomotora. El golazo seria utilizar un protocolo ya probado en arduino como el modbus y solo concentrarse en el bus de comunicación.
"Si no entra como tornillo, entra como clavo"

surbyte

Que torpeza la mía... por la via tienes DC y de alta corriente asi que la energía no es problema.

victorjam

Quote
No se si pretendes desarrollar algo o ir a lo seguro y  que salga funcionando.
Pues casi que voy a lo seguro :). Lo que me propones de la corriente alterna acoplada a la componente DC es muy similar al DCC. La diferencia es que el DCC lo que hace es cambiar la polaridad de las vias a través del booster. En el decoder de la locomotora se pone un rectificador para convertir la corriente "alterna" (onda cuadrada de pulsos) para obtener la alimentación y con un opto puedes obtener la señal. El "pero" es el hecho de necesitar un booster de alta corriente ya que hay que alimentar las locomotoras y los accesorios; y también, que solo puedes enviar datos y no recibirlos desde la estación. Hice una simulación en proteus y la verdad me sorprendió gratamente ver que funcionaba incluso en el simulador.

Y creo que me leiste el pensamiento. Mi idea, la implemente como la implemente, iba encaminada a utilizar el protocolo modbus o algo muy similar.

Quote
Que torpeza la mía... por la via tienes DC y de alta corriente asi que la energía no es problema.
Si y no. El mayor problema es que casi no tengo hueco dentro de la locomotora para poner placas. Así que lo tengo que minimizar y cuanto menos circuito mejor.

El L298 ya se lleva un hueco importante. Y el transceptor obviamente, tendrá que ir fuera, ya que la locomotora es metálica y me hará de jaula de Faraday. Aun así, casi todos los modulos funcionan a 3.3v lo que implica tener una fuente de 3.3v y la tensión de la via es superior a los 18v con lo que:

- Si uso un regulador step-down no debería tener problemas de disipación de calor pero tendré que usar un hueco importante.

- Si uso un regulador lineal, tendré un TO220, con sus condensadores asociados, ocupa menos sitio, pero si tengo consumo se me dispara la potencia de disipación y tendré que usar un disipador.

Dicho esto, estoy mirando que el NRF consume menos, tiene buen alcance aunque no sea un problema, y es mas barato.

A su vez estaba pensando en alimentar todo con 3.3V, y en vez de usar una atmega328p (UNO) usar un attiny85 de los que tengo por casa también aburridos. Si lo alimento todo con 3.3v me quito también el problema de usar convertidores de nivel, aunque el NRF sea tolerante a 5v.

Así que el "decoder" de la locomotora se compondrá de:

- Fuente 3.3V
- Attiny85
- Puente H
- NRF24L01+

Lucario448

- Si uso un regulador step-down no debería tener problemas de disipación de calor pero tendré que usar un hueco importante.
No sé qué palabras clave específicas tendrías que usar para encontrarlo, pero puedo jurar que existen de esos que de largo no llegan ni a 5 cm, de ancho ni a 3, y de alto ni a 2.
Son casi tan anchos como un dedo índice, y como 3/4 del largo del pulgar

surbyte

En lo personal veo mas ventajas en un ESP8266 tal vez 01 que cumpliría la tarea, todo en 1, es chico. Tiene Memoria de sobra. 2 GPIOs y si miras fino, 2 mas soldandolo.
Es para considerarlo. Ahora no se que pasará dentro de la locomotora.

Quiero decir, tienes en un solo chip todo, comunicación y control. Mismo tamaño del nRF24

victorjam

#7
Oct 24, 2017, 07:55 am Last Edit: Oct 24, 2017, 07:58 am by victorjam Reason: tag-image
Hola chicos.

Pues la verdad es que tengo ya alguna cosa hecha. En un principio tengo la controladora de las vias casi "terminada", por no decir terminada del todo. El proyecto lo hemos modificado un poco. Sigo teniendo dos locomotoras y el control de las vias, usando NRF24 para la comunicación. Pero mi amigo optó por usar un
PC en vez de un "mando a distancia".

Luego postearé el control control de vias.

Ahora quiero empezar a hacer el decoder de locomotora, con lo cual me asalta una duda. Para controlar el motor voy a usar un L298 y dicho motor no llega a consumir los 2A pero se queda muy cerca. Estaba pensando en "puentear" el puente H. Y no sé si será muy recomendable:



Me refiero a que tengo dos salidas de motor y unirlas de forma que solo trabajen con un motor. Para ello uno las entradas correspondientes de cada uno de ellos y las salidas. En la simulación de proteus si funciona, pero es solo eso una simulación.

¿Creeis que es factible?

victorjam

#8
Oct 26, 2017, 08:10 pm Last Edit: Oct 26, 2017, 08:20 pm by victorjam Reason: attachments
Echando un vistazo al datasheet del L298N he visto que si se puede hacer y la forma en la que hay que hacerlo. Así que duda resuelta y os la comentaré mas tarde.

Hoy os voy a contar como va el proyecto. Os recuerdo: dos locomotoras y cambios de vias a controlar, todo ello con una red NRF24.

Mientras mi amigo se dedicaba a desarrollar el circuito de la vias, yo me preocupe mas de como controlar el cambio.

Al ser una locomotora de cuarenta años no sabia lo que iba a llevar el cambio. Lo que conlleva a que hay que desmontar uno y ver como funciona.







Como veis no es el último grito en tecnologia. Pensaba que iría como un solenoide con un electroimán y muelle y no.

El circuito se compone de una bobina que está unida a unas chapas que cuando introduces corriente funcionan como un electroimán. En su interior hay un cilindro de plastico, con un engranaje y un tope que evita que se valla más allá de la posición. Dentro de este cilindro se halla un imán permanente.

Ahí esta la magia. Si introduces una tensión continua con una determinada polaridad en la bobina se genera un campo magnetico que si está en oposición al del iman, le obliga a girar para alinearse y si ya estaba alineado no pasa nada. Para volver a producir el cambio de posición hay que cambiar la polaridad de la bobina para hacer que el iman se vuelva a mover.

¿Cómo lo controlamos? Pues claro está con un puente H. Salvo que en vez de alimentar permanentemente la bobina, tan solo hay que dar un pulso.

victorjam

#9
Oct 26, 2017, 08:24 pm Last Edit: Oct 26, 2017, 08:27 pm by victorjam
Una vez que ya sabía como controlar el cambio me faltaba una cosa. Saber su estado. Despues de discutirlo con mi colega, llegamos a la conclusion que necesitabamos una carrera. Así que le instalamos una carrera al cambio de via:



Esta carrera además de indicar al controlador de vias en que posición está, controla la luz de los semáforos que ha creado con diodos led.

victorjam

#10
Oct 26, 2017, 08:29 pm Last Edit: Oct 26, 2017, 08:55 pm by victorjam
Ya tengo el estado y sé como cambiar la via. Tenía que preparar un circuito:



La placa se compone de:

  • Atmega328p
  • Zócalo para NRF24
  • Entradas optoacopladas
  • Dos 595
  • 4 puentes L293D


No explicaré para que el atmega ni el zócalo del NRF porque es obvio.

Las entradas optoacopladas se debe a que el circuito funciona a 5V y la alimentación la coge directamente de las vias.

El circuito de las vias tiene una tensión fija de 19-20V para alimentar a este y a las locomotoras (o cualquier cosa que se desee poner). Con tensión fija, no solo me refiero a que sea constante, sino que está conectada directamente a la via, así que se puede coger en cualquier punto de esta y que cada riel tiene su polaridad.

No he dicho el número de cambios que tiene el circuito, pero os lo diré ahora: 8. Teniendo en cuenta que tengo que tener 8 entradas y para controlar el puente H necesito dos pines por cada uno (total 16) el arduino se quedaba sin pines. Así que para controlar la lógica de los puente H, utilizo dos registro de desplazamiento 74595 en cascada y obtengo las 16 señales necesarias.

Haciendo eso, me sobraba las lineas del bus SPI, para controlar el NRF, espacio para programarlo a traves del puerto serie y para un diodo de señalización.

El circuito funcionando:



Quitando un problemilla con el footprint de proteus del botón de reset que al final lo tuve que quitar es totalmente funcional. El mayor problema que tiene, y no es del circuito, si no del cambio, es que al ser tan viejos, por dentro están oxidados y hay que limpiarlos bien para que funcione correctamente.

En cuanto al software nada especial. Utilizo la libreria para el RF24 de TMHR, así que como la RF24Network para crear una red de nodos. Y transmito mensajes de tipo: funcion, valor. Por ejemplo el paquete { 01, 00 } me devuelve un paquete tipo { 01, "estado de las entradas" }. Otro ejemplo { 02, 01 }, es la orden de cambiar la via 1.

surbyte

Que placer me da leer a alguien que entiende lo que es documentar un proyecto!!

Esto es un proyecto... gracias victorjam por como lo vas llevando.

victorjam

#12
Nov 02, 2017, 12:19 pm Last Edit: Nov 02, 2017, 12:36 pm by victorjam
Ahora he empezado a trabajar con la locomotora, entre otras cosas hay que saber como funciona.

Locomotora:


Una vez abierta:


Dentro de ella podemos ver los poco elementos que la componen y aun así un poco lioso:

En la parte de atrás hay una placa que contiene una PCB. En dicha PCB estan las luces de atrás y un circuito regulador a base de transistores. Las luces son bombillas de 7.5V. En la otra locomotora que hay las luces van unidas a la tensión de la via, al ser el control analógico, cuando bajas la tensión con el reostato, las luces se vienen abajo. En este no pasa eso, ya que utiliza un par de reguladores de tensión y las bombillas son de poco voltage y aunque baje la tensión de la via siguen luciendo igual. Problema: La mitad de las bombillas estan fundidas. Solución: Diodos LED blancos. Deberé prescindir de esta placa.

En el centro hay otra PCB que canaliza las conexiones y las lleva hacia atrás, al motor de vuelta, al control de humo de la chimenea y a las luces delanteras. Esta placa tendré que ver como sustituirla, ya que el control del humo quiero poner un interruptor para poder apagarlo sin que tenga que controlarlo el arduino.

La pesa, me sorprendió. La locomotora es todo plástico y pesa un quintal. Así que cuando la abrimos y vimos el cacho de plomo, descubrimos porque pesaba tanto. Este peso hace que la locomotora se agarre bien a la via.

En la parte roja vereis un conector para la alimentación que se extrae de las vias y para el motor. Hay tres conectores y no sé como va internamente ya que no puedo abrir la reductora sin cargarmela.

Detalle reductora:


Así que la solución que he optado es sacar en dos terminales la alimentación de la via y soldar al motor unos cables en las escobillas anulando asi el posible funcionamiento de los conectores.

Detalle del motor "trucado":


victorjam

#13
Nov 02, 2017, 12:39 pm Last Edit: Nov 02, 2017, 12:55 pm by victorjam
Tengo preparado un circuito decoder de locomotora de pruebas.





Cuento con poco espacio así que he tenido que aprevechar al máximo.

El circuito consta de:

  • Rectificador
  • Fuente de 12, 5, 3'3 V
  • Drivers de luces
  • Puente H
  • CPU
  • NRF24


En la entrada del circuito he puesto un rectificador con diodos 1N5400, para poder obtener la señal de las vias. Uso el puente porque así me olvido de saber donde tengo que poner la polaridad en las vias.

Uso 3 fuentes de alimentacion, una de 12V que tiene doble uso, por un lado me rebaja la tensión de las vias (recordad que son 19V) asi el regulador de 5 y el de 3'3 no tienen tanta caida de tensión; además de poder enchufarle las luces.

El puente H es un L298N que al final no ha hecho falta puentearlo, ya que el motor solo llega a consumir 1A haciendo fuerza.

La CPU es un Attiny85. Por problemas de espacio el Atmega era una opción poco viable y además no usaba todos los pines.

El driver de luces sirve para que el attiny pueda controlar las luces. Si va hacia adelante tendra que encenderse las de delente, si va hacia atras, las de atras. Además de la cabina. También me sirve para indicar un error haciendo que las lueces parpadeen. El driver es un simple transistor BC547 que me da de sobra para alimentar a tres leds.

El mayor problema ha sido el NFR24 conectado al attiny. En otra entrada os explicaré el problema y la solución.

Gracias Surbyte!. Pero te contaré mi secreto: no tengo memoria (al contrario que tu) y se me va la cabeza por todos los lados, así que hago fotos, anotó, re-escribo, y todo lo que haga falta para que cuando vuelva a echar mano, lo tenga todo claro.

victorjam

#14
Nov 02, 2017, 08:33 pm Last Edit: Nov 02, 2017, 08:35 pm by victorjam
Hola de nuevo chicos.

Como dije en un post anterior, voy a explicaros el problema que he tenido con el Attiny84 y el uso del modufo rf NRF24L01 y cual ha sido la solución que he encontrado.

Antes de empezar os digo que librerias he usado:

Libreria NRF24L01 de TMRH20
ATTinyCore de SpenceKonde

La libreria de TMRh20 trae soporte para micros de la serie attiny y dado que estos carecen de bus SPI nativo, implementa dicho protocolo usando el bus serie universal del que dispone (USI). En teoría no es necesario disponer de ninguna otra libreria para hacerlo funcionar.

Ahora bien si cogemos el código de ejemplo que viene en la libreria, vemos que tenemos que hacer lo siguiente:


Code: [Select]

/*
    ATtiny24/44/84 Pin map with CE_PIN 8 and CSN_PIN 7
    Schematic provided and successfully tested by Carmine Pastore (https://github.com/Carminepz)
                                  +-\/-+
    nRF24L01  VCC, pin2 --- VCC  1|o   |14 GND --- nRF24L01  GND, pin1
                            PB0  2|    |13 AREF
                            PB1  3|    |12 PA1
                            PB3  4|    |11 PA2 --- nRF24L01   CE, pin3
                            PB2  5|    |10 PA3 --- nRF24L01  CSN, pin4
                            PA7  6|    |9  PA4 --- nRF24L01  SCK, pin5
    nRF24L01 MOSI, pin7 --- PA6  7|    |8  PA5 --- nRF24L01 MISO, pin6
                                  +----+
*/
// CE and CSN are configurable, specified values for ATtiny85 as connected above
#define CE_PIN 3
#define CSN_PIN 4
//#define CSN_PIN 3 // uncomment for ATtiny85 3 pins solution
#include "RF24.h"
RF24 radio(CE_PIN, CSN_PIN);


Lo lógico y normal, es que hagas lo que te dice el ejemplo, pero a la hora de ponerlo en marcha, compila, pero no funciona.

Analizando el ejemplo, está mal. Los pines CE y CSN que define aquí son los que utiliza el NRF, pero NO los del attiny. Corrigiendo eso y poniendo los valores correctos de pines del core, tampoco funciona.

Aquí entré en pánico y eche mano de google, que curiosamente me mandaba a un "issue" de la libreria que indicaba esto mismo. Depués de leermelo, no enterarme, leerlo otra vez, medio aclarame, probar lo que proponian, incluso cambié el core, la misma libreria por otra. Nada. El attiny y el NRF no funcionan juntos.

A la! vamos a leer... Cogí la libreria la lei detenidamente hasta que di con el siguiente trozo de código:

Code: [Select]

#elif defined(__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
// these depend on the core used (check pins_arduino.h)
// this is for jeelabs' one (based on google-code core)
# define DI   4   // PA6
# define DO   5   // PA5
# define USCK 6   // PA4
# define SS   3 // PA7


Esto hace que forzosamente tengamos que utilizar dichos pines. Dichos pines son exactamente el bus SPI, siendo DI->MISO, DO->MOSI, USCK->SCK y SS->SS. Y digo forzosamente porque de otra forma no funciona. Eso hace que cuando declaremos un objeto Radio(CE,CSN), el pin CE lo podemos elegir, pero no el CSN (SS). Todo lo contrario a lo que dice la libreria.

Otra cosa importante es que hay introducir el código:

Code: [Select]

#define __AVR_ATtiny84__


Simplemente para que la libreria use el bus SPI antes indicado.

Como anecdota me resulta curioso que haya una función llamada isChipConnected que te indica si el NRF está conectado y casi nadie la usa... simplemente te dicen es que no comunica... leche, primero vamos a ver si está conectado ¿no?

Y como apertivo os dejo una de mis chuletas que suelo hacer para acordarme de las cosas:


Go Up