BlinkenlightsProtocolEnglish: Difference between revisions

From BlinkenArea Wiki
Jump to: navigation, search
(New page: __NOEDITSECTION__ {{FlagDe|target=BlinkenlightsProtocol}} ''back to summary'' The Blinkenlights protocol is used to transmit black/white Blinkenlights streams using UDP pack...)
 
m (stream timeout)
 
(3 intermediate revisions by 2 users not shown)
Line 3: Line 3:
''[[Protocols|back to summary]]''
''[[Protocols|back to summary]]''


The Blinkenlights protocol is used to transmit black/white Blinkenlights streams using UDP packets. Simply, a UDP packet is sent for every new frame:
== Stream ==
 
The Blinkenlights protocol is used to transmit black/white Blinkenlights streams using UDP packets. Simply, a UDP packet is sent for every new frame (frames lasting more than one second are repeated every second, 5 seconds is the stream timeout):


<pre>
<pre>
Line 33: Line 35:
* all values are in network byte order - big endian - highbyte first
* all values are in network byte order - big endian - highbyte first


The dynamic extension can be used to request a BLP stream dynamically. A request packet is sent periodically (e.g. every 10s) to the UDP port of the server. The server then replys with a BLP stream sent from this port to the source port of the request packet. After no request packet has been received for a longer time (e.g. 30s), the stream is no longer sent.
The UDP port should be configurable at server and client side. The standard port is UDP 2323.
 
It is also possible to send those packets over stream-like connections, like TCP or serial ports.
 
== Dynamic Extension ==
 
The dynamic extension can be used to request a BLP stream dynamically. A request packet is sent periodically (every 10s) to the UDP port of the server. The server then replys with a BLP stream sent from this port to the source port of the request packet. After no request packet has been received for a longer time (30s), the stream is no longer sent.


The format of the request packet is as follows:  
The format of the request packet is as follows:  
Line 67: Line 75:
* command: fixed value
* command: fixed value


The UDP port should be configurable at server and client side. The standard port is UDP 2323.
== Additional Information ==
 
A further extension allows to transmit information in addition to
the stream packets or the request packets of the dynamic extension.
Those information packets have the following structure:
 
<pre>
+-----------------------+
| magic                |
| 0xDE 0xAD  0xBE 0x23 |
+-----------------------+
| info                  |
| 0x45 0x4E  0x44 0x00 |
| 0x00 0x00  0x00 0x00 |
+-----------------------+
</pre>
 
* magic: fixed value
* info: 0..8 ASCII characters, padded with 0x00 to 8 bytes in total
** "END", S2R: the stream has ended
* abbreviations:
** S2R: sender to receiver, packet is sent in same direction as stream frames
** R2S: receiver to sender, packet is sent in same direction as stream requests
 
[[Category: Protocols]]

Latest revision as of 21:46, 21 December 2011

Zur deutschsprachigen Version dieser Seite

back to summary

Stream

The Blinkenlights protocol is used to transmit black/white Blinkenlights streams using UDP packets. Simply, a UDP packet is sent for every new frame (frames lasting more than one second are repeated every second, 5 seconds is the stream timeout):

+-----------------------+
| magic                 |
| 0xDE 0xAD   0xBE 0xEF |
+-----------------------+
| frame number          |
| 0x00 0x00   0x00 0x00 |
+-----------+-----------+
| width     | height    |
| 0x00 0x12 | 0x00 0x08 |
+-----------+-----------+
| pixels                |
| 0x01 0x01   0x00 0x00 |
| 0x00 0x00   0x01 0x00 |
| ...                   |
| 0x00 0x00   0x00 0x00 |
+-----------------------+
  • magic: fixed value
  • frame number: number of the frame, incremented with every frame, use is optional
  • width: the width of the image in pixels
  • height: the height of the image in pixels
  • pixels: the value of the width * height pixels
    • 0x00 for off, 0x01 for on, no other values allowed
    • from left to right, then from top to bottom (i.e. top left pixel first, pixel right to it next, ...)
  • all values are in network byte order - big endian - highbyte first

The UDP port should be configurable at server and client side. The standard port is UDP 2323.

It is also possible to send those packets over stream-like connections, like TCP or serial ports.

Dynamic Extension

The dynamic extension can be used to request a BLP stream dynamically. A request packet is sent periodically (every 10s) to the UDP port of the server. The server then replys with a BLP stream sent from this port to the source port of the request packet. After no request packet has been received for a longer time (30s), the stream is no longer sent.

The format of the request packet is as follows:

+-----------------------+
| magic                 |
| 0xDE 0xAD   0xBE 0xCD |
+-----------------------+
| command               |
| 'R'  'E'    'F'  'R'  |
| 'E'  'S'    'H'       |
+-----------------------+
  • magic: fixed value
  • command: fixed value

It is also possible to tell the server that the stream is no longer needed. This happens by sending a close packet instead of a request packet:

+-----------------------+
| magic                 |
| 0xDE 0xAD   0xBE 0xCD |
+-----------------------+
| command               |
| 'C'  'L'    'O'  'S'  |
| 'E'                   |
+-----------------------+
  • magic: fixed value
  • command: fixed value

Additional Information

A further extension allows to transmit information in addition to the stream packets or the request packets of the dynamic extension. Those information packets have the following structure:

+-----------------------+
| magic                 |
| 0xDE 0xAD   0xBE 0x23 |
+-----------------------+
| info                  |
| 0x45 0x4E   0x44 0x00 |
| 0x00 0x00   0x00 0x00 |
+-----------------------+
  • magic: fixed value
  • info: 0..8 ASCII characters, padded with 0x00 to 8 bytes in total
    • "END", S2R: the stream has ended
  • abbreviations:
    • S2R: sender to receiver, packet is sent in same direction as stream frames
    • R2S: receiver to sender, packet is sent in same direction as stream requests