WIFI Extension 2.0 now supports Mesh Networking

With firmware version 2.1.0 the WIFI Extension 2.0 now supports Mesh Networking.

With Mesh Networking enabled you can have a whole bunch of stacks with WIFI Extension 2.0 and only one of them has to be reachable by a WIFI router.

The WIFI Extensions can arbitrarily move in and out of range of each other, the mesh will always be maintained automatically.

The configuration is very easy. You just have to put the extensions into Mesh Mode and configure a group prefix/id and a mesh gateway ip/port per mesh.

Please note, the following software versions are necessary for the new mesh features:

  • WIFI Extension 2.0 version 2.1.0,
  • Master Brick version 2.4.2,
  • Brick Daemon version 2.3.0 and
  • Brick Viewer version 2.3.7.

New homepage and server infrastructure

tl;dr: There will be a change of servers on Thursday January 12th 2017 starting at 08:00 Uhr. Please be ready for a downtime of up to 8-10 hours.

After we already wrote about changes in our system of building blocks yesterday, we want to introduce our new homepage today:

From a user perspective the content of the site does not change a lot. The frontpage as well as the explanation sites for new customers have been redesigned and improved. All of the other content stays essentially the same.

Surprisingly ~30% of our visitors come to our site via a smart phone or tablet. This is especially surprising since our products are normally used/programmed with a normal desktop PC. To deal with this fact the new homepage, particularity the shop and documentation, will now have a better usability for mobile devices.

From a technical perspective the new site has big changes. We will use a completely new CMS. This will make creation of new content and blog entries considerably easier for us. Furthermore, the domain “” will relocate to a new server. We will then have a physical separation between, mailserver, and If the visitor numbers increase further in the future, it will be easy to move parts of the new site or single databases to new servers.

To do the server and software switch we have to migrate our complete user database (this took about 4 hours in tests). Additionally we will have to change the DNS entry for to a new IP. Until this is known by all nameservers it will take some more time (~6 hours). Our mailserver will keep the old IP and it should be reachable for the whole time.

The server switch will be on Thursday January 12th 2017 starting at 08:00 Uhr. Please be ready for a downtime of up to 8-10 hours.

Outlook for 2017

After yesterdays review of last year we want to look into the future today.

We are happy to be able to announce a new generation of Bricklets, that we want to introduce today.

Currently each Bricklet has parts like sensors, analog-digital converters, LEDs, interface extensions etc. These parts are directly connected to the processor on the Bricks (through the Bricklet cable). This concept has the advantage, that simple Bricklets only need few parts. Every Bricklet has an EEPROM that saves the code for the Brick. This code is loaded by the Brick, written into its own flash and executed periodically. Because of this a Brick does not have to know each individual Bricklet. This allows the big variety of the different building blocks.

A disadvantage is, that the processor of the Brick has to run all of the Bricklet code as well as the code for the Brick functionality itself. Applications like a frequency counter or similar, that need to react permanently to a signal, are hard to realize. Another disadvantage is that the code of the Bricklets is only compatible to the SAM3 and SAM4 processors of Atmel. In the past we were confident that these processors are available for a long time. Since Microchip bought Atmel this is unfortunately not guaranteed anymore.

We will solve this problems with a new generation of Bricklets. The new Bricklets will have their own co-processors that only have two tasks:

  • To implement the Bricklet functionality,

  • and to communicate with the Brick.

The connected Brick has less load, since it only has to talk to the Bricklets and it can flexibly decide how to do so. The first new Bricklets of this generation will be the successor of the GPS Bricklet and a RS485 Bricklet:

The current plan envisages that piece by piece all Bricklets are converted to a the new version with co-processor in a three year time frame.

After the conversion there is no dependence to a specific processor type anymore. All of the communication is done through well defined protocols. This would also allow something like a Raspberry PI shield that enables a RPI to directly talk to Bricklets.

We will talk more about the technical details of the co-processors and the utilized protocol. With this blog entry we would like to get some feedback in regards to a specific detail: The Bricklet connector.

Currently we use a 10 pole connector/socket from the JST SH series. The socket is functional and fits perfectly on the 4x4cm Bricks with regards to size. It has the disadvantage that the connector does not latch. If the connector is plugged in skewed, it is possible that the pins in the socket get bent (this can result in short circuits or similar).

For the communication with the new co-processor Bricklets we theoretically only need 7 wires. This would theoretically allow us to change the connector to one the is more comfortable to use. We are mostly looking at the GH series of connectors from JST:

This connector is latched. Additionally the pins in the socket are affixed to the socket casing dual-sided at the top and at the bottom. This allows for a better connection during vibrations (there are always two contact points available) und it is impossible to accidentally bend pins. The haptic of the connector is a big improvement. It even has a satisfactory “click-sound” if you plug it in.

The question now is: Would you rather have us switch to this new connector, or do you think it is better we keep the some connector with the complete system?

Scenario 1

  • The connectors remain the same for all of the building blocks.

  • The normal 10-pole to 10-pole Bricklet cable is compatible to the new and old generation of Bricklets.

Scenario 2

  • The connector on the new co-processor Bricklets is a 7-pole JST GH.

  • There are two Bricklet cable variants: 10-pole to 10-pole for the old Bricklets and 10-pole to 7-pole for the new generation of Bricklets.

  • After all Bricklets are converted (perhaps in 3 years) we will be able to change the connectors of the Bricks to the new 7-pol variant.

  • After that we only need 7-pole to 7-pole cables for the whole system.

In both scenarios the old Bricklets and the Bricklets of the new generation are completely compatible to each other and the old Bricks.

Which of the scenarios do you prefer? Please tell us your opinion in the Forum. Thanks!

Looking back at 2016

The year 2016 has concluded and we want to thank you for the exciting and successful year!

We released eight new Bricklets in 2016:

Additionally we now have the new WIFI Extension 2.0 as well as the Ethernet Extensions with and wihtout PoE.

We visited three trade shows:

Often customers come to us with a prototype made out of Bricks and Bricklets. They want to use the prototype as a starting point for a product that will be produced in bigger quantities. Internally we call these kinds of projects “industry projects”.

In 2016 we invested a large portion of our time in industry projects. Among others, we developed a system of sensors with controlling unit for a big German energy utility company. The system is used in electric car charging stations and intelligent street lamps.

For 2017 we set ourselves the target to work more on our system of building blocks. For that we recruited two additional full time employees at the end of 2016!

Tomorrow we will release a detailed list of future changes that we plan for the building blocks in the blog. We already look forward to your feedback regarding the changes.