Cómo enviamos SMS desde la cueva



Una vez que mi colega Peter sugirió participar en un proyecto interesante: la creación de un "teléfono cueva para espeleólogos", ya que está interesado en la espeleología. Los espeleólogos tienen ese problema: la comunicación inalámbrica subterránea no funciona en la práctica. La recepción de radio aceptable solo es posible en la línea de visión, pero vale la pena un par de vueltas y no hay conexión. Y necesita comunicarse a través de la cueva, cuya longitud puede ser de varios kilómetros. Por supuesto, la comunicación móvil no atrapa allí, lo que significa que no hay conexiones con el mundo exterior para grupos que trabajan de forma autónoma en la cueva durante varias semanas.

En agosto de 2018, Peter debía participar en una expedición a una cueva bastante compleja y peligrosa. Para esta expedición, decidimos desarrollar un nuevo dispositivo que resolvería el problema de conectar grupos de trabajo autónomos con el mundo exterior.

Descripción de la idea.


Los espeleólogos tienen "teléfonos de cueva" que funcionan a través de un cable de campo (generalmente esto es p-274), extendido a lo largo de toda la cueva, algo como esto:


(C) Pavel Rudko, TP17 Nedra, producción Krasnoyarsk.

La idea era conectar un teléfono subterráneo a un teléfono inteligente y comunicarse con el mundo exterior a través de una "estación base" celular en la superficie. Para poder enviar SMS a parientes, amigos y parientes desde debajo del suelo, solicite un pronóstico del tiempo en la superficie, para que en caso de duchas con anticipación salga a la superficie.

Peter y otros espele√≥logos planearon descender al fondo del sistema Snezhnaya , que se encuentra en Abjasia y que una vez fue el segundo sistema de cuevas m√°s profundo del mundo. Planearon pasar por la entrada inferior, la cueva del Banco. Desde el punto de vista de uno de los principales peligros de la cueva, las inundaciones, lanzarse al fondo de esta manera es mucho m√°s seguro que todas las otras rutas conocidas, pero a√ļn debe superar una secci√≥n muy peligrosa: las cascadas rugientes. Es completamente intransitable en la inundaci√≥n de 250 metros a lo largo del r√≠o subterr√°neo. Antes de pasar por esta secci√≥n, quer√≠amos saber el clima en la superficie.

Desde el campamento subterráneo autónomo, en el que se planeó vivir durante dos semanas, hasta la salida más cercana a la superficie, a 3.5 km del camino, con una diferencia de altura de 800 m. Una línea de comunicación subterránea ya estaba equipada en toda la ruta con otros grupos trabajando en la cueva; fue extendida por un campo cable P-274. Planeamos usar esta línea en nuestra idea.

Quedaba por construir un par de dispositivos: el control deber√≠a estar en el grupo en la cueva, el controlado, en la superficie en la zona de recepci√≥n confiable de la se√Īal GSM. Y era necesario encontrar una forma de comunicaci√≥n para ellos. El dispositivo administrado debe recibir comandos del administrador y poder recibir y enviar SMS. Una condici√≥n importante fue la autonom√≠a completa del dispositivo en la superficie durante dos semanas, es decir, el t√©rmino completo de la expedici√≥n, ya que nadie nos estaba esperando en la entrada de la cueva. No hab√≠a nadie para recargar, reemplazar las bater√≠as o reiniciar el dispositivo.

En el desarrollo participó:

  • Koveshnikov Peter - autor de la idea, iniciador, desarrollo de la parte de software.
  • Matveev Lyubomir - montaje, instalaci√≥n, cableado de placas transceptoras.
  • Shelepin Sergey - dise√Īo de transceptor.

El esquema general es el siguiente. Una estaci√≥n base est√° instalada en la superficie, funciona con una bater√≠a cargada por una bater√≠a solar, debe funcionar durante al menos dos semanas, teniendo en cuenta la duraci√≥n promedio de los viajes a las cuevas, y debe ser aut√≥noma para que no requiera la atenci√≥n de las personas. La persona a continuaci√≥n puede, con la ayuda de una pinza de cocodrilo o una terminal atornillada, unirse en cualquier lugar de la l√≠nea (cable de campo estirado en las cuevas) y establecer la conexi√≥n del tel√©fono subterr√°neo con la estaci√≥n terrestre. Est√° en modo de "suspensi√≥n", peri√≥dicamente "se despierta" y recibe se√Īales de servicio. El modo de suspensi√≥n es necesario para ahorrar energ√≠a de la bater√≠a, ya que el sol no siempre existe para alimentar la bater√≠a.

Y ahora algunos detalles técnicos.

Implementación de la idea.


El complejo utilizado por nosotros en esta expedición fue el siguiente:

  1. Dos teléfonos inteligentes con Android que ejecutan un programa especialmente escrito.
  2. Dos transceptores de dise√Īo propio, conectados a la l√≠nea subterr√°nea y a los puertos de audio de los tel√©fonos.
  3. El campo de campo doble P-274 de unos 3600 m de largo, extendido a una profundidad de 800 m.
  4. Teléfono de superficie complejo de energía.
    1. Banco de energía para alimentar un teléfono "de superficie".
    2. Arduino , que reinicia el proceso de cargar el teléfono desde el banco de energía.
    3. Panel solar para cargar el banco de potencia.



Tomaron como base el circuito de un tel√©fono normal, solo que en lugar de una persona, el tel√©fono inteligente mismo recibe y transmite comandos. Para comunicarse entre s√≠, los dispositivos intercambian secuencias de se√Īales de sonido: tonos DTMF (se√Īal anal√≥gica multifrecuencia de doble tono con 16 tonos). El canal es half duplex. Para transferir los datos en s√≠, se utilizan 9 tonos de 16, y los 7 restantes son tonos de servicio, por ejemplo, indican el comienzo / final de un mensaje / secuencia, una se√Īal de reinicio de emergencia, etc. La duraci√≥n de los tonos DTMF, y por lo tanto la velocidad de transmisi√≥n, var√≠a de 1 tono por segundo a 15 tonos por segundo. Excluyendo pausas t√©cnicas, esto corresponde a 0.3-5.5 bytes por segundo. Los tel√©fonos inteligentes que usan la biblioteca dtmf-cpp convierten el texto en tonos y viceversa.




Los transceptores se conectan a los tel√©fonos a trav√©s de un conector de audio de 3,5 mm mediante un miniconector de 4 pines, como un auricular normal. Cualquier se√Īal de audio que el tel√©fono quiera reproducir va al transceptor, y todo lo que sucede en la l√≠nea se amplifica y transmite al tel√©fono a trav√©s del canal del micr√≥fono. Adem√°s de amplificar la se√Īal de entrada, el transceptor a√≠sla el tel√©fono de la l√≠nea para evitar da√Īos debido a sobretensiones accidentales. Adem√°s, el transceptor controla la separaci√≥n del medio de transmisi√≥n. Cuando el tel√©fono intenta reproducir algo, el transceptor conecta el canal de audio izquierdo del tel√©fono a la l√≠nea, el resto del tiempo el canal del micr√≥fono est√° conectado a la l√≠nea, a la cual est√° conectada la tierra. Cuando es necesario transmitir, el software env√≠a una se√Īal a√©rea al canal derecho para que el transceptor cambie al modo de transmisi√≥n.

Puede escuchar cómo se comunican nuestros transceptores aquí: cloud.mail.ru/public/JAjQ/wuF4XMm4W

Se inicia un programa autoescrito en los tel√©fonos, escuchando el canal de comunicaci√≥n en anticipaci√≥n de ciertas se√Īales o entrada del usuario a trav√©s de la interfaz. Algoritmo de transferencia de datos:

  1. El usuario en el tel√©fono de control selecciona el comando deseado en el men√ļ.
  2. El programa genera una solicitud en forma de una secuencia de bytes.
  3. Una secuencia se divide en secuencias de no más de 16 bytes, se agrega una suma de verificación a cada una de ellas y luego las secuencias de bytes se codifican en una secuencia de tonos DTMF. Se agregan dos secuencias de servicio al conjunto de secuencias de tonos, que indican el comienzo y el final del grupo de secuencias.
  4. Cada secuencia está codificada en PCM 16bit 8000 / s mono y se reproduce por teléfono.
  5. Cada secuencia es le√≠da por un tel√©fono controlado, decodificada, verificada por errores y, dependiendo del resultado, se env√≠a una se√Īal de recepci√≥n exitosa o no exitosa.
  6. Despu√©s de recibir una se√Īal de confirmaci√≥n, el tel√©fono administrado transmite la siguiente secuencia o repite la actual.
  7. Cuando todas las secuencias se reciben con éxito, el teléfono administrado recopila un flujo de bytes de las secuencias, lo decodifica en un comando y lo ejecuta.

La transferencia de datos desde un teléfono administrado a un administrador se realiza de acuerdo con el mismo algoritmo.

El video está disponible aquí: https://drive.google.com/file/d/1Y4O5R1Hce0S_djni-B1k5_B9Lw7uRlyp/view?usp=sharing


Ejemplo: un hombre en una cueva en su tel√©fono inteligente en el programa selecciona el comando "Enviar SMS", ingresa el n√ļmero de tel√©fono al que desea enviar un mensaje y su texto. Todos estos datos est√°n codificados por medio de se√Īales DTMF, transmitidas en modo de tono por cable a la superficie, donde otro tel√©fono las decodifica y env√≠a un SMS al n√ļmero especificado a trav√©s de su tarjeta SIM. Con la retroalimentaci√≥n, el mismo patr√≥n es aproximadamente el mismo: el tel√©fono se despierta peri√≥dicamente, sale del modo avi√≥n, recibe los SMS acumulados del operador y los almacena en su sala de espera hasta que el comando de servicio "darme SMS" proviene de las cuevas. Todo lo que se acumula, el tel√©fono inteligente transmite por la l√≠nea.

Fuente de alimentación


Todo el complejo durante la expedición debe comer algo. No hay problemas para alimentar el teléfono subterráneo: tanto el teléfono como el transceptor tienen una batería incorporada, durante el uso, el consumo no es demasiado grande, el resto del tiempo están apagados. Con el poder de un teléfono controlado "de superficie", la situación es mucho más complicada: necesita permanecer en condiciones de trabajo durante al menos dos semanas.

Si el tel√©fono inteligente escucha continuamente la l√≠nea e incluso se conecta a la red GSM, durar√° varias horas y el panel solar no resolver√° este problema, ya que proporciona menos energ√≠a de la que consume el tel√©fono inteligente y el banco de energ√≠a solo extender√° el tiempo de trabajo por un d√≠a dos. Tuve que hacer un modo de espera en el que no se toca la l√≠nea, y tambi√©n activar el modo avi√≥n. Despu√©s de 5 minutos de inactividad, el programa se queda dormido y se despierta cada 10 minutos durante 15 segundos, esperando una se√Īal especial de activaci√≥n. El modo avi√≥n se apaga 6 veces al d√≠a durante 10 minutos para recibir SMS. El problema es que administrar el modo avi√≥n requiere para la aplicaci√≥n derechos elevados que no se pueden obtener sin rootear el tel√©fono. Todas las dem√°s funcionalidades de la aplicaci√≥n, no relacionadas con el ahorro de energ√≠a, no requieren derechos elevados y funcionan en cualquier tel√©fono con Android 4.1 y superior.

Pruebas de campo y planes


En esta expedición, Peter y un equipo de espeleólogos probaron los dispositivos por primera vez en el campo. Por supuesto, hubo algunos problemas. La solicitud fue escrita muy rápidamente, en la rodilla, porque la expedición se estaba quedando sin tiempo.

Hubo dos grandes problemas de software, el problema con la fuente de alimentación del aparato de "superficie" y el sellado del complejo de "superficie", el problema con el conector. Los muchachos estaban listos para la mayoría de los problemas y usaban opciones de respaldo preparadas previamente, con algo para improvisar sobre la marcha. De una forma u otra, el sistema funcionó, pudimos realizar pruebas completas. El segundo grupo, que permaneció en el fondo de la cueva, para investigar el primer ascenso después de la partida de la parte principal de la expedición, informó sobre los resultados y también se enteró del clima actual y el pronóstico. Casi todos los problemas y defectos detectados se solucionaron fácilmente y los corregimos para la próxima expedición a Snezhnaya, que tuvo lugar en diciembre de 2018 - enero de 2019.

Durante las pruebas, descubrimos la tasa de transferencia de datos m√°xima estable. No difiere de la velocidad m√°xima estable obtenida en condiciones de laboratorio al conectar los dispositivos directamente entre s√≠. La se√Īal transmitida a trav√©s de la l√≠nea de comunicaci√≥n que se extend√≠a a trav√©s de la cueva no se distorsion√≥ de ninguna manera, no se not√≥ ning√ļn ruido extra√Īo de volumen comparable. Solo ligeramente con la profundidad de descenso, el volumen de la se√Īal cay√≥. Debido a problemas de software, tambi√©n fue posible verificar la operaci√≥n en condiciones de una se√Īal intermitente, ‚Äútartamudeante‚ÄĚ distorsionada, en la cual, a primera vista, no se puede lograr una transmisi√≥n exitosa. Sin embargo, fue posible seleccionar un modo operativo en el que, incluso en tales condiciones, se admite la comunicaci√≥n entre los dos dispositivos, lo que sugiere la estabilidad potencialmente muy alta del protocolo de transmisi√≥n que creamos.

Originalmente se plane√≥ usar un banco de energ√≠a para alimentar el tel√©fono superior. Result√≥ que el banco de energ√≠a que ten√≠amos hab√≠a cargado el tel√©fono al 100% y apagado. Para inicializar la carga nuevamente, ten√≠a que quitar el cable del banco de energ√≠a e insertarlo nuevamente, de lo contrario no entendi√≥ que el tel√©fono se hab√≠a sentado y era hora de emitir energ√≠a nuevamente. Faltaban un par de d√≠as antes de la expedici√≥n. No se me ocurri√≥ nada mejor que enga√Īar a Arduino.


Video: cloud.mail.ru/public/76ay/F5xinJZQi

Seg√ļn el cronograma de Arduino, cada tres horas, usando un rel√©, rompi√≥ el canal + 5v del cable USB del banco de energ√≠a del banco de energ√≠a y lo volvi√≥ a encender despu√©s de 15 minutos. Al principio, la placa funcionaba con 4 bater√≠as AA, y luego adaptaron el compartimiento de la bater√≠a con cuatro latas 18650. Esto result√≥ ser el eslab√≥n m√°s d√©bil, porque fueron las bater√≠as que alimentaron el Arduino las primeras en agotarse. Pero algunas veces ella trabajaba. El primer grupo de la expedici√≥n, que ascendi√≥ a la superficie, cambi√≥ las bater√≠as y el sistema funcion√≥ durante otra semana.

Continuamos nuestros experimentos: hay una versión funcional del teléfono donante, al que se suelda un gran bloque con 18650 a través de una abertura en la carcasa. ¡El teléfono está en modo de espera y las baterías se descargaron solo después de 26.5 días!





Por lo tanto, en el futuro es probable que abandonemos el panel solar, que también es un eslabón débil: puede espolvorearse con polvo o nieve, salpicado de tierra. Durante las tres semanas de la expedición con un voltaje de operación de 4.6 V de las baterías para el transceptor, el "superior" se descargó a 3.8 V y el "inferior" a 4.1 V.

La versión actual de nuestro transceptor no sabe cómo funcionar como un teléfono normal. Queremos finalizar el esquema para que pueda usar el transceptor sin un teléfono inteligente en el modo habitual de "teléfono de la cueva": presione - diga, suelte, escuche.

Ahora el software solo admite la recepción y transmisión de SMS, así como varios comandos de servicio. El protocolo de transferencia de datos no impone ninguna restricción, excepto el ancho de banda, por lo que es relativamente fácil programar la descarga de pronósticos meteorológicos de Internet o, por ejemplo, enviar mensajes a mensajeros instantáneos. Desafortunadamente, la velocidad de transferencia no es suficiente para acceder completamente a Internet y transferir imágenes. La velocidad máxima estable ahora es de aproximadamente 6 bytes por segundo. En un canal estable, se tarda aproximadamente 1 minuto en enviar o recibir un SMS en 160 caracteres cirílicos.

Para la pr√≥xima expedici√≥n, planeamos finalizar el software agregando las funciones que faltan y corrigiendo errores, as√≠ como reelaborar el sistema de energ√≠a del complejo "de superficie". Ya se implement√≥ la funci√≥n de hacer sonar la l√≠nea: una vez por minuto se da una se√Īal de servicio para verificar la l√≠nea en busca de interrupciones. Tambi√©n agregamos funciones de servicio como la configuraci√≥n de velocidad manual, reinicio forzado y otras peque√Īas cosas. Quiz√°s entonces hagamos que el tel√©fono se conecte y descubra el pron√≥stico del tiempo. Me gustar√≠a conectar mi propia estaci√≥n meteorol√≥gica a un tel√©fono de superficie, recopilado, posiblemente, basado en Arduino y enviar datos actualizados de sensores a lo largo de la l√≠nea.

Source: https://habr.com/ru/post/438272/


All Articles