Blog

Instagram

We now have an instagram account: https://www.instagram.com/tinkerforge.

We get asked to give out more information about new Bricks/Bricklets, new production runs and similar all the time. With instagram we hope to be able to do lots of small and fast updates and also show some more details of our development process with photos of development/testing setups and similar.

RED Brick Image 1.11: Big performance boost

The RED Brick image version 1.11 is now available: http://download.tinkerforge.com/red_images/full/

In the RED Brick image release 1.10 we had many significant changes compared to 1.9. Among other things we updated the linux kernel from 3.4 to 4.13. This was a lot of work for us. We had to port drivers, adapt our SPI communication code etc. We gained some necessary security updates (for example the KRACK WPA fix) and lots of driver support for modern hardware (for example Bluetooth 5.0). Especially because of the security issues with the older Linux kernel, the update was without any alternative from our perspective.

Unfortunately we had to accept a regression in performance. This regression came mainly from changes in the Linux kernel that make multi-core processors more efficient (for example busy waiting for IO in interrupts). While this increases performance in multi-core systems, we saw a decrease in performance on the RED Brick (a single-core system), especially in IO bound loads.

Since we are still selling lots of RED Bricks and the feedback is always very positive, we decided to go down the rabbit whole of increasing the performance for the next image version again.

Among other things we

To make these changes and test them properly we had to invest about two months of work. It took us a lot of trial and error to find the actual performance bottlenecks.

We tested with three different benchmarks:

Benchmark 1: CPU Bound

For the CPU bound performance tests we used sysbench with the parameters "--test=cpu --cpu-max-prime=4096 run".

The governor (if applicable) was set to performance and the connection to the RED Brick was done with SSH through the Ethernet Extension.

The average execution time decreased from version 1.10 to 1.11 is about 5.4ms, which translates to a performance increase of 25%. The performance is now also slightly better then in the 1.9 image with 3.4 kernel.

Benchmark 2: IO Bound

For the IO bound performance tests we used iperf3 with the parameters "-c ishraq-tinkerforge -N -t 120".

The governor (if applicable) was set to performance and the connection to the RED Brick was done with SSH through the Ethernet Extension.

We tested with and without stack. In the tests with stack we used a Master Brick with connceted Thermal Imaging Bricklet. We used the Thermal Imaging Bricklet since it can easily generate enough data to saturate the stack communication.

The graph speaks for itself here: We managed to achieve a very significant performance incerase of 220% compared to 1.10 and 23% compared to 1.9!

Benchmark 3: Stack Communication

For the pure stack communication test we used a Python script on the RED Brick that gatheres thermal data via getter/callback, does no computation with it (throws the data away) and calculates the frames per second.

As you can see we were able to increase the performance to 1.10 in this test, but still have a small regression compared to 1.9. However, during this test the CPU on 1.9 is run at the limit, while we have time for computations left in 1.11. You can see this in effect in the IO bound test, which adds a bit more CPU load, since it has to transfer the data to the PC.

So overall, after a lot of trial and error, we decided that this trade-off (slightly decreased stack communication throughput but significantly more CPU time available for computation) is the way to go. We are convinced that in real-world applications the performance in 1.11 is increased significantly compared to 1.10 and still increased moderately compared to 1.9.

New Bricklets February 2018 part 2: Outdoor Weather Bricklet and more

In the last blog entry we introduced the new Remote Switch Bricklet 2.0, Motion Detector Bricklet 2.0, Analog In Bricklet 3.0 and NFC Bricklet.

In todays part we want to present the Outdoor Weather, Temperature IR Bricklet 2.0, Rotary Encoder Bricklet 2.0 and the Solid State Bricklet 2.0.

As mentioned in the previous blog entry, all of the new Bricklets have a 7 pole Bricklet connector.

Outdoor Weather Bricklet

In the past we discovered that it is pretty hard to make a water proof enclosure that can be used for environment measurements with Bricks and Bricklets. To circumvent this problem we now offer the Outdoor Weather Bricklet. The Bricklet serves as a receiver for the Outdoor Weather Station WS-6147 and the Temperature/Humidity Sensor TH-6148.

With a 433MHz receiver the Bricklet is able to receive measurements from up to 255 outdoor weather stations as well as up to 255 sensors. Every sensor gets a unique ID at the first startup that can be used to match measurements to specific sensors/stations.

The Outdoor Weather Station WS-6147 is easy to build up and it measures temperature, wind speed, wind direction, rain as well as humidity. The measurments are transferred wirelesly with a frequency of 45 seconds. Additionally we add the Temperature/Humidity Sensor TH-6148 to our product line. The sensor measures temperature in °C as well as humidity in %RH.

The Outdoor Weather Brickelt in combination with the Outdoor Weather Station or the Temperature/Humidity Sensor is the perfect solution to add outdoor weather data to  the Starter Kit: Weather Station.


Temperature IR, Solid State Relay und Rotary Encoder Bricklet 2.0

The Temperature IR Bricklet, Solid State Relay Bricklet and Rotary Encoder Bricklet got an update to hardware version 2.0. All of the three Bricklets have a user configurable status LED as well as the new 7 pole connector. The Temperature IR Bricklet 2.0 and the Rotary Encoder Bricklet 2.0 additionally got the new and improved callback API. With the utilization of a co-processor we were able to increase the sampling rate of the Rotary Encoder. It is now practically impossible to ever loose any steps.

The technical specification of the three Bricklets stays essentially the same. The Temperature IR Bricklet 2.0 contactlessly measures temperature in the range of -70°C up to 380°C, the Solid State Relay Bricklet 2.0 can switch solid state relays with up to 380V/25A AC or 50V/80A DC and the Rotary Encoder Bricklet 2.0 is rotatable by 360° and it has 24 single steps in sum.

Outdoor Weather Station, new NFC Bricklet and product updates

It is time again to introduce new Bricklets! Since yesterday we got eight new Bricklets in our shop. Some of them are improved versions of existing Bricklets, but we also released some completely new developed Bricklets.

The following Bricklets are new in our product range:

To be able to introduce all eight new Bricklets in detail we will start with four in this blog entry and introduce the next four in a second part. In the first part we will introduce Remote Switch 2.0, Motion Detector 2.0, Analog In 3.0 and NFC Bricklet. The second part will deal with Temperature IR 2.0, Rotary Encoder 2.0, Solid State Relay 2.0 and the new Outdoor Weather Bricklet.

As we already wrote, the new Bricklets will replace the old counterparts. All of the new Bricklets have a co-processor and thus a 7-pole connector, as we already announced in the Outlook for 2017.

Since we have some of the predecessors still in stock, we will sell them off with a discount of 30%. Of course only as long the the stocks last!

Remote Switch Bricklet 2.0

The Remote Switch Bricklet 2.0 will replace the old Remote Switch Bricklet. The new Bricklet has all of the features that the old Bricklet has. You can still use it for home automation and it come with a 433MHz radio module including a corresponding SMA antenna. You can use the Bricklet together with the standard (PT2262 or HX2262) remote mains switches, as the predecessor. Additionally the new Remote Switch Bricklet 2.0 can now also receive data from a remote!

Motion Detector Bricklet 2.0

The Motion Detector Bricklet will be replaced by the Motion Detector Bricklet 2.0. The new Bricklet has many improvements. We don't use a ready-made module anymore, instead we developed our own PIR solution. The Bricklet is more compact and it has a detection angle of 120°, compared to 100° of the old Bricklet. The PIR sensitivity of the new bricklet can be controlled via API. So you can change the detection range depending on your application. A special gimmick of the Bricklet is the blue backlight. The backlight is dimmable and can be controlled via the API (for example during a motion detection). Since the backlight consists of three individually dimmable LEDs, you can also use it to show small animations!

Backlight in action:

Analog In Bricklet 3.0

The Analog In Bricklet 3.0 replaces the Analog In Bricklet 2.0. The specification is comparable to the predecessor, but it has the advantage that the analogue signal is measured directly on the Bricklet, it is not transferred through the Bricklet cable anymore. The voltage measurement is done on the Bricklet by the processor and the measurement is transferred digitally. Additionally the API more averaging possibilities.

NFC Bricklet

The successor of the NFC/RFID Bricklet has the name NFC Bricklet. For the old Bricklet we put "RFID" in the name, since technically the 13.56MHz NFC frequency is part of RFID. Unfortunately some customers falsely believed that the Bricklet is also compatible to the 125-134kHz RFID frequency. To make sure that there can't be any confusion we just removed "RFID" from the name. Because of that the Bricklet does not need the "2.0" at the end.

Like the old Bricklet, the new Bricklet can read and write NFC Forum Type 1 and 2 as well as Mifare Classic tags. Additionally it supports NFC Forum Type 3 and 4 including the necessary encryption. It also supports NFC P2P as well as card emulation. The API now has support for reading and writing NDEF directly. In sum the new features are a huge improvement and it is easier to use too.

While i am writing this blog entry we have already sold 41 of the new NFC Bricklets (they are available in the shop since yesterday) although there has not yet been any announcement. So this Bricklet obviously attracts a large interest! We are very sorry for the long waiting time. The transition from the old NFC/RFID Bricklet to the new Bricklet unfortunatly took way longer then we expected.

Brick Firmware Update

We just released new Brick firmwares that fix three important bugs:

  • Fix RS485 timing bug. This is a very old bug that we were not able to figure out for many years. Bricklets that use I2C (for example Temperature Bricklet) would somtimes give false values every few 1000 messages if RS485 was used. This was caused by a mix of I2C/RS485 timing constraints. We now use DMA for I2C Messages to fix this.
  • The handling of the initial enumeration (the enumerate callback with enumeration type = CONNECTED) has been completely reworked. Double enumerations don't happen anymore and the enumeration also works if a USB cable is connected to an already powered stack. This also fixes some other strange behavior. For example: In a RS485 network, if you restarted the RS485 master stack you had to restart the slave stacks as well, otherwise they wouldn't enumerate again. With the update the RS485 slaves will automatically re-enumerate if the RS485 master re-enumerates itself.
  • We will now never do a real hard reset if triggered by USB. USB has reset/suspend/resume messages that triggered a hardware reset (internal messages). There are several possibilities, when a PC can trigger these messages. For example on startup or when the USB hardware detects EMI. So far the Brick firmware simply resets the hardware. With the new firmwares the USB state machine will be properly resetted (as requested by the PC), but everything else will keep on running. So the Bricks/Bricklets will not loose state and for example a stepper motor will keep running until the request is fully processed. From the PC perspective the Brick will disconnect and immediately connect again. A new initial enumeration will be send. If you have problems with unwanted resets (for example if a relay switches an inductive load) this will probably fix this issue! The PC will still reset the USB, but from the user perspective everything will keep running and working, no lost messages or similar.

Especially the last one (relay switching resulting in stack resets) is a problem that we have heard sometimes, but we where never able to reproduce that. A few weeks ago we finally were able to create a setup here where we could reliably reproduce this problem. After many hours of debugging it turned out that the problem is that the PC registeres an EMI event through the USB cable and as a result tells the Brick to reset itself (on Linux this happens if you get the dmesg message "disabled by hub (EMI?), re-enabling ..."). This reset will now not result in a real hardware reset anymore and everything will just keep running even if your USB hub does a reset.

To fix this we had to restructure a lot of code, we used this restructering to improve the hotplug/enumeration functionality a lot.

You can update your Bricks through Brick Viewer.