Blog

We just released the new firmware version 2.0.6 for the LED Strip Bricklet. When we started with the Bricklet, it only supported WS2801 LEDs. More LEDs were added over time and now we added three more.

The LED Strip Bricklet now supports

• WS2801,

• WS2811,

• WS2812/SK6812/WS2813 (NeoPixel RGB),

• SK6812RGBW (NeoPixel RGBW),

• LPD8806 and

• APA102 (DotStar).

Especially interesting are the new NeoPixel RGBW and DotStar LEDs. The former has an additional individually controllable white LED and the latter are available with an additional intensity channel or as completely white strips with 24 bit resolution per LED.

Additionally we added more API to make it easier to handle LED strips from different manufacturers. Since the order of the LEDs inside of a package is not standardized, some LEDs are controlled in the order RGB, others are BGR or even different. You can now define the order of the LEDs of your strip with the set_channel_mapping function. After the channel mapping is set correctly the LEDs are always in the sequence RGB or RGBW.

We have two new Bricklets available: The CAN Bricklet and the RGB LED Bricklet.

With the CAN Bricklet you can send and receive frames on a CAN bus. A CAN bus is often used in cars as well as industrial sensors and other industrial parts. We are planning to offer a tutorial on how to use the CAN Bricklet with CANopen soon. The Bricklet has a configurable baudrate between 10kbit/s and 1Mbit/s. It is possible to apply filters to match for frames with a specific identifier.

The CAN Bricklet is available for 19.99€ including VAT.

The RGB LED Bricklet is equipped with a single controllable RGB LED. Each color channel (red, green, blue) has a resolution of 8 bit.

During the design phase of the RGB LED Bricklet we made a rather embarrassing mistake. We tried to fit the LED on Bricklet with a width of 15mm. It didn’t fit, so we had to make it wider. We accidentally ended up ordering the PCBs with a width of 17.5mm, which does not fit in our standard 5mm grid that we use for all Bricks and Bricklets. We will add another 2.5mm in hardware version 1.1. In the meantime the RGB LED Bricklet with hardware version 1.0 is available for half the price (3.49€ instead of 6.99€).

We only have 250pcs with hardware version 1.0 in stock, so we expect that hardware version 1.1 with the correct hole spacing will be available soon!

A while ago Microsoft released Windows 10 IoT Core that can run on different embedded boards, such as the Raspberry Pi. The normal Brick Daemon for Windows does not work on Windows 10 IoT Core. But now we have a beta version of Brick Daemon that works on Windows 10 IoT Core.

Installation

This version of Brick Daemon has been tested on a Raspberry Pi 2 Model B with the Windows 10 IoT Core versions 10.0.10586, 10.0.14295 and 10.0.14376.

At the moment Brick Daemon for Windows 10 IoT Core can only be installed from source code. If you don’t have Visual Studio 2015 for Windows 10 IoT development installed yet then you can follow Microsoft’s Getting Started guide to install it.

Now you can download and unpack the required Brick Daemon and daemonlib source code from GitHub. The daemonlib source code has to be unpacked to src\daemonlib directory in the Brick Daemon source code directory:

brickd-2.2.2-uwp-beta1
-> src
   -> brickd
      -> client.c
      -> ...
   -> daemonlib
      -> daemon.c
      -> ...

Now open src\brickd\brickd_uwp.sln in Visual Studio 2015 and compile and run the project. You should now see a running Brick Daemon app.

It’s a beta!

This is a beta version because there is currently one major issue: USB device auto-detection doesn’t work properly for all Bricks.

The Windows.Devices API to access USB devices requires that every USB device has a DeviceInterfaceGUID assigned. Normally this would just work out-of-the box with all Bricks, but Windows 10 IoT Core (at least versions 10.0.10586, 10.0.14295 and 10.0.14376) seem to have a bug that breaks this for all Bricks except the RED Brick. It’s unclear why the RED Brick is not affected by this problem.

Becasue of this all Bricks except the RED Brick need a manual change in the Windows Registry to make the Windows.Devices API accept them. Here’s what you need to once do for every Brick:

Connect the Brick to USB first, then connect to Windows 10 IoT Core using Power Shell and modify and execute the following command:

reg add "HKLM\System\CurrentControlSet\Enum\USB\VID_16D0&PID_063D\6K9mW5\Device Parameters" /v DeviceInterfaceGUIDs /t REG_MULTI_SZ /d "{870013DD-FB1D-4BD7-A96C-1F0B7D31AF41}"

This adds the missing DeviceInterfaceGUID for a Brick with UID 6K9mW5. To add the DeviceInterfaceGUID for your Brick replace 6K9mW5 with the UID of your Brick in the command.

Afterwards you need to reset the Brick. Now Brick Daemon should find it. But sometimes the reg add command hangs for some unknown reason. If this happens restart Windows 10 IoT Core and try again.

There is a thread in our forum for your feedback.

The second part will discuss the technical details and challenges of porting Brick Daemon to Windows 10 IoT Core.

The new WIFI Extension 2.0 is finally available!

It features the now ubiquitous ESP8266. We use the ESP-WROOM-02 module which is FCC/CE compatible. As you can see on GitHub the development for this new Extension started on July 27th 2015. Nearly one year ago, holy moly!

The new WIFI Extension 2.0 comes with it’s own firmware that can be updated completely automatically by the Brick Viewer through a Master Brick. So you don’t need a FTDI cable or similar to update the Extension. Compared to the old WIFI Extension we have many new features and even more are planned:

Every other property between the two are either equal or very similar (RF output power, etc.). As you can see, the new WIFI Extension 2.0 can replace the old WIFI Extension in all but one feature: You can’t connect an external antenna. We realize that this is necessary for some applications. Unfortunately none of the ESP8266 modules with a external antenna connector that are currently available on the market is FCC and CE compatible. As far as we can tell they have neither been tested, nor would they pass a test.

As a workaround we will still offer the old WIFI Extension for the time being. In the last production run a few weeks ago we made sure to produce a full batch. So we expect the old WIFI Extension to be available as fallback for a long time :-)

This year the Automatica is from 21st to 24th June in Munich. We will present our building blocks at this trade fair for automation and mechatronics for the first time. We are very curious about the feedback. Our booth is in hall A5 stand 139A. You will be able to see applications four our building blocks in the areas of low cost automation and rapid prototyping.

As an exhibitor we will have an allocation of free tickets again. If you want to visit us at Automatica, please write an email to info@tinkerforge.com.