Overview: The XDK110

The Bosch Cross Domain Development Kit (XDK) is a programmable sensor device for building IoT applications. It contains a wide range of sensors and means of connectivity and is extensible using its extension bus. Due to its versatility it also serves as reference platform for Mita.

To learn more about the XDK head over to http://xdk.io.

Implemented System Resources

Currently implemented sensors, connectivities and buses in the XDK110 platform:

For the gyroscope you can choose from three different variants:

1. Pre-calibrated, more robust through sensor fusion
2. Direct access to BMI160
3. Direct access to BMG160

Configuration

Binary Name

To customize the produced binary name configure XDK110.applicationName: string . The default name is MitaApplication:

setup XDK110 {
  applicationName = "ShockDetector";
}

Startup Delay

To debug the startup process you can configure a startup delay so the XDK can connect via USB before setting up devices, connectivity, etc.:

setup XDK110 {
  startupDelay = 5000; /* wait 5 seconds before initialization */
}

Extension Bus Power

Per default the XDK doesn’t power the 2.5V and 3.3V lines on its extension bus. Some system resources like I2C or GPIO already change this, however in some cases you need to do this manually for example when using the ADC with a microphone:

setup XDK110 {
  powerExternalDevices = true;
}

Sensors

Any sensor can be used without configuring it. It will be initialized with sensible defaults. If you want to change a sensor’s default hardware parameters just set it up, e.g. the accelerometer:

setup accelerometer {
  // change the bandwidth of the low-pass filter
  bandwidth = BW_1000Hz;
}

Content assist (CTRL+Space) will provide you with all available configuration items and their valid values.

Temperature, pressure and humidity are available from a single resource: environment.

Device Information

The XDK offers some information you can read out via modalities.

Power Status

An approximation of whether the device is charging or on battery, and what the battery level is can be read out using XDK110.powerStatus. For example:

every button_one.pressed {
    let ps = XDK110.powerStatus.read();
    where(ps) {
        is(PowerStatus.Battery -> level) {
            println(`Battery level: approx. ${level}%`);
        }
        is(PowerStatus.Corded) {
            println("Charged");
        }
    }   
}

This is only an approximation based on the voltage level read out of channel 7. During charging the reported level can be over 100%.

Connectivities

Hardware

Hardware connectivities are available as named singletons: this means that you can configure each connectivity only once and need to give it a name. These connectivities however offer multiple instantiation of their signals. This means that for example the LED resource can provide up to three different signals for the yellow, orange and red LED.

Software

Software connectivities can have as many instances as you want. Both HTTP REST and MQTT require you to specify a WLAN instance as a transport layer.

Buses

GPIO

GPIO is a named singleton: you can instantiate it once and need to give it a name. Each of the 21 available GPIO pins can be configured as either input or output. Input pins can be operated in different modes:

• pull up/pull down: the pin is connected to high or low via a resistor, so that if the pin is not driven from the outside it returns to a set state.
• pull up with glitch filter: like pull up except for small glitches being filtered out.
• no pull: the pin floats freely, i.e. if it is not driven it keeps its current state except for environmental influences and self-drain.

I2C

I2C can be instantiated multiple times so you can model different devices on the same bus. You can exchange either single words from one to four byte or complete messages as arrays of integer words. For multi-byte words, both little and big endianess are supported with the default being the XDK’s endianess, little endian.

Events

Some sensors provide events you can react to. These events are things like “device moved” (accelerometer.any_motion) or “button was pressed” (button_one/button_two.pressed).

The platform itself provides a special startup event which is triggered after the device has fully started up. This means that all resources are initialized, for example WLAN is connected, sensors collect data, and all events are enabled.

Specification

Sensors

Accelerometer (BMA280)

The BMA280 is a tri axial, low-g acceleration sensor with digital output for consumer applications. It allows measurements of acceleration in three perpendicular axes.

Configuration

Modalities

Events

Gyroscope (Calibrated, Sensor Fusion)

This sensor is a front end for a software library that improves on accuracy and physical limititations of the built-in sensors using sensor fusion.

Alternatively you can access two hardware sensors directly: BMI160 and BMG160

This virtual sensor only offers modalities.

Modalities

Gyroscope (BMI160)

The BMI160 is a small, low power, low noise 16-bit inertial measurement unit designed for use in mobile applications like augmented reality or indoor navigation which require highly accurate, real-time sensor data.

Configuration

Modalities

Gyroscope (BMG160)

The BMG160 is an ultra-small, digital 3-axis angular rate sensor with a measurement range up to 2000°/s and a digital resolution of 16 bit for consumer electronics applications.

Configuration

Modalities

Magnetometer (BMM150)

The BMM150 is a low power and low noise 3-axis digital geomagnetic sensor to be used in compass applications.

Configuration

Modalities

Environment (BME280)

The BME280 is a combined digital humidity, pressure and temperature sensor based on proven sensing principles.

Configuration

Modalities

Light(MAX44009)

The XDK light sensor.

Configuration

Modalities

Noise Sensor

The noise sensor uses the XDK’s microphone to detect noise around it. The noise is calculated over 256 microphone samples. Note that this value is without unit and needs to be calibrated/converted by your application if you require absolute noise level measurements.

Configuration

Modalities

Buttons

The XDK features two buttons. Pressed and released are encoded by true and false in Mita. Button presses can be detected using event handlers, i.e. every button_one.pressed.

Modalities

Events

Connectivities

LED

The XDK features three custom usable LEDs in red, orange and yellow. On and off are encoded using true and false in Mita.

Modalities

ADC

The XDK’s ADC (Analog Digital Converter) can measure voltages against internal or external potentials.

Configuration

Signals

BLE

BLE (Bluetooth Low Energy) allows the XDK to communicate over short range, up to 50m, with various devices like smartphones. In BLE a server continuously advertises all characteristics and clients can connect without requiring further interaction or authentication.

Configuration

Signals

WLAN

WLAN is one of the hardware connectivities available on the XDK. Configuration is done using sum types. Even though the concept of sum types may be daunting they are actually very easy to use. Say you want to configure authentication. Content assist (CTRL+Space) offers you three different choices: None, Enterprise and Personal. Each accepts a different number of parameters. For example to configure a WLAN with WPA2 Personal you would write this:

setup net: WLAN {
  ssid = "MyWlan";
  authentication = Personal(psk = "mySecretKey");
  /* ... */
}

Configuring IP address works the same: you can choose from either Dhcp or Static.

Content assist will help you fill in all parameters.

Configuration

MQTT

MQTT is a messaging protocol for low bandwidth networks. The current implementation is based on the serval stack. MQTT requires a setup WLAN resource.

Example

setup net: WLAN { /* ... */ }

setup backend: MQTT {
  transport = net;
  url = "mqtt://iot.eclipse.org";
  clientId = "XDK42";

  var telemetry = topic("telemetry");
}

every 100 milliseconds {
  backend.telemetry.write(`${accelerometer.magnitude.read()}`);
}

Configuration

Signals

Eclipse Hono

Mita implements a HonoMqtt resource you can use to easily connect to an Eclipse Hono service via MQTT.

Example

setup net: WLAN { /* ... */ }

setup backend: HonoMqtt {
  transport = net;
  url = "mqtt://iot.eclipse.org";
  clientId = "XDK42";
  authentication = Authenticated(username="consumer@HONO", password="verysecret");

  var telemetry = telemetry(qos=0);
}

every 100 milliseconds {
  backend.telemetry.write(`${accelerometer.magnitude.read()}`);
}

Configuration

Signals

REST over HTTP

Using REST you can easily talk to servers over HTTP. REST defines a stateless interface with a simple URL scheme. Normally a REST server consists of a versioned endpoint like http://api.github.com/v3 which then provides different resources, for example api.github.com/v3/repos/eclipse/mita/branches and /repos/eclipse/mita/issues.

Currently only writing is supported.

Example

setup net: WLAN { /* ... */ }

setup backend: HttpRestClient {
  transport = net;
  endpointBase = "http://jsonplaceholder.typicode.com";

  var posts = resource("/posts");
}

every 100 milliseconds {
  backend.branches.write(`${accelerometer.magnitude.read()}`);
}

Configuration

Signals

LoRa

LoRa is a low-power network for IoT. Since bandwidth is usually extremely limited you should only send small messages infrequently. In this implementation there are two ways to send data: either raw bytes or CayenneLPP messages, a serializable predefined format.

Receiving messages is currently not supported.

Example

setup lora: LoRa {
  region = EU;
  loraAppKey = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
  loraAppEui = [0,0,0,0,0,0,0,0];

  var r = raw(0, Unconfirmed);
  var c = cayenne(1, Confirmed);
}

every 1 hour {
  let data: array<CayennePayload, 1>;
  data[0] = CayennePayload.Accelerometer(
    accelerometer.x_axis.read() as int16, 
    accelerometer.y_axis.read() as int16, 
    accelerometer.z_axis.read() as int16
  );
  lora.c.write(data);
}

every 10 minutes {
  let data: array<uint8, _> = [0xCA, 0xFE];
  lora.r.write(data);
}

Configuration

Signals

Cayenne Messages

The following CayenneLPP messages are supported via a sum type:

alt CayennePayload {
    DigitalInput: uint8
  | DigitalOutput: uint8
  | AnalogInput: int16
  | AnalogOutput: int16
  | IlluminanceSensor: uint16
  | PresenceSensor: uint8
  | TemperatureSensor: int16
  | HumiditySensor: uint8
  | Accelerometer: int16, int16, int16
  | Barometer: uint16
  | Gyrometer: int16, int16, int16
  | GpsLocation: {Latitude: int32, Longitude: int32, Altitude: int32}
}

Constructing them works like in the example above or as described in the documentation of sum types. For example to create a GPS location message type CayennePayload.GpsLocation(Latitude=lat, Altitude=alt, Longitude=lon).

Buses

GPIO

GPIO provides bit-wise communication with the environment. Low (0V) and high (3.3V) are represented by false and true.

Example

setup test: GPIO {
  var out = digitalOut(pin = PA1, initialValue = false);
  var inp = digitalIn(pin = PB2, mode = PullDown);
}

every 100 milliseconds {
  test.out.write(true);
  let x = test.inp.read();
}

Signals

I2C

The I2C bus provides access to interfaced devices via I2C.

Configuration

Signals

IO

SD Card

SD cards can be used to log data without connectivity. Only FAT32 is supported.

There are different kinds of file access:

• read or write
• resuming/appending or rewinding
• text or binary

Resuming only applies to read access to files. It means that, when you do consecutive reads, the second reads picks up where the first left of.

Appending only applies to write access to files. It means that, when you write to an already existing file, you will always append content.

Rewinding applies to both kinds of accesses to files. It means that reads or writes always start at the beginning of the file. When writing, the file will always be truncated first.

Text means you will get null terminated strings, where binary will give you blocks of bytes.

In all cases, writing will ensure that the file exists and create it if it doesn’t.

You can declare multiple files with the same path; this way you can read and write at the same time or emulate pipes.

Files will not stay open between calls, this means that you can safely declare a file with write access multiple times, for example to read it in both text- and binary-mode.

Configuration