Re: [Talk-es] Traducción longitudes

2012-04-18 Por tema Maria Arias de Reyna 
El Martes, 17 de abril de 2012, Rafael Avila Coya escribió:
 En 17/04/12 20:09, Iván Sánchez Ortega escribiu:
  On Martes, 17 de abril de 2012 19:41:38 Jonay Santana escribió:
  D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6”
  D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8”
  D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5”
  D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0”
  D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8”
  
  [...]
  
  El 0 que tiene inmediatamente a la izquierda de los corchetes *creo*
  que puede indicar el signo, para latitudes N sería 0, y para latitudes
  S sería F.
  
  Eso se llama complemento a 2 en binario, el 0 o la F es parte del número
  (el número son 6 caracteres hexadecimales, no 5).
  
  Así asumí que la longitud estaría entre las llaves:
  D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del
  signo sí tendría sentido, la F anterior sería el menos, pero el 787AF
  no es la longitud, al menos no sin transformarla de alguna manera que
  aún no pillo.
  
  Prueba 1024*1024-hex2dec(0x787af), a ver si te cuadra.
 
 Uy, por poco...
 
 1024*1024-hex2dec(0x787af) = 555089, pero
 15º 25’ 56.8” = 68 décimas de segundo...
 
 Una diferencia de 47.9 segundos :-/


No descartes que eso sea un error de redondeo en alguna parte del decodificador 
que está usando el programa. 

-- 
María Arias de Reyna Domínguez
Área de Operaciones

Emergya Consultoría 
Tfno: +34 954 51 75 77 / +34 607 43 74 27
Fax: +34 954 51 64 73 
www.emergya.com

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-18 Por tema Jonay Santana 
Uf, 47.9 segundos son demasiados metros de error donde me encuentro...

Voy a copiar algunas tramas más, junto con la longitud que la
aplicación me dice que tiene el vehículo para ese momento preciso.
Encontré uno en un garaje, que se movía poco, con lo que las
longitudes son casi iguales (a veces incluso lo son, pero no así el
dato que el vehículo mandó).

01 D0304205E00F73E2F77A192A5B001A88 - 2012.01.01-00.23.32 = NO ESTÁ
02 D0304205A00F748CF77A8B2B6D001A87 - 2012.01.01-00.22.32 = -15º25’53.3”
03 D0304205600F7562F77AB2326B001A86 - 2012.01.01-00.21.32 = NO ESTÁ
04 D0304205200F7588F77B924B8D001A86 - 2012.01.01-00.20.32 = -15º25’56.3”
05 D0304204E00F7514F77D76509D001A84 - 2012.01.01-00.19.32 = NO ESTÁ
06 D0304204A00F7471F77F03507A001A83 - 2012.01.01-00.18.32 = -15º25’56.3”
07 D0304204600F7374F78067539D001A82 - 2012.01.01-00.17.32 = NO ESTÁ
08 D0304204200F736AF782234A80001A80 - 2012.01.01-00.16.32 = -15º25’56.3”
09 D0304203E00F7351F783E94988001A7F - 2012.01.01-00.15.32 = NO ESTÁ
10 AF304203A00F738FF785A6351A7E - 2012.01.01-00.14.32 = -15º25’56.5”
11 D0304203600F733CF7867D4DA3001A7D - 2012.01.01-00.13.32 = NO ESTÁ
12 D0304203200F71E2F787B050A3001A7C - 2012.01.01-00.12.32 = -15º25’56.5”
13 D0304202E00F7055F752A8001A7B - 2012.01.01-00.11.32 = NO ESTÁ
14 D0304202A00F6EA6F788985208001A79 - 2012.01.01-00.10.32 = -15º25’56.3”
15 D0304202600F6D28F7880E4CAF001A78 - 2012.01.01-00.09.32 = NO ESTÁ
01 D030420A600F70ABF77B922127001A8D - 2012.01.01-00.41.32 = NO ESTÁ
02 D030420A200F7134F77B382911001A8C - 2012.01.01-00.40.32 = -15º25’56.3”
03 D0304209E00F7127F77AD81301001A8C - 2012.01.01-00.39.32 = NO ESTÁ
04 D0304209A00F712CF77A8E1A41001A8B - 2012.01.01-00.38.32 = -15º25’56.5”
05 D0304209600F716DF77A00193A001A8B - 2012.01.01-00.37.32 = NO ESTÁ
06 D0304209200F71C4F779872B22001A8B - 2012.01.01-00.36.32 = -15º25’56.3”
07 D0304208E00F71C4F778E81D5D001A8A - 2012.01.01-00.35.32 = NO ESTÁ
08 D0304208A00F71D1F7791C0C9A001A8A - 2012.01.01-00.34.32 = -15º25’56.6”
09 D0304208600F71D1F7793F0051001A8A - 2012.01.01-00.33.32 = NO ESTÁ
10 D0304207E00F71CFF7793F0046001A8A - 2012.01.01-00.31.32 = NO ESTÁ
11 D0304207600F71D0F7793F0044001A8A - 2012.01.01-00.29.32 = NO ESTÁ
12 D0304206E00F71D1F779400042001A8A - 2012.01.01-00.27.32 = NO ESTÁ
13 D0304206A00F71E3F7794B0060001A8A - 2012.01.01-00.26.32 = -15º25’56.1”
14 D0304206600F71E9F779BC3473001A89 - 2012.01.01-00.25.32 = NO ESTÁ
15 D0304206200F72DFF77A383755001A88 - 2012.01.01-00.24.32 = -15º25’56.1”

  Me ha llamado la atención que la aplicación desecha posiciones que
el vehículo sí que ha mandado (son las que he puesto como NO ESTÁ,
cosa que desconocía.

  Voy a seguir investigando, si a alguien se le ocurre algo, le estaré
eternamente agradecido. :)

El 18/04/12, Maria Arias de Reyna mar...@emergya.com escribió:
 El Martes, 17 de abril de 2012, Rafael Avila Coya escribió:
 En 17/04/12 20:09, Iván Sánchez Ortega escribiu:
  On Martes, 17 de abril de 2012 19:41:38 Jonay Santana escribió:
  D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6”
  D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8”
  D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5”
  D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0”
  D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8”
 
  [...]
 
  El 0 que tiene inmediatamente a la izquierda de los corchetes *creo*
  que puede indicar el signo, para latitudes N sería 0, y para latitudes
  S sería F.
 
  Eso se llama complemento a 2 en binario, el 0 o la F es parte del número
  (el número son 6 caracteres hexadecimales, no 5).
 
  Así asumí que la longitud estaría entre las llaves:
  D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del
  signo sí tendría sentido, la F anterior sería el menos, pero el 787AF
  no es la longitud, al menos no sin transformarla de alguna manera que
  aún no pillo.
 
  Prueba 1024*1024-hex2dec(0x787af), a ver si te cuadra.

 Uy, por poco...

 1024*1024-hex2dec(0x787af) = 555089, pero
 15º 25’ 56.8” = 68 décimas de segundo...

 Una diferencia de 47.9 segundos :-/


 No descartes que eso sea un error de redondeo en alguna parte del
 decodificador
 que está usando el programa.

 --
 María Arias de Reyna Domínguez
 Área de Operaciones

 Emergya Consultoría
 Tfno: +34 954 51 75 77 / +34 607 43 74 27
 Fax: +34 954 51 64 73
 www.emergya.com

 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-es



-- 

Jonay

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-18 Por tema Benjamín Valero Espinosa 
El 18 de abril de 2012 11:43, Jonay Santana jonay.sant...@gmail.comescribió:

 Uf, 47.9 segundos son demasiados metros de error donde me encuentro...

 Voy a copiar algunas tramas más, junto con la longitud que la
 aplicación me dice que tiene el vehículo para ese momento preciso.
 Encontré uno en un garaje, que se movía poco, con lo que las
 longitudes son casi iguales (a veces incluso lo son, pero no así el
 dato que el vehículo mandó).

 01 D0304205E00F73E2F77A192A5B001A88 - 2012.01.01-00.23.32 = NO ESTÁ
 02 D0304205A00F748CF77A8B2B6D001A87 - 2012.01.01-00.22.32 = -15º25’53.3”
 03 D0304205600F7562F77AB2326B001A86 - 2012.01.01-00.21.32 = NO ESTÁ
 04 D0304205200F7588F77B924B8D001A86 - 2012.01.01-00.20.32 = -15º25’56.3”
 05 D0304204E00F7514F77D76509D001A84 - 2012.01.01-00.19.32 = NO ESTÁ
 06 D0304204A00F7471F77F03507A001A83 - 2012.01.01-00.18.32 = -15º25’56.3”
 07 D0304204600F7374F78067539D001A82 - 2012.01.01-00.17.32 = NO ESTÁ
 08 D0304204200F736AF782234A80001A80 - 2012.01.01-00.16.32 = -15º25’56.3”
 09 D0304203E00F7351F783E94988001A7F - 2012.01.01-00.15.32 = NO ESTÁ
 10 AF304203A00F738FF785A6351A7E - 2012.01.01-00.14.32 = -15º25’56.5”
 11 D0304203600F733CF7867D4DA3001A7D - 2012.01.01-00.13.32 = NO ESTÁ
 12 D0304203200F71E2F787B050A3001A7C - 2012.01.01-00.12.32 = -15º25’56.5”
 13 D0304202E00F7055F752A8001A7B - 2012.01.01-00.11.32 = NO ESTÁ
 14 D0304202A00F6EA6F788985208001A79 - 2012.01.01-00.10.32 = -15º25’56.3”
 15 D0304202600F6D28F7880E4CAF001A78 - 2012.01.01-00.09.32 = NO ESTÁ
 01 D030420A600F70ABF77B922127001A8D - 2012.01.01-00.41.32 = NO ESTÁ
 02 D030420A200F7134F77B382911001A8C - 2012.01.01-00.40.32 = -15º25’56.3”
 03 D0304209E00F7127F77AD81301001A8C - 2012.01.01-00.39.32 = NO ESTÁ
 04 D0304209A00F712CF77A8E1A41001A8B - 2012.01.01-00.38.32 = -15º25’56.5”
 05 D0304209600F716DF77A00193A001A8B - 2012.01.01-00.37.32 = NO ESTÁ
 06 D0304209200F71C4F779872B22001A8B - 2012.01.01-00.36.32 = -15º25’56.3”
 07 D0304208E00F71C4F778E81D5D001A8A - 2012.01.01-00.35.32 = NO ESTÁ
 08 D0304208A00F71D1F7791C0C9A001A8A - 2012.01.01-00.34.32 = -15º25’56.6”
 09 D0304208600F71D1F7793F0051001A8A - 2012.01.01-00.33.32 = NO ESTÁ
 10 D0304207E00F71CFF7793F0046001A8A - 2012.01.01-00.31.32 = NO ESTÁ
 11 D0304207600F71D0F7793F0044001A8A - 2012.01.01-00.29.32 = NO ESTÁ
 12 D0304206E00F71D1F779400042001A8A - 2012.01.01-00.27.32 = NO ESTÁ
 13 D0304206A00F71E3F7794B0060001A8A - 2012.01.01-00.26.32 = -15º25’56.1”
 14 D0304206600F71E9F779BC3473001A89 - 2012.01.01-00.25.32 = NO ESTÁ
 15 D0304206200F72DFF77A383755001A88 - 2012.01.01-00.24.32 = -15º25’56.1”

  Me ha llamado la atención que la aplicación desecha posiciones que
 el vehículo sí que ha mandado (son las que he puesto como NO ESTÁ,
 cosa que desconocía.


¿Y el resto de datos sí los tienes relacionados y contrastados en varias
tramas (kilometrajes, hora, velocidad, latitud...)? Quizá dejando sólo los
bits que aún no sabes a qué se corresponden (que serán pocos ya), se vea
(lo veamos) más fácilmente. Las tramas a bote pronto tienen pinta de estar
ordenadas en varios sitios (los dos últimos bytes, y los de las posiciones
13-14), no sé si por casualidad o por algo en especial, porque con las
horas no se corresponden. Quizá quitando algo de bosque podamos ver el
árbol ;)
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-18 Por tema Jonay Santana 
Pues podando, la información de la longitud ha de estar en los
caracteres que no son X:

D030XX0FAXXXF70B03XX

¿Cómo lo sé? Lanzando una consulta en la base de datos que almacena
las posiciones, y buscando todas las que compartían longitud. Luego
cotejé esa información con lo que enviaron los vehículos en ese
instante, obtuve varias tramas, y con X enmascaré todo lo que no era
igual. Rudimentario, cierto, pero creo que correcto.

  Vamos a ver si encontramos el dichoso árbol... :D

El 18/04/12, Benjamín Valero Espinosa benjaval...@gmail.com escribió:
 El 18 de abril de 2012 11:43, Jonay Santana
 jonay.sant...@gmail.comescribió:

 Uf, 47.9 segundos son demasiados metros de error donde me encuentro...

 Voy a copiar algunas tramas más, junto con la longitud que la
 aplicación me dice que tiene el vehículo para ese momento preciso.
 Encontré uno en un garaje, que se movía poco, con lo que las
 longitudes son casi iguales (a veces incluso lo son, pero no así el
 dato que el vehículo mandó).

 01 D0304205E00F73E2F77A192A5B001A88 - 2012.01.01-00.23.32 = NO ESTÁ
 02 D0304205A00F748CF77A8B2B6D001A87 - 2012.01.01-00.22.32 = -15º25’53.3”
 03 D0304205600F7562F77AB2326B001A86 - 2012.01.01-00.21.32 = NO ESTÁ
 04 D0304205200F7588F77B924B8D001A86 - 2012.01.01-00.20.32 = -15º25’56.3”
 05 D0304204E00F7514F77D76509D001A84 - 2012.01.01-00.19.32 = NO ESTÁ
 06 D0304204A00F7471F77F03507A001A83 - 2012.01.01-00.18.32 = -15º25’56.3”
 07 D0304204600F7374F78067539D001A82 - 2012.01.01-00.17.32 = NO ESTÁ
 08 D0304204200F736AF782234A80001A80 - 2012.01.01-00.16.32 = -15º25’56.3”
 09 D0304203E00F7351F783E94988001A7F - 2012.01.01-00.15.32 = NO ESTÁ
 10 AF304203A00F738FF785A6351A7E - 2012.01.01-00.14.32 = -15º25’56.5”
 11 D0304203600F733CF7867D4DA3001A7D - 2012.01.01-00.13.32 = NO ESTÁ
 12 D0304203200F71E2F787B050A3001A7C - 2012.01.01-00.12.32 = -15º25’56.5”
 13 D0304202E00F7055F752A8001A7B - 2012.01.01-00.11.32 = NO ESTÁ
 14 D0304202A00F6EA6F788985208001A79 - 2012.01.01-00.10.32 = -15º25’56.3”
 15 D0304202600F6D28F7880E4CAF001A78 - 2012.01.01-00.09.32 = NO ESTÁ
 01 D030420A600F70ABF77B922127001A8D - 2012.01.01-00.41.32 = NO ESTÁ
 02 D030420A200F7134F77B382911001A8C - 2012.01.01-00.40.32 = -15º25’56.3”
 03 D0304209E00F7127F77AD81301001A8C - 2012.01.01-00.39.32 = NO ESTÁ
 04 D0304209A00F712CF77A8E1A41001A8B - 2012.01.01-00.38.32 = -15º25’56.5”
 05 D0304209600F716DF77A00193A001A8B - 2012.01.01-00.37.32 = NO ESTÁ
 06 D0304209200F71C4F779872B22001A8B - 2012.01.01-00.36.32 = -15º25’56.3”
 07 D0304208E00F71C4F778E81D5D001A8A - 2012.01.01-00.35.32 = NO ESTÁ
 08 D0304208A00F71D1F7791C0C9A001A8A - 2012.01.01-00.34.32 = -15º25’56.6”
 09 D0304208600F71D1F7793F0051001A8A - 2012.01.01-00.33.32 = NO ESTÁ
 10 D0304207E00F71CFF7793F0046001A8A - 2012.01.01-00.31.32 = NO ESTÁ
 11 D0304207600F71D0F7793F0044001A8A - 2012.01.01-00.29.32 = NO ESTÁ
 12 D0304206E00F71D1F779400042001A8A - 2012.01.01-00.27.32 = NO ESTÁ
 13 D0304206A00F71E3F7794B0060001A8A - 2012.01.01-00.26.32 = -15º25’56.1”
 14 D0304206600F71E9F779BC3473001A89 - 2012.01.01-00.25.32 = NO ESTÁ
 15 D0304206200F72DFF77A383755001A88 - 2012.01.01-00.24.32 = -15º25’56.1”

  Me ha llamado la atención que la aplicación desecha posiciones que
 el vehículo sí que ha mandado (son las que he puesto como NO ESTÁ,
 cosa que desconocía.


 ¿Y el resto de datos sí los tienes relacionados y contrastados en varias
 tramas (kilometrajes, hora, velocidad, latitud...)? Quizá dejando sólo los
 bits que aún no sabes a qué se corresponden (que serán pocos ya), se vea
 (lo veamos) más fácilmente. Las tramas a bote pronto tienen pinta de estar
 ordenadas en varios sitios (los dos últimos bytes, y los de las posiciones
 13-14), no sé si por casualidad o por algo en especial, porque con las
 horas no se corresponden. Quizá quitando algo de bosque podamos ver el
 árbol ;)



-- 

Jonay

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-18 Por tema Jose Luis Perez Diez 
El Wednesday 18 April 2012 11:43:31 Jonay Santana va escriure:
 Voy a copiar algunas tramas más, junto con la longitud que la
 aplicación me dice que tiene el vehículo para ese momento preciso.
 Encontré uno en un garaje, que se movía poco, con lo que las
 longitudes son casi iguales (a veces incluso lo son, pero no así el
 dato que el vehículo mandó).
 
 01 D0304205E00F73E2F77A192A5B001A88 - 2012.01.01-00.23.32 = NO ESTÁ

14 D0304206600F71E9F779BC3473001A89 - 2012.01.01-00.25.32 = NO ESTÁ
15 D0304206200F72DFF77A383755001A88 - 2012.01.01-00.24.32 = -15º25’56.1”


¿que datos deduce la aplicacion del stream? 

seria interesante que tene un trozo del stream de unas horas (tal como llega al 
servidor)
integro con la latitud i longitud observada ya por los datos que envias parece
que el sistema datos cada 60 segundos (aunque en le flujo nada parece indicar 
un timestamp en segundos ) ya que la unica parte que se incrementa 
constantemente 
lo hace de 0x40 (64)

(los bits  6:8 y 9:11 son compatibles con las cordenadas que te puede dar un 
vehiculo
 terrestre dos lecturas seguidas no se han de diferenciar en mas de un valor de 
11 bits)
 

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-18 Por tema Jonay Santana 
El 18/04/12, Jose Luis Perez Diez jl...@escomposlinux.org escribió:
 El Wednesday 18 April 2012 11:43:31 Jonay Santana va escriure:
 Voy a copiar algunas tramas más, junto con la longitud que la
 aplicación me dice que tiene el vehículo para ese momento preciso.
 Encontré uno en un garaje, que se movía poco, con lo que las
 longitudes son casi iguales (a veces incluso lo son, pero no así el
 dato que el vehículo mandó).

 01 D0304205E00F73E2F77A192A5B001A88 - 2012.01.01-00.23.32 = NO ESTÁ
 
14 D0304206600F71E9F779BC3473001A89 - 2012.01.01-00.25.32 = NO ESTÁ
15 D0304206200F72DFF77A383755001A88 - 2012.01.01-00.24.32 = -15º25’56.1”


 ¿que datos deduce la aplicacion del stream?

  En la base de datos se almacenan montones:

  + Identificador del vehículo (número entero)
  + Identificador de la flota
  + Timestamp
  + Latitud
  + Longitud
  + Velocidad
  + Kilómetros recorridos
  + Rumbo
  + Causa del registro (número entero)
  + Nivel de la batería (aunque no se muestra en la aplicación).
  + Satélites visibles / satélites usados
  + Niveles de temperatura

  Luego hay un par de campos más que no sé qué son, y casi siempre
están a cero o a nulo. Yo he descifrado la latitud (en las posiciones
10 a 15), la velocidad (en las posiciones 22 a 23), y los kilómetros
recorridos (30 y 31).

 (los bits  6:8 y 9:11 son compatibles con las cordenadas que te puede dar un
 vehiculo
  terrestre dos lecturas seguidas no se han de diferenciar en mas de un valor
 de 11 bits)

  Esta parte no la he entendido... :(

-- 

Jonay

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-17 Por tema Maria Arias de Reyna 
El Martes, 17 de abril de 2012, Jonay Santana escribió:
   Buenos días a todos. Recurro a la inteligencia colectiva de la
 lista, a ver si me pueden echar un cabo, porque lo que es la
 inteligencia individual de un servidor no da para mucho más. ;)
 
   A lo que vamos, estoy trabajando en un sistema de gestión de flotas
 que va actualizando posiciones de vehículos en un mapa, y los equipos
 envían su posición, velocidad, etc. en un formato de trama fijo.
 Aunque he descifrado parámetros como kilometrajes, velocidades, y
 latitudes, las longitudes se me atraviesan.
 
   Aquí van un par de dichas tramas:
 
 Trama 01: D0304202200F6BA1*F7880A*4A0E001A77
 Trama 02 D0304201E00F6A2F*F7878A*4007001A76
 Trama 03 D0304201A00F699E*F787B0*008A001A75
 Trama 04 D0304201200F699C*F787AE*006D001A75
 Trama 05 D0304200A00F699B*F787B2*0061001A75
 Trama 06 D0304200200F699F*F787AF*0057001A75
 
   Tengo claro que la longitud tiene que estar por narices en las
 posiciones que he destacado entre los asteriscos, pero no le veo
 lógica ninguna. Las latitudes simplemente estaban en décimas se
 segundo, pasadas a hexadecimal, e incrustadas en las tramas, pero las
 longitudes no me cuadran.
 
   ¿Alguna sugerencia? Agradecido que quedo de antemano...


Veamos, ¿de dónde salen esas tramas? ¿Es de un GPS? ¿Es del sistema de gestión 
de flotas? ¿Qué documentación tiene? ¿No te referencia ningún formato concreto? 
¿Por qué sabes que la longitud tiene que estar ahí? ¿No será que has 
descifrado alguna otra cosa mal?

-- 
María Arias de Reyna Domínguez
Área de Operaciones

Emergya Consultoría 
Tfno: +34 954 51 75 77 / +34 607 43 74 27
Fax: +34 954 51 64 73 
www.emergya.com

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-17 Por tema Rafael Avila Coya 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Quizá sería interesante que pusieses la longitud de cada trama, para así
poder discurrir cual es la forma de codificar la longitud que tiene ese
sistema. Es decir, poner algo así como:

F7880A = 18,45678 grados N
F7878A = 23,43269 grados S

etc.

Rafa Ávila.

En 17/04/12 16:14, Jonay Santana escribiu:
 -- Forwarded message --
 From: Jonay Santana jonay.sant...@gmail.com
 Date: Tue, 17 Apr 2012 15:14:26 +0100
 Subject: Re: [Talk-es] Traducción longitudes
 To: Maria Arias de Reyna mar...@emergya.com
 
 El 17/04/12, Maria Arias de Reyna mar...@emergya.com escribió:

 Veamos, ¿de dónde salen esas tramas?
 
   Eso es lo que recibe el servidor que almacena los datos de posición
 de los vehículos.
 
 ¿Es de un GPS? ¿Es del sistema de
 gestión
 de flotas?
 
   Pues sí, y también, sí. Lo envían los vehículos, y lo recibe el servidor.
 
 ¿Qué documentación tiene?
 
   Ninguna, ese es el problema.
 
 ¿No te referencia ningún formato
 concreto?
 
   Nada de nada. Sin documentación me tengo que dejar los ojos para
 sacarlo por mí mismo.
 
 ¿Por qué sabes que la longitud tiene que estar ahí?
 
   Porque sí puedo ver la latitud y la longitud en otra aplicación, y
 cotejando esta que se muestra con lo que el servidor recibe, tengo que
 descifrar lo que mandan los vehículos. He mirado todos los coches con
 la misma longitud, he comparado las tramas para esos instantes, y los
 únicos campos que no cambian son los que destaqué.
 
 ¿No será que has
 descifrado alguna otra cosa mal?
 
   Hombre, puede ser, pero estoy bastante seguro de que lo poco que
 tengo, lo tengo bien. He comprobado bastantes posiciones y concuerdan
 a la perfección. La que se me atraviesa es la longitud...
 
 


- -- 
- 

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPjZ7TAAoJEB3niTly2pPQwYEQAIepnyY1LrhKZzLBZaGZyC9j
Ya0lZsHmslO8YPhhTx7q49jyNN0sqTNUpWq5DHsUwuYEf9Tn99bMHel0x6w5B9vS
h2eNqUfiU2mL1KV7KhFkmeQLkwEuReV5d6QsepMvoZBKUq/ApvUwjom9t+ASHwK+
zftjncSKAqhXzIP4+aUI3GDo9Uzey1/yGz6p/+H/SLNoj1jV00MWeNZRGKqcPxmr
wOWLh8vqFDWo+5dVEZxUCBemQoh4X4Lkw7JxPRrGIL7Hn7x25gJkzsYT7QC45zlA
SaC/GKJ1cngtMftSoEwnB0yrJECMLgWvcye19mc0NZtyEL+KPGdtD880nOYxDDcM
FwfNbHCUL67Bep6j6yrgbaH2BOtVe5fV1Xg5FeUjCoOa+sDpYAYjcKsIB7fta+OP
BC0l7sFc+UJMqFA1qMSbH8wImcfSqAeaO82x6ylXqwFw0KsKKMetMHgRdUcs1AFx
Hj1eXftL+JrcYenOQPGRhnrM3DooTd1i4PxfXwHJ76TksTLm+4DM9WeIsBKuv4by
l/BBqGA7aoYSDFOjQCzF3p6+b3STwtleBZi7Bi7aPlZQTpwfHp7kcA3nB0pbh+Jq
fJiLaoOWilWSSchM3O8XXiG8zgIq0cW7eoFL9vhV8DjQ8FsfYnAqOLP/WIEsAY3C
yCP3956VlkFTCnkcfGwX
=dXYc
-END PGP SIGNATURE-

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-17 Por tema Jonay Santana 
El 17/04/12, Rafael Avila Coya ravilac...@gmail.com escribió:
 -BEGIN PGP SIGNED MESSAGE-
 Quizá sería interesante que pusieses la longitud de cada trama, para así
 poder discurrir cual es la forma de codificar la longitud que tiene ese
 sistema. Es decir, poner algo así como:

 F7880A = 18,45678 grados N
 F7878A = 23,43269 grados S
 etc.
 Rafa Ávila.

  Mucha razón, perdón por no haber puesto algo obvio. Ahí van las
tramas con sus longitudes:

D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6”
D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8”
D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5”
D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0”
D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8”

  Como decía antes, la latitud la ubiqué rápidamente, en una trama
normal estaría entre los corchetes, tal que así:

D0304200200[F699F]F787AF0057001A75 - F699F = 1010079 décimas de
segundo, que concuerda exactamente con la latitud que sé que tenía el
vehículo.

El 0 que tiene inmediatamente a la izquierda de los corchetes *creo*
que puede indicar el signo, para latitudes N sería 0, y para latitudes
S sería F. Así asumí que la longitud estaría entre las llaves:
D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del
signo sí tendría sentido, la F anterior sería el menos, pero el 787AF
no es la longitud, al menos no sin transformarla de alguna manera que
aún no pillo.

A ver si alguien en la lista me ilumina... Muchas gracias aunque sea
por intentarlo.

-- 

Jonay

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-17 Por tema José Luis Domingo López 
El Tuesday día 17 de April de 2012, a las 13:48:36 +0100,
Jonay Santana escribió:

 las longitudes se me atraviesan.
   Aquí van un par de dichas tramas:
 
 Trama 01: D0304202200F6BA1*F7880A*4A0E001A77
 Trama 02 D0304201E00F6A2F*F7878A*4007001A76
 Trama 03 D0304201A00F699E*F787B0*008A001A75
 Trama 04 D0304201200F699C*F787AE*006D001A75
 Trama 05 D0304200A00F699B*F787B2*0061001A75
 Trama 06 D0304200200F699F*F787AF*0057001A75
 
En primer lugar, decir que tú sí que sabes divertirte, hacer ingeniería
inversa de un protocolo o formato que a todas luces parece mejorable ;-)

Yo no puedo decir mucho, sólo dos cosas:

1. Parece que el texto entre asteriscos es hexadecimal, por lo tanto,
   cuatro bits por carácter, por lo tanto, máximo de 24 bits para representar
   la longitud, que tiene un rango de escala de 360 grados, o 180 grados
   positivos, y otros tantos negativos. Con 24 bits puedes codificar máximo
   2^24 combinaciones, de tal manera que la precisión máxima que
   teóricamente puedes obtener será de 360/16777216 = 0.077 segundos de grado.
   O pasado a metros, 4*1000/16777216 = 2.4 metros. Esa información
   puede ser de utilidad para deducir qué significa un valor.

2. ¿Existe la posibilidad, o tienes ya, datos contrastados de ubicación de
   algún vehículo junto con su trama asociada? Es decir, que para un vehículo
   tengas a la vez tramas indescifrables, y una posición GPS fiable, al menos,
   en un rango de unos 100 metros, debería ser suficiente. Si hay una
   ubicación fija conocida (parking de una base de operaciones) o similar
   puedes obtener esos datos sin necesidad de ayuda de terceros.

3. Abundando en lo anterior, lo ideal sería tener posiciones verificables
   con coordenadas GPS para puntos a igual latitud y longitudes distintas. Si
   sabes de algún trayecto y pasa por una carretera totalmente norte-sur,
   podrías valerte de esa información aún sin posiciones GPS válidas, gracias
   a la velocidad y la marca de tiempo.

En cualquier caso, habría que colgar a quien diseñó el sistema del palo
mayor, porque estas cosas se documentan. Salvo, claro está, que se diseñara
con la intención de tener al cliente cogido por los interfaces.

Un saludo.

-- 
José Luis Domingo López
Linux Registered User #189436 Linux Kubuntu 11.10 (Linux 
3.0.0-17-generic-pae)



signature.asc
Description: Digital signature
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-17 Por tema Iván Sánchez Ortega 
On Martes, 17 de abril de 2012 19:41:38 Jonay Santana escribió:
 D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6”
 D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8”
 D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5”
 D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0”
 D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8”
[...]
 El 0 que tiene inmediatamente a la izquierda de los corchetes *creo*
 que puede indicar el signo, para latitudes N sería 0, y para latitudes
 S sería F.

Eso se llama complemento a 2 en binario, el 0 o la F es parte del número (el 
número son 6 caracteres hexadecimales, no 5).

 Así asumí que la longitud estaría entre las llaves:
 D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del
 signo sí tendría sentido, la F anterior sería el menos, pero el 787AF
 no es la longitud, al menos no sin transformarla de alguna manera que
 aún no pillo.

Prueba 1024*1024-hex2dec(0x787af), a ver si te cuadra.


-- 
--
Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org

The more you tighten your grip, Tarkin, the more star systems will slip 
through your fingers.
  -- Princess Leia

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-17 Por tema Rafael Avila Coya 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

En 17/04/12 20:09, Iván Sánchez Ortega escribiu:
 On Martes, 17 de abril de 2012 19:41:38 Jonay Santana escribió:
 D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6”
 D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8”
 D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5”
 D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0”
 D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8”
 [...]
 El 0 que tiene inmediatamente a la izquierda de los corchetes *creo*
 que puede indicar el signo, para latitudes N sería 0, y para latitudes
 S sería F.
 
 Eso se llama complemento a 2 en binario, el 0 o la F es parte del número (el 
 número son 6 caracteres hexadecimales, no 5).
 
 Así asumí que la longitud estaría entre las llaves:
 D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del
 signo sí tendría sentido, la F anterior sería el menos, pero el 787AF
 no es la longitud, al menos no sin transformarla de alguna manera que
 aún no pillo.
 
 Prueba 1024*1024-hex2dec(0x787af), a ver si te cuadra.
 
 

Uy, por poco...

1024*1024-hex2dec(0x787af) = 555089, pero
15º 25’ 56.8” = 68 décimas de segundo...

Una diferencia de 47.9 segundos :-/

- -- 
- 

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPjeFiAAoJEB3niTly2pPQlDMQAIbmHwv/34e+SWAX+lELwDYr
LncC068j3AxM+Y5QzNzZVuG6IlUS4augjXRjefue/0aCATgJJK0YWrO0En2xRLj7
p7yYzlWSnpCWj3QB2YFTIYThaYqBQGmCZwW+BXg4lTv4sHt+GHstgJvjb7AeGdW8
hHA/xUouOuvGy68jH7vQNSCW1Syu516fVSGwEgKegUKUDZsmX5gIop/asLwOLye8
uohu64tD2rRvmsxlj55cdLU0vS1udJM0DXzNfjZnNaafBDs4zGc12vfPcsGiXGQc
EVKuISUi2wP2NZnhZShA1mnFwApTw2FdIpJMMNRnIPB41c1SKv5LZT3lh9XIk3rE
zTbNyGqkdcNPCBQMeupyFZbRhK3jAvPnzu7Qpijq4Whso0sDZ5ohtd1z7SzVsYma
K3veesTP0UIyEm79VeMsj4QCQv5JGut4TggKE/sfOObr2We8IJIlK66gq92GhYF7
ITpKd5G7kG/HGZ98DTkb8S2MJK3YrS0eoDsUzjqFueFz4h6gKNvn8RHon8m13DdS
FWeL5V6b4Yy5lc0GbR7b3uxUCCq64/wMlEG4lx27Z0uUSevKkMl9qBp4ODQRiIMZ
DJkM89K6Er46MyIbYqK6r+N8xC17lzDjBywkOcW4TglZhyycLIY+MBaINKy3Syea
53fUwK4Qc1+fC7uKL6kd
=NhPW
-END PGP SIGNATURE-

___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Traducción longitudes

2012-04-17 Por tema Benjamín Valero Espinosa 
El 17 de abril de 2012 19:41, Jonay Santana escribió:

  Mucha razón, perdón por no haber puesto algo obvio. Ahí van las
 tramas con sus longitudes:

 D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8”
 D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8”


Si no te has equivocado, estas dos tramas deberían coincidir en alguna
parte, suponiendo que la longitud hexadecimal esté expresada a nivel de
décimas de segundo como en la latitud. Lo único que coincide es el F787,
que no nos sirve porque también coincide en otros valores distintos :S Uff,
incluso estoy mirando en binario por si el corte estuviera en medio de
algún hexadecimal, pero ni por esas.

Si tienes suficientes datos y ganas, yo lo haría a lo bestia pasándolo todo
a binario y comparando los que sabes que coinciden, pero aún así puede ser
engañoso, porque lo mismo las dos del ejemplo realmente son 56,77'' y
56,82'' :(
___
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es