Omnirig e Icom

Hay una cosa que no me suena: dices que el omnirig sólo te deja seleccionar el equipo y nada más. ¿No te deja cambiar los valores de número y velocidad del COM y los de RTS y DTR?

Creo que para el 7300 tienes que ajustar estos dos últimos a LOW. con mis equipos, no recuerdo que combinación me hacía pasar a TX como te pasa a tí. 

Yo utilizo el Log40M, con Omni-rig en una Icom IC-7610 y también en una IC-7300. Permite trabajar el ft-8 sin necesidad de desconectar ni cambiar nada.

Adjunto mi configuración del Omni-rig 1.19 por si os sirve.

Adrián V.

EA5ITV

No me he explicado bien. El OmniRig utiliza un sistema de ajuste para cada equipo que se adapta al sistema de CAT. En los Icom, para controlar el transceptor, cambio de VFO, frecuencia, modo, etc, utiliza el protocolo CI-V, esto datos se encuentas en unis archivos *.INI que se puede leer con un editor de texto plano, como el notepad de Windows.

Estos ficheros están empaquetados en un archivo ZIP Riglni.zip, cada equipo que puede manejar el OmniRig (y por lo tanto el Log4 tiene su nombre, por ejemplo, IC-7300.ini contiene los comandos de los parámetros que puede manejar del equipo. 

Las tres primeras instrucciones que OmniRig transmite al equipo es colocar el modo Echo Back a ON (Con lo cual el Icom envía un eco de la trama que envía el software.

La segunda ajusta en el menú el modo Transceive a OFF y la tercera ajusta el modo CW normal  a LSB.

Pues bien, si alguien quiere recibir la frecuencia activa del Icom, no puede hacerlo con el OmniRig, pues quieras o no lo inactiva y es necesario tenerlo activado para que el decodificador de banda reciba los cambios de frecuencia. No tiene nada qiue ver ni con el puerto ni con la velocidad de transmisión de datos. Son parámetros que solo se puede inhabilitar borrándolos del fichero ini, pero con consecuencias imprevisibles en cuento al funcionamiento del logbook.

Probablemente hay un método para enviar desde el Arduino un requerimiento para quie el equipo indique la frecuencia activa, pero esto complica en exceso el código con lo que lo mejor es cambiar de programa.

Has probado esto?

mySerial.write(0xFE); mySerial.write(0xFE); mySerial.write(TRX_address); mySerial.write(0xE0);
mySerial.write(0x03);  // Read operating frequency, command 03
mySerial.write(0xFD); // end sequence
delay(20);

Es para el IC-7000, pero creo que en el 7300 puede ser igual, mira en el manual.

Hola Enio

Describes dos problemas diferentes:

en cuanto intento conectar el CAT, el Icom entra en transmisión que sólo puedo evitar cerrando la aplicación. Lo que provoca esta acción no deseada es el OmniRig.

Esto en el Omnirig, o cual otro programa que utilice el CAT, lo puede causar los valores RTS y DTR. En la configuración de Omnirig que aporta EA5ITV puedes modificar esos valores, tanto en RIG1 como en RIG2. Por ejemplo, yo tengo todos los valores a LOW, si los pongo a HIGH no noto diferencia salvo si cambio el DTR del RIG2 (aun no utilizandolo) a HIGH que se me pone en transmisión, no se porqué, supongo que sera la configuración de cada uno en el equipo.

Hay otra razón para que deje de utilizar el OmniRig. Buscando alguna razón para el comportamiento del software, he leído las especificaciones del equipo que utiliza OmniRig. En el inicio ajusta tres parámetros de entrada, entre ellos el modo transceive que lo pone a OFF,

Esto es un problema ya que hay programas que requieren que CI-V Transceive este ON para que funcione el CAT y si te lo cambia el Omnirig, o cualquier programa, tienes que cambiarlo desde el menú del equipo.

En el caso de Omnirig he modificado la siguiente instrucción en el fichero .ini sin notar ninguna diferencia en los programas que utilizo:

[INIT2]
;Turn CI-V transceive ON
Command=FEFE98E0.1A050112.01.FD
ReplyLength=16
Validate=FEFE98E01A05011201FD.FEFEE098FBFD

Espero que te sea de ayuda.

73

Gracias José Angel, no solo lo he probado sino que lo utilizo en mi programa. Aunque esté en inglés es un diseño mío, aunque el nombre de algunas variables que definen el preámbulo y final de la trama, son sugerencia de un amigo. (SOFrame = StartOfFrame) (EOFrame = EndOfFrame)

La siguiente secuencia es la trama que envía el Icom, la salvedad es que el comando 0x03 lo incluye siempre en el requerimiento de la frecuencia y cuando el envío de la trama con la frecuencia es contestación a un requerimiento y 0x00 es el comando cuando el Icom envía la trama con la frecuencia producto de un cambio (modo Transceive).

//--------------------------- byte frame value
const uint8_t SOFrame = 0xFE;
const uint8_t EOFrame = 0xFD;
const uint8_t COMrequest = 0x03;
const uint8_t COMtransceive = 0x00;
const uint8_t RIGaddress = 0x94;
const uint8_t CONTROLaddress = 0x0E;

/* Byte position in the frame
* -------------------------------------------------------------
* |0xFE|0xFE|0x0E|0x94|0x03/0x00|BCD1|BCD2|BCD3|BCD4|BCD5|0xFD|
* -------------------------------------------------------------
* | 0   | 1     | 2    |  3   |  4             | 5    | 6     | 7     | 8      | 9     | 10   |
* -------------------------------------------------------------
* |Prelude    | To   |From|Command  | Data                                    |End |
* ------------------------------------------------------------
* When the frequency data comming by a request, the command is 0x03
* When the frequency data comming by a change in the rig, (transceive 'ON' mode) the command is 0x00
*/

(En la escritura del foro no queda indentado)

Por esto, la trama que has descrito es una solicitud desde el control (en este caso un Arduino) para que el Icom envía la frecuencia de trabajo:

Esta es la función que utilizo, aunque hay muchas formas, ésta, en mi opinión es la que mejor responde al concepto de programación ágil:

//------------------------------------ REQUEST
void request_frequency () {
   uint8_t comRequest = 0x03;

   Serial1.flush();
   Serial1.write(SOFrame);
   Serial1.write(SOFrame);
   Serial1.write(RIGaddress);
   Serial1.write(CONTROLaddress);
   Serial1.write(comRequest);
   Serial1.write(EOFrame);
   delay(20);
}

Otra forma sería:

void request_frequency () {

   uint8_t arrayEnd = 5;

   uint8_t frameValue [] = {0xFE, 0xFE, 0x94, 0x0E, 0x03, 0xFD};

   Serial1.flush ();

   for (uint bytePos = 0; bytePos <= arrayEnd; bytePos++)

      Serial1.write (frameValue [bytePos]); 

   delay (20);

}

Aunque creo que la primera es más clara y probablemente más rápida, seguro que hay más formas.... 🤣 🤣 🤣 

El código que has enviado corresponde a un puerto serie generado por software. Normalmente se utiliza este recurso cuando se utiliza una placa NANO o UNO que solo tienen un puerto serie hardware que se utiliza por defecto en el conversor USB/UART, o también con el monitor serie. Yo utilizo una placa MEGA que cuesta poco más que las anteriores y tiene cuatro puertos hardware y creo que pronto me pasaré a una Teensy. Los puerto generados por librerías externar para emular puertos serie, tiene algunos inconvenientes de incompatibilidades, es mejor huir de este dñebito técnico cuando tienes placas que ofrecen varios puertos serie hardware.

Esto en el Omnirig, o cual otro programa que utilice el CAT, lo puede causar los valores RTS y DTR. En la configuración de Omnirig que aporta EA5ITV puedes modificar esos valores, tanto en RIG1 como en RIG2. Por ejemplo, yo tengo todos los valores a LOW, si los pongo a HIGH no noto diferencia salvo si cambio el DTR del RIG2 (aun no utilizandolo) a HIGH que se me pone en transmisión, no se porqué, supongo que sera la configuración de cada uno en el equipo.

Gracias, es una orientación, probaré porque me gustaría no tener que prescindir del Log4.

Esto es un problema ya que hay programas que requieren que CI-V Transceive este ON para que funcione el CAT y si te lo cambia el Omnirig, o cualquier programa, tienes que cambiarlo desde el menú del equipo.

Bueno es la primera idea que se me ocurrió pero no la he probado porque no sé que relevancia o que función tiene en Omnirig, he revisado otros equipos y solo le he visto en el IC-7610 y me mosquea. Ya había observado que de vez en cuando el Icom se ponía el solito el Transceive a OFF, ahora me doy cuenta que o hacía cuando conectaba Log4 (OmniRig).

Voy a probar cambiar la instrucción INI poniendo el comando a 01 a ver que pasa, aunque ya lo hago desde el programa del proyecto desde que había observado que él solo se ponía a OFF:

void set_transceive_mode_on () {
   uint8_t transceiveModeOn = 1;

   Serial1.flush();
   Serial1.write(SOFrame);
   Serial1.write(SOFrame);
   Serial1.write(RIGaddress);
   Serial1.write(CONTROLaddress);
   Serial1.write(0x1A);
   Serial1.write(0x05);
   Serial1.write(0x00);
   Serial1.write(0x71);
   Serial1.write(dec_to_hex(transceiveModeOn));
   Serial1.write(EOFrame);
   delay(20);
}

como ves el comando es 1A y el subcomando 05 y 0071 el dato es 01, la función que transforma (empaqueta) el formato a BDC es:

uint8_t dec_to_hex (uint8_t value) {
   return ((value/10) *16) + (value % 10);
}

No entiendo el significado del valor después de la trama con la instrucción para modificar en estado del modop Transceive.

Validate=FEFE98E01A05011201FD.FEFEE098FBFD

FE FE (preludio) E0= (¿To control?)  98 (¿From transceive?) FB (¿OK?) FD (end) ¿Se contesta Ominirig asismismo? Curioso. Lo lógico es que el Icom conteste si la instrucción es OK o NO

Hola Enio,

Esto no tiene nada que ver con Log4OM. Si has configurado el Log4OM con OmniRig, OmniRig es quien controla el puerto y la comunicación con la radio, no Log4OM ni otros programas que soporten OmniRig (como Swisslog, WSJT, JTDX, etc). OmniRig sólo envía los datos internamente a los programas soportados. Por mi experiencia, si te sirve de algo y creo ya te lo han dicho por aquí, el tema que se ponga el 7300 en TX es porque la línea RTS está en HIGH y hay que ponerla en LOW. En Swisslog, conectado el 7300 directo al puerto COM, tengo que poner en LOW RTS para evitar eso, sino se pone en TX. 

Referente a OmniRig nunca he entendido porqué desactivan el parámetro CI-V transceive en los ICOM. La única razón supongo será porque OmniRig haga "polling" (solicitar periódicamente desde el software cierta información al equipo) para recibir la frecuencia y modo, sino no recibiría ese dato. No me he dedicado a fondo a revisar los INI ni monitorizar el puerto estando conectado con Omnirig, pero es la única cosa que se me ocurre. Si el CI-V transceive está activado y el programa hace "polling" al equipo, suelen haber problemas, de ahí que los programas que lo hacen requieran que se desactive ese parámetro. Como bien dices, estando activado ese parámetro, el equipo envía el modo y frecuencia cada vez que se cambia en el equipo sin necesidad que el software de control tenga que solicitar nada.

He encontrado este enlace que quizá te pueda ayudar también, que habla de los ajustes en la radio:

https://radioaficion.com/cms/ic-7300-usb-port-settings/

73

Gracias Jordi, ya he comentado que el cambio de Log4 era debido a que necesitaba OmniRig  (HamLib está descartado) y el problema de la puesta en TX del equipo estaba originado por este mismo. La verdad es que no he investigado mucho el problema, estoy muy dedicado el proyecto actual y me ha sorprendido y molestado esta circunstancia puesto que hasta el formateo del DD funcionaba perfectamente y he dado por supuesto algunas cosas sin investigar. Voy a intentar ajustar la línea RTS. Por otra parte HRD también tiene su propio sistema de CAT.

Yo tampoco tengo claro porqué OmniRig pone el modo transceive a OFF, he supuesto que la intención es evitar el follón de datos que se mezclan en el buffer y hace un "request" controlado porque necesita conocer la frecuencia del equipo. Lo cierto es que transceive ON es compatible con el cointrol de los demás parámetros porque se puede identificar cualquier tipo de trama. También voy a probar de modificar el parámetro Transceive OFF a ON, para ver que pasa.

Hola Enio,

En Swisslog he hecho justo una modificación sobre eso, precisamente para evitar una saturación del búffer con tanta cantidad de datos, ya que algún usuario ha tenido problemas. En la versión actual de Swisslog se hace "polling" hacia el equipo siempre y no se puede desactivar. Ahora he sacado una beta donde si está CI-V transceive ON, hay que poner 0 en el campo donde se ajusta la solicitud de frecuencia para evitar que lo haga. Y un valor superior a 0 sólo en caso que CI-V transceive esté en OFF. Hay otros programas, como Dx Lab Commander, que también hacen "polling" y aconsejan desactivar CI-V transceive. Según su documentación, CI-V transceive no es algo fiable en todos los equipos ICOM, y haciendo la solicitudes desde el programa se tiene mejor control. Pero yo creo que eso sucedía en equipos más antiguos no los actuales.

Espero des con la tecla pero ya te digo que no es culpa de Log4OM porque aquí quien está en medio es OmniRig y te sucedería lo mismo si usases Swisslog u otro programa que configures con OmniRig.

¡73 y suerte!

Bueno Jordi, ya he puesto DTR y RTS a low y el Icom no se pone en modo transmitir. Omnirig hace "polling" cada 500ms. es muy difícil controlar el buffer porque la cantidad de datos que transmite el Icom en modo Tranceive ON es de al menos una trama de 11 bytes cada Hz, por lo que en un desplazamiento rápido de 100 KHz, por ejemplo, el Icom suelta un chorro de 1 Mby, si la carga de proceso de cada trama es alta se pueden dar colisiones en el buffer si no trabaja a la misma velocidad. La velocidad de proceso de un Arduino es de 16Mby, muy inferior a la de un PC.

Bueno, el caso es que he conseguido cambiar la trama del inicio 

[INIT2]
;Turn CI-V transceive ON
Command=FEFE94E0.1A050071.01.FD
ReplyLength=16
Validate=FEFE94E01A05007101FD.FEFEE094FBFD

Log4 con OmniRig funciona como siempre y Tranceive se queda en ON, como está mandado. Gracias y gracias Marco.

El proyecto en el que estoy trabajando es un controlador automático de antenas que selecciona una antena en función de las bandas de trabajo. Está basado en una placa de Arduino y está programado en C++. El programa necesita detectar los cambios de frecuencia para detectar un cambio de banda para comprobar si es necesario cambiar de antena. El proceso más difícil para mí que nunca había trabajado con procesos de datos vía puerto serie ha sido seguir los cambios de frecuencia, por esta razón he programado el Arduino en modo "sniffer", aunque los cambios de unos Hz son irrelevantes para el proyecto, esto me ha llevado a montar un nuevo dial en el display, no era necesario pero entiendo que era la única forma de trabajar con seguridad la frecuencia, el caso es que el dial responde perfectamente, no pierde la lectura de una sola trama en cualquier circunstancia y mucho menos en cualquier cambio de banda.

He probado la forma de programar haciendo un "request" 500ms, pero con el dial en movimiento se pierden tramas, aunque no es significativo me he sentido más seguro haciendo "sniffer" teniendo en cuenta que sólo manejo la frecuencia (únicamente al inicio, en el la función setting (), pongo en hora el reloj interno del Icom, verifico que Transceive esté en ON y hago un request de la frecuencia, esto, además, entiendo que complica el tráfico en el buffer (del Arduino con un buffer de 16bit para las dos direcciones TX y RX, no como el Icom que en [REMOTE] tiene un buffer por cada sentido) porque hace un eco de cada "request" antes de enviar la trama con la frecuencia.

Si cambio de placa a una Teensy, es probable que monitorice el comportamiento del buffer con el OmniRig, pero ya estpy pemnsando en un nuevo proyecto basado en la Rapsberri Pico en Phyton.

El proceso de salida a pantalla es siempre numérico, la frecuencia la obtengo en tramos de 10KHz y la divido en tren enteros, MHz, KHz, y Hz, con lo que evito el so de las cadenas y refresco la pantalla solo cuando hay cambios de uno, dos o tres parámetros.

Lo que tengo encima del Icom es un prototipo en una caja Minibox reciclada.

Este trabajo ha sido posible gracias a la ayuda y la paciencia de Javier EA1N y Josep EA3FUZ.

Hola,

    Como bien dijo Jordi, la razón por la que el omnirig desactive el modo transceiver ( en kenwood se llama auto información), es porque no hay ningún control sobre la información, ni incluso se sabe si el equipo esta apagado o es que no se mueve el vfo. Lo lógico en un programa de cat es que sea el programa el que extraiga la información que necesite, en el momento que la necesite. Si está activo el envío de información sin ser solicitada y se va a hacer polling, se debería de implementar un control de flujo para evitar choque de paquetes, refiriéndose en concreto a ICOM, ya que es el mismo bus por el que va toda la información , "la de ida" y "la de vuelta". En otros equipos no es problemático el choque de paquetes ya que son distintas las líneas TX y RX. De ahí que la prueba de enviar cada 500ms (como un martillo pilón) una solicitud de información al equipo, genera colisiones de datos si en ese momento, y con el modo tranceiver on, se mueve el vfo, ya que no hay implementado un control de flujo de datos ( el arduino y el icom hablan a la vez, montan pileup). Lo lógico seria hacer esa solicitud si hace más de 500ms que no hay trafico en el puerto, o sin tener una lectura de frecuencia.

    Si se mira el trafico entre equipo y pc con diferentes softwares, se ve claramente que cada uno necesita información diferente. Por ejemplo N1MM genera muy poco trafico, ya que solo pide la frecuencia del vfo A, la del B, el modo y si esta en split. No quiere mas información, pero la pide periódicamente, así se asegura en todo momento donde esta el equipo y que no se perdió nada. El HRD genera un trafico bestial, ya que quiere saber no solo las frecuencias, sino el ancho del filtro, el modo, señal del smiter, que parámetro indica el smiter, cuando esta en tx y cuando en rx, el nivel del alc en transmision, la potencia, ...Por lo tanto, que el equipo le este enviando la frecuencia cada vez que se mueve el VFO es spam para el software. El OM2000A+ extrae del equipo el VFO en el que está activada la TX y la frecuencia de éste, lo demás no lo quiere, pero eso lo pregunta continuamente si es él quien tiene el control o cuando hace un tiempo que no lo consigue extraer del trafico entre pc y emisora. 

   Respecto a cambiar a un procesador mas potente, un arduino nano es capaz de extraer la frecuencia entre todo el trafico que genera el HRD, doy fe de ello, incluso con equipos kenwood que para enviar la frecuencia utiliza mas bytes que icom. El decodificador que hice ( con un mega) y lleva 10 años funcionando 24/7, extrae la frecuencia del VFO A, del B, y si esta en split, del trafico entre HRD y equipo ( icom, kenwood o tentec), la solicita si pasan 250 ms sin tener una lectura correcta de ella, atiende y actualiza una pantalla grafica tactil, se comunica por serie con un arduino remoto en la base de la torre y mas.

   Un saludo.

   EA1N - Javi -

Gracias Javier, es sumamente interesante la exposición que has hecho del funcionamiento de un CAT. Como sabes, lo mío es programar, es decir, dar instrucciones a una máquina para que ejecute unas tareas. Aunque sepas programar de manera eficiente, lo primero es conocer cómo funciona la máquina. Lo más fácil es es traducir las instrucciones a código aunque hacerlo de manera eficiente y comprensible es algo más complicado o cuesta algo más de trabajo.

Cuando inicié este proyecto no tenía ni idea de cómo funciona un puerto serie y mucho menos uno tan complicado como el del [REMOTE] del Icom con un solo camino de ida y vuelta. Poco a poco me he ido enterando de cómo funciona y espero que gracias a este hilo haya más colegas que se interesan por conocer los detalles de cómo funciona su software de CAT o de control remoto.

Lo cierto es que nadie me había explicado (ni tampoco he encontrado documentación), aunque ya lo había intuido, que un sistema CAT era un diálogo entre el control y el equipo y que requerir un dato era hacer "polling" (gracias Jordi). Lo cierto es que opté por el monólogo (modo transceive) ya que el único dato que me interesaba era la santa frecuencia y esto ya lo tenía, lo cierto es que desde un principio ya hacía "polling" en el setup () para conocer la frecuencia inicial cuando arranca el programa como el equipo encendido. Todo el código de otros programas que he consultado utilizar el modo "sniffer", pero podría haber enfocado perfectamente la programación en modo "polling", bastaba con inhibir el modo transceive, colocar un timer de 500ms (o mayor) y procesar la respuesta desechando el eco. En algunas circunstancias se podrían perder la lectura de unos pocos Hz más, pero eso es irrelevante para un control de antena.

El control de encendido y apagado entiendo que también se puede obtener por polling aunque el equipo esté apaga gracias al comando 0x1A 0x05 0x00 0x92 (00=off/01=off) no lo he probado pero si no ese será otro porque HRD (que yo sepa) enciende el equipo. De todos modos para detectar el estado (encendido/apagado) utilizaré la salida de 13,8V del conector ACC, me parece más seguro) En cualquier caso el funcionamiento del OmiRig en el Log4 es compatible con el modo transceive ON del Icom. De hecho, las pruebas indican que funciona correctamente.

Bueno... de acuerdo con que un Arduino UNO y un NANO pueden procesar toda la información que entrega el Icom, siempre y cuando no se monitorice ("DEBUGGING") por el puerto Serie a una velocidad de 9600 baudios 🤣 🤣 🤣 que en mi experiencia provoca desastres. Sin embargo creo que hay que considerar que una placa MEGA dispone de cuatro puertos físicos y una Teensy es más pequeña que un NANO y tiene seis. Son algo  más caras pero asumible para un proyecto de este tipo y disponen de más memoria. La MEGA PRO 2560, cuesta el doble que una NANO y es el doble de tamaño, la Teensy es algo más pequeña pero tiene un reloj que puede llegar a 90MHz.

Hola Enio,

Como habrás podido comprobar esto es bastante apasionante y divertido (al menos así lo considero para los que estamos enredados en estos menesteres de programación 😊 ). Creo que lo mejor en tu caso sería desactivar CI-V transceive y controlar tú desde el Arduino cuando quieres recibir los datos. Reduces muchísimo el tráfico. Cualquier otro parámetro que no sea QRG y modo debe solicitarse explícitamente desde el software, aunque esté el CI-V Transceive en marcha, ya que con eso la radio sólo envía cambios de QRG/Modo, nada más. Pero tú no necesitas nada más que la frecuencia, por lo que sólo precisas solicitarle eso (sin el modo) reduciendo drásticamente el tráfico del puerto). El tiempo de solicitud (el "polling" que dicen los ingleses) dependerá de lo fluida que quieras la lectura en el display cuando giras el dial. Con 100ms la lectura es súper fluida aunque 500ms es un valor intermedio bueno. 

Por si te puede interesar, te explico como hago yo en Swisslog para detectar los cambios de banda. En Swisslog, si se usa control del rotor y el CAT, como en la configuración del rotor se pueden poner las bandas que maneja la antena, al cambiar de banda el equipo, Swisslog selecciona automáticamente el rotor correspondiente de acuerdo a la banda definida en cada rotor (se pueden configurar hasta 4). Con esto también evito que la antena gire en una banda no manejada por ningún rotor, en caso que se le de una orden de giro. Simplemente lo que hago es guardar en una variable la última frecuencia leída y la comparo con la frecuencia actual que se lee del equipo. Si la diferencia de frecuencia es superior a 1MHz entonces ejecuto las acciones de cambio de banda. Con esto me ahorro un montón de procesos continuos e innecesarios para una mejor fluidez y descarga de la CPU. En tu caso no es importante, pero en un programa que ejecuta miles de acciones hay que mirar de optimizar al máximo todos los procesos. 

73

Efectivamente, aunque hoy en día hay verdaderos "maquinones", yo soy de los que piensan en el ahorro en procesos, gestión de memoria, etc. aunque siempre se comete algún exceso en declaración de variables, por ejemplo.

El polling lo tengo asustado también en 500ms y el timeout en 4s.

Hola, gracias Gaspar y Antonio. Como solo me interesaba la frecuencia tiré por lo más cómodo y por he programado en sniffer. La mayor parte del comportamiento del flujo de datos entre el Icom y el Arduino lo he ido descubriendo a base de monitorizar las tramas.  También he analizado código, en especial el de RemoteQTH y un par de programas más para Arduino y todos utilizan el modo "sniffer" y no hacen polling. Lo cierto es que una cosa es un programa orientado a controlar el equipo deforma integral como Swiss Log, Omni Rig o HRD, desde un PC y ora cosa es controlar un conmutador de antena de forma automática. Ya tengo alguna experiencia programando una placa básica de Arduino controlada por el modo ACC (Tensión variable).

El proyecto en el que estoy trabajando el principal objetivo es probar es la utilidad de una placa con un mCU para cacharrear en cosas de la radio, muy lejos de un CAT con un PC.

En cualquier caso, me gusta hacer las cosas bien y aunque programar la Arduino para que reciba la frecuencia en Transceive es compatible con el comportamiento de un equipo que solicita datos por otro puerto, en cualquier caso, yo también hago polling en el setup porque si enciendo el control con el equipo encendido no se enteraría en qué frecuencia estaba hasta que no moviera el dial. Ocurre también que la primera prueba quehice me volvía loco porque recibía una trama corta con el comando frecuencia 0x03 sin datos hasta que no leí que Icom hace eco de todas las solicitudesñ Además, filtrar una trama solo de frecuencia, es sencillo (más comodo) que programar un función sea capaz de leer cualquier trama. Así que como también, mejor muerto que sencillo, me voy a dedicar a reprogramar para hacer polling (evidentemente 500ms). No le he encomntrado urtilidad al timeou. También estoy probando con una pantalla TFT.

Buenas de nuevo.

  Como mera información, el que los decodificadores que se encuentran por la red tipo remoteqth trabajen en modo sniffer leyendo el tráfico del bus del cat, es porque están pensados para procesar la información que se transfiere entre el pc y el equipo. Cuando se crearon esos decodificadores, los equipos no traían puerto USB, por lo que el Cat se conectaba a un puerto serie o al bus civ ( dependiendo de la marca). El modo transceiver o auto información no se usaba, ya que debía de haber un pc generando tráfico. Hoy en día se puede conectar al pc por USB y usar el puerto serie para por ejemplo el decodificador, pero antes no existía eso, así que solo quedaba extraer la información en modo sniffer o como yo implementé, poner un selector electrónico que derivara el cat al pc o al Arduino. Y hacer cambios extremadamente rápidos para enviar solicitudes desde el Arduino y devolver la línea al pc, retornado el Arduino a sniffer.

Si se quiere alta fiabilidad, seguridad, y elegancia en el funcionamiento se debe usar polling en vez de modo transceiver. Pero es mi opinión.

Un saludo.

EA1N -javi-

Estoy de acuerdo Javi, creo que es sencillo hacer que el Arduino pregunte al Icom por la frecuencia de trabajo cada 500ms. En estos momentos estoy terminando el montaje del dispositivo y ya, con comodidad y con una pantalla TFT que he incorporado me voy a dedicar a hacer el programa. Estoy escribiendo un trabajo sobre el funcionamiento CI-V y debo añadir la experiencia con la recepción de la frecuencia en en este modo.