Over Local Network Integration

Communicating With The Fresh KDS Application Over TCP/UDP

Fresh KDS Local Network Discovery

Discovery Broadcast

In order to know where to send TCP packet and message data, you will first need to know to which node on your network data should be sent.

Each node (tablet) with KDS installed and running - also referred to as “screens” - sends a UDP broadcast message containing the Device Identifier, IP Address , and SDK version every two (2) seconds. To discover Fresh KDS screens on your network, listen for these UDP broadcast messages on port 28000.

The broadcasted message must be parsed by your consuming implementation. These values are unlabeled as they come across the network to your device (they are not structured using traditional XML/JSON paradigms); as such, the way we think about parsing data from Hexidecimal must change. As recommended elsewhere, language-native libraries (or otherwise) may be of assistance in converting the data to the necessary formats for consumption downstream by your implementation.

UDP & Hexadecimal Primer

UDP communicates using bytes. The bytes received over UDP are encoded Hexadecimal format. Each eventually plain-text ASCII character is represented by two characters in Hexadecimal format (representing a single Hexadecimal value). For instance, the literal FreshKDS (8 characters in length) is represented by 16 characters in Hexidecimal format. Each ASCII character, e.g. F, is represented by two characters, e.g. 46 - a single Hexidecimal value.

Example Broadcast

The UDP broadcast is received in a byte array. This array will always have a length of 102. Encode this array to Hex. Notice the hex string has a length of 204. This is an example of a hex string broadcast from a KDS screen:


Parsing the UDP message into relevant data is critical for understanding screen information. The information parsed from this screen should be saved locally and used to later send data.

Parsing UDP Broadcast Messages

Parsing the broadcast string is as simple as knowing what indexes map to what information. You should break the larger broadcast message into smaller substrings in order to obtain values:

Value Start Index Length Hex Value ASCII Translation
Application (start of broadcast) 0 24 46726573684B445300000000 FreshKDS
Version 24 16 312E300000000000 1.0
IP Address 40 20 C0A80103000000000000
Identier 60 40 4537413039414144374239380000000000000000 E7A09AAD7B98
Name 100 104 656D756C61746F7200000000000000000000... emulator

The hex value is obtained by using the start/end indices to get the substring of the larger messages. The hexidecimal char 00 should be trimmed from the end of each value. Be careful not to trim just 0 as it could be part of the last hexidecimal char in the value.

The Application, Version, Identifier and Name can all easily by translated to ASCII with any HEX to ASCII converter.

The IP Address needs to be converted from HEX to DECIMAL in order to obtain the 4 digits making up the devices IP address. From the example above we have C0A80103000000000000 trimmed to C0A80103.

Hex Dec
C0 192
A8 168
01 1
03 3

The converted decimal values can be joined to give us our properly formatted IP Address:


  • Version in the table above refers to the version of the protocol defined in this document. If the version is the same as you are expecting, you can be assured your parsing algorithm will work as there have been no changes to the message body’s structure.