This proposal is to also develop a different standard, targeted for human readout rather than smartphone.
So the design choices here are more aimed towards human perception. Specifically in the ability to visually discern the colour seqence manually (for manual entry). So this could include situations where a person is speaking out the colour seqence over phone while observing the led in some faulty equipment.
A common thing about the below encoding is that besides the "single led", the "two led" and "three led" transmit binary data via pulses. In which the period between pulses where all leds are off, is considered to be the bit clock.
This approach makes it easier for humans to discern/read off colour. This is because white pulses have the potential issue of blending between colours, while darkness is much easier to discern as a space between colours (especially between repeating colours). E.g. blue blue blue should be read as 3xblue, but in practice could be missed without an obvious transition to darkness.
That being said, there is nothing stopping a smartphone from decoding these. However this approach is much slower from a data rate transfer perspective.
Single LED
Just use morse code to send textual data, since its such a common standard for human communicating between humans over a single binary channel medium without encoding/decoding equipment. There are people who can interpret morse code already. Plus it would probbly be too hard to have a seqence that can transmit binary information that is human transcriptable to a computer easily.
Two colour (Or Just Two labeled LEDs )
Each bit in a word is pulsed one by one. With both of them pulsed together once all words are together.
COLOUR
1
2
Description
DARK
0
0
- bit clocking (Or channel down)
led 1
0
1
- 1 data pulse
led 2
1
0
- 0 data pules
led 1&2
1
1
- Symbol Space (Or Idle if constant)
It could be a seperate led labeled "1" and "0", or a mixed colour led of below pattern:
2
1
G
R
B
R
B
G
Green and Blue are usually stronger than red visually, so is picked as the "high" "1" pulse over red.
Blue is visually stronger than green usually, so is the "high" "1" instead.
RGB
updated: tried this in practice, and made some adjustments. (Green/Red is often used as fail/working status led. So avoid if possible.) (Also impractical for more than ) (Also this is most likely only used for error status code, if being read out manually field operators)
When inactive, the led is a steady red/green (or less commonly any other colours) for more than a few seconds.
However during a status code transmission, it will first transmit a steady red (or green), then a color sequences where each colour represents 2 bits, and a dark period between each pulse to seperate the half nibble pulses. When done, a steady idle colour (Often red/green) will appear for more than a few seconds. This status code sequence will repeat while the status is active.
Also here is a handy javascript function to decode the colour sequence below
```
function js_interpret_color_code(str)
{
var seq = str.split('');
var pos = 0;
var code = 0;
for ( c in seq )
{
switch(seq[c])
{
case 'b': code = code | (0 << (pos*2)); break; // Blue : 0x01 = 0b00
case 'm': code = code | (1 << (pos*2)); break; // Magenta: 0x02 = 0b01
case 'y': code = code | (2 << (pos*2)); break; // Yellow : 0x03 = 0b10
case 'w': code = code | (3 << (pos*2)); break; // White : 0x04 = 0b11
}
pos++;
console.log(seq[c]+" : "+pos);
}
return code;
}
```
Simple mode
In this one, two bits are sent at a time every colour pulse. Cyan is intentionally omitted for simple color code due to potential confusion with blue (colour perception makes us perceive the blue spectrum more strongly than green). (Also talking to a few others got similar answers of calling Cyan as light blue, thus field operators may accidentally call Cyan as blue).
COLOUR
R
G
B
Description
DARK
0
0
0
- bit clocking (or channel down)
BLUE
0
0
1
- 00
GREEN
0
1
0
- Clear Idle/Start Signal. Often Indicates normal status
CYAN
0
1
1
- (Unused since its easily mistaken for blue)
RED
1
0
0
- Clear Idle/Start Signal. Often Indicates a fail status
MAGENTA
1
0
1
- 01
YELLOW
1
1
0
- 10
WHITE
1
1
1
- 11
The standard structure of this is that the first 16bits (bit 0 to 15) is the status code, while the next 16 bits represents the event details. Any further and the status code will be more than 16 pulses in length which would be unbearably long.
Note: Status code 0 is reserved for no status.
Word stream output
This is similar to the above, but the output is not a repeating status code structure, but rather a binary stream. Also the harder to read cyan color is used as a word separator (e.g. to seperate each 8 bit byte).
This proposal is to also develop a different standard, targeted for human readout rather than smartphone.
So the design choices here are more aimed towards human perception. Specifically in the ability to visually discern the colour seqence manually (for manual entry). So this could include situations where a person is speaking out the colour seqence over phone while observing the led in some faulty equipment.
A common thing about the below encoding is that besides the "single led", the "two led" and "three led" transmit binary data via pulses. In which the period between pulses where all leds are off, is considered to be the bit clock.
This approach makes it easier for humans to discern/read off colour. This is because white pulses have the potential issue of blending between colours, while darkness is much easier to discern as a space between colours (especially between repeating colours). E.g. blue blue blue should be read as 3xblue, but in practice could be missed without an obvious transition to darkness.
That being said, there is nothing stopping a smartphone from decoding these. However this approach is much slower from a data rate transfer perspective.
Single LED
Just use morse code to send textual data, since its such a common standard for human communicating between humans over a single binary channel medium without encoding/decoding equipment. There are people who can interpret morse code already. Plus it would probbly be too hard to have a seqence that can transmit binary information that is human transcriptable to a computer easily.
Two colour (Or Just Two labeled LEDs )
Each bit in a word is pulsed one by one. With both of them pulsed together once all words are together.
It could be a seperate led labeled "1" and "0", or a mixed colour led of below pattern:
Green and Blue are usually stronger than red visually, so is picked as the "high" "1" pulse over red. Blue is visually stronger than green usually, so is the "high" "1" instead.
RGB
updated: tried this in practice, and made some adjustments. (Green/Red is often used as fail/working status led. So avoid if possible.) (Also impractical for more than ) (Also this is most likely only used for error status code, if being read out manually field operators)
When inactive, the led is a steady red/green (or less commonly any other colours) for more than a few seconds.
However during a status code transmission, it will first transmit a steady red (or green), then a color sequences where each colour represents 2 bits, and a dark period between each pulse to seperate the half nibble pulses. When done, a steady idle colour (Often red/green) will appear for more than a few seconds. This status code sequence will repeat while the status is active.
Also here is a handy javascript function to decode the colour sequence below
Simple mode
In this one, two bits are sent at a time every colour pulse. Cyan is intentionally omitted for simple color code due to potential confusion with blue (colour perception makes us perceive the blue spectrum more strongly than green). (Also talking to a few others got similar answers of calling Cyan as light blue, thus field operators may accidentally call Cyan as blue).
The standard structure of this is that the first 16bits (bit 0 to 15) is the status code, while the next 16 bits represents the event details. Any further and the status code will be more than 16 pulses in length which would be unbearably long.
Note: Status code 0 is reserved for no status.
Word stream output
This is similar to the above, but the output is not a repeating status code structure, but rather a binary stream. Also the harder to read cyan color is used as a word separator (e.g. to seperate each 8 bit byte).