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

Proyecto decodificador de bandas universal.  

Página 1 / 2
  RSS
EA2J
 EA2J
Mensajes: 3308
19 julio, 2021 16:42     #364974

Me he embarcado en un nuevo proyecto que quizá tenga interés para alguien más. Se trata de un decodificador de bandas para los principales sistemas que utilizan los equipos comerciales, en especial el ACC y REMOTE (CI-V) de Icom, el BCD  de Yaesu y el CAT USB de otros equipos.

Desde un punto de vista de hardward acabo de diseñar un "shield" para la placa Mega 2560 PRO (compatible con Arduino ATmega2560). Esta placa dispone de E/S digitales suficientes y memoria de sobra para procesar cualquier sistema, por otra parte se trata de una placa de tamaño reducido en relación a la de Arduino MEGA. He dispuesto 8 salidas digitales para pilotar los relés de 8 antenas, 4 entradas digitales para el sistema BCD de Yaesu, dos entradas analógicas con resistencias para los divisores necesarios, salidas a 5V y 2 tomas para el puerto I2C (display o pantalla TFT) además de un puerto auxiliar Serie (RX/TX) para la entrada directa del conector REMOTE de Icom. No he encontrada nada diseñado así en la bibliografía internacional.

Acabo de encargar cinco placas de circuito impreso, así que me sobran tres. Me gustaría ir compartiendo la experiencia a medida que progrese.

El programa del decodificador para el ACC de Icom está ya resuelto, el mismo sistema se puede utilizar para el Yaesu FT817. El deco para el BCD de Yaesu está resuelto sobre el papel a falta de material para probarlo y ahora estoy pegándome con la entrada de CI-V.

La idea es que, a diferencia de un deco universal como el que utiliza RemoteQTH, se pueda montar cada uno un deco para cada equipo y para las antenas que necesite con un programa fácil de cargar y ajustar.

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

ResponderCitar
  EA6DT me gusta
EA2J
 EA2J
Mensajes: 3308
19 julio, 2021 16:45     #364975
image

El ansiaviva me ha vencido y he dejado de documentar algunas entradas en la seriegrafía, nada grave, es doble cara y me sale por menos de 2€ cada PCB. Las MEGA 2560 Pro se pueden encontrar sobre 10€ aunque hay ofertas chinas por unos 5€ para los pacientes.

El circuito integrado es un UDN 2981 que va muy bien para pilotar hasta 8 relés de hasta 50V y 500mA.

Dispone también de un acceso a 4 E/S digitales que se pueden utilizar con la programación adecuada para cuatro pulsadores o para una salida BCD con el objeto de pilotar un accesorio compatible con este protocolo.

Esta publicación fue modificada hace 4 meses 3 veces por EA2J

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

ResponderCitar
  EA6DT y EA3SE me gusta
EA5TV
Mensajes: 788
19 julio, 2021 19:02     #364980

Muy interesante, pero me pregunto si para los Yaesu que no tienen implementada de fabrica los 60 m servirá. Lo digo porque veo las entradas del BCD, pero segun tengo enetendido, la codificacion BCD para 60 m es la misma que para 40.

Saludos.

Rafa. EA5TV

Rafa. EA5TV. (Ex EA5BFX)
GRUPO TORTUGAS CW
En radio desde 1979 y todavia sigo aprendiendo

ResponderCitar
  EA6DT me gusta
EA2J
 EA2J
Mensajes: 3308
20 julio, 2021 09:19     #365007

De momento he decidido la forma de decodificar en C++ una entrada BCD de 4bit, en realidad, Yaesu establece un código decimal de entre nueve y once posibilidades decimales expresada en un número binario de 4bit, numera las bandas de 0 en adelante, (0 para la más baja, 160m) y secuencialmente, hasta la más alta. Un código de 4bit permite codificar 16 elementos contados en base 10, así que hay espacios libres para que Yaesu adjudique un número a la banda de 60m si lo decide, pero si lo hace, será probablemente con equipos nuevos y no secuencialmente porque dejaría obsoletos a todos los decos actuales.

Es algo a estudiar, en este momento ya he probado una función que recibe el estado de cuatro entradas digitales y aplica la fórmula de conversión de números de base 2 a base 10. Una vez que tenemos la banda expresada en un número entero decimal, es fácil decodificar la banda en forma de cadena y activar el relé correspondiente a la antena que el usuario haya asignado a este relé dentro del código o con un front-end que habría que crear. De la misma forma cualquier número decimal se puede transformar en un número. C++, además, tiene un función matemática que cambia de base 10 a base 2.

El caso es que la placa de CI está preparada para recibir información de un número binario (con umbral de 2.6V y un máximo de 5V) de 4bit y aplicarlo en el sistema de E/S de un ATmega2460. El algoritmo de decodificación estará escrito en función de cómo se haya decodificado, es muy sencillo, y esto último depende de Yaesu únicamente, pero la ventaja es que se puede reprogramar fácilmente en el caso que Yaesu incluya los 60m en el código.

Una placa "shield" tiene esa función, servir de comunicación entre una placa de Arduino y los sensores y actuadores de un proyecto relacionado, en este caso entre el mayor número posible de equipos comerciales, un grupo de antenas y el o la operadora de la radio.

Edito, no he recogido todavía documentación relacionada con la aplicación del código BCD en los modelos de Yaesu, a priori, como especulación únicamente, creo que sería poco inteligente por parte de los ingenieros de Yaesu, aplicar el mismo número a dos bandas diferentes cuando tienen números libres. El método de codificación por tensión variable del ACC de Icom que inserta las bandas WARC entre el resto de bandas, adjudicando los 0V a los 30 y la misma tensión a los 17 que a los 15 y la de los 12 a la de los 10, tiene su explicación de no modificar el reparto de tensión entre 0 y 8V que ya estaba establecida, teniendo en cuenta, además que ya estaba implementado el protocolo CI-V que presenta la frecuencia con mayor precisión, incluida cualquier nueva banda, como la de 60m.

Como ejemplo, un equipo más moderno, el Yaesu FT817 tiene un sistema de codificación de banda por tensión variable que incluye las bandas WARC separadas en un conector de 8 pines. 

También hay que tener en cuenta que estos sistemas de codificación por tensión variable están destinadas a ser decodificados con sistema de filtrado de estado sólido. El uso de mCU cambia el paradigma.

Esta publicación fue modificada hace 4 meses por EA2J

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

ResponderCitar
  EA6DT, EA1CN, EA1TA y 1 les gusta
EA1TA
Mensajes: 461
20 julio, 2021 11:37     #365013

No paras, Enio... el siguiente proyecto? 

Apertas Manuel ea1ta

Esta publicación fue modificada hace 4 meses por EA1TA

Manuel Fafian
EB1DEY 1986
EC1AGR 1988
EA1TA 2007
La formulación de un problema, es más importante que su solución.

ResponderCitar
  EA6DT me gusta
EA2J
 EA2J
Mensajes: 3308
22 julio, 2021 15:55     #365104

He resideñado la placa de circuito impreso para añadir una entrada más digitalk para el pulsador de MODO, resistencias externas PullDown para las entradas digitales y he modificado los pines de entrada del puerto Serial 1, para hacerlo sobre el puerto hard del mCU. También he revisado la seriegrafía.

Gracias Javi por las correcciones.

image

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

ResponderCitar
  EA6DT, EA1CN y EA1TA me gusta
EA2J
 EA2J
Mensajes: 3308
24 julio, 2021 18:37     #365163

Bueno, ya he entendido el manejo del protocolo CIV, por lo menos decodificar modo y frecuencia, funciona y puede leer el modo y la frecuencia estoy trabajando en depurar la función. También estoy trabajando en el display y se me ha ocurrido una idea malvada:

Meter una base de datos con el plan de asignación de bandas de la IARU, esto es muy sencillo, cruzar la frecuencia de trabajo con el plan de bandas e indicar en un display con cuatro líneas la asignación del modo autorizado a la frecuencia e indicar automáticamente las recomendaciones de uso preferente o el centro de una actividad. Creo que no hay nada hecho por el estilo, sería algo original y útil para despistados, pero el curro de meter el plan de bandas es pesado necesitaría ayuda de alguien que se lo quisiera picar.

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

ResponderCitar
  EA6DT, EA1CN y EA1TA me gusta
EA2J
 EA2J
Mensajes: 3308
7 agosto, 2021 22:26     #365726

Bueno, por si alguien le interesa para compartir información. Ya tengo funcionando el dial del IC-7300 en un display mediante el protocolo CI-V, desde el conector [REMOTE]. Esto me permite saber en todo momento la frecuencia activa del equipo y seleccionar la antena correspondiente a la banda de trabajo. Y esto es parte del proyecto de un decodificador para diferentes equipos que espero publicar.

Lo cierto es que ha sido complicado, no tenía ni idea de cómo funciona el CI-V y realmente ha sido más complicado de lo que esperaba. Gracias a la ayuda de mi profe, Javier cuya paciencia he puesto a prueba. También me ha ayudado mucho el excelente trabajo de DF4OR, un clásico.

Lo más complicado para mí ha sido entender el funcionamiento del buffer que cuando se mueve el dial un poco rápido plantea un problema de lectura en especial porque los datos de RX y TX viajan por el mismo cable, por esta razón ha habido que enviar los datos de TX mediante un dispositivo de colector abierto que he resuelto con la ayuda de Javier con un par de 2N2222.

Otro planteamiento con dificultades ha sido entender la decodificación de la frecuencia que viene en cinco bytes HEX en formato BCD, complicado hasta que lo entiendes claro. Luego es cuando puedes decir: ¡está chupado!

Bueno, comparto esta información porque he tendido algunos correos preguntando por el proyecto.

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

ResponderCitar
  EA1TA, EA6DT, EA1CN y 1 les gusta
EA2J
 EA2J
Mensajes: 3308
10 agosto, 2021 18:33     #365834

Ya he terminado provisionalmente el diseño de la placa del circuito impreso del decodificar (lo dejo en plural en lugar de "universal"). Esta placa es un "shield" para la placa MEGA PRO clónica o compatible con la Arduino Mega puesto que lleva el mismo mCU. He escogido esta placa porque dispone de suficientes entradas y salidas, en especial tres puertos serie, además de memoria suficiente para soportar código sin demasiadas rrestricciones y capacidad de proceso de sobra.

Le he añadido a la versión tres una salida a colector abierto para el TX del puerto Serial1 con el fin de enviar comandos CI-V a un transceptor Icom (Gracias Javier), otra conexión Serial2 para probar una pantalla Nextion y otra toma SPI para pantalla o periféricos que utilizan este tipo de puerto serie, una entrada a 4 I/O digitales con resistencias PULLDOWN para la entrada BCD del codificador de Yaesu, así como un eventual pulsador sobre entrada digital con resistencia PULLDOWN y tres más sin resistencias con propósito general.

Los controles por CAT se pueden procesar a través de la entrada USB/URAT CH340.

Las salidas pueden controlar hasta seis antenas con relés de 12V con el CI UDN2981.

Ha quedado una placa que puede controlar con la programación correspondiente un conjunto de antenas con diferentes equipos. De momento el código para el sistema [ACC] de Arduino ya está comprobado y funcionando. El código para el control con CI-V está ya en marcha y a falta de pruebas.

Lo cierto es que está siendo un proyecto que cuesta pero muy satisfactorio que espero publicar en breve en mi web. Aprendizaje que ha sido posible gracias a la ayuda de Javier que me ha ayudado a pegarme con el buffer del Icom, a Josep que me ha hecho comprender desde un punto de vista matemático cómo se decodifica un sistema BCD embebido en un código Hexadecimal y que me ha permitido desarrollar un algoritmo de decodificación mixto por desplazamiento del nibble superior y por uso del módulo resto (%).

Si alguien tiene curiosidad ya sabe que me tiene en el correo o en mensajería aunque es más divertido en abierto.

image

 

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

ResponderCitar
  EA1TA, EA5NK, EA6DT y 1 les gusta
EA2J
 EA2J
Mensajes: 3308
15 septiembre, 2021 20:58     #367254

Aunque no veo respuestas en el foro sigo informando de los progresos con el trabajo. No sé si el tema despierta poco interés pero considero que experimentar y aprender los modos de comunicación entre máquinas y equipos es una parte de la radio aunque solo sea por culturilla.

Ya he terminado la placa shell, la he montado y funciona, por cierto, me sobran 4, si alguien las necesita basta con enviarme un sobre acolchado de tamaño carta estándar con la dirección puesta y los sellos necesarios. He terminado de escribir el texto y espero que se publique en la revista pronto.

Estoy progresando rápidamente en el manejo del protocolo CI-V con el Arduino y ya me puedo comunicar con los comandos, puedo recibir la frecuencia, el modo y el filtro y también puedo seleccionarlo desde la placa.

Ha sido muy interesante decodificar los datos empaquetados en modo BCD con formato hexadecimal, ha sido al principio lioso pero con la ayuda de Javi, EA1N ya manejo con soltura la decodificación por dos métodos. Lo cierto es que no he encontrado nada escrito en español y, aparte del excelente trabajo (un clásico)de DF4OR, no hay mucho escrito.

Un tema también que me interesa es una forma sencilla de ajustar la fecha y la hora del reloj interno del IC-7300, para ello he incluido un RTC DS3231 con cuyos datos ajustará el reloj interno, por lo menos una vez al día.

En este momento estoy trabajando en dar forma al sketch que decodificará la frecuencia del Icom, detectará la banda de trabajo y seleccionará la antena adecuada. Estou a vuestra disposición.

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

ResponderCitar
  EA1TA y EA3FNM me gusta
EA3FNM
Mensajes: 1397
15 septiembre, 2021 21:58     #367256

Buen trabajo Enio,

Yo si lo sigo ya que estos cacharros me apasionan.

Slts

EA3FNM
ex-ec3ccq
Pedro
Barcelona
ea3fnm@gmail.com

ResponderCitar
EA7BD
Mensajes: 56
17 septiembre, 2021 18:21     #367307

sigue adelante, que aunque no contestemos se que somos muchos  los interesados en ese invento, aunque a mi se me escapa de nivel, me parece de lo mas interesante sobre todo lo de actualizar el reloj de 7300, que me tiene loco.

ResponderCitar
EA2J
 EA2J
Mensajes: 3308
17 septiembre, 2021 19:00     #367310

Bueno... hay varios trabajo publicados para actualizar el reloj del IC-7300, el mío además, parece que la batería se ha estropeado porque pierde los datos de un día para otro. Los trabajos que he leído se basan en programación para el control vía USB, instrucciones desde una consola de Linux o en Python, el problema es que si el puerto USB está ocupado por el CAT, habría que habilitar otra vía. Desde el PC se puede utilizar el reloj interno del PC o un servidor NTP.

No es necesaria mucha precisión en el reloj interno, ya que no refleja la lectura de segundos aunque seguramente los cuenta en el proceso interno del RTC). Lo interesante es demostrar que se puede leer y ajustar desde un mCU vía puerto serie al conector [REMOTE] utilizando el protocolo CI-V.

Lo interesante es que esta utilidad se añadiera a un sistema CAT como OmniRig o RS-BA. Lo cierto es que ha sido divertido pues manejar la hora y la fecha del IC-7300 requiere un sistema complejo de gestión ya que utiliza un comando 0x1A y dos subcomandos empaquetados en tres bytes.

0xFE 0xFE 0x94 0x0E 0x1A 0x00 0x94 0x20 0x21 0x09 0x17 0xFD

Este frame pone la fecha de hoy en el reloj interno del IC-7300, donde

0xFE 0xFE es el inicio

0x94 es el destino, 0x94 es la dirección predeterminada del IC-7300

0x0E es la dirección del control (Arduino)

0x1A es el comando

0x00 0x94 es el subcomando de la fecha (0094)

0x20 0x21 0x09 0x17 (20210917) es el área de datos que ocupa 4 bytes empaquetados en modo BCD

0xFD es el final

Para solicitar que el equipo envíe la fecha al control, se envía el frame sin datos.

Funciona muy bien. En algún foro había leído que algún colega dudaba de que fuera posible utilizar una placa de Arduino utilizando el protocolo CI-V para ajustar la fecha y la hora del reloj interno. Está probado y funciona.

Todo está explicado en el manual

image

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

ResponderCitar
  EA3FNM me gusta
EA3FNM
Mensajes: 1397
17 septiembre, 2021 20:48     #367315

Si el comando CI-V está SI será posible y con el RTC resuelto 😀 

No se cuanto se va de madre el reloj pero igual hay que ponerle un refresco cada hora en punto,por ejemplo. Ahí lo dejo. 😉 

Otro tema sera, por ejemplo.yo no uso el usb sino el CI-V para el control del equipo. A ver como anda el tema colisiones. 

En un foro USA habian.desarrollado un "hub" ci-v pero a nivel fisico sin gestion de paquetes.

EA3FNM
ex-ec3ccq
Pedro
Barcelona
ea3fnm@gmail.com

ResponderCitar
EA2J
 EA2J
Mensajes: 3308
17 septiembre, 2021 21:31     #367319

El problema no es que el reloj interno del equipo sea impreciso, el problema es que Icom ha puesto una batería de respaldo de muy poca capacidad. Normalmente el RTC que tienen los equipos (y los PCs), cuando se desconecta la fuente de alimentación una batería se ocupa de mantener en marcha el reloj (Una batería recargable o una pila porque el consumo es insignificante). Pero la batería del IC-7300 tiene muy poca capacidad y si está más de un día sin conectar se agota y el RTC se resetea.

Para que mantenga el reloj bastaría con ajustar la hora cada vez que se pone en marcha. He escrito una función que extrae los datos del RTC del Arduino que tiene una buena batería. Crea un frame con la instrucción de ajuste y el tiempo real y la envía al equipo. 

Edito para añadir: El IC-7300 se comunica con una máquina de control (PC o mCU) a través de un puerto Serie directo [REMOTE] o con USB/UART. El Arduino se puede comunicar con el equipo vía [REMOTE] a puerto serie: en este caso, los datos circulan en ambos sentidos por el mismo cable que se conecta directamente a RX y con un dispositivo "open collector" a TX.

A través del puerto USB se puede conectar desde un PC, para esto bastaría con sistema de scrpit desde una consola o con un programa escrito en Python que puede enviar y recibir paquetes CI-V, el problema es que si el puerto está ocupado por el CAT habría que habilitar otra vía diferente.

Esta publicación fue modificada hace 2 meses por EA2J

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

ResponderCitar
EA2J
 EA2J
Mensajes: 3308
19 septiembre, 2021 20:44     #367360

A medida que voy avanzando en el desarrollo de un programa para decodificar algunos parámetros que se pueden controlar con una máquina voy entendiendo mejor el funcionamiento de la comunicación entre equipo y control. Uno de los problemas que se le plantean al programador es la diferencia de velocidad que hay entre la entrega de datos y la capacidad de proceso de la máquina. Normalmente hay un buffer que se encarga de equilibrar los procesos de salida y entrada, pero cuando el buffer se desborda hay pérdida de datos porque los paquetes se truncan o se pierden.

En el caso del IC-7300 y una placa de Arduino se da una circunstancia que probablemente será común a otras marcas o procedimientos. En el caso que describo, el equipo, un Icom IC-7300 transmite un frame de 11 bytes cada vez que el operador desplaza un Hz el díal. La estrategia del programador consiste en aislar el frame validar su utilidad como dato, decodificar los datos, utilizarlos para actuar sobre un selector de antena y presentarlos en un display.

Cuando el operador se desplaza de frecuencia unos pocos KHz y lo hace suavemente, no hay ningún problema, cualquier código se ejecuta sin problemas, pero si el operador gira el dial rápidamente y se desplaza unas decenas de KHz en poco tiempo, transmite una enorme cantidad de datos, por ejemplo, un desplazamiento de 100 KHz representan un MBy que el Icom entrega al control. Si el control funciona con ciclos de reloj de 16MHz el procesador podría procesar los datos sin problemas, pero cada frame debe soportar una veintena de instrucciones de cálculo y manejo que hacen que la digestión de los datos sea más lenta que la alimentación del equipos y al final el buffer se llena y se desborda provocando pérdida de datos.

He tenido la oportunidad de probar este fenómeno y de crear un algoritmo de proceso capaz de "digerir" los datos evitando que el buffer se desborde. He revisado la literatura sobre cómo procesar los datos de un CAT y no he encontrado nada al respecto. Incluso un programa de referencia de un kit con código abierto, decodifica los datos con un programa más "pesado" que que utilizaba al principio. Habría que ver cómo responde a los desplazamientos rápidos de dial.

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

ResponderCitar
  EA1TA me gusta
EA6763URE
Mensajes: 51
19 septiembre, 2021 22:41     #367364
Publicado por: @ea2j

He revisado la literatura sobre cómo procesar los datos de un CAT y no he encontrado nada al respecto. Incluso un programa de referencia de un kit con código abierto, decodifica los datos con un programa más "pesado" que que utilizaba al principio. Habría que ver cómo responde a los desplazamientos rápidos de dial.

En principio entiendo no interesan las frecuencias intermedias en un movimiento rápido de la perilla del VFO.

A bote pronto con ir leyendo mientras siga recibiendo la instrucción de cambio de frecuencia e ir truncando tu buffer cuando llenes su tamaño (evento que podrías usar para actualizar feedback, si procede), y una vez parado, tratarlo como una pila LIFO para recuperar la última frecuencia. debería ser suficiente.

 

Luis. EA4HNL

ResponderCitar
EA2J
 EA2J
Mensajes: 3308
20 septiembre, 2021 11:05     #367368

Gracias por participar Luis.

Es una idea, pero no puedes dejar de procesar las frecuencias intermedias porque no puedes controlar la velocidad imprime el operador al VFO. Provoco una interrupción para enviar el control de flujo a una función externa al loop para evitar que la lectura de eventos que completan el programa añadan "peso" al proceso, pero no puedes dejar de procesar cada lectura, ni siquiera puedes recuperar un error. Bueno... por lo menos esto es lo que he calculado salvo mejor medida.

Ya he intentado transfiriendo todo el paquete que envía el Icom a un array para procesar los datos recibidos después, pero no funciona, se truncan las frames finales, el bufer, como sabes, es un sistema FIFO y si tienes un array válido que procesar lo pues hacer del primero al último o viceversa, lo importante es que hay bytes fijos que identifican la validez del frame copiado, en especial la psoción de los bytes de datos.

La solución para el desbordamiento del buffer, en mi opinión, es utilizar un mCU con un procesador más rápido, por esto voy a probar con un esp32 que ya tengo por aquí, pero es posible que también con una Teensy cuyos relojes tienen un ciclo de trabajo el doble que ATmega2560 y, posiblemente un buffer mayor lo que permitiría un diseño más elegante.

Un par de instrucciones simples en el loop () permite ver toda la salida de datos de Icom a cualquier velocidad:

loop () {;

if (Serial1.available ())

    Serial.println (Serial1.read (), HEX);

{

Estas dos líneas leen la salida del buffer e imprimen en el monitor serie los bytes que leen. Leyendo a 16 MHz no se recarga el buffer y puedes ver todos los datos que envía el equipo por la salida [REMOTE].

La mayoría de los programas que he visto procesan los datos en el loop () de forma que cada ciclo, además de procesar los datos de frecuencia tienen que manejar el resto de los eventos que se quieren programar, por ejemplo la lectura de un pulsador que cambie el modo de un conmutador de antena de automático a manual.

De esta forma el modo "sniffer" (if Serial1.available ()) transfiere el control a una función externa hasta que se vacía el buffer.

loop () {

   if (Serial1.available ()) {

      process_frame ();

   {

{

 

void process_frame () {

   while (Serial1.available ()) {

   .

   .

   .

   }

}

 

De esta forma mientras el Icom esté enviando frames toma el control de flujo la función, lo que permite descargar el peso del trabajo.

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

ResponderCitar
  EC5APB y EA6763URE me gusta
EA2ET
Mensajes: 6263
20 septiembre, 2021 14:26     #367374

Igual digo una chorrada...

Ignorar datos puerto serie

Vaciar buffer, pedir el dato que interesa, leer y analizar, procesar si interesa, si no interesa retardo y volver.

 

Si quieres buenas respuestas haz buenas preguntas

73 de Angel, EA2ET.

ResponderCitar
EA6763URE
Mensajes: 51
20 septiembre, 2021 17:27     #367379
Publicado por: @ea2et

Igual digo una chorrada...

Ignorar datos puerto serie

Vaciar buffer, pedir el dato que interesa, leer y analizar, procesar si interesa, si no interesa retardo y volver.

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.

Luis. EA4HNL

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

WEBCLUSTER EA4URE


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

Bienvenida/o a la información básica sobre las cookies de la página web responsabilidad de la entidad:

UNIÓN DE RADIOAFICIONADOS ESPAÑOLES

Una cookie o galleta informática es un pequeño archivo de información que se guarda en tu ordenador, “smartphone” o tableta cada vez que visitas nuestra página web. Algunas cookies son nuestras y otras pertenecen a empresas externas que prestan servicios para nuestra página web.

Las cookies pueden ser de varios tipos: las cookies técnicas son necesarias para que nuestra página web pueda funcionar, no necesitan de tu autorización y son las únicas que tenemos activadas por defecto. Por tanto, son las únicas cookies que estarán activas si solo pulsas el botón ACEPTAR.

El resto de cookies sirven para mejorar nuestra página, para personalizarla en base a tus preferencias, o para poder mostrarte publicidad ajustada a tus búsquedas, gustos e intereses personales. Todas ellas las tenemos desactivadas por defecto, pero puedes activarlas en nuestro apartado CONFIGURACIÓN DE COOKIES: toma el control y disfruta de una navegación personalizada en nuestra página, con un paso tan sencillo y rápido como la marcación de las casillas que tú quieras.

Si quieres más información, consulta la POLÍTICA DE COOKIES de nuestra página web.

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
  • wp-settings-1
  • wp-settings-time-1
  • wpf_read_forums
  • wpf_read_topics

RECHAZAR TODOS
ACEPTAR TODOS