URE foro pequeñas
LOTW y error PROP_M...
 
Notificaciones
Limpiar todo

LOTW y error PROP_MODE RPT

EA4CYQ
Mensajes: 637
#29831  - 4 marzo, 2015 18:17 

Buenas tardes,

No tiene sentido este error, pues PROR_MODE: RPT es correcto. Alguien sabe donde está el error.

Error: Invalid PROP_MODE (RPT) on line 378
CALL: EB4ETH
BAND: 2M
MODE: FM
QSO_DATE: 20020128
TIME_ON: 1750
PROP_MODE: RPT

Juan Antonio

ResponderCitar
Inició el tema
EA7BJ
Mensajes: 1997
#270981  - 4 marzo, 2015 19:12 

si haces un copia pega de la linea 378 de tu fichero .adi quizas tengamos mas datos para buscar el error....

Que programa TQSL usas para subir los ficheros ??

ResponderCitar
EA1S
 EA1S
Mensajes: 1358
#270982  - 4 marzo, 2015 19:31 
EA4CYQ escribió:
Buenas tardes,

No tiene sentido este error, pues PROR_MODE: RPT es correcto. Alguien sabe donde está el error.

Error: Invalid PROP_MODE (RPT) on line 378
CALL: EB4ETH
BAND: 2M
MODE: FM
QSO_DATE: 20020128
TIME_ON: 1750
PROP_MODE: RPT

Juan Antonio

Hola Juan Antonio

¿Estas seguro que PROR_MODE: RPT es correcto? No se si tienes mas QSO con ese modo y te los ha reconocido pero creo que este modo de propagacion no se contempla y no se puede agregar ni editar como si fuera un modo de transmision

🅴🅰1🆂▁ ▂ ▃ ▄ +𝟲𝟬𝗱𝗕
'
❼❸ & 𝓫𝓾𝓮𝓷𝓪 𝓬𝓪𝔃𝓪 𝓮𝓷 𝓵𝓪𝓼 𝓸𝓷𝓭𝓪𝓼...
'
𝗠𝗮𝗿𝗰𝗼 𝗘𝗔𝟭𝗦 - 𝗘𝗔𝟭𝗦𝗕 📡

ResponderCitar
EA7BJ
Mensajes: 1997
#270983  - 4 marzo, 2015 19:44 

las ultimas especificaciones del protocolo .ADI si lo contempla.....

ResponderCitar
EA1S
 EA1S
Mensajes: 1358
#270990  - 4 marzo, 2015 20:36 
EA7BJ escribió:
las ultimas especificaciones del protocolo .ADI si lo contempla.....

ya, ¿pero LoTW?

🅴🅰1🆂▁ ▂ ▃ ▄ +𝟲𝟬𝗱𝗕
'
❼❸ & 𝓫𝓾𝓮𝓷𝓪 𝓬𝓪𝔃𝓪 𝓮𝓷 𝓵𝓪𝓼 𝓸𝓷𝓭𝓪𝓼...
'
𝗠𝗮𝗿𝗰𝗼 𝗘𝗔𝟭𝗦 - 𝗘𝗔𝟭𝗦𝗕 📡

ResponderCitar
EA4YG
Mensajes: 475
#270984  - 5 marzo, 2015 08:42 

En ADIF debe figurar exactamente como:

RPT y no estar en contraposición con otros datos, por ejemplo:

RPT AO-40

En este caso el modo de propagación no se corresponde con el contacto en SAT y daría error.

Otra cuestión es si LOTW admite el modo RPT pero si no lo admite debe ignorarlo, así como otros múltiples datos que pueden ir en un ADIF, ya que hay que tener en cuenta que el ADIF no es un estándar y que cualquiera puede "inventar" o crear los datos que le conviene.

La prueba de ello es que LOTW ha "inventado" sus propios datos, eQSL tiene los suyos y muchos programas también han "inventado" los que necesitaban.

Muchos de ellos incluso tienen doble, tiple, etc. definición, ejemplos:

.- EQ_CALL es de eQSL para introducir el callsign de la estación contactada cuando ya existe en el ADIF, más o menos estándar, el dato CALL para el mismo propósito.

.- OWNER_CALLSIGN lo mismo que el anterior pero en este caso no se de quien es el "invento".

.- QSLRDATE es la definición, más o menos estándar, del ADIF original para la fecha de envío de QSL, sin embargo, encontramos, en un posible ADIF, los datos con la misma información: LOTW_QSLRDATE esto lo "inventa" y duplica LOTW o EQSL_QSLRDATE con el mismo concepto correspondiente a eQSL.

Y así podría enumerar muchos otros datos para el despropósito del uso del ADIF actual.

Saludos.

Antonio-EA4YG.

ResponderCitar
EA7P
 EA7P
Mensajes: 1008
#270985  - 5 marzo, 2015 17:11 

También a mi el otro dia me echó para atrás varios contactos en LOTW por ese motivo, bueno me parece que yo los tenía como via REP (repetidor) asi que edité el adif cambiando REP por RPT y tampoco me lo aceptaba, no supe que hacer.
Lo curioso es que contactos más antiguos hechos via repetidor hasta ahora los subí siempre sin problema, me da que deben haber modificado algo en la última versión del software... :unsure:

Visita mi Radio-Web: https://EA7P.ure.es

ResponderCitar
EA4YG
Mensajes: 475
#271027  - 6 marzo, 2015 08:24 
EA7AHA escribió:
También a mi el otro dia me echó para atrás varios contactos en LOTW por ese motivo, bueno me parece que yo los tenía como via REP (repetidor) asi que edité el adif cambiando REP por RPT y tampoco me lo aceptaba, no supe que hacer.
Lo curioso es que contactos más antiguos hechos via repetidor hasta ahora los subí siempre sin problema, me da que deben haber modificado algo en la última versión del software... :unsure:

Es posible que si se trata de concursos el contacto en este tipo de PROP_MODE no sea admitido y lo rechace como error, de todas formas si algún dato no lo admite debe ignorarlo simplemente.

Lo que queda por aclarar es si solo rechaza el contacto en RPT (comunicando el error) y admite todos los demás o rechaza el LOG completo.

Saludos.

Antonio-EA4YG.

Nota: En RadioGes iba el PROP_MODE, por error, como REP pero en las últimas versiones ya va como RPT (error al teclear.... je,je,je).

ResponderCitar
EA4CYQ
Mensajes: 637
#271060  - 6 marzo, 2015 22:52 

Ya parece estar claro, en LOTW han eliminado RPT como PROP_MODE.

Prueba de ellos es que en la query para filtrar QSOs, no aparece la opción RPT.

Que le vamos a hacer.

Juan Antonio

ResponderCitar
Inició el tema
EA7P
 EA7P
Mensajes: 1008
#270986  - 9 marzo, 2015 11:24 

Claro eso explicaría porque siempre los he subido sin problemas y ahora no me los admitía.
Hombre el contacto que vaya via RPT es rechazado pero el resto no, es decir se rechazan contactos no validos pero el resto del LOG es admitido en LOTW sin problema, si usas el programita TQSL para subirlos te muestra un reporte de errores donde muestra los que no son válidos.

Visita mi Radio-Web: https://EA7P.ure.es

ResponderCitar
EA8TX
Mensajes: 60
#270987  - 9 marzo, 2015 15:11 

Hola,
Recientemente he subido mi log al Lotw e igualmente me rechazo algunos qso. Concretamente todos los qso via sat que tengo. Todos por la misma razón, no indicar el nombre del satélite en el campo propagación sat. Pongo un ejemplo :

Error: PROP_MODE = 'SAT' but no SAT_NAME on line 19991
QSO_DATE: 20131129
TIME_ON: 1752
CALL: G0VHS
BAND: 2m
FREQ: 145
BAND_RX: 10m
FREQ_RX: 29
MODE: SSB
PROP_MODE: SAT

Yo uso el VQlog, hasta ahora indicaba el nombre del satélite en el campo observaciones, nunca me fijé que hay una pestaña especifica para ello. La pregunta es, si este criterio es nuevo o siempre fue así exigir el nombre del satélite en el campo propagación para validar un qso.
73 Y DX DX DX
EA8TX
Fernando

ResponderCitar
EA4CYQ
Mensajes: 637
#271343  - 9 marzo, 2015 18:08 

Hola Fernando,

Desde que conozco LOTW y así lo indican las instrucciones de LOTW, para poder subir un contacto de satélite es imprescindible, aparte de lo que se pide para un QSO normal es:

BAND_RX: 70cm
PROP_MODE: SAT
SAT_NAME: FO-29

No conozco el VQLOG, pero por lo que parece el campo SAT_NAME no lo crea en el adif y entonces LOTW entiene que no está correcto.

Juan Antonio

ResponderCitar
Inició el tema
EA8TX
Mensajes: 60
#270988  - 9 marzo, 2015 18:33 

Hola Juan Antonio,
Gracias por responder. No es problema del VQlog, como decía, este tiene una pestaña especifica para introducir el nombre del satélite, yo desconocía esto y siempre puse el nombre del satélite en observaciones. El caso es que hablando con otro usuario de Lotw, también con VQlog y también poniendo el nombre en el campo observaciones no había tenido problemas para subir los qso, quizás le entendi mal. En cualquier caso, entiendo por tu respuesta que siempre fue así y es ese el criterio de Lotw para validar un qso vía SAT, lo que me parece cuando menos curioso, pues no veo que aporta esa info para validar un qso, es como si en un qso por MS tienes que añadir obligatoriamente el nombre de la lluvia tipo " Perseidas " o " Liridas " .
En cualquier caso, parece este el criterio de lotw así que no me queda más remedio que editar manualmente uno a uno más de 700 qso, lo que no me agrada, pero va a ser la única forma de subir esos qso.
Repito, gracias por la aclaración Jose Antonio.
73 Y DX DX DX
EA8TX
Fernando

ResponderCitar

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