Interfaz rotor Arduino de K3NG

Hola,

Lo primero que se me viene a la cabeza es por qué usar un nano pudiendo usar otro mayor.
El más pequeño que tengo en un Mega. Ahora estoy pensando en un Due, o mejor aún, EtherDue.

Yo no te tengo el nano por lo que no te puedo facilitar una copia.
Lo que se me ocurre es eso, "podar" al mínimo.
Supongo que ya has eliminado todas las librerias que no usas, LiquidCrystal, nada de Luna, LM303, etc.
Luego, en donde se hacen los ajustes, puedes borrar todos los que no uses, dejar solo los que usas.

No se me ocurren más cosas.

73, Máximo - EA1DDO

Gracias Máximo, siempre me gusta, por principio, utilizar los recursos mínimos necesarios para obtener resultados. Además, el tamaño del transformador de alimentación del motor del rotor deja poco espacio en la caja.

Por otra parte, ya tengo un controlador con un Arduino UNO, con el mismo chip ATmega328 que funciona desde hace casi un año. Además, M0UPU ofrece un circuito impreso y componentes para un Arduino UNO, EA4TX también para Arduino UNO y Remote QTH para Arduino NANO. Luego debería funcionar con ambos modelos, pero falla en los dos, lo he comprobado.

He podado los #defines en el fichero rotator_features.h pero nada, he dejado únicamente las prestaciones básicas: Preset por encoder, pulsadores de giro derecho e izquierdo y he anulado todas las referencias a elevación, etc.

Tengo la impresión de que la versión del código que estoy utilizando está demasiado hinchado y tendré que espabilar para limpiarlo más.

Lo he probado con un Arduino Mega y funciona OK. Recuerdo que un amable colega me envió una versión antigua que funciona bien con el UNO, pero no encuentro su referencia.

Si no me queda más remedio tendré que rediseñar la placa para utilizar un Mega.

Escribió:

Tengo la impresión de que la versión del código que estoy utilizando está demasiado hinchado y tendré que espabilar para limpiarlo más.

Eso es cierto.
De vez en cuando salen actualizaciones y tienden a ser mayores.

Tendrás que buscar alguna versión antigua. Creo que los de RemoteQTH tenían una para bajar de su página.

Yo tengo algunas antiguas, pero están completas. Tendrías que podarlas.

73, Máximo

Bueno... he encontrado la versión de RemoteQTH de 2015. Las variables cabes en la memoria del NANO, pero al compilar da varias páginas de "Warnings" HI...

La mayoría están relacionadas con la conversión obsoleta de constantes de cadena. El código pasa pero no es aceptable. Probablemente faltan definiciones de "char *" en especial para las constantes de las cadenas de posición, pero no se como ni donde colocarlas. Tendré que consultar el foro de programadores.

Lo dicho, si quieres yo tengo versiones guardadas desde el 2014.

73, Máximo

https://www.ure.es/wp-content/uploads/wpforo/default_attachments/media/kunena/attachments/283/k3ng_rotator_controller_20140510.rar

Bueno... he podado el fichero rotator_features.h al máximo y he añadido la OPTION_SAVE_MEMORY_EXCLUDE_REMOTE_CMDS con lo que se libera bastante memoria (Gracias a la indicación de un colega en la lista de distribución Yahoo) . También he desactivado la lectura y presentación de décimas de grado.

El código pasa pero el compilador advierte que se pueden producir problemas de estabilidad por la poca memoria disponible para las variables locales. Las primeras muestran un resultado estable y funciona. Seguiré haciendo pruebas. La opción de un Arduino Mega parece como más segura, pero aún puede funcionar con un UNO o NANO con el consiguiente ahorro de espacio y recursos.

También se puede inhabilitar el debugger cuando se ha comprobado que el código funciona y está ajustado a las necesidades.

Desmarcar //#define DEBUG_DUMP

Con lo cual se libera suficiente espacio de memoria.

Un problema adicional es la definición de los mensajes que presenta el display (Posición acimut en grados y en posición (N, S, E, O, etc)

Aunque se seleccione un display estandar de 16 x 2 de 4 bit, es necesario definir de nuevo las columnas y filas en el fichero rotator_settings.h y definir en qué columna debe aparecer la información, pero como todo son constantes denidas en otros ficheeros, es necesario revisar prácticamente todo el código.

Bueno... parece ser que es un tema que no interesa demasiado, aún así, deseo compartir los progresos.

La falta de memoria quedó resuelta. Únicamente fue necesario activar una línea y desactivar otra del debugger.

A pesar de esto apareció otro problema más difícil de resolver. La última versión, aparentemente la única disponible del código fuente en el servidor GitUb es un galimatías (por lo menos para mi) que me ha sido imposible ajustar al proyecto que he montado.

No hay documentación disponible que explique con precisión los parámetros que es necesario ajustar para que funcione un proyecto determinado:

Sensor por potenciómetro.
Preajuste por encoder.
Display de 2 líneas por 16 columnas de 4 bit.

Me ha sido imposible asignar las funciones a las dos líneas del display.

La primera línea el estado de la posición de la antena (N, S, E, O. etc) cuando está estática, la función que realiza (Girando) cuando está en marcha o la dirección en grados de destino cuando se preajusta.

La segunda línea, la posición actual en grados estática o dinámica. Tampoco he podido encontrar una ayuda efectiva en la lista de correos de usuarios de Yahoo.

He resuelto el problema al encontrar en un backup la versión de 2015 que utilicé para montar el anterior interface. A sido sencillo ajustar todos los parámetros necesarios con las variaciones que he introducido.

Cuando funciona esta interface es una buena y económica solución para complementar un rotor analógico o para sustituir el controlador. También es una buena excusa para cacharrear y para enredar con el código de Arduino.

No tengo rotor, pero si veo interesante el hilo, no te desanimes.
Compartir tus experiencias siempre puede ayudar a alguien ..o viceversa.

Si que interesa y mucho.
Aprendemos de vosotros. Gracias.

Gracias por los comentarios. Sigo pegándome con el código. La idea es dejar un código limpio que funcione únicamente con las funciones básicas de un rotor: Acimut, sensor por potenciómetro (Muchos Yaesu y rotores de bajo costo, G-450, 600, 650 etc), preajuste de rección acimut por encoder (muy interesante para rotores que no disponen de esta prestación) y display 16 x 2 de 4 bit. Un programa que no haya que modificar las líneas de código para que funcione y documentarlo.

De momento he "podado" más de dos mil líneas y funciona partiendo de una versión de 2015. Mantener un programa con tantas opciones como las que dispone la versión actual en especial con seguimiento de órbitas y control remoto por ethernet complica tanto que dificulta el ajuste a unas necesidades básicas.

Queda bastante trabajo.

Encontré un vídeo en Youtube con algo que creo es exactamente lo que quieres hacer; està en polaco pero con el traductor de Google se entiende. El código es sencillo y breve.

http://tyfek.republika.pl/Sterownik_rotora_arduino/sterownik_rotora_arduino.html

73 de EA3NR, Enric

Gracias Enric, muy interesante. No he encontrado el código del programa.

Estoy montando un mando completo incluido el transformador para el motor del rotor y el prototipo funciona ya con el código para Arduino
de EA3NG publicado en 2015.

Buenas noches Enio, estos son los codigos que se refiere el amigo Enric

http://tyfek.republika.pl/Sterownik_rotora_arduino/Rotor_V1_1.ino

http://tyfek.republika.pl/Sterownik_rotora_arduino/Rotor_V1_2.ino

¡Muy interesante!

Una forma de entender la sintaxis de un lenguaje de programación es analizar diferentes tipos de código. El código de k3ng es muy complejo porque abarca decenas de posibilidades de sensores y programación de rumbo, incluyendo rutas orbitales, remotering, etc.

El código que has puesto es mucho más entendible y, probablemente (hay variables en polaco e inglés) es una modificación de otras fuentes.

Me has ayudado a seguir jugando con el arduino y el controlador del rotor. Gracias.

EA2HW escribió:

¡Muy interesante!

Una forma de entender la sintaxis de un lenguaje de programación es analizar diferentes tipos de código. El código de k3ng es muy complejo porque abarca decenas de posibilidades de sensores y programación de rumbo, incluyendo rutas orbitales, remotering, etc.

El código que has puesto es mucho más entendible y, probablemente (hay variables en polaco e inglés) es una modificación de otras fuentes.

Me has ayudado a seguir jugando con el arduino y el controlador del rotor. Gracias.

El código de K3NG es una obra de arte, deja muchas posibilidades abiertas para que cada uno se configure las opciones que le interesen... En mi opinión, creo que es un poco demasiado complejo y que tienes que saber bastante de microcontroladores y de lenguaje de programación C, y aún así tiene algunas partes complicadas de entender.
No soy un especialista en microcontroladores y programación, pero mi consejo es que para empezar busques hardware y software sencillo que hagan las funciones que tu quieres implementar, intenta entenderlo y ponerlo en marcha, y luego le vas añadiendo más funcionalidades.
El buen software es el que se diseña de manera modular y se pueden aprovechar funciones para hacer otras cosas; por ejemplo: en la web de arduino encontraras un ejemplo para leer datos de GPS en formato NMEA, pero esta misma rutina te sirve para leer qualquier puerto serie para qualquier otro tipo de aplicación.
En resumen, en programación ya está todo inventado, solamente tienes que encontrar el código que hace lo que tu quieres o algo muy parecido y adaptarlo a tus necesidades.
Saludos!

73 de EA3NR, Enric

Gracias Enric, estoy en ello. Me costó bastante después de unos años sin practicar pasar de un sistema de programación procedural a modelos orientados a objetos. Aunque un código esté bien estructurado y documentado es muy difícil meterte en la mente del que lo ha diseñado es más sencillo hacerlo tu desde el principio.

El código de k3ng es como mínimo complejo. Ya no se trata de de entender los procedimientos, esto es sencillo y la estructura del #C es hasta cierto punto sencilla de entender si la vas despojando de las ramas que no te sirven. Lo más sencillo es dejárselo todo al compilador como aparentemente es la intención de k3ng, pero el ultima versión las definiciones y opciones que se deben activar o desactivar (comentar o descomentar) son tan numerosas y complejas que no es posible acertar cuáles son. Las constantes que se definen no describen qué función tienen.

Por ejemplo: si utilizas un display 16x2 de 4 bit que es lo más económico y habitual, debería bastar con definir este elemento en un punto, pero es que aparece en varios ficheros. Cuando consigues que el compilador entiende que debe utilizar el display, te das cuenta que el código, por defecto describe un display de 4 x 20 en otro fichero para sacar las variables al display, cuando lo corriges, tienes que adivinar que línea selecciona la variable "lectura AZ" para que la saque en la segunda línea y en la primera el "status". Al final yo por lo menos no lo he conseguido.

Lo he resuelto a base de utilizar una versión de código de 2015 que tenía perdida por un disco duro y aun así me ha costado unas cuantas horas adaptarla porque he tenido que adivinar midiendo que las salidas de los pines de Arduino podían estar por defecto LOW o HIGH (estaban en el código al revés), establecer el giro máximo del rotor, la posición de inicio, etc. Todo ello con una documentación bastante marciana y con una ayuda nula en el distribuidor de correo de Yahoo.

Es muy interesante tener una interfaz del rotor a base de un Arduino y fuente enorme de experiencia montarla. Estoy ya en la etapa final. He cambiado los relés por unos finder de la serie 36 de 5V porque me he cargado (como me lo temía) un conjunto chino (los transistores SMDque pilotan los reles).

Espero publicar la experiencia porque sirve para conocer cómo funciona un rotor, los diferentes sistemas de sensor acimutal, sistemas de preajuste de dirección, etc. y cómo funciona un Arduino así como las posibilidades de comunicar el interfaz con un programa de PC para dirigir la antena.

¡Seguiré atento al hilo!
Tengo en mente montarme un controlador de rotor para sustituir el mando de mi Yaesu G-800S y seguro que algo de lo que estás compartiendo en el foro sobre tu experiencia me servirá.
Saludos y QRV...