Por qué tu spot puede marcarse como DUPLICADO (DXCluster Telnet/WebCluster)

Hola Kin. Cuando dices "nuestro DXCluster", te refieres al de URE y al webcluster.ure.es? Si es afirmativo, tengo ciertas dudas.

Saludos, José María

Sí, a nuestro WebClusterURE y de Telnet. Pero en realidad pasa lo mismo con la mayoría de los clusters de telnet, porque son del tipo DXSpider.

Kin

Publicado por: EA3CV

↑

Se analiza el indicativo del spotter

Estaba leyendo esto y me hizo pensar...

El cluster, como todos saben, se usa para muchas cosas. Una de ellas es todo lo referente a la propagación. Hay utilidades y programas "escuchando" y sobre eso analizan la propagación.

Si un mismo spot, o sea, mismo Dx, misma frecuencia, incluso en segundos o pocos minutos de separación, lo envían diferentes estaciones de diferentes lugares, eso está ayudando a saber como está la propagación.

Si algunos de esos spots se dan como duplicados y se borran... ¿No estamos afectando o limitando esas herramientas de propagación?

Por ejemplo:

dx EA1AAA 7165 OH0XX

dx EA8AAA 7165 OH0XX

dx EA6AAA 7165 OH0XX

Esos serían a nivel nacional, pero ya marcan unas diferencias pues entre EA1 y EA8 hay 2000 Km, y casi lo mismo con EA6. Puede ser noche en EA6 y aún día en EA1 y EA8, o al revés.

Ya no quiero pensar si lo ponemos a nivel internacional.

¿Estoy equivocado en algo?

Gracias

73, Máximo EA1DDO

Habría posibilidad de que este webcluster admitiese caracteres especiales como la "ñ" y vocales acentuadas? Ya que algunos cluster (DXFun, por ejemplo) sí lo permiten, no estaría mal que este, perteneciente a la URE, usado en su mayoría por radioaficionados españoles, tuvieramos opción de usar la letra ñ: estoy pensando en spot de actividades o indicativos especiales.

Un saludo, José María

Hola Máximo,

El motivo principal de la “duplicidad” no está en un problema intrínseco del clúster, sino en el mal uso que algunos hacen de él: envío de spots de forma malintencionada o, como mínimo, sin control por parte del spotter (automatismos mal configurados, prisas, etc.). Esto lleva ocurriendo desde hace mucho tiempo y ha generado múltiples quejas de usuarios; precisamente por eso, los desarrolladores han terminado aplicando limitaciones para contener este tipo de comportamientos y reducir el ruido/abuso.

Por otra parte, respecto a utilizar los spots “humanos” como referencia de condiciones de propagación: en mi opinión (y pensando especialmente en SSB), no es una práctica especialmente extendida ni representativa. De hecho, hace unos meses puse a disposición de la comunidad una funcionalidad orientada a ayudar con predicciones asociadas a cada spot recibido (spots enriquecidos) y personalizadas por usuario, y el resultado fue muy limitado: en el mejor de los casos, no pasó de 4 usuarios activos. Creo que esto dice bastante sobre el uso real que se hace de ese enfoque.

Un saludo,

Buenas, José María.

Tanto nuestro Webcluster como el acceso por Telnet aceptan caracteres en UTF-8 sin problema. La incidencia aparece en el otro extremo de la cadena: la información no va directa, sino que se propaga por múltiples nodos que forman la red mundial de clúster hasta terminar en las aplicaciones cliente de cada usuario.

El punto crítico es que no todos esos nodos (ni todos los clientes) están correctamente configurados para tratar UTF-8. Cuando en algún tramo se usa otra codificación, caracteres como ñ, ç, ü, etc., pueden “romperse” y acabar viéndose como símbolos o letras extrañas. No es un fallo de un único sistema, sino una falta de uniformidad en la codificación a lo largo del recorrido.

Por eso comentaba que, dado que no parece haber voluntad general de homogeneizar algo relativamente sencillo, la forma más práctica de evitar problemas es prescindir de estos caracteres y limitarse a texto ASCII.

Un saludo.