Mando rotor Arduino KeNG proyectos, dudas

El software, a falta de ajustar algunos detalles está funcionando. Adaptar el código a cada rotor es sencillo y cuando haya comprobado que funciona perfectamente pudo facilitar el listado de "rotator_features.h", "rotator_settings.h" y "rotator_pines.h" o bien los tres archivos junto con el *.ino

Hola . 

Muy interesante . Me puedes decir que es overlap ?

Por otro lado tengo pregunta , se puede usar el driver BTS 7960 para controlar el motor ?

Y potenciómetro tipo Hall ?

Saludos 

EC4AGT

Wojtek 

Bueno... overlap en relación a un rotor define la posibilidad de que gire más de 360º. El controlador en este caso debe conocer la posición y debe poder avivar al usuario de que el rotor está en esta posición, generalmente mediante un diodo led encendido o intermitente.- Estos aspectos son sencillos de controlar con el software de K3NG.

Es evidente que un BT7960 puede controlar un motor. Lo que no tengo ni idea es si algún fabricante utiliza estos componentes en concreto. Lo mismo digo para un medidor de corriente de tipo Hall. Yo los he utilizado para medir el consumo de amplificador lineal y entiendo que desde un punto de la física un medidor de este tipo puede controlar el motor de un rotor. Es posible que los haya pero yo lo desconozco.

He revisado superficialmente los tipo de sensores que incluye el software de K3NG y no he encontrado ninguno de los que citas. Potenciómetros, decodificadores de varios tipos y sobre todo brújulas (compases) digitales de diferentes fabricantes.

El problema de adaptar un código de terceros para un microprocesador y periféricos, en mi opinión, no es únicamente el tipo de componente sino, sobre todo, las librerías de comunicación. Por esto me he limitado a unos tipo de rotor de sencillos, que no es poco.

Por ejemplo:

¿qué display vamos a utilizar?,  ¿un estándar de dos líneas y 16 columnas, de 4 líneas y 20 columnas o una pantalla táctil? La información necesaria es:

Con la antena estática, el rumbo actual. Con la antena en movimiento la dirección de rotación y el rumbo dinámico. Para esta información dos líneas de 16 columnas son suficientes, ahorro de espacio, tiempo y dinero, aunque evidentemente, un indicador gráfico, incluso un teclado virtual en una pantalla táctil sería mucho más estético, aunque más caro y complicado. Sobre todo porque las librerías que se utilizan en el software para toas las pantallas posibles crean confusión (por lo menos a este servidor), por lo que lo más seguro es utilizar el viejo y manido bus de 4 bit con la librería LiquidCrystal.h

El diseño del módulo adaptador del bus de 4 bit:

Este potenciómetro usa un amigo mío para control de posición . Usa un Nano y software k3ng. Yo en principio pensaba que da pulsos pero al parecer es un potenciómetro que da tensión 0-5 V.  No se porque ha elegido este tipo de potenciómetro , le tendré que preguntar . No  se más detalles 

PS

Lo de display yo quisiera  usar con el módulo i2c pero no llegue activar en el programa , finalmente he tenido que pedir ayuda 

El adaptador que tú has hecho es para conectar como i2c ? Es equivalente a los módulos que venden para los lcd ?

EC4AGT

Según me comenta , le usa porque es más exacto , es un potenciómetro digital - analógico . Por otro lado se ve que está mejor hecho mecánicamente que un potenciómetro tradicional . Me imagino que no tiene pista de carbono o alambre con lo cual tendrá menos desgaste y estará más duradero . 

Hola a todos.

El uso de visualizadores con comando por I2C reduce mucho el cableado. La mayor parte de los "conversores I2C-paralelo" usan el PCF8574T (con una dirección por defecto 0x27) o el PCF8574AT (dirección 0x3F). La librería LiquidCrystal_I2C resuelve el problema en la mayoría de los casos pero hay otras. Y siempre se puede cargar un "escaneador de direcciones I2C" para probar que el visualizador está conectado y en qué dirección...

Lo del potenciómetro por efecto Hall es un invento.

jon, ea2sn

Es complicado activar lo de i2c ? Yo tengo activado el display con todo el cableado 

Ya lo he conseguido . Poco a poco se aprende lago más 

Normalmente el cambio requiere:

tener la librería accesible

cambiar el #include de LiquidCrystal.h por LiquidCrystal_I2C.h

definir el lcd en función de la librería, puede ser  LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);// dirección I2C y patillas usadas

definiendo después en el setup el tamaño con  lcd.begin(16,2);

escribiendo después en el loop con comandos del tipo:

lcd.setCursor(0,0); //posicionando el cursor
lcd.print(" EJEMPLO "); 

Otra definición que he encontrado para esta librería (que tiene muchas versiones) sería:

LiquidCrystal_I2C lcd(0x20,16,2); // dirección I2C, tamaño de línea y número de líneas

inicializando después en el setup con  lcd.init(); 

y escribiendo después en el loop.

La "traducción" desde LiquidCrystal a LiquidCrystal_I2C se puede ver leyendo los ejemplos que vienen con la librería que consigamos.

Suerte con las pruebas.

jon, ea2sn

Bueno... como bien indica Jon los conversores del bus de 4 bit a serie I2C reducen el cableado (de 8 a 4) y liberan 4 I/O digitales. La detección es simple con una pequeña aplicación libre IC2 Scanner. Personalmente utilizo preferentemente este puerto de comunicación con el display, incluso con una pantalla Nextion táctil. Hay varias librerías para este este conversor, personalmente utilizo Liquid_Crystal_I2C de Frank de Brabander.

https://github.com/fdebrabander/Arduino-LiquidCrystal-I2C-library

Peeero... K3NG utiliza para las salidas al display una clase escrita por él: rotator_k3ngdisplay.cpp en la que llama a las librerías I2C para los displays YOURDUINO_I2C_LCD, RFROBOT_I2C_DISPLAY, YWROBOT_I2C_DISPLAY y SAINSMART_I2C_LCD y ninguno de estos displays están a mano ni tampoco estás seguro de la librería o de la versión que estás utilizando porque no tienes control y modificar los accesos al compilador es causa de muchos problemas. Sopesando los pros y los contras, lo más segurola es utilizar el bus de 4 bit que lleva una librería básica en el IDE. Evidentemente, es posible (tampoco es tan difícil) modificar el código para meter la librería que conoces y manejas con un determinado display, pero, en mi opinión, no merece la pena para el un pequeño rotor.

No he estudiado la forma de eludir la clase K3ngdisplay y crear un objeto independiente que permita utilizar los métodos de una libraría conocida.

En cuanto al potenciómetro de posición acimut que indica EC4AGT,  es evidente que cuanto mayor calidad mecánica y electrónica tenga mayor precisión tendrá. Creí que tu pregunta trataba del driver driver BTS 7960 utilizado con motores de potencia. Este potenciómetro tiene una condición importante, está situado en el interior del rotor y su desmultiplicación adaptada a la corona del rotor. No creo que sea sencillo sustituir un potenciómetro por otro de diferente diseño que el original, habría que adaptar mecánicamente los componentes aunque desconozco si algún fabricante ofrece potenciómetros especiales para algunos rotores.

Lo de sustituir el potenciometro no es ningún problema ya que el rotor es de fabricación  casera . Como escribí antes , he conseguido que funciona con display i2c ,  con pulsadores izqu / der . También con el encoder rotativo de mando . Tampoco conseguido que esta encendido la iluminación del display ( solo se enciende cuando se carga el programa ) 

Pero , como digo , poco a poco estoy aprendiendo y resolviendo los problemas. 

Saludos a todos, 

tengo el problema de retardar el freno de un rotor T2X pero a la conexión , esta definido en el programa en la linea en la desconexión :

   --- rotation settings---

#define AZ_BRAKE_DELAY 2000 // in milliseconds

pero en este rotor existe el problema que si pulsas a la vez el freno y el giro algunas algunas veces se queda bloqueado .

¿ alguien lo tiene solucionado ?, 

saludos 

Fernando EA5GHD

Opción interesante porque limita el tiempo max de operación del Rotor así se protege en caso del bloqueo por alguna causa

-------- rotation settings --------

#define OPERATION_TIMEOUT 60000  //

originalmente esta definida en 120000 (dos minutos) , lo he dejado en uno para ajustarlo mas 

Se supone que el tiempo que media entre la liberación del freno y el arranque del rotor  está definida en la constante AZ_BRAKE_DELAY. si dos segundos es poco, probar a aumentar el tiempo de espera, por ejemplo AZ_BRAKE_DELAY 4000 (cuatro segundos).

En cualquier caso creo haber leído otros parámetros sobre el freno que quizá influyan en el tiempo o en la secuencia. Sería conveniente revisarlos en el archivo rotator_settings 

Las constantes de liberación y bloqueo del freno son:

#define BRAKE_RELEASE_OFF 0
#define BRAKE_RELEASE_ON 1

Están definidas en rotator.h

Las constantes de retardo y de estado están rotator_setings.h

#define AZ_BRAKE_DELAY 3000 // in milliseconds
#define EL_BRAKE_DELAY 3000 // in milliseconds

#define BRAKE_ACTIVE_STATE HIGH
#define BRAKE_INACTIVE_STATE LOW

En el programa original el retardo es de 3 segundos.

La función que detecta si el freno está desactivado (podada la función de elevación):

void check_brake_release() {
static byte in_az_brake_release_delay = 0;
static unsigned long az_brake_delay_start_time = 0;

if ((az_state == IDLE) && (brake_az_engaged)) {
if (in_az_brake_release_delay) {
if ((millis() - az_brake_delay_start_time) > AZ_BRAKE_DELAY) {
brake_release(AZ, BRAKE_RELEASE_OFF);
in_az_brake_release_delay = 0;
}
} else {
az_brake_delay_start_time = millis();
in_az_brake_release_delay = 1;
}
}

if ((az_state != IDLE) && (brake_az_engaged)) {in_az_brake_release_delay = 0;}

} /* check_brake_release */

La función que libera el freno (una podadas las líneas de programación dedicadas a la elevación y depuración):

void brake_release(byte az_or_el, byte operation){

if (brake_az && (configuration.brake_az_disabled == 0)) {
   if (operation == BRAKE_RELEASE_ON) {
      digitalWriteEnhanced(brake_az, BRAKE_ACTIVE_STATE);
      brake_az_engaged = 1;
   } else {
      digitalWriteEnhanced(brake_az, BRAKE_INACTIVE_STATE);
      brake_az_engaged = 0;
     }

   }

} /* brake_release */

Esta función debería indicar el estado correcto del freno antes de activar el rotor.

Ok iré probando , para retardar la puesta en marcha del motor, en el T2x es un problema , lo estoy usando con un HamIV y perfecto.

Gracias