Keiser® Multi-Bike Receiver

Development Guide for the Multi-Bike Receiver.

NOTE API Version 1.1 is compliant with the Keiser LTS (Long Term Support) version 1.0 and adds non-breaking functionality.

Changes Adds support for bike gears.

The Keiser Multi-Bike Receiver allows a link between several M3i equipped bikes and an external monitoring service. Bluetooth data is received from several bikes by the receiver and retransmitted using IPv4’s UDP protocol. The receiver allows configuration to reduce packet sizes and increase reliability by only sending data relevant to the application.

Hardware

The Multi-Bike Receiver package is comprised of a receiving unit with a single ethernet port, an HDMI port, and a DC power adapter. The package also include 1 CAT5e cable for use in connecting the receiver to a router or switch.

Basic Multi-Bike Receiver setup using ethernet to connect to a basic router.

Transmission

Data received from a bike is combined with the other bike data received over a half second time-period and then transmitted over IPv4 via Multicast. The transmission is a UDP (IPv4 Protocol 17) Multicast. The default destination is address 239.10.10.10 and port 35680. These values are configurable within the receiver. It is possible that several receivers will exist within a single facility and will be considered to operate in the same collision domain, so IP addresses should be configurable within the application. Each receiver will transmit data collected from any bike in range so it is probable that two or more receivers will transmit a single bikes data. It is the responsibility of the monitoring software to detect these occurrences as the receiver makes no attempts to resolve these duplicate broadcasts.

Setting Default Description
Broadcast IP Address 239.10.10.10 The multicast address which broadcasts are directed to.
Port 35680 The port which broadcasts are directed to.

Broadcast Datagram Structure

The UDP datagram is a IPv4 standard packet which most platforms make accessible through a networking API. If no networking API is available, the packet can be parsed very simply using a byte stream parser. There is no acknowledgment required with a UDP transmission, and partial packet transmissions are not accepted. This allows packets to be transmitted faster, and the smaller packet reduces the chance of collision. There is, however, no guarantee of packet transmission completion, so collisions may occur and will result in the total loss of that packet of information.

Broadcast Datagram

01 00 5E 0A 0A 0A 00 07 80 01 68 EB 08 00 45 00 00 33 00 00 40 00 01 11 BE DE C0 A8 01 1F EF 0A 0A 0A 81 04 8B 60 00 1F A6 6A 0B 9F 38 7E 75 29 3B 78 DB 06 13 63 7B EA 00 00 09 00 71 00 00 00 BA 0F
  • 01 00 5E … EB 08 00 The Ethernet II header includes the source MAC address as well as the listening device's MAC address. These values are not needed for most applications.
  • 45 00 00 … 0A 0A 0A The IPV4 header contains the source address (receiver's IP address) as well as the destination address (broadcast IP address). These values are necessary if the networking APIs in use do not allow for address group binding.
  • 81 04 8B 60 00 1F A6 6A The UDP header contains the source port (broadcast port) as well as the destination port (port received on). These values are necessary if the networking APIs in use do not allow port filtering.
  • 0B 9F 38 … 00 BA 0F The packet data section contains the transmission data. Most APIs will make this data accessible as a byte stream for parsing.

Packet Data Structure

The data packet begins with one byte of API version data, then one byte of configuration data, and finally the collected bike data concatenated without spaces or identifiers. The API version byte is an unsigned byte integer corresponding to the API version. The configuration byte is a bit flag byte used to determine the appropriate parsing settings and for calculating the bike data offsets.

Packet Data

0B 9F 38 7E 75 29 3B 78 DB 06 13 63 7B EA 00 00 09 00 71 00 00 00 BA 0F
  • 0B The API version byte indicates the API version which should be used for parsing the remainder of the data stream.
  • 8F The configuration byte sets the parameters outlining the structure of the bike data included in the packet data.
  • 38 7E 75 … 00 BA 0F The bike data portion contains all the data pertaining to the bikes detected during the reception period. Each individual bikes data is concatenated to together after the configuration byte.

API Version

The API version byte should be used to identify the API version being broadcast prior to parsing. This version byte will always be the first byte in the broadcast starting at API version 1.0 and moving forward. The byte is an integer wit decimal accuracy, so the value should be divided by 10 to achieve the actual version number.

API Version Byte

0x0B = 11 (API Version 1.1)

Configuration Byte

Bit Name Description
0x01 UUID Send Unset does not send UUID, Set sends 6 byte UUID.
0x02 Version Send Unset does not send version, Set sends 2 byte version.
0x04 Interval Send Unset does not send interval data, Set sends 7 byte interval data.
0x08 RSSI Send Unset does not send RSSI, Set sends 1 signed byte RSSI (-128 – 127).
0x10 Gear Send Unset does not send Gear, Set sends 1 unsigned byte Gear (1 to 24).
0x80 Imperial Units Unset means values are metric units, Set means values are imperial units.
  • UUID Send provides a 6 byte UUID, similar to a MAC address, which can be used to identify the bike regardless of bike identification value. Should only be used when bike identification value is not unique within the collision domain.
  • Version Send provides version number corresponding to the bike computers software version in the Major Version and Minor Version data fields.
  • Interval Send provides accumulated data averages and sends the Interval, Kcal, Clock, and Trip data fields. If interval is not set, broadcasts of averaged data from the bikes will be omitted from the broadcast.
  • RSSI Send provides received signal strength at the receiver at a 1-dBm resolution with a range of -128 to 127 dBm. This data is available for use in debugging, but should not be used in most situations.
  • Gear Send provides the displayed gear value for the bike.
  • Imperial Units determines the units used in the Trip data field.

Configuration Byte

9F = (1001 1111)
  • 0x01 (0000 0001) UUID Send flag is set.
  • 0x02 (0000 0010) Version Send flag is set.
  • 0x04 (0000 0100) Interval Send flag is set.
  • 0x08 (0000 1000) RSSI send flag is set.
  • 0x10 (0001 0000) Gear send flag is set.
  • 0x80 (1000 0000) Imperial Units flag is set.

Bike Data Structure

All data is transmitted in little endian, with least significant byte in first byte of offset. All transmissions begin with the two byte version and configuration header, followed immediately by the bike data. Bike data proceeds in the order BikeId, UUID, Major Version, Minor Version, RPM, HR, Power, Interval, Kcal, Clock, Trip, and RSSI. The bike data size will range from 5 to 21 bytes depending upon configuration. This allows for 100 bikes per transmission with the shortest data configuration, and 25 bikes per transmission with the longest data configuration. These values are based on the default configuration for broadcast datagram size taking into account IP and Ethernet headers and assuming moderate traffic on a stable network.

Name Data Size Description
Bike Id 1 Byte The bike Id is a domain specific ordinal number which corresponds to the number printed on the bike.
UUID 6 Bytes The UUID is a universally unique identifier which will be assigned to that bike indefinitely.
Major Version 1 Byte The software build major number of the bike. (Independent of API Version)
Minor Version 1 Byte The software build minor number of the bike. (Independent of API Version)
RPM 1 Byte The RPM value is the bike pedaling cadence in revolutions per minute (RPM) with integer precision.
HR 1 Byte The HR value is the riders heart rate in beats per minute (BPM) as detected by a heart rate strap worn by the rider with integer precision. If the rider is not wearing a heart rate strap, the value will be 0.
Power 2 Bytes The Power value is the power produced by the rider in watts with integer precision.
Interval 1 Byte The Interval value indicates the current state of data transmission. A value of 0 indicates that data is all real time. A value between 1 and 99 indicates the current set of data are averages over the interval. A value greater than 128 and less than 255 indicates that the rider is currently in an interval. The actual interval number will be this number minus 128. (Ex: 0x84 = 132 = Interval 4 In-Progress) A value of 255 indicates the current transmission is averages over the course of the entire ride.
Kcal 2 Bytes The Kcal value is the energy produced throughout the ride with some assumed lose of energy in proportion to average human inefficiency with integer precision.
Clock 2 Bytes The Clock value is the time spent pedaling in seconds with integer precision.
Trip 2 Bytes The Trip value is the distance pedaling with decimal precision.
RSSI 1 Byte The RSSI value is the received signal strength indication as determined by the receiver in decibel-milliwatts (dBm). The value is a signed number with integer precision, and should only be used for debugging purposes.
Gear 1 Byte The Gear value is the resistance metric used on the bike's display. A value of 0 indicates the bike does not support transmission of the gear. If supported, this value will be between 1 and 24.

Bike Data

38 7E 75 29 3B 78 DB 06 13 63 7B EA 00 00 09 00 71 00 00 00 BA 0F
Data Attribute Value
38 Bike Id 0x38 = 56
7E 75 29 3B 78 DB UUID DB:78:3B:29:75:7E
06 Major Version 0x06 = 6
13 Minor Version 0x13 = 19
63 RPM 0x63 = 99 RPM
7B HR 0x7B = 123 BPM
EA 00 Power 0x00EA = 234 watts
00 Interval 0x00 = 0 (real time)
09 00 Kcal 0x0009 = 9 Kcal
71 00 Clock 0x0071 = 71 seconds
00 00 Trip 0x0000 = 0 miles
BA RSSI 0xBA = -70 dBm
0F Gear 0x0F = Gear 15

Dynamic Network Buildup

The multi-bike receiver has support for allowing dynamic network buildup for quicker installations. The receiver broadcasts a structured packet every 30 seconds to broadcast ip address 239.10.10.10 on port 35679. The broadcast is a ASCII encoded byte stream. All characters used can be decoded using either ASCII or UTF-8 decoders.

Network Bulidup Brodcast Structure

4B 45 49 53 45 52 2D 52 45 43 45 49 56 45 52 7C 4E 41 4D 45 3A 52 65 63 65 69 76 65 72 20 53 69 6D 75 6C 61 74 6F 72 7C 41 50 49 3A 31 31 7C 49 50 3A 32 33 39 2E 31 30 2E 31 30 2E 31 30 7C 50 4F 52 54 3A 33 35 36 38 30 7C

Decoded using UTF-8

KEISER-RECEIVER|NAME:Receiver Simulator|API:11|IP:239.10.10.10|PORT:35680|

The character stream uses vertical bar character ( | U+0007C) as key-value pair delimiters, and the colon character( : U+003A) is used to separate keys and their associated values. The first segment will always include the string "KEISER-RECEIVER". The segments following will include key-value pairs in no specific order.

Parsed Data Structure

{
        "NAME":"Receiver Simulator",
        "API":11,
        "IP":"239.10.10.10",
        "PORT":35680
}

Development Tools

Name Description
Multi-Bike Receiver Simulator Simulates a multi-bike receiver broadcast using the computer's default network connection.
Multi-Bike Receiver Debugger Allows viewing of broadcast data using the computer's default network connection.
Multi-Bike Receiver Finder Tools used to detect multi-bike receiver's IP address for configuration.

Developer Support

We are here to help. If you are having trouble understanding the documentation or have a question, please feel free to contact us. We also want to hear what great things people are able to do with our products, so please let us know about your project.

Keiser Open Development
development@keiser.com
Toll-Free: +1 (800) 888-7009