Publicidad Google grande + Astroradio
URE foro pequeñas
Soft K3NG para cont...
 
Notificaciones

Soft K3NG para controlar rotor versión simple , dónde puedo encontrar ?  

Página 1 / 2
  RSS
EC4AGT
Mensajes: 164
13 enero, 2020 15:42     #341952

Buenas tardes 

En este enlace 

https://remoteqth.com/single-rotator-interface.php

Aparece información sobre control simple del rotor con un Arduino Nano. Está todo menos el software. Por mucho que busco no le encuentro. Estoy interesado en esta versión , tengo otra pero es más compleja y no doy con ella. Me interesa que el display se puede conectar con módulo i2c para simplificar el cableado 

Si alguien tiene un enlace que me pudiera pasar estaría muy agradecido . 

EC4AGT
Wojtek
73

ResponderCitar
EA3GCV
Mensajes: 533
13 enero, 2020 16:34     #341954

Hola,

El programa PSTROTATOR soporta el Arduino de K3NG:

https://www.qsl.net/yo3dmu/index_Page346.htm

Puedes probarlo gratuitamente durante 10 minutos cada sesión. Tiene un coste de 20€ pero vale la pena ya que tiene funciones muy interesantes.

73

 

Jordi, EA3GCV

ResponderCitar
EC4AGT
Mensajes: 164
13 enero, 2020 17:00     #341955

Buenas tardes. 

Si , conozco este programa y es muy bueno . 

Pero ahora estoy intentando hacer el control con el Arduino . Y en el enlace del mi primer post viene el proyecto. Por lo que veo , es perfecto para lo que quiero hacer , lo único es que el soft ya no es disponible .

 

Saludos Cordiales 

EC4AGT

Wojtek

EC4AGT
Wojtek
73

ResponderCitar
EA1N
 EA1N
Mensajes: 188
13 enero, 2020 17:10     #341958

@ec4agt

Hola,

 

    Lo tienes aqui.

https://remoteqth.com/wiki/index.php?page=Rotator+module+version+3.3#Firmware

Un saludo EA1EVR -Javi -

ResponderCitar
EA3GCV
Mensajes: 533
13 enero, 2020 17:28     #341960

@ec4agt

Disculpa me he confundido del software que necesitabas, pensaba era de control y es para programar el Arduino. 

73

Jordi, EA3GCV

ResponderCitar
EC4AGT
Mensajes: 164
13 enero, 2020 17:35     #341961

Hola de nuevo

 

Muchas gracias , sobretodo EA1EVR 

Ahora intentare configurar y probar como funciona

 

73

 

EC4AGT

Wojtek

EC4AGT
Wojtek
73

ResponderCitar
EA2J
 EA2J
Mensajes: 2334
14 enero, 2020 09:18     #341984

Estoy trabajando en adaptar la versión actual del software a un rotor Yaesu G650 incluyendo el mando de preselección con un encoder y control de "overlap". La idea es aprovechar el trafo de un mando para construir una caja que contenga todo. También, por supuesto, la comunicación con el PC vía USB para utilizar los programas HRD y N1MM. El planteamiento, independientemente de los costes, tiene una serie ventajas e inconvenientes sobre la utilización de los mandos de fábrica en especial los de Yaesu de la serie G-400, 450, 600, 650 etc. El sistema de señalamiento con la esfera de dirección es espectacular pero compleja ya que implica el uso de un motor sincronizado con el del rotor a través de un potenciómetro local. Por eso he considerado como mejor solución el uso de una cabina integral.

La tarjeta Arduino es una NANO. La memoria es insuficiente si se quiere depurar el funcionamiento con el debugger que incorpora el programa de K3NG, pero no sé como va a funcionar con una MEGA y para las prestaciones que requiere un Yaesu G650 es suficiente además de ganar espacio en la cabina.

Este proyecto plantea una serie de problemas que hay que ir resolviendo, en especial de software. El programa está muy bien hecho en líneas generales. Una gran parte del código se ha realizado por expertos en programación con C++, pero también es un programa en el que han intervenido ¿decenas? de programadores aplicando soluciones a medida que se iban planteando problemas sin la coordinación que exige un proyecto multidisplinar, como es lógico al tratarse de un proyecto pro bono que ha ido progresando a lo largo de años.

En este momento estoy diseñando cuatro módulos, el primero contiene el Arduino con las entradas y las salidas, el segundo el display (1602) con las entradas y salidas, el tercero los relés con una UDN8931AT y el cuarto el regulador de la fuente con salidas a 12V (relés Finder vserie 41) y 5V.

Utilicé el programa de RemoteQTH (v:2.0.2015021501) modificado  para el mando que utilizo actualmente y que ha funcionado bien tres años, pero quiero incorporar el código actual de emulación Yaesu (v.2019.01.03.01) y adaptarlo para el Yaesu G-650 que incluye el control de overlap. De momento, salvo algunos pequeños detalles que estoy resolviendo, he conseguido que funcione salvo la comunicación con HRD que da problemas, sin embargo, funciona aparentemente bien con el mando de N1MM.

También estoy documentando todo lo concerniente a las correcciones de las características (rotator_features.h). Abandoné la tarea de "podar" las líneas que no son útiles y me he dedicado a analizar la lógica trazando el flujo de las funciones de setup() y, sobre todo del loop() pero he desistido de la posibilidad de utilizar librerías propias para el display. Hacerlo sencillo para que funcione.

Si algún compañero está interesado en el proyecto, un privado para compartir experiencia o en el foro si la pregunta o propuesta es de interés general.

En cualquier caso, el control de un rotor es una situación frecuente para los radioaficionados, aportar una solución "llave en mano" para que cualquier colega pueda montarse un mando alternativo, bien sea para mejorar el mando de fábrica o para reutilizar un rotor usado puede ser un trabajo interesante, por parte agradecería cualquier iniciativa para hacerlo de forma colaborativa.

Comment is free, but facts are sacred. (C.P.Scott)
http://www.enioea2hw.wordpress.com

ResponderCitar
EC4AGT
Mensajes: 164
14 enero, 2020 22:41     #342023

Buenas noches .

 

Me parece una idea muy buena . Me refiero hacer un proyecto que luego cada uno le puede copiar para realizar su propio montaje de un controlador. 

Yo , por desgracia no tengo suficientes conocimientos para aportar más ideas. Soy , por decir simple consumidor .

He intentado fabricar mi propio controlador en varias ocasiones pero no llegue  terminar. Incluso he comprado algunas placas PCB  pero finalmente han acabado en un cajón. 

Ahora , como tengo la emisora averiada y no merece la pena de repararla ,  pobre tenía unos 25 años me quiero entretener con mi rotor y terminar el controlador .

 

EC4AGT

73

Wojtek 

EC4AGT
Wojtek
73

ResponderCitar
EA5GHD
Mensajes: 68
14 enero, 2020 22:44     #342024

@ea2hw

saludos A todos , 

Estoy de acuerdo , podemos abrir , no se si hay alguno por ahí , un foro para compartir experiencias y ayudarnos a experimentar  , yo he conseguido hacer funcionar el Código de K3NG después de muchas horas sacando conclusiones y experimentado ,  lo he adaptado al Rotor Ham IV de Hy-Gain que son lo que yo utilizo y el Arduino Mega para no tener problemas de memoria, mas o menos yo utilizo el 50% de su memmoria , Utilizo el mando original sin modificar nada de su interior , solo he tenido que sacar dos cables del interior para poder accionar el freno ( con mucho cuidado porque funciona directamente con 220 V , lo demas se puede tomas de la parte trasera del mando del rotor ) para el que no conozca nada del tema , puede investigar en :

https://blog.radioartisan.com/yaesu-rotator-computer-serial-interface/

el código se puede descargar gratuitamente y ahi esta toda la información ,,, mas o menos...

Os dejo una foto para que podáis ver como va mi proyecto para que os podáis hacer una idea

 

Un saludo

Fernando EA5GHD

 

 

 K3NG 5p
ResponderCitar
EA5GHD
Mensajes: 68
14 enero, 2020 22:46     #342025

Os dejo otra foto , no se si se puede colocar mas de una en cada respuesta.

 

Un saludo

 K3NG 7p
ResponderCitar
EC4AGT
Mensajes: 164
15 enero, 2020 02:28     #342031

Buenas noches 

Pues veo que se lo has currado. Yo igual , estoy estudiando el programa pero para mí es demasiado completo. Seguro , que para mí aplicación sobra amitad de ficheros que tiene. Por eso estoy buscando una version reducida. Sólo quiero controlar en el eje horizontal más el freno. Tengo un par de versiones y con una estoy trabajando para adaptar para mí mí proyecto.

Saludos 

EC4AGT

Wojtek 

EC4AGT
Wojtek
73

ResponderCitar
EA2J
 EA2J
Mensajes: 2334
15 enero, 2020 19:24     #342056

Wojtek, reducir el código es un error que ya he cometido y del que he aprendido. El compilador se ocupa de reducir el código. Si quieres entender cómo funciona el software analiza únicamente las funciones dentro de setup() y, sobre todo, de loop() y estudia detenidamente los ficheros que puedes modificar:

rotator_features.h

En el que se definen las características y prestaciones de las que podemos debatir para entender qué hace cada una y cómo se adapta a nuestro rotor.

rotator_settings.h

En el que se marcan los límites y el comportamiento del rotor

rotator_pins.h

En el que se definen las salidas y entradas analógicas y digitales.

Prefiero trabajar con la última versión en la que se supone que se habrán corregido los "bugs" relacionados con le comunicación USB.

Esta publicación fue modificada hace 3 meses por EA2J

Comment is free, but facts are sacred. (C.P.Scott)
http://www.enioea2hw.wordpress.com

ResponderCitar
EC4AGT
Mensajes: 164
16 enero, 2020 07:47     #342065

Ok

Muchas gracias por explicación . Esa información estaba buscando . Como tiene tantos ficheros o partes de programa no sabía exactamente cuál y que hay que modificar. Con tu repuesta ya sabré que hay que tocar. Es más , ayer he conseguido que algo ya funcione . Me queda mucho para aprender y entender el programa pero ya algo he descubierto 

 

Muchas gracias y 73

EC4AGT

Wojtek 

EC4AGT
Wojtek
73

ResponderCitar
EA2J
 EA2J
Mensajes: 2334
16 enero, 2020 11:04     #342079

En mi experiencia, modificar el código escrito por terceros es más difícil que escribir de nuevo, en especial cuando ese código es el resultado de la intervención de muchos programadores sin una coordinación, con lo que cada cual aporta los conceptos propios que todos pueden ser buenos pero diferentes. Los programas de K3NG (RadioArtisan) son el resultado de la suma de diferentes aportaciones que han ido añadiendo nuevas prestaciones, arreglos y adaptaciones a un programa.

Intentar "podar" lo que es superfluo para cada proyecto es un error porque siempre te vas a encontrar una parte que llama a funciones (métodos) en otra parte que las modifica. Este programa lo he "podado" con un analizador de código profesional (Clion) y lo he reducido a 3.000 líneas (de cerca de 20.000), pero al final no puede hacerlo funcionar. Ahora, partiendo de la última versión publicada consigo que funciona con el controlador antiguo para el G-600, de esta forma solo me queda añadir el control del "overlap" y los tres diodos LED que indican giro CW y CCW y Overlap.

Siempre es mejor partir de la última versión y no de la de 2015 que se utiliza habitualmente con el hardware sw RemoteQTH. Les escribí un correo solicitando un listado de las "features" activadas y me comentaro que ellos fabricaban hard pero soft.

También comprobar cómo funciona con un encoder incremental. Repasando los archivos auxiliares del programa son los siguientes (no te recomiendo borrar ninguno, pues se modifica todas las direcciones para el compilador. Tendrías que ir salvando cada cambio con un nombre y una carpeta diferente.

k3ng_rotator_controller.ino            Fichero principal 14.074 líneas!

rotator.h                                                Define las macros, no se debe modificar nada.

rotator_clock_and_gps.h                 Fichero vacío, el código está en algún repositorio de GiHub.

rotator_command_processing.h    Fichero vacío. Ni idea qué función podría tener

rotator_debug.cpp                             Pasar. Librería para depurar el programa con salidas a través del monitor serie.

rotator_debug.h                                 Pasar. Cabecera de la librería del depurador.

rotator_dependences.h                     No tocar. Analiza, deriva y depura las "features" activadas, solo para programadores expertos.

rotator_ethernet.h                              Fichero vacío. Como las funciones clock y gps están en algún otro repositorio.

rotator_features.h                               Aquí hay que modificar las características que hay que activar. En otro hilo podemos comentar cómo

rotator_features_ea4tx_ars_usb.h  No tocar. Éste fichero contiene las características del hard de EA4TX y las cuatro siguientes de otros proveedores

_m0upu.h, _test.h y w6kcn.h           Lo mismo que la anterior, características adaptadas a diferente hard

rotator_hardware.h                           Añade características de diferentes componentes

rotator_k3ngdisplay.cpp                  No tocar. Librería para la comunicación de diferentes visualizadores. Matar pulgas a cañonazos.

rotator_k3ngdisplay.h                       No tocar. Cabecera de la librería

rotator_languaje,h                              Traducción a diferentes idiomas. Se puede modificar respetando la longitud de las cadenas.

rotator_moon_and_sun.h                Fichero vacío, como los anteriores en algún repositorio de GitHub

rotator_pins.h                                      Aquí hay que definir las I/O en función del montaje y placa utilizados, hay reglas.

rotator_pins_ea4tx_ars_usb.h, _m0upu.h, test.h y _w6kcn.h, _w6_az_test_setup.h  Definen los pines del hardward de estos proveedores

rotator_settings.h                              Aquí se ajustan los parámetros iniciales del rotor, mucha atención. Debate conveniente.

rotator_settings_ea4tx_ars_usb.h, _m0upu.h, test.h y _w6kcn.h, _w6_az_test_setup.h Ajustes específicos de cada hardware, didáctico.

rotator_steeper.h                              Fichero vacío, ni idea sobre el propósito ni sobre dónde está el código actualmente.

Del análisis de la distribución del código en archivos se pueden sacar algunas conclusiones, por ejemplo, ha habido incorporaciones interesantes como un RTC controlado por GPS o función remota con ethernet, etc. que luego se han sacado del cuerpo del programa sin modificar los archivos. Revisando las funciones que trabajan en loop() se leen llamadas a funciones específicas de GPS, Ethernet, etc. que están insertadas en el cuerpo del programa, lo cual indica bastante descoordinación. Por otra parte, las librerías del RTC se limitan a módulos anticuados, lo cual indica que no hay continuidad para estas prestaciones y pone en duda otras.

A pesar de todo, es un excelente programa para rotores básicos con las prestaciones necesarias y un funcionamiento fiable.

Esta publicación fue modificada hace 3 meses por EA2J

Comment is free, but facts are sacred. (C.P.Scott)
http://www.enioea2hw.wordpress.com

ResponderCitar
EC4AGT
Mensajes: 164
16 enero, 2020 18:25     #342094

Buenas tardes

Estoy intentando cargar la ultima version de programa del año pasado y a la hora de eligir en

rotator.features.h el display i2c

FEATURE_RFROBOT I2C_DISPLAY  y me sale este error 

rotator_k3ngdisplay.cpp:60:24: error: conflicting declaration 'LiquidCrystal_I2C lcd'

 

En ostra version no tenia este problema , es posible solicionarlo ?

 

 

EC4AGT
Wojtek
73

ResponderCitar
EA2J
 EA2J
Mensajes: 2334
16 enero, 2020 21:30     #342103

Le echaré un vistazo cuando pueda. El error apunta a la librería de K3NG

concretamente en esta definición:

#if defined(FEATURE_RFROBOT_I2C_DISPLAY)
                          LiquidCrystal_I2C lcd(0x27,16,2);
                         // LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
#endif //FEATURE_RFROBOT_I2C_DISPLAY

La librería que está utilizando en esta versión es:

#if defined(FEATURE_YOURDUINO_I2C_LCD) || defined(FEATURE_RFROBOT_I2C_DISPLAY) || defined(FEATURE_SAINSMART_I2C_LCD)
                                 #include <LiquidCrystal_I2C.h>
#endif

¿La tienes cargada correctamente en el IDE?

También se activa la otra definición en "rotator_dependencies.h"

#if defined(FEATURE_4_BIT_LCD_DISPLAY) || defined(FEATURE_I2C_LCD) || defined(FEATURE_ADAFRUIT_I2C_LCD) || defined(FEATURE_YOURDUINO_I2C_LCD) || defined(FEATURE_RFROBOT_I2C_DISPLAY) || defined(FEATURE_YWROBOT_I2C_DISPLAY) || defined(FEATURE_SAINSMART_I2C_LCD) || defined(FEATURE_MIDAS_I2C_DISPLAY) || defined(FEATURE_FABO_LCD_PCF8574_DISPLAY)
                                #define FEATURE_LCD_DISPLAY
#endif

Y esta otra:

#if defined(FEATURE_ADAFRUIT_I2C_LCD) || defined(FEATURE_YOURDUINO_I2C_LCD) || defined(FEATURE_RFROBOT_I2C_DISPLAY) || defined(FEATURE_YWROBOT_I2C_DISPLAY) || defined(FEATURE_SAINSMART_I2C_LCD) || defined(FEATURE_MIDAS_I2C_DISPLAY) || defined(FEATURE_FABO_LCD_PCF8574_DISPLAY)
                                       #define FEATURE_I2C_LCD
#endif

Ahora habría que hacer un seguimiento para ver dónde se produce el conflicto.

Como he apuntado anteriormente, utilizando el bus de 4 bit se eluden estos problemas. La solución para poder trabajar con seguridad con un display I2C sería desconectar las salidas (lcd.print)  de la librería k3ngdisplay y trabajar con instrucciones propias. Pero eso puede ser tambiñen complicado. El bus de 4 bit elimina todos los estos problemas.

Comment is free, but facts are sacred. (C.P.Scott)
http://www.enioea2hw.wordpress.com

ResponderCitar
EC4AGT
Mensajes: 164
16 enero, 2020 23:02     #342111

Hola 

Y este bus de 4 bit que has hecho se puede comprar ? Sé que no es complicado pero si hay ya un módulo hecho no me complicaría las cosas 

EC4AGT
Wojtek
73

ResponderCitar
EA2J
 EA2J
Mensajes: 2334
17 enero, 2020 08:38     #342122

 El bus de 4 bit es el puerto de comunicación estándar de los visualizadores (displays) de 2 o cuatro líneas. La ventaja es que la librería de comunicación está incluida por defecto en el IDE del Arduino. La desventaja es que necesita 8 hilos para conectar (Vdd, Vss, RS, E, y 4 entradas digitales).

K3NG en el fichero que crea el objeto k3ngdisplay.cpp carga la librería estándar LyquidCristal.h que no te va a dar problemas. Hay que activar (descomentar) la característica "feature" #define FEATURE_4_BIT_LCD_DISPLAY en el fichero rotator_features.h

#ifdef FEATURE_4_BIT_LCD_DISPLAY
#include <LiquidCrystal.h>
                       LiquidCrystal lcd(lcd_4_bit_rs_pin, lcd_4_bit_enable_pin, lcd_4_bit_d4_pin, lcd_4_bit_d5_pin, lcd_4_bit_d6_pin, lcd_4_bit_d7_pin);
#endif // FEATURE_4_BIT_LCD_DISPLAY

El puerto I2C para estos displays es una placa que se suelda (a veces ya viene soldada) y es un conversor serie/paralelo que utiliza solo cuatro cables (Vss, Vdd, SCL y SDA). Esa es la ventaja. El inconveniente es que hay varias librerías con características diferentes. Como no tienes control sobre las librerías que utiliza k3ng, pueden surgir conflictos.

En el UNO y NANO los pines del I2C son los mismops A4=SDA y A5=SCL, se pueden conectar varios dispositivos I2C al mismo puerto. UNO trae un puerto suplementario en los pines 27=SDA y 28=SCL. Estos pis son los primeros en la línea antes de AREF

El circuito que he diseñado no tiene componentes activos sólo enruta los terminales e incluye el potenciómetro de contraste y una pequeña resistencia para la alimentación de la luz de fondo. Esto no hace más que simplificar el montaje con tres terminales Molex KK254, uno de cuatro para el bus, otro de dos para la alimentación y un tercero para RS y E. Este circuito se puede utilizar con cualquier propósito cuando se alimenta el display con el bus de 4 bit.

Finalmente hay que definir correctamente los pines asignados en rotator_pins.h

//classic 4 bit LCD pins
#define lcd_4_bit_rs_pin 12                          
#define lcd_4_bit_enable_pin 11                    
#define lcd_4_bit_d4_pin 10                             
#define lcd_4_bit_d5_pin 9                       
#define lcd_4_bit_d6_pin 8                        
#define lcd_4_bit_d7_pin 7                           

Esta publicación fue modificada hace 3 meses por EA2J

Comment is free, but facts are sacred. (C.P.Scott)
http://www.enioea2hw.wordpress.com

ResponderCitar
EC4AGT
Mensajes: 164
17 enero, 2020 19:11     #342148

Ok , gracias por responder y aclararme los problemas que pueden surgir. Finalmente voy hacer una placa igual como la tuya. Espero que este fin de semana podre seguir con las pruebas. Lo único que quiero activar es una salida para el freno , salida de reles cambiar por PWM y añadir una entrada para pulsador SW del encoder rotativo del mando

 

Gracias 

73

Wojtek

EC4AGT 

EC4AGT
Wojtek
73

ResponderCitar
EA2J
 EA2J
Mensajes: 2334
19 enero, 2020 10:57     #342201

Bueno, la salida del freno supone un relé más y calcular la alimentación del activador del freno, tanto el freno, el secuenciador se puede ajustar en el software, así como las salidas PWM para la velocidad de arranque y parada. No he trabajado nunca con estos parámetros, pero no lo veo difícil para ajustar. Cada paso se puede probar en la mesa de operaciones.

He terminado el módulo de relés, he seleccionado un UDN2981AT, este circuito, como sabes, puede manejar hasta 8 relés así que te sobra para los dos relés de dirección mas el freno.

He seleccionado relés Finder de la serie 41.61 a 12V. Tienen los dos circuitos del secundario conectados internamente en paralelo y aguantan hasta 16Amp. Están sobredimensionados para el consumo del motor (Max.30Vac y 500mA), pero también conoces el aforismo "caballo grande ande o no ande", aunque para el freno pueden ser necesarios.

Para el motor podrías utilizar perfectamente la 31 de Finder o los módulos (baratos) de relés para Arduino.

 

 modulo reles esquema

Comment is free, but facts are sacred. (C.P.Scott)
http://www.enioea2hw.wordpress.com

ResponderCitar
Página 1 / 2

QDURE - https://qsl.ure.es


Imprime y confirma tus QSL en tan solo tres click.

Nunca fue tan fácil y cómodo
el confirmar tus contactos.

TIENDA ONLINE URE


Publicaciones, mapas, polos, camisetas, gorras, tazas, forros polares y mucho más...

EA4URE-5 - DX CLUSTER


Recibe en tiempo real las estaciones activas en las bandas de radioaficionado

Utilizamos cookies propias y de terceros, analizando sus hábitos de navegación en nuestra página web, con la finalidad de garantizar la calidad, seguridad y mejora de los servicios ofrecidos a través de la misma.

CONFIGURACIONES DE PRIVACIDAD GUARDADAS!
Configuración de Cookies

Desde aquí podrás configurar las cookies propias y de terceros, y modificar parámetros que afectarán directamente a tu experiencia de navegación en esta web.

Estas cookies son importantes para darte acceso seguro a zonas con información personal o para reconocerte cuando inicias sesión. Activadas por defecto.


Estas cookies son necesarias para que la página web funcione, por lo que no se pueden desactivar. Por lo general, solo se configuran en respuesta a sus acciones realizadas al solicitar servicios, como establecer sus preferencias de privacidad, iniciar sesión o completar formularios, en ningún caso almacenan información de identificación personal. En caso de que configure su navegador para bloquear estas cookies, la página web no funcionaría correctamente.

  • wordpress_test_cookie
  • wordpress_logged_in_
  • wordpress_sec

RECHAZAR TODAS
ACEPTAR TODAS