Interfaz rotor Arduino de K3NG

Es una idea Cedric, el G800S es un equipo más moderno y completo que el G600 que utilizo. Tiene controlador de velocidad y un preselector de rumbo, probablemente por potenciómetro y permite sobregiro.

No necesitas sustituir el mando completo, sólo es necesario montar el gabinete de control y conectarlo al actual aprovechando la alimentación del rotor. La ventaja que puedes obtener es incorporar un marcador de rumbo digital, un preselector por encoder y un interfaz para controlarlo desde un programa en el PC, por ejemplo HRD aunque parece que k3ng está cabreado con los propietarios y no quiere dar soporte.

Desde luego el código se puede adaptar a ese rotor si estás dispuesto a estudiarlo, el fichero principal tiene 12.000 lineas :laugh: yo lo he podado hasta las 4.000 y aún me queda por analizar algunas condiciones.

Verás que cada procedimiento tiene que descartar o incluir toda una serie de opciones. Algunas declaraciones, funciones y procedimientos pierden hasta el 90% del código.

Hola,

Bueno, lo que hace Enio, lo de podar, es debido a que él usa un Arduino Nano, pero si usas un Arduino más "normalito", un Uno, o el que uso yo un Mega, no se necesita podar nada. Simplemente activas o desactivas las funciones que te interesan.

73, Máximo - EA1DDO

No es del todo exacto Máximo. La memoria del ATmega 328 que utilizan tanto el NANO 3.0 como el UNO es suficiente como para cargar la mayoría de las prestaciones del interface de k3ng, sólo algunas de las prestaciones adicionales utilizadas en control remoto requieren un microprocesador mayor como el MEGA. El compilador se ocupa de crear un ejecutable con la extensión proporcionada a las prestaciones que defines en el código y para trabajar como interface y control le sobra memoria al UNO y al NANO (y al MICRO que utiliza RemoteQTH) incluso con funciones como la de freno o control de velocidad de rotación para acimut y elevación.

Como he indicado la falta de documentación dificulta los ajustes en el código. Una linea en el código #define OPTION_SAVE_MEMORY_EXCLUDE_REMOTE_CMDS se quedaba en tiempo de compilación con una buena parte de la memoria destinada a las variables locales y el compilador sacaba un "warning", desactivando la linea ha sido suficiente y más eliminando las opciones del depurador una vez comprobado que el programa funciona le sobre memoria.

En mi opinión para el proyecto del interfaz para el G800, si no vas a controlarlo en remoto y no vas a incluir prestaciones de ethernet, te basta con un NANO o quizá un UNO si necesitas muchas puertas digitales ahorrando mucho espacio.

En principio pensé "podar" (eliminar línea de opciones que no necesito) para ahorrar memoria porque me daba problemas (que solucioné desacticando la línea descrita), pero eso no soluciona nada porque es el compilador el que elimina lineas que no son más que inclusiones condicionales. Estoy limpiando el código para entenderlo mejor haciendo a mano lo que hace el compilador, pero eso en la práctica no ahorra más que un poco de memoria al eliminar algunas constantes o variables que no voy a utilizar y que se definen fuera de las condiciones.

Un ejemplo: la definición de variables tiene unas 500 líneas de código, si está definida la función para que la lectura de la dirección muestre uno o dos decimales, las variables cambian de valor, como es lógico, de número entero (int) a largo (long), una variable "int" ocupa menos memoria que una variable "long"

Para indicar el rumbo correcto de una direccional de tres elementos basta con indicar los grados, por lo tanto me interesa desactivar esa opción (como a la mayoría que no hace rebote lunar o satélites). Con esa opción desactivada el compilador solo "ve" la definición de variables a partir de "#else". Es lo mismo que borrar a mano todas las líneas entre #ifdef y #else y finalmente #endif, luego borrar en todo el código las instrucciones para el compilador que se refieren a los decimales. Pues bien, solo de las 500 líneas de la definición se quedan unas 150. La memoria utilizada es la misma, pero el código es más limpio y se puede entender meyor (y aprender)

#ifdef FEATURE_TWO_DECIMAL_PLACE_HEADINGS
long azimuth = 0;
long raw_azimuth = 0;
long target_azimuth = 0;
long target_raw_azimuth = 0;
long azimuth_starting_point = AZIMUTH_STARTING_POINT_DEFAULT;
long azimuth_rotation_capability = AZIMUTH_ROTATION_CAPABILITY_DEFAULT;
#else
int azimuth = 0;
int raw_azimuth = 0;
int target_azimuth = 0;
int target_raw_azimuth = 0;
int azimuth_starting_point = AZIMUTH_STARTING_POINT_DEFAULT;
int azimuth_rotation_capability = AZIMUTH_ROTATION_CAPABILITY_DEFAULT;
#endif

Ha caído en mis manos una caja de remoteqth para cuatro controladores de rotor de K3NG mediante un servidor, es de un amigo y me lo trajo para prepararlo y configurar todo.

Pues bien me he llevado una sorpresa al poner en marcha los controladores, los rotores a usar son los HI Gain T2X, mi cabeza me decía que la placa de estos controladores no los iba a soportar, pero previa consulta en el foro del creador y garantizarme que si, catapum, las pistas de la pcb del controlador se queman. ¿como es posible querer conducir casi 8 amperios por una pista de menos de un milimetro?

La pista que señálo con el puntero tiene que soportar la corriente del solenoide para soltar el freno, y la corriente de una de las bobinas del motor a la vez, esto es imposible, y efectivamente se quema con tan solo 5 segundor el rotor girando.

Mucho cuidado con los rotores que conectáis directamente al db15 del controlador tal y como recomienda el diseñador.

Gracias por el aviso.

73, Máximo

Bueno el controlador está funcionando y el código adaptado a las funciones del rotor G-600. Este mando incluye un transformador para la alimentación del motor del rotor.

Los circuitos impresos lo ha realizado EA2CJA

Buenas noches

Yo hize el controlador segun proyecto SP3TYF ( el que menciona colega EA3NR ) y puedo decir que funciona. Varias veces me puse en contacto con el autor porque tenia algunas dudas y siempre me respondio. Hable con el porque quieria implantar un rele para liberar el freno del motor pero finalmente no se ha podido hacer nada. Yo tengo problema con el motor que tiene freno incorporado. El motor se alimenta a 27 Vdc y para que gire mas lento le tengo que alimentar con unos 15-20 V. Con esta tension el freno tiene menos fuerza de separacion . Y por eso mi idea era poner tercer rele para el freno ( tras separarle electricamente ) del motor .Luego deje este projecto porque me salio oportunidad de comprar placas pcb para el controlador K3NG ( de remoteqth ) pero finalmente no he las conseguido. Espero volver algun dia terminar el controlador de SP3TYF cuando tenga alguna placa pcb.

EC4AGT

Estuve revisando el código de SP3TYF. Es más sencillo que el de K3NG porque está destinado únicamente a mover un rotor con sensor por potenciómetro, preset con encoder y display.

Fue una opción que finalmente descarté al entenderme con el código de K3NG que me pareció algo más completo. En cualquier caso veo que ambos funcionan.

Añadir a cualquiera de los dos códigos la opción para pilotar un tercer relé de freno es una tarea alcanzable, quizá más sencilla si utilizar el código de K3NG que ya está escrito para ello.

Si mantienes una copia del sketch de SP3TYF (para hacer reversible la prueba) puedes hacer pruebas con el de K3NG, cambiando los pines a tu proyecto y adaptando las características de giro del rotor.

En el caso de añadir la prestación de control de freno tendrías que definir el pin que activa el relé del freno #define brake_az 0 (pin digital) en rotator_pins.h, el tiempo de retardo #define AZ_BRAKE_DELAY 1000, y el estado activo e inactivo del pin del relé del freno #define BRAKE_ACTIVE_STATE HIGH/LOW y #define BRAKE_INACTIVE_STATE HIGH/LOW en rotator_settings.h (Todo esto en la versión que he utilizado).

Para incorporar estas características en el código de SP3TYF, tendrías que adaptar las constantes que utiliza (que no he revisado). Definir una entrada/salida digital que tengas libre asignándola a una salida que activa un relé con el mismo hardware que el que utilizas para los relés de giro. Decirle a Arduino que esa salida debe estar en estado HIGH (1 o alto, es decir: +5Vcc) cuando se libera el freno que, como es lógico, cuando el rotor se mueve, por lo tanto, tienes que buscar el procedimiento en el código que activa el rotor en cualquier dirección y liberar el freno. Debes tomar todas las precauciones para que el rotor no inicie un giro con el freno activo.

Para implementar la prestación de freno en el código de SP3TYF te sugiero la posibilidad de revisar el código de K3NG para comprobar cuál la técnica que utiliza. Si libera el freno cada vez que se activan los relés de giro o liberar el freno cada vez que se incia una sesión, lo cual no me parece lógico. En cualquier caso lo consultaría en la lista de correo de Yahoo.

Otra técnica que podrías utilizar es cambiar los relés chinos que usa SP3TYF para el rotor por otros relés con doble circuito. Incluir un tiempo de espera en las salidas de estos relés y asignar uno de los secundarios para actuar sobre el freno.

Siento no poderte ser de más utilidad.

EA2HW escribió:

Bueno el controlador está funcionando y el código adaptado a las funciones del rotor G-600. Este mando incluye un transformador para la alimentación del motor del rotor.

Los circuitos impresos lo ha realizado EA2CJA

Hola Enio:

Llevo varios dias dándole vueltas al asunto de construirme un mando y me he encontrado con tu proyecto. Mi idea es la misma que la tuya, mando sencillo y el código de K3NG con tantos archivos se me antoja una muralla....

La parte Hardware la tengo clara, pero el software pensaba que era más sencillo. Voy a ver el código del polaco a ver si con este me animo....

¿No tendrá alguien el código preparado para un G450-C, es decir, potenciómetro, control de azimuth, pulsadores, y display? Sería de gran ayuda...

73's de Juan Carlos EA5WA

EA2HW escribió:

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.

Hola Enio:

¿Conseguiste un código sencillo para el Yaesu G450?

¿Alguien tiene el código de EA3NG disponible?

Gracias

Pues nada....Una pena que nadie quiera compartir nada....

Gracias de todas formas

Juan Carlos,

Sigo dirigiendo la antena con la interfaz de K3NG. El sketch que utilizo lo tuve que currar línea a línea partiendo de una variante que encontré en en Internet en la página de uno de los que venden el CI, no recuerdo quien.

Desafortunadamente en la última reinstalación de SO, fromateé por error el disco de datos y no he conseguido recuperar algunos trabajos, entre ellos el sketch modificado que está compilado en el microprocesador y no tengo forma de recuperar el código fuente. Siento no poder mandártelo.

PS: El código inicial es el de RemoteQTH https://remoteqth.com/single-rotator-interface.php

Las variaciones las tienes en mi página.

Muchas gracias Enio. Le echaré un vistazo a tu página.

Enviado desde mi Redmi Note 3 mediante Tapatalk

Estoy intentando cargar el soft de k3ng sobre un arduino uno después de recortarlo y me dice que no encuentra la librería wire....
Se supone que va instalada con el IDE oficial, ¿no?

Enviado desde mi Redmi Note 3 mediante Tapatalk

Que no es interesante? Precisamente estoy empezando a ver como montar un circuito que me sustituya los rotores yaesu que tengo. Con un solo mando poder hacer funcionar los tres un Yaesu G1000dxc, G650 y un G450. Cuando termine la primera fase lo diré y luego veremos si puedo seguir.....

Hola

El 15 de Junio escribi en este hilo  https://www.ure.es/foros/tecnico/contro-rotor-k3ng/#post-323938

Con el cambio en la Web, pues no estara muy actualizado, seria interesante tener un hilo unico.

Yo me estoy "pegando" con el proyecto........el problema no es la confeccion del esquema circuito con el arduino, pulsadores, potenciometro display, etc......... El problema radica en configuracion y compliacion del programa pues al ser software libre hay infinidad de versiones.

Yo lo tengo "casi" preparado en un Arduino Mega para un rotor Ham IV, y lo que he hecho es del software que esta en el Gitub, bajarme la ultima version y a partir de eso, hacer las configuraciones necesarias. Voy despacio, muy despacio....pero algo estoy consiguiendo. 

Lo que he podido ver, leer.....etc, etc, la version sobre la que trabaja Enio, de Remote QTH, esta muy optimizada, pero no se le pueden implementar apenas cosa, por eso me decido a lo que estoy haciendo, es complicado, maxime si no tienes mucha idea de progrmacion y solo aplicas el acierto/ error para las configuraciones.

OS leo, intentado aprender mas, cuando mis avances sean mayores, os lo contare.

Saludos cordiales

Hola, os cuento mi experiencia desde la ultima vez que escribí hace tres meses.

Despues de leer, leer………, y a veces, no comprender. Por fin me decidi.

Mi configuración es un CD-45 ( el cual desmonte limpie y modifiqué ) para Azimut y un Yaesu G-500A para elevación.
Siguiendo el esquema básico de K3NG, me decante por utilizar un Arduino MEGA, ( por la multitud de posibilidaddes de poder añadir cosas posterioremente ).

En un principio quería lo básico, azimut y elevación utilizando los potenciómetros de cada uno de los rotores y unos pulsadores para girar arriba-abajo / izquierda derecha, saber la ubicación exacta utilizando un GPS y una vez tenido esto implementar un Joistick y suprimir los pulsadores, ( y luego poco a poco ir haciendo mas experimentos ).

Mi principal problema ha sido la interpretación de los ficheros de configuración por la multitud de posibilidades que tiene y por la poca información al respecto que hay “pululando por la red” , hay mucha sobre el hardware, con multitud de montajes, multitud de videos, multitud de opciones, pero sobre los ficheros de configuración muy poco y lo poco que hay a veces, para neófitos en programación, demasiado complicado de entender, buff…que rollo, pero os lo cuento por que me da la sansación que no soy el unico al que le pasa o ha pasado. Partia de que tenia configuraciones de proyectos realizados que funcionaban y los softwares con lo que sabia que es lo que hacia cada proyecto, a partir de eso, me puse manos a la obra, a ratos, sin prisa pero sin pausa. Despues de pegarme con el arduino y sus librerías y compilaciones ( eso es otro mundo a parte ) he llegado a la siguiete conclusión: de la multitud de ficheros que trae el software de K3NG, los realmente importantes y donde esta el meollo de las configuraciones son:

rotator features.h     CARACTERISTICAS DEL ROTOR
rotator settings.h     AJUSTES DEL ROTOR
rotator_pins.h          CONFIGURACION DE LOS PINES DE ENTRADA Y SALIDAS

A partir de aquí, jugando con el método acierto/error he conseguido que al menos funcione, ahora queda el “trabajo fino” de ajustes y demás, pero lo gordo está, y teniendo en cuenta de mis limitaciones electrónicas e informáticas, pues me doy por satisfecho.
Se agradecería que el personal contara sus experiencias, sobretodo en los ficheros de configuración, para entre todos intentar avanzar.

Saludos cordiales

Anibal - EA1ASC

Bueno, pues como nadie cuenta mucho sobre el tema, aquí dejo mis lineas modificadas para obtener un controlador de rotor sencillo (botones de giro manual, control automático por pc y display LCD). Para ello, sólo tenéis que borrar las dos barras (//) de la izquierda ya que todo lo que tiene las dos barras son comentarios y no es tenido en cuenta a la hora de compilar. Os aconsejo que lo hagáis con el Notepad++:

En el archivo rotator_features.h:

#define FEATURE_YAESU_EMULATION                                              para activar la emulación Yaesu GS232A

#define OPTION_GS_232B_EMULATION                            para activar la emulación GS232B (yo he activado las dos....)

#define FEATURE_AZ_POSITION_POTENTIOMETER      para activar el uso del potenciómetro interno  del rotor

#define LANGUAGE_SPANISH                                                para que en el display salgan los mensajes en Castellano

#define FEATURE_4_BIT_LCD_DISPLAY                               para utilizar un display LCD de 4 bits

#define OPTION_DISPLAY_DIRECTION_STATUS              para que aparezcan los puntos cardinales en la linea superior del display

#define OPTION_C_COMMAND_SENDS_AZ_AND_EL                 NO SE PARA QUE, pero la he activado por si acaso

#define OPTION_DELAY_C_CMD_OUTPUT                       TAMPOCO SE PARA QUE.....Según dicen mejora el uso con el Ham Radio Deluxe

En el archivo rotator_pins.h:

#define rotator_analog_az A0                  para definir el pin por el que recibo la señal del cursor del potenciómetro de azimuth

#define button_cw A2                               para definir en que patilla tendré conectado el botón de girar a derechas (sentido horario)

#define button_ccw A3                             para definir en que patilla tendré conectado el botón de girar a izquierda (sentido anti-horario)

#define rotator_cw 8                                 para definir que salida del arduino (Digital 8 en mi caso) controla el relé de giro a derechas

#define rotator_ccw 9                               para definir que salida del arduino (Digital 9 en mi caso) controla el relé de giro a izquierdas

En el archivo rotator_settings.h:

#define LCD_COLUMNS 16                        para definir el número de columnas de nuestro display (en mi caso 16)

#define AZIMUTH_ROTATION_CAPABILITY_DEFAULT_450               ya que mi rotor tiene un Overlap de 90  grados (360+90 = 450)

#define AZIMUTH_STARTING_POINT_DEFAULT 180    para definir que la rotación empiece en 180 grados (Sur)

#define ROTATE_PIN_INACTIVE_VALUE_HIGH               para definir la lógica de las salidas que activan los relés

#define ROTATE_PIN_ACTIVE_VALUE_LOW                      para definir la lógica de las salidas que activan los relés

Espero que sea de ayuda para alguien....

Seguro que sí, Juan Carlos!

73, Manolo

Este finde he hecho las primeras pruebas con el rotor Yaesu G450C y  lo he calibrado de manera correcta siguiendo el manual de K3NG.

FUNCIONA PERFECTAMENTE

Siguiente paso colocar el rotor en su sitio y montar antenas.....

73's