Accident Alert Info Panel Project (Part 1)

Instead of intro

The history of the project creation could not have started if it were not for one unpretentious “But” - there is equipment in the department that should work smoothly, 24/7/365 (around the clock, seven days a week, always) - in fact, they are hardware stations optical multiplexers, SDH equipment) and SIP telephony servers (as well as the Call Center, but the operators themselves tell us about this, they were very well trained to respond to the slightest failures).
The equipment itself is located in the server room, remote from the office, and quite noisy (50-80db inside is the norm, you even have to talk in raised tones, because otherwise the interlocutor is just not heard at half a meter).
In case of any equipment failures, it is necessary to eliminate them quickly (failures can occur both from our side and from the connected operators, as well as for independent reasons, for example, breakage of optics, overload on the line, other data loss), due to than you need to constantly do for performance indicators.
Measures are taken, but earlier this happened with some delay due to the lack of control.
Visual monitoring of the equipment is possible (indication of warnings and accidents of the pre-mortem), but this requires being close to the equipment, which is not always possible.

Interested please under the cat. (Caution, traffic ~ 10-15MB photo)

Content

Part 2

For those who are not interested in the background, you can safely skip it , and go to the main idea of ​​the post.
')

Preamble

Thus, to monitor the condition of the equipment, a monitor was required. A normal monitor does not fit in view of the complexity of visual control, as well as the absence of meaning in it. It is much easier to see if the red light is on, than to look for which indicators have turned red on the monitor somewhere, which are already red (the unconnected conclusions of the optical converters display rather unpleasant crash indicators), and so on.

The first option was a complex of them:

• Virtual Server (ubuntu 11.04, 512MB RAM, NoGUI).
• Scripts on the same server (written in Perl).
• Alarm devices such as "Flashing".

Hardware characteristics of the current (working) notification device:
ATMega48 + Arlan 9000 + LED strip (1 sektor) 12V + IRLML2402 as a key.
The device operates in byte mode on a USART, sends the same byte backward, and checks for what exactly came.
If “1” - allows the timer interrupt to work (it works about once per second, flips a pin that controls the MOSTFET key).
If "0" - prohibits his work.
In both cases, after exiting the interrupt, the MCU continues to wait for bytes from the USART.
Powered by 12V with the simplest stabilizer KR142EN5A (5V output, which is more than enough to power the MCU and the low-voltage IRF-key).

In the server part, everything is even simpler. CRON runs every minute a script (not even a script, but rather a cycle for launching the script itself and a waiting pause), so that the interpreter runs every 10 seconds. There are few devices, so you can solve this problem in the forehead.
The script sequentially checks the states of the device by SNMP requests, remembering the state. If at least somewhere the status of an accident is returned, the symbol “1” is transmitted to the actuator. If everything is good everywhere, then “0” is transmitted.
Everything works, but not to say that it is convenient - it is not known WHAT feels bad.

[/ Prehistory]

Now the main part.

Currently, the development of a more comprehensive network device alerts (although the same will work in conjunction with a virtual server and more advanced scripts).
The finished material will be posted in the relevant topic.
The current source code does not differ in beauty, because in the framework of the preliminary article will not be laid out.

The essence of the device:
MCU : ATMega1284p (chose what was available, literally on hand), quartz at 18.432MHz / RAM: 16kB, Flash: 128kB, EEPROM: 4kB, USART /;
Ethernet module : ENC28J60; / Library sources and description of working with the module here /
Indication : 20 modules 8x8 LED DOT Matrix (purchased on E-Bay);
Sound : Piezo, DAC 8bit R-2R on resistors, sampling frequency will be ~ 22kHz, Single-tone signals;
Additional periphery : DS12B20 thermometers;
Power : \ Currently questionable, because I do not want extra wires to the device, and there is a desire to assemble it according to the POE scheme, but the finished module will not withstand 48V, therefore, probably, 12V PSU will be used as the POE adapter \
As an internal power source, and a stabilizer, the Step-Down DC-DC Converter module on the LM2596 (from the same E-Bay) is used;
Debugging: UART in RS232 mode (at a speed of 115200), turns on only when the MCU starts, if there is potential on the specified MCU pin, otherwise it is not turned on and almost does not consume system resources;

Design
The device will be constructively an info-panel (to resemble those in buses), but smaller in size (the original one could not find - it does not google what is presented in our buses, but it resembles a running line).

The finished device will have a size of the visible area of ​​20x400mm (1 line for 20 modules), may later become two-line, or increase the font (most likely the first).
Work is planned on the Ethernet (fully independent).
The organization of work on the Ethernet network occurs through the ENC28J60 module ( special thanks to the user easyelexnronix, Lifelover for the module driver, as well as examples of working with it ).
The possibility of sound alerts is planned (the presence and necessity of a sound signal is controlled by the server), as well as the ability to play streaming sound (decoding will also occur on the server side; the problem with playback and low processing power, as well as the complete lack of DMA, is solved by ring buffer); text display - dynamic.

So, in order:
Core
From the MCU is required multitasking, and at the same time a hard real time (for sound), because an attempt was made to use FreeRTOS, but after calculating the overhead costs, this idea was abandoned. Playing sound (relatively) of high quality requires data processing at a frequency of 22 kHz (so as not to suffer from resampling sound), switching tasks in this mode will require a significant portion of the MCU resources. With the standard system interrupt frequency (100..1000Hz), PCM sound without DMA cannot be played.

Sound
Sound processing occurs when the timer is interrupted. The same interruption, in the absence of data in the sound buffer, will independently disconnect itself.
A single-tone beeper will be connected to the outputs of the PWM-generator, which does not exclude the possibility of only one piezo emitter for alerts.


Indicator
The implementation of the indicator is planned on shift registers with latches 74HC595 (column drivers + row driver) + IRLML2402 as a row driver (buffer).
Registers are used as column drivers, since their current load allows to power the whole line (8 points) at the same time.
These lines will be gradually pushed through the registers horizontally, starting from the "right" edge, so as not to bother with the additional frame buffer, and the entire image is output line by line.
At the same time, the registers have a common data bus, but separate clocking buses (+1 to the saved MCU pins).
Dynamic indication at a frequency of 125Hz should not be perceived by the eye as flickering (meaning the total frequency of regeneration), the switching frequency of the lines is 1kHz (a timer counting milliseconds is used).
Due to the presence of latches in the registers, it will be possible to completely avoid flickering when switching lines (I will add a small pause of several cycles after switching the registers to the Z-state, snapping new data and switching to the operating mode).

Power supply
As already stated, the power will be supplied from the outside to the ENC28J60 module, since its design allows you to remove the voltage from 3 and 4 pairs of cable (they are not closed to the case and not connected to anything). Then this voltage will flow to the DC-DC converter and drop to 5V.
At the moment there is a question of voltage levels:
The core must be powered from 4.5-5V, because otherwise, it is not guaranteed to work at a frequency above 12MHz (valid for 3.3V), but the network interface must be powered from 3.3V, otherwise the chip gets very hot, and there is a danger of its failure. There is only one converter available, therefore, a necessary Low Drop 5V -> 3.3V to a current of up to 250mA is necessary, again, preferably a pulse with high efficiency. In stock, unfortunately, no.

upd: I am already advised to assemble the converter on the placer elements and power everything from normal POE without any restrictions in 12V. That's just in this circuit I was not very lucky. If something began to work, then sometimes it burned pretty effectively.

It is likely that RTC support will be added to the final project ( DS1307 ). Including, I will try to describe the work with NTP (it will be ugly, but I will describe the basic functionality).
For one thing, I will recall / learn the principles of data processing at different levels of OSI.

Currently available:

• Partially compiled library (network appears, it remains to finish checking for the presence of the link and data handlers ... everything ... a lot ..)
• Ethernet module ENC28J60
• Step-Down DC-DC Converter (LM2596)
• Indicators (disassembled) (20 pcs)
• The ATMega1284p MCU on the debug board (it looks pretty sloppy, but it’s shared for yourself).
• Piezo emitter
• Thermometer DS18B20, rewritten library from scratch. The basic minimum of functions: “Read byte”, “Start conversion”, “Read Scratchpad”.
• RTC DS1307

The thermometer library will be rewritten to optimize and eliminate delays in the operation of the MCU during conversion. At the moment, temperature conversion causes the MCU to freeze for ~ 750ms, which creates a very unpleasant pause when working with the network, as well as sound.



What is not:

• Added libraries
• DMA and very sorry.
• Sign generator. (Dopilivaetsya)
• Adapters for LED modules (the module pinout is just awful, and for the panel it will be more convenient to assemble them when there are a row on one side and columns on the other.

/ Order adapters turned out to be commercially unprofitable. The price at the factory was broken in the amount of 4000 (excluding VAT) for 40 pieces. With VAT we get almost 5k wooden. We'll have to hone the skills of working with a mini-drill and LUT. /

The matrix of characters is planned 6x8, without font optimizations.

 //A { 0b00000000, 0b00100000, 0b01010000, 0b01010000, 0b10001000, 0b11111000, 0b10001000, 0b00000000, } 

Moreover, only 6 high bits will be displayed on the indicator, the remaining 2 will be skipped.
No pseudographics yet.
Output pictures from the "network" is probably also. But to describe the graphics buffer for a short time, you can make animations directly from the server.

There was an idea to buy a Raspberry PI and write a script on top of it ... but it is not sporty. There, the ARM-11, 512MB RAM, Linux ... yes there you can raise the monitoring server itself! .. but the real time in any * nix system is soft, and a hard time is required to display the display.
Of course, it was possible to make RPI + any simpler ATMega48 type controller (yes, it is also available), with the exchange via SPI / UART and peripherals on top of the controller itself, but this is not sporty either.
The goal of the project was to set up for itself “To meet the small budget and assemble a notification device,” because this is how it is done. Almost healthy sports interest.

To be continued.