Musical programmable school bell "Schoolboy-3"

Since I changed the platform for the school bell, I post the source code of the previous project “Schoolboy-3”. Immediately I explain that I did not plan to distribute the source code somewhere other than Russia, therefore 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 like that.

A bit of history

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

The problem was that it was homemade. Since it commutes with the fire warning system, the iron must have a certificate of conformity, i.e. pass the test, it takes time, money. I wanted to get around this point, but for this you need a ready-made iron, which would be suitable for functionality and would be cheap. So, returning home once, I paid attention to my mobile phone. Why not? It also contains everything you need just for this application. I even felt uneasy at the thought that such an idea had never occurred to anyone before, and I did a review and knew what other school bell systems were built on.
')
There was really one problem, I had never come across Java so closely and even more so, I didn’t write midlets. It was not clear how the concrete implementation of the java-machine will behave when operating in continuous mode. I also did not solve the problem of signing the midlet. In general, I am surprised by the situation that I have to pay something else (regularly) in order to exploit the mobile phone at my discretion.

Putting aside the signing problem for the time being, I began to search for the cheapest and most convenient phone for experiments. It was necessary to coincide so much that at this time there was a simple Fly MC150DS running. Of all its useful properties, the main criterion for his choice was the absence of the need to sign the midlet. It looked strange against the background of all other devices of other firms, where people on the forums did not think of anything in order to circumvent 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 spoiled all the beauty and simplicity of the idea. Having loaded my development environment, docks, etc., I managed to sketch a somehow working engine that formed the schedule for the tasks (playing the melody). As soon as I managed to test the work of the engine during the day, I turned to the school with the request of 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 time was found. I could not believe in the results, rechecking them for days - the application braked for 20 seconds every day. It looked unreal because I figured the clock on the phone was accurate. But the fact remained a fact - 20 seconds difference came from somewhere. It was only half the trouble, the second part was that you cannot correct the time in the phone from the MIDlet. You can read it, but adjust it - no. It baffled me. The most important feature of automated call submission is the exact time of their submission, and I have some kind of simply unknown creepy cant in this place.

When I walked away from the shock (so much time was spent on an empty idea), I noticed that the time inside the MIDlet is different from the time on the phone, i.e. in fact, a time “stream” of its own is created inside the midlet. Perhaps it was not interested in game developers, because For days on the phone, no one plays, but in my case this led to an accumulation of error in the countdown. I didn’t understand what exactly was going on inside a particular java-machine implementation, but for myself I understood it that way. When loading, the java-machine initializes an internal time counter from the system clock, the thread that is responsible for counting time in the process of operation slows down and therefore counts the time incorrectly, which affects the returned Date () values.

What to do? Only one thing occurred to me - to keep track of the time in my program and adjust the tasks for the timers, depending on the correction that has run over the entire period of operation. Honestly, I myself after several years do not know exactly how it works for me, but it works. Every day at midnight, a packet of calls is formed, and the time is adjusted, where the delta is calculated as the product of the days that have passed since the beginning of work and the discrepancy in one day. This daily discrepancy is determined empirically by 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 the last time it seems in NetBeans 8. You can fully test the work of the MIDlet on the emulator. To do this, you need to collect 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 folder Melodies with github in the root of the file system. There are both melodies themselves and configuration files. Perhaps in the Settings.txt file you will need to change the paths to local ones for the emulator, I don’t remember exactly. See how it works under the debugger.

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

Maybe my project will push someone to any ideas on using a mobile phone. It is a pity that so much computational good is thrown into the dustbin of history every year, and yet they could serve and serve people, grinding nil and odinichki.

Links

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