CoMatrix setup, SAMR21-xpro microcontroller with a DS18S20 temperature sensor and Raspberry Pi 3 gateway.
Our Client speaks CoMatrix
How to overcome kernel panic, deal with buffer limitations and LOL at random. (19.05.2021)
Förderjahr 2018 / Project Call #13 / ProjektID: 3441 / Projekt: CoMatrix

This blogpost gives you an insight into the challenges and difficulties in the development of the CoMatrix client library, which is backed by the RIOT OS[1]

RIOT OS is a free and open source IoT operating system, which is developed and maintained by a grassroots community. RIOT OS supports a variety of microcontroller boards, including the hardware platform used in our CoMatrix project (SAMR21-xpro[2]). Applications integrate specific IoT libraries, which are available as RIOT OS modules or packages, enabled by a switch in the Makefile to keep the memory footprint of the firmware binary small. In our CoMatrix client implementation we use two CoAP libraries (gcoap and nanocoap), the generic network routing module for 802.15.4 protocol support and the tinyCBOR package, which integrates external source files from Intel.

CoMatrix setup, SAMR21-xpro microcontroller with a DS18S20 temperature sensor and Raspberry Pi 3 gateway.

If you are used to higher programming languages and nearly unlimited virtual memory space, coding in C for a microcontroller opens a can of worms. Be aware of your buffer lengths, free your allocated memory after use without dangling pointers and take care of the number of threads you are calling. Anything can possibly result in a kernel panic and lead your program execution into a system failure.

Here we like to share our experiences with three selected problems which occured during the implementation of the CoMatrix client library:

  1. Overcoming gcoap packet size limitations: With a noob enthusiasm we started to send gcoap packets containing our CoMatrix requests to the CoMatrix gateway (implemented in Python) running on a Raspberry Pi. But just small fragmented parts of the content arrived at the gateway, until we figured out that the default packet size of a gcoap packet is set to 128 bytes (GCOAP_PDU_BUF_SIZE). Unfortunately this is not enough for a CoMatrix CoAP request, where the Matrix access token alone has a length of over 250 bytes. So we experimented and increased the buffer size to 500 bytes, which was sufficient for our tests. Further Tobi asked for the reason of this size limitation of the GCOAP_PDU_BUF_SIZE on the RIOT OS IRC channel, which lead to an RIOT OS issue and a new pull request to change the default value[3]. (@chrysn: Thanks for your support.)
  2. Everything but Random A Matrix client sends messages into a room at a Synapse server containing an unique message identifier. So where do we get unique numbers on a microcontroller? After being aware of this problem, we decided to request a timestamp from the CoMatrix gateway on initialization after a SAMR21-xpro reset. This solution triggered another problem, which was caused by the lack of randomness. Each CoAP request on initialization uses the same CoAP token. Our CoMatrix gateway detects the same CoAP token and therefore answers with the same (old) message (containing an old timestamp). So this is still a problem, but the current workaround is to restart the gateway also.
  3. Still not able to talk in secret Our future work is to make that happen. Currently both CoMatrix client and gatway only support plaintext CoAP.

Now to the good news: Our prototype client implementation contains two example applications.

Example CoMatrix Chat … is a simple CoMatrix command line chat application, which enables anyone to test all implemented CoMatrix features.

CoMatrix currently supports

  • registration of a new user at a Synapse homeserver,
  • joining of a room on a Synapse server (after an invitation),
  • a login with username and password to get a new Synapse access token,
  • a logout to disable the Synapse access token,
  • sending messages to a room (be brief - the buffer sizes are still limited) and
  • receiving the last message of a room.

Example CoMatrix Temperature Sensor

We upgraded our SAMR21-xpro board with a DS18S20 temperature sensor. Due to the lack of input interfaces on a sensor node, all necessary parameters such as the Synapse access token, the Matrix room id, the domain or IP address of the Synapse server and the link-local IPv6 address of the gateway are set in the application configuration file. Build the firmware and flash it on your SAMR21-xpro and the CoMatrix sensor node will measure the temperature each minute and send the current value into your specified Matrix room.

Coding the CoMatrix client was fun and we learned a lot, we hope you enjoy our code as well.

Our code will be published at https://gitlab.com/comatrix/comatrix soon.

Links:

CAPTCHA
Diese Frage dient der Überprüfung, ob Sie ein menschlicher Besucher sind und um automatisierten SPAM zu verhindern.

    Weitere Blogbeiträge

    Datenschutzinformation
    Der datenschutzrechtliche Verantwortliche (Internet Privatstiftung Austria - Internet Foundation Austria, Österreich würde gerne mit folgenden Diensten Ihre personenbezogenen Daten verarbeiten. Zur Personalisierung können Technologien wie Cookies, LocalStorage usw. verwendet werden. Dies ist für die Nutzung der Website nicht notwendig, ermöglicht aber eine noch engere Interaktion mit Ihnen. Falls gewünscht, treffen Sie bitte eine Auswahl: