He hecho la prueba y he puesto a transmitir el Flex en 14.066 y lo escucho en el sdr de Andorra y el sonio es el mismo y la imagen es la que adjunto (se utilizó solo el tono TX del wsjt)

empiezo a creer que no es un problema originado por pérdida de paquetes.

Si suponemos que Flex paquetiza en transmisión el FT8 en bloques de 40 ms (el valor más habitual en voz), en un periodo en tu TX se usarán aproximadamente 300 paquetes. Si la pérdida que te dice Flex de 0.09% es real (1) y suponiendo que las pérdidas se distribuyen en el tiempo (2) tendrías problemas aproximadamente en 1 de cada 4 periodos de transmisión, y eso no parece que sea lo que te pasa.

Además, si suponemos que en el otro sentido la red y/o aplicaciones se comportan igual, también se tendrían que perder paquetes, debería verse algo parecido y no lo parece mirando las figuras que mandas.

La pérdida de paquetes o el vaciado del "buffer de de-jitter" produce un "click" muy característico. ¿Puedes hacer esta prueba y mandarme el audio a mi correo de qrz.com?

1. en el escenario que falla, buscas una frecuencia fuera de las normales y transmites la morralla que sale en la figura.

2. con otro equipo escuchas esa señal y grabas el audio con el móvil, por ejemplo.

Lo que me despista es la diferencia que hay en las medidas de "calidad" que te da Flex entre la "latencia" y la "latencia max". ¿Puedes sacarla otra vez y ver si siempre sale algo igual?.

(1) Se podría "esnifar" la red en ambos extremos del escenario que falla, en el lado remoto valdría con poner un software como NetworkTrafficView o AppNetworkCounter, en el lado de la radio habría que poner un "hub" y un PC capturando todo el tráfico que entra al Flex, pero esto empieza a ser de nota.

(2) no creo que las pérdidas de paquetes se concentren en un determinado momento, porque entonces sólo tendrías mala señal en ese momento y no en todo el periodo como parece deducirse de una de las figuras que has puesto. 

73  jose EA4AFP

Te estás fiando del diagnostico que te puse propietario de SmartSDR, que no tiene ningún problema, SmartSDR funciona correctamente, el problema lo presenta DAX. Que es un componente (o subsistema de audio) de SmartSDR que corre como proceso auxiliar para enrutar audio digital de forma fácil  entre el radio Flex y programas externos como JTDX, N1MM, etc... 

DAX se instala dentro del paquete SmartSDR y se ejecuta como una aplicación separada, con cierta autonomía operativa, pero es propietaria y dependiente de SmartSDR, y como te decía es demasiado hermética para poder diagnosticar o poder ajustar los buffers, etc...

Me hubiera gustado subir algún video aquí (no es posible por el peso) y eso te hubiera despejado todas las dudas, verías claramente que es una perdida de paquetes, flex tiene un monitor en el que se aprecia perfectamente los "clicks" a los que te refieres. Por eso en un post anterior puse dos imágenes, una con la señal limpia y otra con los "clicks" (cada señal orizontal que ocupa todo el ancho de banda de TX en DIGI-U es un "clik").

Te envio un video por privado para que lo veas, para mi no hay duda.

empiezo a creer que no es un problema originado por pérdida de paquetes.

Si suponemos que Flex paquetiza en transmisión el FT8 en bloques de 40 ms (el valor más habitual en voz), en un periodo en tu TX se usarán aproximadamente 300 paquetes. Si la pérdida que te dice Flex de 0.09% es real (1) y suponiendo que las pérdidas se distribuyen en el tiempo (2) tendrías problemas aproximadamente en 1 de cada 4 periodos de transmisión, y eso no parece que sea lo que te pasa.

Además, si suponemos que en el otro sentido la red y/o aplicaciones se comportan igual, también se tendrían que perder paquetes, debería verse algo parecido y no lo parece mirando las figuras que mandas.

La pérdida de paquetes o el vaciado del "buffer de de-jitter" produce un "click" muy característico. ¿Puedes hacer esta prueba y mandarme el audio a mi correo de qrz.com?

1. en el escenario que falla, buscas una frecuencia fuera de las normales y transmites la morralla que sale en la figura.

2. con otro equipo escuchas esa señal y grabas el audio con el móvil, por ejemplo.

Lo que me despista es la diferencia que hay en las medidas de "calidad" que te da Flex entre la "latencia" y la "latencia max". ¿Puedes sacarla otra vez y ver si siempre sale algo igual?.

(1) Se podría "esnifar" la red en ambos extremos del escenario que falla, en el lado remoto valdría con poner un software como NetworkTrafficView o AppNetworkCounter, en el lado de la radio habría que poner un "hub" y un PC capturando todo el tráfico que entra al Flex, pero esto empieza a ser de nota.

(2) no creo que las pérdidas de paquetes se concentren en un determinado momento, porque entonces sólo tendrías mala señal en ese momento y no en todo el periodo como parece deducirse de una de las figuras que has puesto. 

73  jose EA4AFP

Que el problema se podría resolver ajustando el Buffer del DAX? Es probable...(ya lo comente en un post anterior), la cuestión es ¿como?...no veo una opción, mas que deshabilitarle todas las funciones, incluida el audio de DAX RX para reducirle el trafico. 

Desconozco si hay alguna aplicación o manera de hacer eso, ajustar el uso de la red para un proceso concreto.

Lo que sí se es que puedes cambiar los ajustes en la tarjeta de red. Tienes muchos ajustes, pero claro, afectan a todas las aplicaciones. Pero por probar...

73, Máximo EA1DDO

¿Cómo has llegado a la conclusión de que se pierden paquetes?

¿Monta Flex RTP/RTCP por encima de UDP para poder hacer medidas de calidad?

Pues la conclusión llega a base de descartar... mismo PC en red LAN no hay problemas, mismo PC con distinto Flex en remoto no hay problema, mismo PC con el mismo Flex pero con distinta conexión a internet en el mismo sitio, no hay problema, etc... El problema solo aparece cuando sale por una conexión concreta.

SmartSDR tiene un sistema de diagnostico pero entiendo que no un RTP/RTCP estándar, sino algo propietario que no se puede considerar de calidad, sino solo orientativo. 

Tampoco tiene una opción propia (que yo sepa) de ajustar el buffer. 

SmartSDR usa dos sistemas de audio, el principal (que esta funcionando bien) y otro que podemos llamar secundario a través de la aplicación "anexa" DAX, que es la que se usa para hacer FT8, ya que genera tarjetas de sonido muy "dinámicas".

Es decir aumentar el buffer en el propio smartSDR (aparte de no tener esa opción) no resuelve el problema porque se produce al usar el audio TX del DAX, y ahí es todo una incógnita, demasiado hermético para poder hacer pruebas de calidad.

Que el problema se podría resolver ajustando el Buffer del DAX? Es probable...(ya lo comente en un post anterior), la cuestión es ¿como?...no veo una opción, mas que deshabilitarle todas las funciones, incluida el audio de DAX RX para reducirle el trafico.   

¿Cómo has llegado a la conclusión de que se pierden paquetes?

¿Monta Flex RTP/RTCP por encima de UDP para poder hacer medidas de calidad?

Respecto a la red, das el dato de la latencia pero no comentas nada del jitter. En mi remoto, que no es Flex, configurar el "buffer de de-jitter" por debajo de 40 ms es exponerse a sufrir en el extremo que recibe "clicks" que son muy molestos.

Tampoco comentas el codec que estás usando. A principios de este siglo la ITU ya tenía varias normas de la serie G en la que analizaba estos temas. De aquellas conclusiones, creo que te puede interesar:

1. Para una tasa de pérdidas de paquetes dada, a mayor capacidad de comprimir y por tanto de usar menor ancho de banda del codec que estés usando, peor es la calidad en recepción. Huye de codecs complejos si es posible.

2. Los codecs basados en modelos de voz son muy buenos para la voz, pero no para los tonos de FT8. 

3. Si te permite elegir el codec, vete a un G.711, da igual el apellido. Si quieres no ocupar mucho ancho de banda, paquetiza en bloques de 40 a 60 ms.

4. Ten en cuenta que el retardo será la suma del tiempo de paquetizado del punto (3), la latencia y la profundidad del "buffer de de-jitter". No te pases de 100-120 ms, la experiencia te dictará este valor.

Si los "click" que se producen por pérdida de paquetes son los responsables de lo que describes, yo empezaría por seleccionar un G.711 y ampliar el "buffer de de-jitter" a un valor alto, por ejemplo 100 ms y ver si lo arregla. 

73  jose  EA4AFP

No. Ya esta comprobado, es una cuestión de perdida de paquetes en la red de internet, que aunque tenga buena latencia y buen ancho de banda, por lo que sea, pierde paquetes UDP.

Hoy he hecho la prueba definitiva...misma ubicación , pero distinta conexión de datos, peor latencia muchísimo menos ancho de banda, mucha mas inestabilidad y sin embargo el problema prácticamente desaparece....

Ahora ya esta clarísimo, el problema ahora será averiguar que esta pensando en la RED exactamente para solucionarlo.

El problema radica en que ese DAX genera un tráfico de datos continuos que es muy probable que tenga una perdida de paquetes que no se pueden controlar, ajustar el buffer de la tarjeta de red podría ayudar,  pero yo he probado y realmente no funciona.

Ah, bueno, entonces parece que ya se sabe donde está el problema.

Alguien que controle del tema, seguro te puede ayudar. Algún tipo de ajustes, o alguna pequeña aplicación que regule ese tráfico de datos, o algo por el estilo.

A todo esto, no se si ya lo has hecho, pero sería bueno contactar con Flex para exponerles el problema. No creo que seas el único en el mundo en esa situación.

Suerte.

73, Máximo EA1DDO

PD. Por cierto, el otro día descubrí una función de Windows para asignar cierta prioridad a cada aplicación por separado.

En el Administrador de Tareas, pestaña Detalles, botón derecho sobre la aplicación deseada y se abre un menú, Establecer Prioridad.