Musical programmable school bell "Schoolboy-3"

Since I changed the platform for the school bell, I post the sources of the previous project “Schoolboy-3”. I immediately explain that I did not plan to distribute the sources somewhere other than Russia, so almost all the code is written in Russian. This may seem funny to someone, do not judge strictly, it was easier for me to write code.

A bit of history

Shkolnik-3 is a music programmable school bell based on a cheap cell phone with Java support. In general, the idea came to me by accident when I thought about replacing the previous version of the school bell “Schoolboy-2”. He was quite primitive, because was assembled on a Mega series AVR microcontroller with a small strapping and a two-line display.

The problem was that it was homemade. Since it is connected to the fire warning system, the hardware must have a certificate of conformity, i.e. pass the test, what it takes time, money. I wanted to get around this point, but for this I need ready-made hardware, which would be suitable in functionality and cheap. So, returning once home, I drew attention to my cell phone. Why not? It contains everything you need just for such an application. I didn’t even feel at ease from the thought that so far no one had come up with such an idea, but I did a review and knew what other school bell systems were built on.

There was really one problem, I had never encountered Java so tightly, and even more so, I did not write midlets. It was not clear how the concrete implementation of the java-machine would behave during continuous operation. Also, I still did not solve the problem of signing the midlet. In general, I am surprised by the situation that I still have to pay something somewhere (regularly) in order to operate the mobile phone as I see fit.

Putting aside the problem with signing so far, I began to look for the cheapest and most convenient phone for experiments. It was necessary to coincide so that at that time a simple Fly MC150DS was in use. Of all its useful properties, the main criterion for his choice was the lack of the need to sign a midlet. It looked strange against the background of all the other devices of other companies, where the people on the forums did not invent anything to get around this requirement.

The next step was to verify the fundamental possibility of using the phone as an automated system. Here I was waiting for one “wonderful” surprise, which almost ruined the whole beauty and simplicity of the idea. Having loaded myself with a development environment, docks, etc., I managed to sketch out a somewhat working engine that formed a schedule for tasks (playing a melody). As soon as I managed to test the engine during the day, I turned to the school with a request for experimental tests. Unlike the previous version, now you could play mp3 files and potentially do so many other things, because the phone is essentially a small PC.

After several days of testing, a very strange behavior of the time was discovered. I could not believe the results, rechecking them for days - the application slowed down by 20 seconds every day. It looked unrealistic because I figured the clock on the phone was going exactly. But the fact remained - 20 seconds of the difference came from somewhere. It was only half the trouble, the second part was that you can not fix the time in the phone from the midlet. You can read it, but not correct it. This baffled me. The most important feature of automated call delivery is the exact time of their delivery, and I have some kind of simply unknown creepy jamb in this place.

When I moved away from the shock (so much time was spent on an empty undertaking), I noticed that the time inside the midlet is different from the time in the phone, i.e. in fact, inside your midlet you create your own “flow” of time. Perhaps this was not of interest to game developers, because nobody plays on the phone for days, but in my case, this led to the accumulation of an error in the countdown. I did not understand what exactly is happening inside a particular implementation of a java machine, but for myself I understood it this way. When loading, the java machine initializes the internal time counter from the system clock, in the process, the thread that is responsible for counting the time slows down and therefore considers the time incorrectly, which affects the returned Date () values.

What to do? It occurred to me only one thing - to additionally keep track of time in my program and adjust tasks for timers, depending on the correction that had accumulated over the entire time of work. Honestly, after several years I myself don’t know exactly how it works for me, but it works. Every day at midnight, a package of calls is formed, and the corrected time is set, where the delta is calculated as the product of the days that have passed since the beginning of work and the residual of one day. This daily discrepancy is determined empirically from the test results. The method, of course, is crooked, but such a phone call worked for a total of three years, until the power connector (micro-usb) cable fell off and the phone was not stolen.

about the project

A detailed description of working with the program can be found in the User Guide, which I attached below. I collected the sources on github for the last time it seems in NetBeans 8. The work of the MIDlet can be fully tested on the emulator. To do this, you need to build the debug version by specifying the value in the main.java file:

// Установка или сброс для отладочного режима.
static final public boolean РЕЖИМ_СИМУЛЯТОРА = true;

In this case, you need to put the Ringtones folder with github in the root of the file system. There are both the melodies themselves and the configuration files. Perhaps in the Settings.txt file it will be necessary to change the paths to the local ones for the emulator, I don’t remember exactly. You can see how it works under the debugger.

The program also uses the microlog module, which keeps very detailed statistics of what is being done in the midlet. At the same time, the microlog.txt file is created in the same folder with tunes, where you can look at user actions or errors that occur during the course of work. It is very comfortable.

Maybe my project will lead someone to some ideas on using a mobile phone. It is unfortunate that so much computational good is thrown into the landfill of history every year, and yet they could still serve and serve people, grinding zeros and ones.

References

1. Sources on github .
2. Schoolboy-3. User Manual (pdf).
3. Musical programmable school bell "Schoolboy-4 . "