Yo, como sabes no domino la programación de Arduino. En principio cin dos antenas tengo suficiente. Ojalá, podría tener más terreno para montar las antenas que deseó.

Era para aprovechar el comutador.

Un saludo y gracias de nuevo 

Gracias por Tu trabajo y tus horas invertidas en este proyecto. Cuando yo termine el mio Te comentaré como funciona.

Un saludo cordial 

PS puedes explicar qué quiere decir que controla dos antenas? No puede más? Lo digo porque yo tengo un computador para 5 antenas 

- Funciona para un IC-7300

- Controla dos antenas

- Activa y desactiva el ATU remoto para la antena de bandas bajas

- La pantalla es TFT y proporciona las siguientes informaciones.

-- Radio activa o inactiva

-- Frecuencia de trabajo

-- Banda de trabajo

-- Límites de frecuencia (Out bounds)

-- Modo de antena, automático y manual

-- Antena activa

-- ATU remoto activado y desactivado

Reloj

- Fecha y día e la semana

- Hora UTC.

- Hora local HH:MM:SS

El programa es estable y llevo una semana sin detectar bugs.

Respecto al código está escrito en C++ con la metodología de clases, 

Decoder_11.ino  (versión 11 fichero principal setup () y loop ())

Display.h y Display.cpp (Clase y métodos para la salida de daos en la pantalla)

Buttons.h y Buttons.cpp (Clase y métodos el control de los cuatro pulsadores - mando antena manual y puesta en hora del reloj)

Radio.h y Radio.cpp (Clase y métodos para el control de la radio y antenas)

Watch.h y Watch.cpp (Clase y métodos para el reloj) 

El código se puede ver y descargar del repositorio https://github.com/argulab/CI_V-control-with-Arduino/tree/master/decoder_11

En conjunto estoy satisfecho relativamente. No he conseguido que funcione el cambio automático del modo transceive a OFF ni el ajuste de la hora y fecha interna de Icom. -Ya sé que hay una aplicación de Icom, pero es sencillo programar la orden de ajuste automático. Icom lee la instrucci`´on y responde con un FB, pero no lo aplica. Es una tarea pendiente que no afecta al funcionamiento del programa: No he encontrado información y será cuestión de experimentar pero está, sin duda en relación con el comportamiento del buffer. En realidad pouedo monitorear el funcionamiento del buffer pero no encuentro explicación al comportamiento.

En realidad sí funciona si reseteo el Arduino con el Icom encendido pero debería funcionar siempre. Estoy cansado y seguiré, encualquier caso el programa funciona estable.

Lo cierto es que es difícil llevar a cabo un proyecto solo, no es lo mismo que hacer un kit, es necesario aprender diseño, electrónica y programación. Para hacer este proyecto he tenido que aprender a manejar Qcad (CAD en 2 dimensiones) FreeCad (Diseño para impresora 3D -carátulas etc), diseño de circuitos impresos, Conocer a fondo un sistema CAT y rebobinar y volver a aprender una nueva forma de programar con clases que no es una forma frecuente en Arduino.

En cualquier caso he terminado tan cansado que acabo de iniciar un nuevo proyecto. Una consola para un rotor G450C pero esta vez con código propio y con comunicación vía serie con el protocolo Yaesu y un preselector con un encoder. El hardware ya está terminado, montado y ha pasado la prueba del humo. ¿Alguien se apunta????

Bueno, ahora que lo dices, recuerdo que el primer equipo que tuve, creo que fue el YAESU-747, traía un tocho al final de los comandos CAT que era un demonio de entender. Supongo que para eso mismo que tú mencionas en tu post. Claro que no sé como conseguí (supongo que de ASTEC-YAESU) un programita que, bajo MS-DOS usaba el CAT, supongo que por RS-232, supongo, insisto. Entonces yo sí entendía de esas cosas. Ya menos o nada.

Bueno, en definitiva Enio, todo está en ponerse y lanzarlo, que del dominio de nuestro entender ya damos cuenta nosotros mismos. HI

Pero tú date cuenta de algunos artículos que aparecen en URE en plan fórmulas, vectores y gráficas. ¿Quién los lee o ve con detenimiento? Pues algunos habrá, sin duda, y con eso puede ser suficiente. 

Yo me acuerdo de un artículo de mi amigo Lluis, EA3OG (con el que coincidí mucho tiempo en CQ Radio Amateur) sobre el funcionamiento de las antenas direccionales, lleno de vectores (Fresnel) que me lo empapé y le saqué punta hasta extremos por mí sorpresivos.

Pues igual, ¡Dale!.

Al margen de lo que cada uno opinemos sobre el uso de estos recursos, personalmente, es un alivio para el trabajo de oficina que hacía al margen de la radio, aunque a muchos les guste y consideren que es una parta de hacer radio.

Pues bien, el cómo se comunica la radio con el software, qué hace, qué opciones existen son aspectos que aunque no los acabemos de entender son una parte de la actividad de muchos colegas que quizá pudieran tener algún interés en conocer desde un punto de vista de divulgación oi de aproximación.

El problema es que una charla sobre este tema puede quedarse en algo insulso o ser un ladrillo de plomo lo difícil es hacer ameno un tema tan

árido.

A mi si me interesaría 😀 👍 

Yo no tengo npi pero seguro que hay colegas que sí y siempre es interesante escuchar y ver (y si procede entender) lo que otros colegas investigan y estudian. Te animo a ello, Enio. Plas plas.

He sacado algunas conclusiones y he aprendido mogollón sobre programación en C++, una asignatura pendiente desde hace años y aunque me falta mucho para dominar el lenguaje, creo que la parte más básica de los recursos están ya bajo control.

El protocolo CI-V se diseñó en su día por Icom con el objetivo de controlar un receptor y un transmisor independientes para que actuaran como un transceptor.

El hecho de que toda la información viaje por un solo bus y el modo de trabajo en transceptor "transceive", anular el modo y solicitar la frecuencia "polling" evitando que el eco complique la lectura de los datos crean problemas que hay que resolver con un mCU de bajo rendimiento.

No hay mucha información en la red sobre CAD para equipos de radioaficionados, aunque haya buenos trabajos profesionales que ofrecen productos con alta tecnología, pero muy poca y no de mucha calidad para Arduino.

Quizá el objetivo de crear un dial externo que fuera tan suave como el del transceptor era un objetivo muy ambicioso para hacerlo con un Arduino, pero he conseguido una presentación fluida en el display con tiempos de polling de 200ms forzando los filtros de proceso ya que hay que descartar en principio el 50% de las tramas que envía el Icom. He fraccionado la lectura con dos métodos, colocando el filtro en el primero con lo que he ahorrado tiempos de computación y he aprendido, a base de crear funciones de depuración, que el tamaño de la trama de datos y el Byte final son suficientes para garantizar la lectura de las suficientes tramas como para que la lectura sea fluida en el dial durante el desplazamiento del VFO a cualquier velocidad.

La lectura profesional de un buffer requiere técnicas complejas de planificación como el método Round Robin, sin embargo, el objetivo principal de este trabajo es un sistema fiable de decodificación de una frecuencia para seleccionar automáticamente la antena adecuada. Yo lo he complicado un poco más para detectar posiciones de dial fuera de banda y he estado jugando con avisos sobre uso de frecuencias recomendadas para cada servicio aplicando el plan de bandas de la IRU, es factible, desde luego, que si te sitúas en la frecuencia de llamada de emergencias te avise el el display. De momento lo he dejado en un aviso de saluda de límites

Me gustaría compartir las experiencias de seis meses de trabajo, en los que ha aplicado como valor añadido el tipo de programación ágil y el enfoque más actual de las clases que permite C++. Quizá prepare una charla sobre los conceptos básicos o la aproximación a los sistemas de CAT. Pero no sé que interés puede tener para el conjunto de los radioaficionados.

uint16_t Reloj::spanish_timezone_offset(DateTime dt) {
uint8_t month = dt.month ();
uint8_t day = dt.day ();
uint8_t dow = dt.dayOfTheWeek ();
uint8_t hour = dt.hour ();
uint8_t lastDay = 24;
uint8_t hourOfChange = 3;
uint16_t summerOffset = 7200;
uint16_t winterOffset = 3600;

switch (month) {
case mar:
if (day <= lastDay) return winterOffset;
if (dow == sun) return (hour <= hourOfChange) ? winterOffset : summerOffset;
return winterOffset;

case oct:
if (day <= lastDay) return summerOffset;
if (dow == sun) return (hour <= hourOfChange) ? summerOffset : winterOffset;
return summerOffset;

default:
if (month > mar && month < oct) return summerOffset;
if (month < mar || month > oct) return winterOffset;
}
}

En primer lugar utilizo un switch que valora las tres posibilidades lógicas: la fecha procesada es marzo, octubre o el resto de los meses. Si es marzo u octubre, valora el día del mes teniendo en cuenta que el cambio horario se produce el último domingo de estos dos meses. La fecha más alta de estos meses de 31 días de que sea domingo es el 24 (lastDay), luego si la fecha es menor o igual, no hay cambio, eso se resuelve con una expresión excluyente, si el día es mayor que el 24, se resuelve con una condición igual a domingo y una expresión ternaria que valora la hora del cambio, las 2 horas local AM.

La librería es <RTClib> que proporciona el tiempo en segundos transcurrido desde una fecha fija (no recuerdo cual), a a cual se añaden 3600 segundo (una hora) en horario de invierno y 7200 segundo en horario de verano.