Deutsch

Delphi 6 / Free Pascal
Programming

Turbo Compare 0.4 alpha

Most tools for comparing files found on the internet are very slow and not very comfortable. Here is my version to tackle this problem. It's a super fast tool for comparing 2 files for equality/inequality and shows the number of differences, its offsets, the hex values of both bytes and the ASCII-characters of it. The main advantage of my development is its incredible speed, using highly optimized assembler routines. You can compare 2 files of 60 MB size using an Intel Pentium II 300 MHz in less than 2 seconds !!! Please see the pictures below. Most of the time is taken by loading the files from hard disk into memory, which needs to be added to the sole seek/compare time. The 8bit-method compares the data byte-wise, whereas the 32bit-method compares 4 bytes at the same time. The later method doesn't necessarily need to be the fastest, because if only 1 byte out of 4 is different, all 4 bytes have to be compared separately again to find out where the differences are (and log these things). So if there are many differences between the files, the 32bit-method is slower than the 8bit. Therefore you should always use the 8bit-method. The switching between the 2 methods is only for testing and experimental purposes.

Another advantage is the possibility of comparing files of a different size. For that purpose the larger file is compared up to the size of the smaller one. I also implemented a history of the last 4 successfully compared files, so you can select it from the drop-down field next time. It's also possible to pass a file path as a parameter at the command line. This file is then used by the program as the first file being compared. So an integration of these function in the context menu of windows is possible without any problems. But at this time there is no option for this - you have to do it manually by editing the registry. Also not fully implemented yet is the saving of the results in different file formats (TXT, TAB, CSV). The speed display (c/b => clock cycles per byte) is set to a fix clock rate of my CPU, so it's useless for anybody else than me. Later on I will implement a measurement routine to determine the current clock rate of the CPU being used. UPDATE 22/07/2010: New version 0.4 alpha available. The project has been ported to GNU Free Pascal under the Lazarus IDE.

Visual FileAnalyzer 0.80 beta

Byte Statistics	Index Table
SVG file	GIF file
BMP file	WAV file

An experimental program for statistical evaluation and graphical representation of file contents. It counts the number of bytes from 00h to FFh and displays it in a barchart. The pattern analyzer shows the value of bytes in a file represented in the respective color with a selectable color map (RGB/cyan/green/grayscale). The file content will be displayed as a map of bytes. This is only useful for small files, because on bigger files there are not enough screen pixels to display each byte. Note that this is still a beta version, so some BUGs could still be present. UPDATE 22/07/2010: New version 0.80 alpha available. The project has been ported to GNU Free Pascal under the Lazarus IDE and includes several improvements. UPDATE 16/02/2011: New version 0.80 beta available. Bugfixes only.

FunkTherm 0.2

Still remaining in an early development stage since 2004, this little program is able to decode data telegrams (frames) sent out by radio thermometers in the 70cm ISM band at around 433.740 MHz AM. It's been my first encounter with sound card programming and the processing of audio signals in general for the purpose of decoding signals and data protocols. Creating this program was what I consider now a little milestone for myself, as it set a foundation for further developments in the field of processing and decoding audio signals (RTTY/FAX/Packet Radio).

The thermometer system used in this example was a wireless weather station of type WS-7073 with built-in receiving module R3 and the outside temperature sensors TX2 and TX3 with LC display. It was purchased from ELV Elektronik in Germany.

My idea was to decode the protocol of the data frames sent out by the outside temperature modules that I was already capturing on my receiver. It had to be done manually in the first place, so I recorded the data frames as wav-files for further analysis. The actual decoding process took place on paper, the wave form printed out. At first it seemed quite hard turning this into bits (how is a bit defined on this wave form ?) and later to actually decode it. The LC display of the TX3 module was the key to discover the changing bits and how this relates to the temperature changes, which finally allowed me to decode most of those 44 bits. The hardest part was to find out how the checksum at the end of each frame has been calculated. This took me 2 hours to figure out. There's also a parity bit, but that wasn't too hard.

The analysis of the protocol was limited to the TX3 module because of it's LC display which was of great help. I assume that the protocol of the TX2 module must be the same as it uses the same receiver. However, there is a chance that it might use a totally different protocol and the receiver switches between them, depending on the first part of the data frame that I couldn't find out about. I guess it might be something like a unique device ID or something OR telling the receiver about the protocol being used to tell it how to decode it. I still have to investigate this further.

There are a great number of those sensor modules and thermometer systems on the German market, and as a conclusion I have say that one can't assume compatibility between modules, neither between the ones sold as different products by ELV Elektronik, nor of different brands/manufacturers from different origins. They all might have their own proprietary implementations of protocols. They might differ just too much, so my software won't work with them, and it will never do. There are just too many out there... each protocol had to be manually decoded again.

The Protocol: Each data frame is about 340 ms long on consists of 3 equal parts of 44 bits each (repeated transmission). The frames are sent out by the temperature sensors every 60 to 62 seconds. Finding the exact transmission frequency is crucial for best decoding results, but this is quite difficult within only one 3rd of a second transmission time per minute. Therefore, as of 23/03/2004 the average decoding rate (valid with correct parity & checksum) is only about 37%. However, relying on the parity check alone, the unverified decode rate is way higher at about 80%. This is because the checksum might have some wrong bits in itself, and also covers bits not needed for decoding the temperature alone.

The actual decoding process has been done by taking the wave data and sending it through an algorithm comparable to a sieve. This detects the rising/falling slopes (0 or 1) and distinguishes between noise and the desired signal. The proper way of doing this would be a software implementation of a digital PLL, but this is still beyond my scope at the moment and I don't have a clue how to do that right now. But this should greatly improve the decoding rate. Other plans for further improvements include the implementation of 2 switched receiving buffers and a "distorted mode" for wrong frequency setting. This should achieve a decode rate (valid frames) of greater than 60%, which would allow me to make the decoding process independent from the unique device ID which I still use as a frame start recognition. Therefore this software currently only supports my own TX3 module and is not yet ready for public release or download. As soon as I make some more progress with its development and got rid of the unique device ID I will make it available here.

Pioneer Rescue Tool 0.1

The PIONEER DVR-630H harddisk recorder crashed with a failure of the internal 250GB Seagate harddrive, and all recordings seemed to be lost (display showing "HDD ERR"). This tool is the result of my attempts to analyze the file system of the recorder from a complete 250GB hard drive image that I was still able to create. So far I haven't heard of anyone being able to simply "mount" that filesystem under any operating system (Windows/Linux/BSD). The tool already allows the reconstructing of some of the recording meta data such as Date, Time, Channel/Source and Title. I've tried to keep it as generic as possible, so it should be working with other harddisk recorders from PIONEER as well (i.e. DVR-530H-S), but no guarantee for that. If the image file is incompatible or seriously damaged the program will simply crash. Please give me your feedback if it has worked for you or not. It is important for me to know for further development of the tool.

Furthermore I already located the MPEG-2 recordings, recovered some of them manually and played them back on the PC with VLC. I think it should be possible to recover ALL recordings even they are scattered (fragmented) across the entire disk. The problem I'm struggling right now and the project is stuck since January 2008 is to link the recording meta data to the actual MPEG-2 streams on the disk. So far I couldn't make that connection, unfortunately. Learn more about it in the REPAIR section under Pioneer DVR-630H.