homecombo
PmFP \overline{_{mF}}
1.1 Introduction
Pulse Mapping Format (or PMF for short) is my own codec designed to efficiently encode data for transmission using only laser pulses. Unlike raw binary, which require 8 bits for every character regardless of its complexity (such as "1" with
00110001
or "A" with
01000001
), PMF offers greater efficiency. This is particularly advantageous when using short pulses for 0 and longer pulses for 1, a method proven most reliable in my tests for data transmission with class 1 & 2 lasers and photodiodes.
Quintessentially, PMF reduces this 8-bit-per-character requirement, by only using a set "seed" of characters, namely the numbers 0 to 9, letters X to Z, and some additional characters and flags.
1.2 Functionality
The PMF codec is designed to only work with base-10 digits, a few letters, a few characters, and some flags. This means that whilst not every letter is encapsulated in the codec, you're able to combine existing characters to create them. This provides the advantage that we don't need to use 8 bits as explained above, but the obvious disadvantage is that it's unable to transmit the whole English alphabet.
When dealing with any type of data transmission, you also need to take into account error checks like checksums and start/end flags. I've only got start/end flags implemented, and this is how they work:
1) The start flag
&DS/
is sent at the start of transmission
2) Data can them be transmitted in pulses (converted by the PMF codec)
3) The end flag
&DE/
is sent at the end of transmission
A transmission is considered "finished", when nothing has been received for at least 21ms. This is such a short timeframe, given the even shorter data transmission window, which means that if it has been more than 21ms, one out of the two scenarios can happen:
a) if the
&DE/
flag is received, the data within the flag is processed
b) if the
&DE/
flag is not received, anything from the
&DS/
flag is discarded (the instructions would not be processed)
1.3 Hash table
Available characters for PMF encoding are as follows (a comparison of native binary is shown as reference):
CharacterOutput for PMFOutput for binary
1
10000
00110001
2
01000
00110010
3
11000
00110011
4
00100
00110100
5
10100
00110101
6
01100
00110110
7
11100
00110111
8
00010
00111000
9
10010
00111001
0
01010
00110000
X
11010
01011000
Y
00110
01011001
Z
10110
01011010
:
01110
00111010
,
11110
00101100
_
00001
01011111
/
10001
00101111
&
01001
00100110
:5
11001
00111010 00110101
:10
00101
00111010 00110001 00110000
:15
10101
00111010 00110001 00110101
:20
01101
00111010 00110010 00110000
:25
11101
00111010 00110010 00110101
:30
00011
00111010 00110011 00110000
+
10011
00101011
-
01011
00101101
START
11011
01010011 01010100 01000001 01010010 01010100
STOP
00111
01010011 01010100 01001111 01010000
SPACE
10111
01010011 01010000 01000001 01000011 01000101
&DS/
01111
00100110 01000100 01010011 00101111
&DE/
11111
00100110 01000100 01000101 00101111
1.4 Practical test
The practical test below represents real-time data transmissions with raw binary as the comparison. Enter anything you want (so long as it's in the "character" column of the table above), followed by spaces after every "bit" of data you want to send (a bit confusing, but that's how data is parsed for sending), and then click send to see how long it takes to transmit!
The blue flash signifies the start of transmission, the red flash signifies a "1", and the green flash signifies the end of transmission.
Valid instruction set
-
START X :30 STOP START X :20 STOP
Invalid instruction set
-
START A:30 STOP START X:20 STOP
Send
L.T.S. (TX)
Elapsed Time: 0.00s
L.R.S (RX)
PMF (top) vs raw binary (bottom)
L.T.S. (TX)
Elapsed Time: 0.00s
L.R.S (RX)
For now, you'll have to refresh the page to test another instruction set out. Currently working on a fix for that!
1.4 Evaluation
Overall, despite the obvious limitation of not having every single key, I think this encoding scheme is super efficient, and would be helpful to implement in situations where the time it takes to send data (such as over optical links) needs to be short to provide faster response times. Take this example code
START X :15 STOP START Y : 9 STOP
(which would translate to: Start moving for 15 seconds in the x direction, then stop and move in the y direction for 9 seconds then stop) and pop it into the test bench and see the difference in length it takes to transmit it. Almost 15 seconds less!