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 or "A" with ), 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.

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 is sent at the start of transmission

2) Data can them be transmitted in pulses (converted by the PMF codec)

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 flag is received, the data within the flag is processed

Available characters for PMF encoding are as follows (a comparison of native binary is shown as reference):

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.

-

-

For now, you'll have to refresh the page to test another instruction set out. Currently working on a fix for that!

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 (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!