Publicidad Google grande + Astroradio
URE foro pequeñas
Proyecto decodifica...
 
Notificaciones
Limpiar todo

Proyecto decodificador de bandas universal.

Página 2 / 2
EA2J
 EA2J
Mensajes: 3764
#367381  - 20 septiembre, 2021 16:41 

No es ninguna tontería, eso es precisamente lo que hay que hacer José Angel, el problema es que para analizar un dato (cada uno) hay que recogerlo en un array y hay que verificar la integridad y, después, decides si utilizas el dato no. Pero el proceso de identificar y filtrar recarga el trabajo. Si colocas más más condiciones añades trabajo. Por ejemplo, el byte 2 tiene que tener la dirección del Icom 0x94, el byte 3 la del control 0x0E o 0x00, el byte 4 el comando que debe ser 0x03 si es respuesta a una demanda o 0x00 si es producto de Transceive. Además de comprobar que comienza con 0xFE.

He estado probando el comportamiento del Icom y siempre que el último byte es un 0xFD, el frame está completo. Por esto he limitado a solo dos condiiciones para dar por válido los datos, que la posición 10 sea un 0xFD y que la posición 4 sea un 0x03 o un 0x00. y parece que funciona a cualquier velocidad de dial. Claro que se puede aumentar el nivel de seguridad, probablemente con un procesador más rápido o con un buffer mayor.

Solo me interesa la frecuencia en KHz y número entero, procesar otro formato sería recargar el proceso, la salida a display si se trabaja con Strings retarda más todavía.

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA2J
 EA2J
Mensajes: 3764
#367382  - 20 septiembre, 2021 17:08 

yo creo que ya va por el buen camino, pero tengo que leerme el asunto con más calma y ver si se puede leer el comando, o la cabecera sin decodificar la entrada completa [ nunca he programado nada usando CAT, asi que la respuesta es general ]. De ser así se podrían descartar los frames completos si pertenecen al comando x y llegan con < n milisegundos de diferencia. 

Ahora recuerdo que en los foros de Elad ya apuntaba uno de los desarrolladores que Arduino podría no tener memoria suficiente para mantener y leer el estado de la radio al operar el VFO, cuando alguien preguntaba para hacer una consola externa.

Una buena opción Luis, pero no he tenido más remedio que descartarla. En un par de foros de desarrolladores mencionan desbordamiento del buffer por el cuello de botella que se crean con algunos procesos.

Pero la única forma que he encontrado de leer los datos de salida por el puerto serie es la función SerialPort.read (); La frame empieza con 0xFE y termina con 0xFD. Pero el comando frecuencia es 0x03 cuando es un envío en modo transceive y 0x00 cuando es una respuesta. 0x03 y 0x00 son números que se pueden repetir en muchas posiciones diferentes y solo los puede relacionar con un comendo cuando están en posición 4. Por lo tanto, no tienes más remedio que contar y contar desde 0 a partir del siguiente desde que recibes el único comando potable para identificar una frame, que 0xFD y si no lo has guardado en un array, lo has perdido, por lo tanto estás obligado a:

Seleccionar el frame completo en un array, los 11 bytes, de la posición 0 a la posición 10. Un proceso

Verificar que la longitud es de 11 bytes, otro proceso

Verificar que el byte que identifica el comando es 0x03 o 0x00, otro más

Esto es lo mínimo y tienes que hacerlo siempre, con todos los frames porque no hay forma de saber si el buffer está lleno, vacío o semilleno, por lo tanto tienes transformar los 5 bytes de datos en valores decimales para extraer la frecuencia y luego procesarla, es decir, sacarla a pantalla, identificar la banda, comprobar si ha habido cambio de banda y, si es así, seleccionar la antena y activarla.

Si utilizas un mCU lentorro como el ATmega2560 o el ATmega328, cuando el operador maneja el dual de forma suave funcionará muy bien, sin problemas. Pero si el Icom envía demasiados datos se desbordará el buffer a menos que se haya pues un cuidado exquisito en aligerar los procesos básicos.

image

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EC5APB reaccionó
EA3FNM
Mensajes: 1701
#367383  - 20 septiembre, 2021 17:31 

Igual tienes que usar dos Arduinos, uno para gestionar el CI-V y otro para el resto?

EA3FNM
ex-ec3ccq
Pedro
Barcelona
ea3fnm@gmail.com

ResponderCitar
EA2J
 EA2J
Mensajes: 3764
#367394  - 20 septiembre, 2021 20:15 

Gracias por la aportación Pedro, no es posible hacerlo así. Bueno, tampoco es un problema porque más o menos está resuelto. Y si no es posible hacerlo con un Arduino Mega, se podría hacer con un DSP32, que cuesta menos de 5 euros y es más pequeño y mucho más rápido. Lo traigo al foro por tres razones. La primera porque sé que ha colegas interesados por el tema y deseo crear inquietud por el conocimiento que no es tan complejo como parece. El segundo porque sé que hay colegas que tienen una buena formación en codificar software y me encantaría conocer sus opiniones o experiencias aunque se lo difícil que un coder con experiencia tenga tiempo para jugar y, por otra parte es difícil encontrar programadores jubilados como yo que no aborrezcan lo que un día fue su trabajo. El tercero es porque simplemente me gusta compartir las experiencias y descubrir un tema que no está publicado es un aliciente.

Veamos Pedro, me alegro que traigas el tema. Las posibilidades de hacer programas para el cuarto de radio es compleja y limitada. Lo más complejo, desde un punto de vista operativo es un sistema CAT que, por otra parte, hay programas incluso gratuitos que lo han resuelto. Personalmente utilizo Omnirig pero hay otros y detrás de cada logger hay uno. Pero también controlar algunos aspectos de un equipo en remoto es una posibilidad que están tal alcance de la mano como montar un kit de un QRP monobanda.

Sin embargo, una de las razones de estar en la radio de muchos colegas es cacharrear, investigar, diseñar y montar dispositivos o simplemente conocer el funcionamiento de los cacharros que sobamos.

Los radioaficionados, para bien o para mal, según se mire, hemos superado la era analógica y cualquier carroza como yo utiliza, al menos, un sistema de comunicación entre el PC y los equipos. La mayoría de los que sobamos los equipos conocemos más o menos cómo funcionan incluso SDR, FPGA, GPU, GNU, DSP, ADC etc  no nos suenan a chino porque son componentes cercanos. Pues buen, el programa que los mueve también debería ser algo cercano. Muchas veces no nos planteamos abrir la mente a nuevos conocimientos porque nos asusta la complejidad, pero no es así. Si cualquier carcamal de 80 años recién cumplidos es capaz de digerir un proceso de comunicación entre máquinas, cualquiera puede hacerlo mejor.

 

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA3SE y EC5APB reaccionaron
EA2J
 EA2J
Mensajes: 3764
#367951  - 5 octubre, 2021 15:25 

Bueno... sigo con el proyecto. Contesto a José Angel. No es necesario vaciar el buffer, se vacía solo con las lecturas Serial1.read(). En realidad he aprendido algo, lo que enlentecía el proceso después de la lectura es la velocidad de salida de datos al monitor serie. Para monitorizar el comportamiento del flujo de datos, teniendo en cuenta las diferentes velocidades y los cambios del volumen de datos que entrega el Icom es necesario que el debugger no cargue el proceso y eso precisamente es lo que estaba haciendo el Monitor Serie a justado a 9600 baudios. Es un error mío que cito para que otros (principiantes) lo tengan en cuenta, al fin y al cabo me confieso principiante en los procesos de lecturas del puerto seerie aunque en mi descargo puedo declarar que nadie lo ha puesto por escrito, al menos donde he hurgado. He ajustado la salida al monitor serie a 115.200 baudios y mano de santo el programa funciona como un Stradivarius.

Lo cierto es que he dudado para estableces la estrategia del programa. Los programadores experimentados en comunicación entre máquinas vía Serie, recomiendan aislar cada trama leyendo los bytes del preludio y el byte final tomando el control de lectura mediante un bucle independiente del loop() bien incrustado en el loop() o en una función externa. Al final he llegado a la conclusión de que es más cómodo dejar el control al loop() a la espera de ver cómo se comporta con la lectura de eventos y el proceso consiguiente, por otra parte, los tres o cuatro proyectos que he consultado, incluido el programa de RemoteQTH hacen lo mismo. 

Ya he terminado el proceso de lectura y el decodificador de frecuencia y, monitorizando las tramas leídas, da un 0% de errores manejando el dial a diferentes velocidades. Me ha quedado un código elegante con muy pocas líneas en el loop().

He añadido al programa una funcionalidad interesante para el IC-7300, no sé si servirá o será necesario en otros equipos. He escrito una función que cada vez que se enciende el decodificador, toma los datos del tiempo (fecha y hora) de un RTC DS3132 que he añadido a la placa y con estos datos pone en hora el reloj interno del IC-7300 corrigiendo la chapuza de los ingenieros de Icom. No he encontrado que nadie utilice un mCU con un RTC externo para poner en hora el reloj, más bien he leído trabajo de algunos colegas que lo hacen desde el PC vía USB programando en Python o mediante scripts.

Esta tarde me voy a dedicar a pulir el código y subirlo al repo de GitHub. Suerte chavales. 

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA2J
 EA2J
Mensajes: 3764
#368151  - 13 octubre, 2021 15:14 

Bueno... por fin he terminado la parte del decodificador de frecuencia CIV. Funciona como un violín, he hecho recuento de tramas fallidas y da el 0%, tengo el dial del Icom y el dial del display del prototipo y, salvo la velocidad de refresco que ofrece una pantalla matricial de 4€ alimentada por el puerto I2C, funcionan exactamente igual.

He terminado la decodificación de bandas y el programa identifica las 10 bandas de HF, incluidos los 60m más la de 6m. He añadido unas funciones que permiten asignar las salidas de los relés (8) a las antenas correspondientes en función de la banda de trabajo. Leyendo las salidas en el monitor del puerto serie funcionan OK.

Además, ajusta la fecha y la hora del reloj interno del IC-7300, leyendo la hora de un RTC DS3231 externo. Todo el código está está escrito en C++ de acuerdo con los patrones del código ágil.

El programa está a falta de implementar el reloj dual (hora local y UTC) cuyo código ya he publicado, incluyendo un algoritmo que actualiza la hora de invierno y verano y añadir un lector de eventos que maneje la selección manual de antena con tres botones, uno para seleccionar el modo y dos para ir hacia adelante y atrás, otro evento para poner en hora el reloj con un botón para seleccionar el modo y los dos anteriores para avanzar y retroceder el tiempo.

He subido el código a mi repo en GitHub https://github.com/argulab/band_decoder/tree/main/decoder_CIV

Edit: Corregir enlace GitHub

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EC5APB y EA6763URE reaccionaron
EA2J
 EA2J
Mensajes: 3764
#369149  - 9 noviembre, 2021 21:19 

Sigo progresando con el proyecto y comparto porque aunque hay poca participación abierta en el foro, recibo algunos correos y me consta que hay algunos colegas que lo siguen.

En este momento estos trabajando con el hard con un nuevo display TFT de 2.8'' con comunicación por puerto SPI. Esta pantalla aporta sobre la matricial 2004 una mayor claridad en la visión, los colores y la posibilidad de cambian fuentes. He dispuesto tres cajas, la central en letra grando es el reloj con hora local, La caja superior, la fecha y debajo la hora UTC y la caja inferior es para la frecuencia, la antena activa y el estado del acoplador remoto.

No ha sido difícil programar la tarjeta que tiene un librería con muchas posibilidades, la ventaja es la velocidad de transferencia de datos gracias al puerto SPI, he tenido que añadir un conversor de nivel lógico con un modulito con cuatro BSS138, para adaptar la tensión TTL del Arduino a la de la pantalla TFT de 3.3V. Funciona muy bien.

El Software está prácticamente terminado y funciona como la seda. Me he decidido por la opción de "polling" con una latencia de 500ms, funciona mejor y me he despreocupado del ajuste del modo transceive. Únicamente he tenido que añadir una condición excluyente en el byte 6, pues al leer la solicitud de la frecuencia el array de lectura que en el byte 10 de la trama tenía el fin de trama 0xFD y también en el byte 6. Podría haber vaciado el array después de cada lectura pero pienso que era más lento que una cláusula excluyente en la función de decodificación del array.

Ahora el dial va a la misma velocidad que el del Icom. Ahora estoy trabajando en optimizar el modo manual de cambio de antena. Cuando lo termine subiré el código al reservorio de GitHub.

Os animo a experimentar con programación para Arduino, os aseguro que es divertido.

1636488057464

 La caja inferior contiene el mando del rotor de antena. Lo primero que voy a hacer en cuanto termine este proyecto es cambiar el display del mando.

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA7BD, EC5APB y EA6OK reaccionaron
EA2J
 EA2J
Mensajes: 3764
#369169  - 10 noviembre, 2021 08:58 

He releído lo que he escrito y puede que haya algo confuso. La lectura de cada trama con la información se almacena en un array de 11 bytes para la posterior decodificación, cada byte, en su posición, contiene información en posiciones fijas. excepto en los cinco bytes, entre el 5 y el 10 que contiene la frecuencia empaquetada en forma BCD. 

El problema es que cada vez que se pide la frecuencia en el modo "polling", el protocolo CI-V devuelve un eco de la petición que es una trama de seis bytes que termina con un final de trama 0xFD. Como no se ha vaciado el array y los bytes del preludio 0xFE 0xFE y el comando 0x03 son los mismos, si no se aplica una cláusula excluyente que prevea esta situación, la lectura de la frecuencia será errónea.

Para evitar esta situación, la forma ideal sería vaciar el array tras cada lectura, pero esto implica incrementar el tiempo de proceso y lo complica, por otra parte C++ no tiene funciones nativas para manejar arrays dinámicos, por esto he necesitado añadir una condición en la que si el byte 6 (5 en el orden de 0 a 10) contiene el byte 0xFD no lo procesa.

 

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA2J
 EA2J
Mensajes: 3764
#369917  - 26 noviembre, 2021 19:28 

Bueno... esta vez no voy a decir que progreso sino todo lo contrario. El programa ha llegado a un punto de complejidad que necesita una escritura de código más estructurada. Las posibilidades de C++ son enormes y he descubierto que el concepto de objetos es una forma de mejorar la comprensión del código porque proporciona una encapsulación mayor. Por esta razón he preferido mejorar el conocimiento de las posibilidades del lenguaje y estoy reescribiendo el código orientado a clases con los métodos correspondientes. Es una evolución de una mentalidad procedural a una mentalidad más moderna y eficiente orientada a los objetos, para ello he creado tres clases, la clase reloj, la clase radio y la clase display.

Lo cierto es que el programa lo tengo casi acabado y esto me permite aprovechar mucho código, y también es cierto cierto que es un reto para progresar sobre todo de forma autodidacta porque no encuentro nadie con el nivel necesario apara aprender.

Ya me gustaría encontrar otros colegas que se interesen por mejorar sus métodos de programación en C++ para compartir las experiencias. Espero subir en breve a Github una versión actualizada aunque sea del reloj. Tampoco estoy seguro de que vaya a poder seguir compartiendo experiencias en este foro, pero seguro que seguiré haciéndolo en mi blog.

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA2J
 EA2J
Mensajes: 3764
#369919  - 26 noviembre, 2021 19:46 

A continuación un ejemplo del método de la clase Reloj para detectar el cambio automático del horario de invierno y verano:

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.

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA2J
 EA2J
Mensajes: 3764
#371291  - 5 enero, 2022 10:57 

Bueno... ya puedo dar por concluido el trabajo. He reescrito todo el código utilizando clases, aplicando métodos y me he pegado con el buffer del Icom. 

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.

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA5NK, EA3FNM y EA3SE reaccionaron
EA1CN
Mensajes: 4250
#371293  - 5 enero, 2022 11:46 

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.

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.

73. Diego

ResponderCitar
EA3FNM
Mensajes: 1701
#371296  - 5 enero, 2022 16:19 

@ea2j

[Pero no sé que interés puede tener para el conjunto de los radioaficionados.]

A mi si me interesaría 😀 👍 

EA3FNM
ex-ec3ccq
Pedro
Barcelona
ea3fnm@gmail.com

ResponderCitar
EA2J
 EA2J
Mensajes: 3764
#371301  - 5 enero, 2022 16:29 

Gracias por el comentario Diego. Hoy en día, la mayor parte de los radioaficionados activos utilizamos sistema de CAT para comunicar el equipo de radio con el PC, incluso muchos utilizamos dos pantallas. Cuando el cuaderno de registros de QSOs (¿Te acuerdas cuando le llamábamos cuaderno de guardia?) añade un comunicado, el libro lo guarda y sus datos están a disposición del software para ser procesados. En realidad el equipo de radio ha entablado una conversación con el PC preguntándole los datos más significativos como la frecuencia, el modo, la fecha y la hora. También le ha pedido a una base de datos en Internet la información que disponga del corresponsal.

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

libro guardia

árido.

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA1CN
Mensajes: 4250
#371306  - 5 enero, 2022 17:47 

Sí, sí, es cierto, Enio. Yo usé ese Libro de Guardia, el antiguo de URE y otro que tenían así monísimo con tapitas de plástico y uno de publi de Yaesu. Hasta que un listo de alumno del instituto, de informática, me hizo uno en MS-DOS, de cuando el DRDOS.

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!.

73. Diego

ResponderCitar
EA2J
 EA2J
Mensajes: 3764
#371802  - 17 enero, 2022 19:48 

He dado por terminado la escritura del programa de control con las siguientes características:

- 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????

consola rotor

 

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EA2AGV, EA2AFF, EA3SE y 1 personas más reaccionaron
EC4AGT
Mensajes: 235
#371821  - 18 enero, 2022 13:05 

Buenos días Enio

 

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 

EC4AGT

Wojtek

73

ResponderCitar
EA2J
 EA2J
Mensajes: 3764
#371823  - 18 enero, 2022 13:14 

Tal como está terminado el proyecto, está programado para controlar dos antenas, sin embargo, el hardware está preparado para controlar hasta 8 antenas, sólo es cuestión de modificar algo el código para que controle las que hagan falta hasta 8. El límite lo pone el driver que es un UDN 2981. Tanto el driver como las salidas ya están preparados, la programación inicializa (prepara) las 8 I/O que activan el driver solo es necesario modicar los estados de las salidas en función de las antenas conectadas.

La cultura del esfuerzo se cultiva desde la motivación, no mediante el castigo como algunos quisieran.
http://www.enioea2hw.wordpress.com
73, Enio

ResponderCitar
Inició el tema
EC4AGT
Mensajes: 235
#371825  - 18 enero, 2022 13:22 

Hola

 

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 

EC4AGT

Wojtek

73

ResponderCitar
Página 2 / 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...

WEBCLUSTER EA4URE


Conoce el nuevo WebCluster de URE, ahora con nuevos filtros e información y compatible con GDURE