mBot 2.4G Wireless Serial

mBot 2.4G Wireless Serial

In contrast to the device's name this device does not implement a USB serial device but a USB HID ("Human Interface Device"). This device is used without a device driver by the mBlock software, by communicating directly with the device using the node-hid library for Node.js

I have not found out yet how to use this device to upload a new program to the mBot's Arduino, and it may well be that this is not possible at all.

The device uses VID 0416 and PID ffff, the manufacturer string reported is "MemsArt" and the product string is "RF UART".

Using the device on linux, from a C program

It is quite easy to communicate with the mBot's serial interface by using the HIDAPI library. I used the HIDRAW backend, but I don't see a reason why any other backend should not work.

The sample program on the HIDAPI webpage works with the mBot if you replace the VID and PID, it sends some (quite senseless) data to the mBot, and reads back the most recent (?) data the mBot wrote to its serial interface. Of course you'll need some programm running on the mBot to tell you what's happening on the serial interface...

The command to compile the sample program on my pi was

gcc -I/usr/include/hidapi hidtest.c -o hidtest -lhidapi-hidraw

HIDAPI Sample Program

While the beginning of the program is a generic listing of connected devices, the line handle = hid_open(0x0416, 0xffff, NULL); opens a connection to the RF UART.

Dumping the strings for manufacturer, product and serial is interesting but carries no real functionality.

The lines sending and reading a feature report do nothing really useful, probably the RF UART does not support such frames.

Writing data

The real interesting part starts with calling the hid_write function. To write useful data to the mBot the block passed to hid_write has to start with a 0x00 byte followed by a byte specifying the number of payload bytes to be transferred.

So, if you want to send the three characters "ABC" to the mBots serial interface, this code should do the job:

unsigned char buf = { 0x00, 0x03, 0x41, 0x42, 0x43 }; res = hid_write(handle, buf, 5);

Reading data

The most simple was to receive data sent by the mBot is to poll for data like it is done in the res = hid_read(handle, buf, 65); line. If there's data in the mBots buffer, the first byte of the received block tells you how many bytes of data in the block are valid.

The following bytes are the payload data.

I don't have an idea on how the mBot's buffer (or is it the library's?) works yet. If I have received data, I always got a single complete line, terminated by a linefeed (0x0a) character...

Notes

• The wireless serial module is (probably) disabled while you are using a serial monitor with a USB cable connected to the mBot. So you have to think of alternatives to show you what's happening. Try the LEDs or the buzzer, be creative! :-)
• The sample program may have to be started with sudo, unless your udev is configured otherwise, see below
• It seems like the mBot side of the interface only sends data to the computer after the mBot has sent a linefeed on its serial. Probably it will also send data when its internal buffer is full, but I have not checked this.
• The mBot's serial interface speed of 115200 is faster than the RF transmission. So, if sending bigger blocks of data, make sure to put in some delay statements, to avoid loosing data because of buffer overflows.

Configure udev to allow access without sudo

I found the solution in principle at http://reactivated.net/writing_udev_rules.html

The device belongs to the "hidraw" subsystem of udev. Since we also know the vendor- and device-id we can create a rule for udev to allow access to the device for everyone:

• sudoedit /etc/udev/rules.d/50-Makeblock2.4G.rules
• Type in the line SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0416", ATTRS{idProduct}=="ffff", MODE:="0666"
• Save it and reboot.

Notes

• The filename (50-Makeblock2.4G.rules) must end with ".rules". The "50-" at the start allows you to set the order in which the rules files are read in (which is probably irrelevant in this case, but may be in others). The rest of the filename has no technical relevance, choose it so you know what this file is about.
• With this udev rule everyone can read and write the device. This is probably not the best solution from a security point of view. Try to make it better!