Me uno al hilo para proponer algo que puede interesar llevar a cabo.Si bien las pruebas que estoy haciendo yo son con un teléfono siemens que admite comandos AT y que no tiene que ver con las tramas con las que estáis trabajando,creo que lo que surja puede servir en general para cualquier tipo de móvil,sea cual sea el protocolo de comunicación que use.
El propósito es implementar las rutinas necesarias para decodificar una trama PDU correspondiente a un SMS entrante,así como también hacerlo a la inversa,es decir,construir un SMS para que nuestro teléfono lo envíe y al que podemos introducirle parámetros tales como el estado de entradas,salidas,etc..
Aquí les pongo un ejemplo de trama PDU correspondiente a un sms recibido por el móvil:
07 91 4306073011F0 04 0B 91 4306600165F5 00 00 40400330651200 08 C8373B8C7EB3C3
(He separado los bloques para que se vea mejor)
07 -- Longitud de la información SMSC (número de octetos)
91 -- Tipo del SMSC (standar)
34607003110 -- Centro emisor mensajes (octetos traspuestos con la F añadida)
04 -- Primer octeto del SMS deliver (standar)
0B -- Longitud número emisor (11 dígitos)
91 -- Tipo del número emisor (standar)
34600610565 -- Numero emisor (octetos traspuestos con la F añadida)
00 -- Identificador de protocolo (standar)
00 -- Datos de codificación del mensaje (standar)
04-04-30-03-56-21-00 (año-mes-dia-horas-minutos-segundos-zona horaria)
08 -- Longitud del mensaje (septetos)
C8 37 3B 8C 7E B3 C3 -- texto del mensaje (octetos de 8 bits,representando datos de 7 bits)
De todo este chorro de caracteres hexadecimales,lo que nos puede servir,a mi juicio,son la fecha,la hora,el número remitente,el número del centro de mensajes y el texto del mensaje.El resto se puede deshechar.En el caso de tener guardada toda la trama en un buffer en RAM como tengo hecho yo,sólo es cuestión de ir recorriendo dicho buffer e ir sacando lo que nos interesa para pos teriormente tratarlo.
El 7º bloque de la trama es el número que nos envía el sms:
4306600165F5
Sólo hay que separar los octetos,darles la vuelta y ya lo tenemos:
4306600165F5 -> 43 06 60 01 65 F5 -> 34 60 06 10 56 5F
-> 600610565 (el 34 es para España) la F se añade al final para que el último octeto no se quede cojo en el caso de que sea un número impar de dígitos.
Para la fecha y la hora sería exactamente lo mismo,y también para el número del centro de mensajes (SMSC).
Lo único que queda es el texto del mensaje y aquí viene lo complicado.
Como apuntó Sispic al comienzo del post,los caracteres del texto
con los que trabajan los móviles son caracteres de 7 bits (del 0 al 127);pueden echar un vistazo a este link para saber de que va:
http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.htmlPues bien,esta codificación a 7 bits no se corresponde exactamente con la tabla ASCII estándar.
Si bien el carácter "N" (así como otros muchos) tiene el mismo código (78,en binario 01001110) tanto en ASCII como en codificación a 7 bits,hay otros mucho caracteres que no disfrutan de esta coincidencia.
Un ejemplo es el carácter "$",cuyo código ASCII es el 36,mientras que su código a 7 bits es el 2.
El último bloque de la trama C8373B8C7EB3C3 consta de 7 octetos C8 37 3B 8C 7E B3 C3,que realmente representan los 8 caracteres que el remitente ha escrito.Esto se debe al modo de concatenar las palabras de 7 bits para convertirlas en octetos de 8 bits(7 octetos por cada 8 caracteres).
Pues lo que hay que hacer con estos octetos es:
1º- Pasarlos a binario (quizá no haga falta).
2º- Deshacer la concatenación para obtener los caracteres a
7bits...ahora tendremos 8 caracteres.
3º- Cambiar cada código 7 bits por su correspondiente ASCII
Después de esto,se supone que ya tenemos una cadena de caracteres que el ordenador o el pic pueden entender y procesar
Pues creo que de momento es todo ¡¡¡menudo rollo acabo de soltar!!!
Saludos a todos!!
