Capturing in progress
|
I have already succeeding emulating FM77AV keyboard's infra red signal with IRToy, Arduino, and then with an FPGA. But, there was one remaining question. What is the correct signal?
According to Deskuma Blog, FM77AV's keyboard is sending 40-bit signal with 100us bit width. However, if you look closely, in the signals he recorded (4n+3)th and (4n+4)th bit always had the same value. Therefore, it could be interpreted as 30-bit signal sent by repeating 100us, 100us, 200us bit widths.
On the other hand, Mr. Kobayashi from ClassicPC.org suggested that the signals are repeating 100us, 125us, 175us bit widths.
When I first succeeded in sending keyboard signals to FM77AV with IRToy, I tried both, and both worked. So, I thought FM77AV's infra-red decoder is tolerant to both bit widths. However, when I did the same thing with Arduino, only 100us, 125us, 175us worked. My FM77AV dropped too many key strokes if I used 100us, 100us, 200us bit widths.
Which is the correct bit widths? The question remained.
Since FM77AV, FM77AV20, and FM77AV40 can accept the same infra-red signals, to find and keep record of the correct keyboard signal contributes to the preservation of these historic 8-bit PCs. I tried may different things, and this time finally I succeeded in recording raw infrared pulses from my Fujitus-original FM77AV40 keyboard.
Capturing in
progress
Close-up of my
Arduino Mega and Infra-Red Receiver circuit. Red LED blinks when it
receives a signal.
I have uploaded the schematics, Arduino source, and control program for Windows, in here. As a side product, I am able to control my TV from the command prompt now.
I used the code for CAPS key because the code is 101010101010101010101010101001. It flips every bit except the last 3 bits.
The result captured from my Fujitsu-original FM77AV40 keyboard is below (click to enlarge):
The first bit consists of 4 pulses. The third bit 7, and the fifth bit 5. This type of infra-red devices typically use 38KHz 50% duty-cycle PWM (Pulse Width Modulation). 38KHz means 1 cycle is 1/38000 second, which is roughly 26us. 50% duty cycle means you need to emit infra-red for 13us and then keep dark the next 13us. For example, if your 1 bit is 100us, you need to send four times of this on/off cycles.
As you can see from the image, the first bit consists of four pulses. Which is roughly 100us. The third bit consists of 7 pulses. 26us*7=182us. But, you can also interpret it as 175us bit width, and the last 7us is simply dropped because the IR led supposed to stay dark during that period. The fifth bit consists of 5 pulses. For the same logic, it can be interpreted as 125us, and the last 5us is discarded. It looks like Mr. Kobayashi's theory is correct.
Similarly I measured infra-red signal from my Arduino-based FM77AV Keyboard emulator and got this:
The signal is almost identical to the one from the Fujitsu-original FM77AV40 keyboard.
Then why the signal with 100us, 100us, 200us bit widths from IRToy worked? It looks to be totally by luck. I also captured signals from IRToy and got this.
Surprisingly, the first bit is using only 3 pulses. The third bit 6 pulses, and the fifth bit 4 pulses. Clearly, one pulse shorter than the correct signal.
Probably this is what happened. When I sent a command to IRToy to emit signal for 100us, IRToy internally divided 100us with 26us with integer division. Integer division drops below decimal. Therefore, IRToy probably decided to send only 100us/26us=3 pulses. Somehow this shortened bit widths fit to the tolerance of FM77AV's keyboard infrared decoder when I tried repeat of 100us, 100us, 200us bit widths.
I also made my raw sampling available from the link below:
[Raw Sampling from FM77AV40's Keyboard InfraRed Signals]
The data file is in the format that the transceiver GUI can open. But, it is just a plain text file. The numbers in the file is on-off cycles in us (microseconds). The last segment in each sample tells the key-release code.
If you have a classic PC unit, please don't throw away. Keep them alive. If you don't have a keyboard, someone must be able to make one. If you don't have a disk drive, someone may be able to make a disk-drive emulator.
Comments are welcome.
Send E-Mail to:
 |