Software 27 May 2006
This page is in two parts:
Part 1: A demo version of Windows software is available. Contact FXL DATA for a copy. This excellent program was written by John Kerr in Perth and has been running for about six years. John asks a $100 royalty payment for the program, and this is good value. It has become the default Windows software until the FXL Windows program (called FXL Chart) is finished.
Currently there are two ways to view the data.
The software that was originally written in 1996 is DOS based and is now very outdated. It is still available, but is not being updated. It will only work on DOS, Windows 95, Windows 98 or Windows Millenium Edition. If you want the DOS version, then please email FXL DATA via the front page contact details.
All the older Microsoft Windows operating systems (95, 98 and ME) are being phased out in favour of the Windows XP series, and there is yet another version of Windows (due for release in late 2006) to make even the Windows XP obsolete.
Therefore a new version of FXL DATA charting software is being written that will suit Windows XP and it's subsequent versions, and at some stage be able to be converted to run on Apple Mac and Linux platforms.
This program is under development and was due for release in December 2005. It is being written in a language (Visual C#) that should be "Future Proof", that is, it should be able to be constantly updated into the future and should not become redundant.
One of the features of Visual C# is that the program can be transported from a Windows operating system to Apple Mac and Linux operating systems.
This program will be an "all purpose charting program", using XML to define the data.
The advantages of XML are that it will make the data files open ended, that is that the recording time can be any length, and there can be (almost) any number of channels. Currently it will handle up to 64 channels.
Another big advantage of XML is that it can be converted easily to almost any other human language, like Spanish, French, German, and even the very complex Chinese and Korean languages, so it will have real value in the future.
The program is being designed as an all purpose charting program, so it is not confined to just Drag Racing, but will find uses in any data acquisition field, from monitoring weather, to waves at the beach, tides, the number of cars crossing an intersection in a day, mining industry, electronics industry, stock market info to counting sheep. The uses are limitless.
The immediate uses will be for Drag Racing.
However, the fact that it is to be an all purpose program is what is slowing down the progress. If the program were simply for Drag Racing, then it would be ready by now.
The management of FXL DATA Pty Ltd have decided that it is more important to make a "Future Proof" program and get the basics correct before releasing it.
Part 2 : How the loggers work. This is only of interest to technicians and engineers.
The loggers were first designed in early 1995 using a Motorola 68SEC811E2FN microprocessor. This is the secure version of the HC11. It has a 2k secure internal EEPROM and 256 byte RAM. Motorola obsoleted the device in July 2000.
The early loggers used a 32k static ram chip for memory. This is addressed by either one or two 4040 counters, depending on model. Later loggers, FXL32 and FXL35 have a 128k static ram, but only use 60k. This is because of the DOS limitation on holding more than 60k. These loggers could use all the 128k ram, but the program is set to stop recording at 60k. The PCBs are designed to take up to 512k ram in the standard 32 pin chip design. If they ever get used for more than 60k, they will need to have a PCB track cut and a jumper soldered in to allow the higher 64k to be addressed. This is not a problem, it was designed that way.
The loggers all communicate at 9600 baud, 8 bit, no parity, 1 stop bit. That's 9600 8N1, if you know what that means.
HOWEVER..... Because the loggers were designed in 1995 when IBM XT and 286's ruled the earth, they all use a very simplistic method of handshaking during the downloading, and this is still used to this day.
Originally, in 1995, the downloading process was to simply trigger the logger and it would stream out the data. The very early programs actually converted the binary recording to five byte ASCII with leading zero blanking. I had it doing binary division to convert time to rpm !!! And that was with a 2k EEPROM !!! I still have the code, and am amazed that I even worked that out. The very original downloads (before I figured out how to write the downloading program myself) were done with a DOS program called PROCOMM. This is the forunner to the Windows Terminal program.
The problem was that the early UARTs (8250) had no byte buffers. It was very common that when the download started, the IBM would suddenly decide that it had to access the hard drive, and simply ignored the Comm Port. This meant that there was a very good chance that one or two bytes were ignored, so the remaining data from the download would be shifted by one or two channels, and then is was corrupted.
If the customer had the 16550 UART, then there was no problem, as these UARTS had a significant byte buffer, either 8 or 16 bytes, depending on the model.
So I was in the ridiculous situation of having to tell customers that they had to have a 16550 UART or it wouldn't download properly.
When I wrote the downloading program, I changed the methodology and made the IBM send one character and wait until it received a response, then it would send another. This made the downloading time more than twice what it should have been. It is typically 93 seconds for a 32k download using the DOS program.
What John Kerr did with his Windows program was to send a string of bytes equal to a line of data, and the logger would stream back the same amount of data. For example, the FXL25 has a byte length of 27 bytes per line of data. His program streamed out 27 bytes, and the logger responds with 27 bytes. This makes his downloads about 70 seconds. Windows allows almost any amount of byte buffering, so it doesn't matter if the IBM is off accessing the hard drive or what ever, it doesn't drop bytes during the download. The logger microprocessor only has a byte buffer of two bytes, but it doesn't overflow because the baud rates are the same.
The downloading cable for all FXL loggers is a null modem cable. Pins 2 and 3 reversed.
The downloading cable for the MPE G3 logger (redesigned FXL22) is also null modem, BUT PINS 2 AND 3 are not reversed.
What does an FXL logger respond to? They respond to single ASCII character interrogations.
If you want to play with the logger, you can set up the Windows Terminal program to send in ASCII 9600 8N1 and simply type in characters from the keyboard.
If you press P then you will get an endless stream of binary gibberish as the logger is in pit run mode. Press p to stop it.
F will give 32 bytes in binary.
D will do a download in binary, but you will have to keep your finger on the key as it will only reply once to each interrogation. The downloading is therefore at the keyboard rate, and is not much use to you, because it is in binary.
Why doesn't the logger use a faster downloading speed than 9600 baud? The microprocessor uses an 8 MHz crystal as the preferred crystal for doing its bootstrap programming of the EEPROM. For some unknown reason, Motorola only made the internal timers division go to 9600 baud, then it goes to strange non standard baud rates. It would ultimately use 125,000 baud as it's fastest rate. The crystal could be changed to 7.3728 MHz, another fairly standard crystal frequency, but then the timers would all be wrong for picking up the rpms and selecting the time for the 100 Hz sample rate. With this crystal, the loggers could have the standard downloading rate of 115,200 baud. It would also mean that each time the internal program had to be changed, the crystal would have to be changed, or the microprocessor would have to be lifted out of its socket. Both options are a hassle. If the microprocessor was to be removed several times, then the socket would crack across it's diagonal points. This has happened to several sockets.
Also the RS232 chip most commonly used is the MAX232. It is only designed to go to 19,200 baud. The MAX202 exists and is a drop in replacement and goes up to 115,200 baud.
USB. Ideally, this is the perfect solution to the memory problem and downloading etc. BUT... It isn't as easy as it sounds. I am researching the subject and intend to make an external adaptor to convert the serial 125000 baud to USB for storing in flash memory.
But then another drama occurrs when you want to do a pit run. You still need to have a cable connected to the logger and the laptop or desktop.
To be continued...
Press back to return.