Once, my colleague Peter offered to take part in one interesting project - to create a “cave phone for speleologists,” since he himself is keen on speleology. Cavers have such a problem: wireless communication underground does not work in practice. Acceptable radio reception is possible only in the line of sight, but it is worth to go for a couple of turns - and there is no connection. And it is necessary to communicate throughout the cave, the length of which may be several kilometers. Mobile communication there, of course, does not catch, and therefore there is no connection with the outside world for groups that work autonomously in a cave for several weeks.

In August 2018, Peter was to take part in an expedition to a rather complex and dangerous cave. For this expedition, we decided to develop a new device that would solve the problem of communication between autonomously working groups and the outside world.

Description of the idea

Cavers have "cave phones" working through a field cable (usually p-274), stretched along the entire length of the cave, something like these:


(C) Pavel Rudko, TP17 Nedra, produced in Krasnoyarsk.

The idea was to connect the underground phone to the smartphone, and through the cellular “base station” on the surface to keep in touch with the outside world. So that you can send SMS to relatives, family and friends out of the ground, request a weather forecast on the surface in order to rise to the surface in case of heavy rains.

Peter and other speleologists planned to descend to the bottom of the Snowy system., located in Abkhazia and the former once the second deepest cave system in the world. Planned to go through the lower entrance, the cave of the Bank. From the point of view of one of the main cave dangers - floods, - going to the bottom by this route is much safer than all the other known routes, but one very dangerous section still has to be overcome - Roaring cascades. It is completely impassable in the flood 250 meters on the underground river. Before passing this site, we wanted to know the weather on the surface.

From the autonomous underground camp, where it was planned to live for two weeks, to the nearest exit to the surface of 3.5 km of the path, with a drop in height of 800 m. On the whole route, other groups working in the cave had already been equipped with an underground communication line - a field cable P-274. We planned to use this line in our idea.

It remained to construct a pair of devices: the controller should be located in the cave group, controlled - on the surface in the zone of reliable reception of the GSM signal. And it was necessary to think of a way of communication for them. The managed device must receive commands from the manager and be able to receive and send SMS. An important condition was the complete autonomy of the device on the surface for two weeks, that is, the entire duration of the expedition, since no one was waiting for us at the cave entrance. There was no one to recharge, replace the batteries or reboot the device.

In the development took part:

• Koveshnikov Peter - the author of the idea, the initiator, the development of the software.
• Matveyev Lubomir - assembly, installation, wiring of transceiver boards.
• Sergey Shelepin - designing transceivers.

The general scheme is as follows. A base station is installed on the surface, it is powered by a battery recharged from a solar battery, it should work for at least two weeks, taking into account the average duration of trips to the caves, and should be autonomous so that its work does not require people's attention. A person at the bottom can, using a crocodile clip or a screwed-on terminal, join at any place on the line (a field wire stretched in the caves) and establish an underground telephone connection with the ground station. It is in “sleep” mode, periodically “wakes up” and receives service signals. Sleep mode is needed to save battery power, because it is not always the sun to power the battery.

And now some technical details.

Implementation of the idea

The complex we used on this expedition looked as follows:

1. Two Android smartphones running a specially written program.
2. Two self-developed transceivers connected to the underground line and to the audio ports of the phones.
3. Strong field field P-274 , about 3600 m long, stretched to a depth of 800 m.
4. Complex power surface phone.
   
   1. Power bank to power the "surface" phone.
   2. Arduino , which restarts the process of charging the phone from the power bank.
   3. Solar panel for charging power bank.

They took the scheme of a regular phone as a basis, only instead of a person the smartphone itself receives and transmits commands. To communicate with each other, the devices exchange sound signal sequences - DTMF tones (16 tone dual tone multi-frequency analog signal). The channel turns out half duplex. To transfer the data itself, 9 out of 16 tones are used, and the remaining 7 are service ones, for example, indicate the beginning / end of a message / sequence, an emergency reset signal, etc. The duration of DTMF tones, and hence the transmission rate varies from 1 tone per second to 15 tones per second. Without taking into account technical pauses, this corresponds to 0.3-5.5 bytes per second. Smartphones using the dtmf-cpp library convert text into tones and back.




The transceivers are connected to phones via a 3.5 mm audio jack using a 4-pin mini-jack, just like a regular headset. Any audio signal that the phone wants to play, goes to the transceiver, and everything that happens in the line, the transceiver amplifies and sends to the phone on the microphone channel. In addition to amplifying the input signal, the transceiver isolates the phone from the line to prevent damage to it as a result of accidental voltage spikes. In addition, the transceiver controls the separation of the transmission medium. When the phone tries to play something, the transceiver connects the left audio channel of the phone to the line, for the rest of the time the microphone channel connected to the ground is connected to the line. When you need to transmit, the software in the right channel gives a service signal so that the transceiver switches to transmit mode.

You can listen to how our transceivers communicate here: cloud.mail.ru/public/JAjQ/wuF4XMm4W

A self-written program is running on the phones, listening to the communication channel, waiting for certain signals or user input via the interface. Algorithm of data transmission:

1. The user on the control telephone selects the desired command from the menu.
2. The program creates a request in the form of a stream of bytes.
3. The stream is divided into sequences of no more than 16 bytes, a checksum is added to each of them, and then the sequences of bytes are encoded in a sequence of DTMF tones. Two service sequences are added to the set of sequences of tones, indicating the beginning and end of a group of sequences.
4. Each sequence is encoded in PCM 16bit 8000 / s mono and is played by the phone.
5. Each sequence is read by a controlled phone, decoded, checked for errors and, depending on the result, a signal of successful or unsuccessful receipt is sent.
6. After receiving the confirmation signal, the controlled phone transmits the following sequence or repeats the current one.
7. When all sequences are successfully received, the managed phone collects a stream of bytes from the sequences, decodes it into a command and executes it.

Data transfer from a managed phone to a manager is performed using the same algorithm.

Video available here: https://drive.google.com/file/d/1Y4O5R1Hce0S_djni-B1k5_B9Lw7uRlyp/view?usp=sharing


Example: a person in a cave on his smartphone in the program selects a command, selects the “Send SMS” command, enters the phone number to which the message should be sent, and its text. All this data is encoded using DTMF signals, in a tone mode, transmitted over the wire to the surface, where the other phone decodes it and sends an SMS to the specified number through its SIM card. With feedback, the pattern is approximately the same: the phone periodically wakes up, leaves the airplane mode, receives the accumulated SMS from the operator and keeps them waiting until the service command “give me SMS” comes from the caves. All that has been accumulated, the smartphone transmits down the line.

Power supply

The whole complex during the expedition must be fed from something. There is no problem with powering an underground telephone - both the telephone and the transceiver have a built-in battery, the consumption is not too high during use, they are turned off the rest of the time. The situation with the “superficial” managed phone is much more complicated: it needs to stay in working condition for at least two weeks.

If the smartphone continuously listens to the line, and it is also connected to the GSM network, the power supply is enough for several hours, and the solar panel does not solve this problem, since it provides less energy than the smartphone consumes, and the power bank will only extend the time for a day -two. I had to do a standby mode in which the line is not tapped, and also enable airplane mode. After 5 minutes of inactivity, the program goes to sleep and wakes up once every 10 minutes for 15 seconds, waiting for a special wake-up signal. Airplane mode turns off 6 times a day for 10 minutes to receive SMS. The problem is that the control of airplane mode requires the application of elevated rights that can not be obtained without ruttingphone. All other functionality of the application, not related to energy saving, does not require elevated rights and works on any phone with Android 4.1 and higher.

Field Trials and Plans

In this expedition, Peter with a team of cavers for the first time tested the device in the field. No problem, of course, not done. The application was written very quickly, on the knee, because the expedition’s deadlines were running out.

There were two big software problems, the problem with the power supply of the “surface” apparatus and with the sealing of the “surface” complex, the problem with the connector. For most of the problems, the guys were ready and used pre-prepared backup options, improvised with something on the go. Anyway, the system worked, we managed to conduct a full test. The second group, which remained at the bottom of the cave in order to investigate the first ascent after the departure of the main part of the expedition, reported on the results, as well as the current weather and forecast. Almost all the problems and shortcomings found were easily fixed and we fixed them for the next expedition to Snezhnaya, which took place in December 2018 - January 2019.

During the tests, we found the maximum stable data transfer rate. It does not differ from the maximum stable speed obtained in the laboratory when the devices are connected directly to each other. The signal transmitted through the communication line stretched through the cave was not distorted in any way, no extraneous noise of comparable volume was noticed. Only slightly with the depth of the descent fell the volume of the signal. Due to software problems, it was also possible to test the operation under the conditions of a distorted, “stuttering”, interrupted signal, in which, at first glance, successful transmission is not achieved. Nevertheless, it was possible to choose the mode of operation in which, even in such conditions, the connection of two devices is maintained - this suggests an idea of ​​the potentially very high stability of the transmission protocol created by us.

It was originally planned to use the power bank to power the top phone. It turned out that the power bank we had had charged the phone to 100% and turned off. In order to re-initialize the charging, it was necessary to pull out the wire from the power bank and insert it back, otherwise he did not understand that the phone had sat down and it was time to release the power again. There were a couple of days before the expedition. I didn’t think of anything better than to pin Arduino.


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

According to the schedule, the Arduino once every three hours using a relay broke down the + 5v channel of the USB power cable from the power bank and turned it back 15 minutes later. At first, the board was powered by 4 AA batteries, and then the battery compartment with four 18650 cans was adapted. This turned out to be the weakest link, because the batteries that fed the Arduino were the first to go. But for some time she worked. The first group of the expedition, which rose to the surface, changed the batteries, and the system worked for another week.

We continue our experiments: there is a working version of the donor phone, to which a large block with 18650 is soldered through a hole in the case. The phone is in standby mode, and the batteries are discharged only after 26.5 days!





Therefore, in the future, we are likely to abandon the solar panel, which is also a weak link: it can be powdered with dust or snow, splashing it with mud. During the three weeks of the expedition from 4.6 V to the working voltage of the batteries for the transceiver, the “top” was discharged to 3.8 V, and the “bottom” to 4.1 V.

The current version of our transceiver does not know how to work as a normal telephone. We want to finalize the scheme so that you can use the transceiver without a smartphone in the usual “cave-phone” mode: clicked - say, let go - listen.

Now the software supports only the reception and transmission of SMS, as well as a number of service commands. The data transfer protocol does not impose any restrictions other than bandwidth, so it is relatively easy to program downloading weather forecasts from the Internet or, for example, sending messages to instant messengers. Unfortunately, the transfer speed is not enough to fully go online and transfer pictures. Maximum stable speed is now about 6 bytes per second. On a stable channel, it takes about 1 minute to send or receive one SMS in 160 Cyrillic characters.

By the next expedition, we plan to refine the software, add the missing functions and correct errors, and rework the power supply system of the “surface” complex. Already implemented the function of calling the line - once a minute a service signal is given to check the line for the presence of breaks. Also added service functions such as manual installation of speed, forced reboot and other trifles. Maybe later we will make the phone go to the Internet and find out the weather forecast. I really want to connect my own meteorological station to the surface phone, collected, possibly based on Arduino, and send actual data from the sensors down the line.