Design of a Fully Digital Telemetry Recording System Based on Disk Array

Publisher:RadiantExplorerLatest update time:2014-09-18 Source: ednchinaKeywords:DRS  RAID  RDRS Reading articles on mobile phones Scan QR code
Read articles on your mobile phone anytime, anywhere

  1 Introduction

  my country's telemetry recording equipment has gone through two generations of products, namely, double-density tape recorders and rotary head tape recorders, which are still in use. In terms of recording principle, they are all analog recording equipment, and many defects have been exposed in long-term use:

  (1) Magnetic tape consumables rely on imports, are expensive, have small recording capacity, low reuse rate, and short data retention time.

  (2) The magnetic head and mechanical tape transport mechanism are precision-machined components with a very complicated calibration process. They are severely worn out over a long period of use, and their recording performance deteriorates significantly, causing great inconvenience to equipment maintenance.

  With the rapid development of computer hard disk manufacturing technology and the advent and continuous application of digital storage technology, digital recording equipment DRS (Digital Recording System) [1] that uses large-capacity and high-speed hard disks to record analog telemetry signals has emerged and has become a replacement product for telemetry recording equipment. However, there are some shortcomings in its design:

  (1) Low degree of digitization: The center frequency of the recorded signal is only 2.1 MHz. It is not possible to directly record the left-hand and right-hand circularly polarized 70 MHz pre-detection signal. It has to rely on an additional analog down-converter for conversion processing, which is not suitable for meeting the recording requirements of the new digital integrated baseband telemetry equipment.

  (2) Poor scalability: Due to the use of dedicated data transmission channels, the bandwidth is limited (16 bits) and fixed. Therefore, if the number of signal recording channels is to be increased, the bandwidth can only be increased by increasing the number of hardware channels. Correspondingly, the number of control drive recording boards must be increased, which will lead to a large number of input and output

The outbound interface relationship changes.

  (3) The reliability of the single hard disk working mode is difficult to guarantee. Once the hard disk is damaged, the entire system will be paralyzed and the recorded data cannot be restored. (4) Failure to utilize internationally accepted technical specifications and standards is not conducive to product upgrading and replacement, and it is difficult to form new industry standards in the long run.

  The above shortcomings show that there are fundamental defects in the initial architecture design of DRS. If we want to completely overcome them, we must improve the architecture design and try to adopt the advanced and popular technologies in digital storage at home and abroad. Therefore, RAID (redundant disk array) technology provides us with new design ideas and concepts. After in-depth research and demonstration and a large number of preliminary experiments, the author finally designed and implemented the all-digital telemetry recording system RDRS with RAID array as the core.

  2 System Design

  2.1 Overall system architecture design

  The RAID standard provides a comprehensive solution for digital storage. RAID5 uses physical stripings with distributed parity to evenly distribute data and redundant check information across a single disk [2]. Under the premise of ensuring data security, it can achieve extremely high data throughput and disk utilization, and is particularly suitable for high-speed continuous large-block data transmission. Taking into account the extremely high security, real-time performance, large storage space and more recording channels of telemetry recording, the array module uses the RAID5 standard composed of 5 SA-TA hard disks with a capacity of 100 GB each, and uses a high-performance ARECA-1120 SA-TA RAID control card as the driver. The RAID card uses OEM products to reduce the workload of hardware development. The reason why the higher-performance SCSI hard disk was not selected as the module is that the SCSI hard disk data interface is too large (50 cores), while the SATA hard disk is a new generation of high-performance hard disk with a serial ATA interface that is becoming increasingly popular in the market. Its external data transmission rate has reached 300 MB/s, close to the SCSI hard disk (320 MB/s), but its interface cable has only 8 cores, and the wiring is very convenient and flexible, which is very suitable for forming an array module, saving chassis space and facilitating quick replacement. The overall system architecture is shown in Figure 1.

Machine architecture

  He used the 64-bit extended PCI bus as the hardware development platform, which can provide a high data transmission bandwidth of 528 Mb/s, while the CPU still uses a high-performance 32-bit P4 (2.4 GHz) processor, and directly maps to the 64-bit bus address space through the main bridge to achieve bus buffering. The hardware part independently developed a PCI bus-based intermediate frequency and video acquisition card with strong versatility and scalability. The software environment is based on the RT-Linux 3.1 real-time operating system kernel, developed under the RedHat 8.0 (kernel version Linux 2.4.18) system platform, and uses standard C language to compile the underlying driver and user application program. In the Kylix development environment, C++ is used to write the user interface program under X-Windows. Since the recording and playback speed specified by the system is as high as 500 Mb/s, the PCI video capture card has very high requirements for the system interrupt response time. For this reason, a real-time operating system RT-Linux platform based on Linux was specially selected. RT-Linux can improve the real-time performance of Linux by modifying some system program codes based on the Linux kernel source code. The modified Linux (i.e. RT-Linux) can quickly respond to hardware interrupts (interrupt response time is less than 15 μs) [3], meeting the real-time performance requirements of the system and providing a guarantee for high-speed acquisition without data loss. At the same time, a set of standard interface functions is provided to realize data transmission and sharing between RT-Linux processes and ordinary Linux processes. Since the data files recorded by the system are sometimes as large as tens of GB or even hundreds of GB, the ordinary file system can no longer meet the capacity requirements under RT-Linux. Therefore, the XFS file system is transplanted to manage the acquired files. XFS is a new high-performance 64-bit file system developed by Silicon Graphics. This file system not only expands the limits of partition and file capacity (maximum 9,000 TB), but also improves the file storage and processing speed.

  2.2 System Hardware Design

  The hardware structure design is shown in Figure 2. The main design components are the intermediate frequency and video acquisition card, which are divided into two parts: recording circuit and playback circuit. When recording data, the 70 MHz intermediate frequency signal is first filtered out of the band by the surface acoustic wave filter, and then the signal strength is controlled within the ideal level range of A/D sampling by the fixed gain and AGC circuit. The 70 MHz signal is directly sampled by the high-speed ADC (40 MSPS) and sent to the FPGA of the intermediate frequency acquisition card. The intermediate frequency bandpass signal spectrum is moved down to the baseband through digital down-conversion to form two orthogonal baseband signals of I and Q. The sampling rate is converted by the CIC filter to obtain the multi-channel video digital group signal, which is sent to the FPGA of the video acquisition card through the LVDS high-speed interface to complete data packaging, buffering and timing control. When the data fills a data block size, the video acquisition card sends an interrupt to the system to request data transmission. After the system responds, it is sent to the system memory through the 64-bit PCI bus in DMA mode. When the data in the memory accumulates to a certain amount of data, the data block is written to the RAID card through the PCI bus and distributed to the disk array. The playback process is the reverse process of recording. The main difference in the circuit is that the video digital group signal needs to be restored through the digital phase shift network and the digital group delay network to restore the I and Q orthogonal signals respectively, and then digitally up-converted by the digital local oscillator NCO with the common DDS clock control frequency division to complete the upward shift of the baseband spectrum, and then the 70 MHz intermediate frequency analog signal is obtained through the high-speed DAC to complete the playback process. [page]

Hardware structure design

  2.3 System software design

  The main function of the system software is to coordinate with the supporting hardware to complete the real-time recording of the intermediate frequency signal before detection and the subsequent playback. It is divided into the video capture card driver module, the main control process, the recording/playback process and the user

The video capture card driver module is inserted into the kernel space as a driver program and runs in the form of a module. Since the user space process cannot directly access the underlying hardware device, the driver module is a bridge between the upper application and the physical layer of the device. The upper application does not need to care about the specific information of the hardware device and can complete the control of the video capture card through the instruction FIFO of RT-Linux. The driver module is responsible for completing the setting, control and status acquisition of the video capture card, as well as regularly reading the B code value and lock flag in the video capture card. The upper application can also set the B code value in the video capture card through the instruction FIFO. The video data acquisition card module and the upper application share the key status and control data of the system through the shared memory of RT-Linux, realizing data sharing between kernel state and user state programs. The main control process is an ordinary Linux process in the user space. It is responsible for completing tasks such as system initialization, maintenance and instruction transmission. It completes the instruction transmission between the user space program and the kernel space program. It is mostly in a waiting state. When it receives an instruction (implemented by a semaphore) from the user (X-Window window interface or text debugging interface), it is sent to the kernel process through FIFO to realize the instruction transmission. At the same time, when he sends the command to start acquisition/playback, he will be responsible for creating an independent read/write disk process to realize the hard disk recording and playback of data. The master control process maintains an initial system configuration parameter file. After the system stops running, it will save the current state of the system and use it to initialize the system parameters when the system is restarted. At the same time, the master control process will repair the task files on the disk array every time it starts to ensure that when the shutdown occurs due to unexpected failures such as power outages, the unfinished task files are repaired. After the recording/playback process is created by the master control process, it continuously transfers data between the hard disk and the acquisition buffer (MBUFF). When recording, as long as there is data in the acquisition buffer (MBUFF), it will write the data to the hard disk array. When replaying, it first fills the acquisition buffer (MBUFF) with the playback data, and then when the data is transferred by DMA, it reads the data in the hard disk array again to fill the empty acquisition buffer (MBUFF). When recording/playback stops, the process ends automatically. The user interface is a user process based on X-window. It provides users with a visual control platform in the form of a window, which displays the system status, task content information and disk array space usage status in real time, and accepts the following user commands: B code setting/display, start recording, playback, renaming, dumping, deletion and data correctness verification of task files on the disk array and other management functions. When the user starts to collect and record, the control command is sent to the main control process, which establishes a disk write process and sends the acquisition command to the underlying video acquisition card through the instruction FIFO, so that the video acquisition device starts to collect data. The video acquisition device will continuously collect the input intermediate frequency pre-detection signal stream data into the ping-pong buffer in the video acquisition card. When the ping-pong buffer is full, it will switch to another ping-pong buffer to continue collecting data, and a data ready interrupt will be generated to trigger the system's interrupt service program. The interrupt service program starts a DMA transfer to transfer the data in the ping-pong buffer to the acquisition buffer (MBUFF) in sequence, and adjusts the acquisition buffer (MBUFF) pointer for the next data storage so that the collected data is temporarily stored here and is not overwritten. The writing process detects in real time whether there is new data in the acquisition buffer (MBUFF). If there is, it will be written to the hard disk array immediately. The 512 MB acquisition buffer (MBUFF) ensures that the acquired data is written to the disk array before it is overwritten. Similarly, when playing back, the playback data on the disk is read into the buffer in advance, and then the playback command is sent. In this way, even if the disk reading speed is temporarily reduced, it can ensure that there is enough playback data in the buffer to be output to the video capture card, ensuring the continuity of playback.

System software design


  3 Conclusion

  In order to test the system performance and reliability, the prototype was subjected to a cumulative 1,000-hour environmental stress test (including test time) and a 100-hour accelerated life test. The performance was stable and reliable, and the recorded data met all indicators. At the same time, the single-disk power-off data recovery test of the disk array during the recording process was repeatedly carried out, and the results were satisfactory, which fully verified the superiority of RAID technology for digital recording.

Keywords:DRS  RAID  RDRS Reference address:Design of a Fully Digital Telemetry Recording System Based on Disk Array

Previous article:Application of digital temperature sensor DS18B20 in satellite power supply system
Next article:Mobile power three-in-one solution

Latest Microcontroller Articles
  • Download from the Internet--ARM Getting Started Notes
    A brief introduction: From today on, the ARM notebook of the rookie is open, and it can be regarded as a place to store these notes. Why publish it? Maybe you are interested in it. In fact, the reason for these notes is ...
  • Learn ARM development(22)
    Turning off and on interrupts Interrupts are an efficient dialogue mechanism, but sometimes you don't want to interrupt the program while it is running. For example, when you are printing something, the program suddenly interrupts and another ...
  • Learn ARM development(21)
    First, declare the task pointer, because it will be used later. Task pointer volatile TASK_TCB* volatile g_pCurrentTask = NULL;volatile TASK_TCB* vol ...
  • Learn ARM development(20)
    With the previous Tick interrupt, the basic task switching conditions are ready. However, this "easterly" is also difficult to understand. Only through continuous practice can we understand it. ...
  • Learn ARM development(19)
    After many days of hard work, I finally got the interrupt working. But in order to allow RTOS to use timer interrupts, what kind of interrupts can be implemented in S3C44B0? There are two methods in S3C44B0. ...
  • Learn ARM development(14)
  • Learn ARM development(15)
  • Learn ARM development(16)
  • Learn ARM development(17)
Change More Related Popular Components

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews


Room 1530, 15th Floor, Building B, No.18 Zhongguancun Street, Haidian District, Beijing, Postal Code: 100190 China Telephone: 008610 8235 0740

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号