Blog

In the last blog entry we already introduced some of our new Bricklets. These new Bricklets were new version replacements for pre-existing Bricklets. Today we want to introduce four brand-new Bricklets: The Industrial Dual Relay Bricklet, Sound Pressure Level Bricklet, Industrial Counter Bricklet as well as the Particulate Matter Bricklet are now available in our shop and documentation.

Industrial Dual Relay Bricklet: With the Industrial Dual Relay Bricklet our product line is extended by a new Industrial Bricklet. It replaces the old Dual Relay Bricklet. The Industrial Dual Relay Bricklet has two relays with three terminals each (single-pole double-throw). It can switch loads up 240VAC/10A as well as 30VDC/7A. In comparission to the predecessor the Bricklet now has the pluggable terminal block that all of the Industrial Bricklets have. Since the Bricklet is often used together with other Industrial Bricklets, this gives better compatibility. A Dual Relay Bricklet in the "industrial form factor" was one of the most common feature requests that we got!

Sound Pressure Level Bricklet: The Sound Intensity Bricklet is replaced by the Sound Pressure Level Bricklet. The Sound Pressure Level Bricklet can measure sound pressure level in dB(A/B/C/D/Z) and ITU-R 468. It iuses a frequency range of 40Hz to 40960Hz and it can measure sound level from 30dB to 120dB. Additionally the Sound Pressure Level Bricklet can measure the spectrum. The specification is comparable to a 200€ sound level meter.

Particulate Matter Bricklet: Many of our customers tried to measure particulates with the Dust Detector Bricklet, but it was not meant to be used for this application. With the Particulate Matter Bricklet we now have a Bricklet that can measure actual particulate matter concentration in the categories PM1.0, PM2.0 and PM10 as well as the number of particles in 100ml of air with the sizes between 0.3µm up to 10µm.

Industrial Counter Bricklet: The Industrial Counter Bricklet is a frequency counter with 4 galvanically isolated channels. With the integrated edge counter you can measure duty cycle, period and frequencies from 0.03Hz up to 4MHz per channel. Since the direction of the counter is configurable and the Bricklet has a time resolution of up to 10.4ns, it can be used to read any sensors that have any kind of edge count or frequency output.

We got a big delivery of new Bricklets! Since we got 15 different new Bricklets at once, we will split the blog entry in two parts.

Some of the new Bricklets got an upgrade with the addition of "2.0" to the name, they will replace the predecessor. Additionally we also have four completely new Bricklets, they will increase the possible applications of the building block system. We will introduce the new Bricklets in the next blog entry.

All of the new Bricklets have the new 7 pole connector. You can find more information about the new connector here. The folloging Bricklets now have a co-processor instead of the EEPROM and are in our shop as of now:

• Load Cell Bricklet 2.0
• PTC Bricklet 2.0
• Voltage/Current Bricklet 2.0
• Real-Time Clock Bricklet 2.0
• Thermocouple Bricklet 2.0

The following Bricklets got the 2.0-upgrade with additional useful improvements:

CAN Bricklet 2.0: The CAN Bricklet 2.0 now has a co-processor and thus more RAM. Because of that the Bricklet is more powerful and it can handle a high volume of data in longer bursts then the predecessor.

RS232 Bricklet 2.0: The RS232 Bricklet 2.0 also has more RAM compared to the predecessor. Because of the bigger buffer the handling of data can be significantly simplified. The Bricklet has the new streaming API, it works exactl the same way as it does with the RS485 Bricklet. The new streaming API was explained in detail here.

LED Strip Bricklet 2.0: Beside many small changes the new LED Strip Bricklet 2.0 has two significant improvments. It is now possible to control up to 2048 RGB or 1536 RGBW LEDs. The Bricklet can therefore control 6x as many LEDs as the old LED Strip Bricklet. Previously we had the constraint that with full usage of a LED Strip Bricklet it was not possible to use the other ports of the Brick. With the new LED Strip Bricklet 2.0 this is not the case anymore. You can control of the available LEDs and at the same time use the other free Bricklet ports without any negative effects.

Industrial Digital In 4 Bricklet 2.0, IO-4 Bricklet 2.0 und Industrial Quad Relay Bricklet 2.0: The new Bricklets with digital in-/outputs got an improved API. The API now uses bool-arrays instead of bit masks. This was sugested to us astoundingly frequent. Particularly users that use high-level languages that normally don't use bit masks (LabVIEW, Matlab, Visual Basic .NET) had often problems with them. On the protocol level the arrays are still transferred as bit masks, so there is not loss in performance.

Tomorrow we will introduce the Industrial Dual Relay Bricklet, Sound Pressure Level Bricklet, Particulate Matter Bricklet and Industrial Counter Bricklet in detail.

As you have probably already heard, the General Data Protection Regulation (GDPR) will become enforcable on May 25th 2018. The GDPR is EU regulation for better data protection and pivacy of individuals in the EU.

In this blog post we would like to inform you how the GDPR rules are implemented at Tinkerforge:

We took a detailed look at all of the data that we are gathering in the light of GDPR. The only relevant part in our company that we found was our Matomo (formerly Piwik) installation. It did set a cookie that you could opt-out on our privacy notice site. Since this needs to be opt-in with GDPR now we just removed the cookies from our Matomo setup. This does not change a whole lot, since we already did honor the "do-not-track" request that browsers set nowadays, in which case Matomo didn't set a cookie anyway.

Our Matomo installation will now collect anonymized data that can not be correlated to an user account, IP address or similar. The collected data includes

• sites visited,
• visiting time,
• country of origin,
• browser
• and similar.

The data is used to

• find dead links (404),
• find sites that talk about Tinkerforge,
• determine server workload through visitor numbers/load times,
• determine effectiveness of advertising/articles
• and similar.

The data is not

• correlated with shop accounts in any way or form,
• used to track recurring visitors
• or used to make a permanent profile of users.

This complies with the requirements of the GDPR.

Additionally we operate a shop. If you create an account in our shop we save the address information as well as the orders. This data is (obviously) necessary to run an online shop and it is unavoidable that we save the data. If you want your shop user account deleted (according to the "right to be forgotten"), write us an email. We can execute a SQL query that removes all of your data from our shop system. What will stay is an archived printed copy as well as an archived digital copy of the invoice that you received with your order. We are legally required to keep them (Aufbewahrungspflicht). If you want to see what data we have, you can log into your account and go to the "My Account" page. The address book and order information that you can see there represents all of the data we have.

If you don't have a shop account and you put products in your shopping cart, the shop sets a cookie with an ID of the content of the cart. If you (for example) open the shop in a new tab, the shopping cart content will persist. The only thing tied to this ID is the shopping cart content, no personal information can be obtained from that or correlated to it. The documentation may set one additional cookie if you explicitely choose a language that does not match your browser language, so on the next visit you will automatically be redirected to the correct language page. Again, this does not contain any or could be linked to your personal information.

Generally speaking, we are in the business of designing, manufacturing and selling hardware. We only collect personal information that is absolutely necessary. Thus the new GDPR rules do not affect us greatly.

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.

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

• changed the scheduling from dynamic to periodic ticks and disabled control groups,
• added support for rescheduling processes during IOCTL calls,
• Improved the SPI interrupt handling and
• Implemented proper DMA support for the spidev driver.

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.