Recently I bought an NVidia Jetson Nano board and a fan for a side project. It is about machine learning with training and inference. Therefore, the CPU and GPU will work a lot and get hot! I searched the web for the right fan and I found the Noctua NF-A4x20 PWM (Amazon*) is recommended. A perfect product: low noise, rubber decoupling, good performance.

As it was delivered, I installed it immediately – of course. The question was: which direction?

So I did some tests in both fan directions. Running a high CPU intense compilation, the performance was better in the downward direction.

Jetson Nano fan – comparison CPU test.

Upward / Downward according to the arrow on the side of the Noctua NF-A4x20 PWM fan.

It is just a few degrees of difference. But it will count if you do training on the Jetson Nano. I did a couple of TensorFlow training jobs which took 12-19 hours. CPU & GPU got very hot, and the fan has cooled the NVidia Jetson Nano like a charm. By the way, I used the 4GB version, but I think the cooling performance and temperatures are the same as the 2GB version.

I also tried the non-PWM version of the fan with the same results. But since the fan is always on without PWM, it is fairly noisy. With the PWM version, the fan usually runs with just 33% of the maximum power.

So I hope this helps for your Noctua NF-A4x20 PWM fan installation: recommended direction is downward according to the arrow printed on the side of the fan.

The post NVidia Jetson Nano fan direction appeared first on Patrick Steinert.

In IoT Use Cases werden oft Daten verarbeitet. Ab einer gewissen Menge an Daten gibt es einen nicht mehr zu erfüllenden Zielkonflikt zwischen Real-Time-Anforderungen und der Genauigkeit. Dieser lässt sich durch die Lambda-Architektur auflösen und in zwei Layern getrennt erfüllen. In SaaS Plattformen, wie der CumulocityIoT, stehen dazu oft Mittel wie Complex Event Processing (CEP) Engines und REST-Schnittstellen zur Verfügung. Im Falle der CumulocityIoT Plattform läuft die Stream Verarbeitung über die CEP Engine Apama. Es gibt jedoch ein paar Dinge für eine stabile und effektive Verarbeitung zu beachten. Daher hier meine 6 Tipps zu IoT Analytics.

1. Daten komplett in-memory anstatt über Datenbanken und Schnittstellen

Bei der Verarbeitung von Daten sollten Zugriffe über HTTP Schnittstellen oder die Datenbank reduziert werden. Diese Zugriffe sind relativ zeitintensiv und blockieren die Verarbeitung. Solche Calls sollten nur bei der Initialisierung oder gelegentlich genutzt werden. Die Datenhaltung sollte besser komplett in-memory erfolgen.

2. Zu hoher Memeory Verbrauch

Es gibt einige Mechanismen, die den Speicherverbrauch nach oben treiben. Teilweise sogar exponentiell. Hier die Top 3:

1. lange onWait Zeiten
2. spawn-Methode, zum Klonen des Kontextes.
3. Modularisierung und Verkettung von Regeln

3. Mind the Gap – Vorbereitung von Up- und Downtimes

Durch Updates, Deployments oder ungeplante Downtimes entstehen Lücken in der Verarbeitung. Diese müssen durch andere Tools im Batch Layer aufgefangen werden. Zudem kann es sein, dass durch neue Parameter oder Fehler eine Neuberechnung notwendig wird. Auch dazu sollte man Tools auf dem Batch Layer, wie Microservices, nutzen.

4. Batch Layer – Es benötigt eine Queue und Statusinformationen

Batch Layer Jobs laufen Stunden und in der Regel parallel. Durch die hohe Last wird das System vermutlich überfordert. Dadurch entstehen Lücken bzw. unvollständige Daten. Wenn dann auch noch Bugs dazu kommen, wird das Chaos perfekt. Es sollte also eine gute Job-Steuerung verwendet werden, um Queues zu verwalten und Status zu erhalten.

5. Tracebility – Wer hat hier eigentlich wann was berechnet?

Hat man nun mehrere Berechnungsalgorithmen in unterschiedlichen Versionen über die Daten geschickt, ist in Zweifelsfall nicht mehr nachzuvollziehen, wodurch die Daten berechnet wurden. Daher sollten auch Metadaten zu den berechneten Daten gespeichert werden. Das erhöht zwar den Gesamtstorage, ist aber im Endeffekt effizienter.

6. Datenformate ändern

Prinzipiell ist es gut, schnell vom Prototypen in die Realität zu kommen. In Hinsicht auf die Datenformate ist es jedoch zu empfehlen, die Skalierungsstufen mit Bedacht zu wählen. Denn die Datenformate, sofern sie nur per REST o.ä. zugänglich sind, sind nur sehr Aufwändig zu ändern. Das resultiert dann entweder in dutzenden Formaten oder in langwierigen Migrationen. Daher sollte, sobald die Skalierung über eine Erprobungsphase hinaus stattfindet, das Datenmodell gut abgehangen sein.

The post 6 Tipps zu IoT Analytics mit der CumulocityIoT Plattform appeared first on Patrick Steinert.

Cybersecurity ist ein Thema, das alle angeht. Schließlich bedienen wir jeden Tag elektronische Geräte, die mit dem Internet verbunden sind. Das Risiko in die Fänge von Cyberkriminellen zu geraten ist real. Allerdings wird Cybersecurity sehr schnell technisch und kompliziert. Normalerweise sind da Nerds unter sich (Stichwort CCC). Wie kann man ein solches Thema der breiten Öffentlichkeit näher bringen? Das CASSIS und der Cybersecurity Cluster Bonn haben dazu ein Format gefunden: den Cybersecurity Slam!

So fand am vergangenen Donnerstagabend der 2. Cybersecurity Slam im Fritz Café der Uni Bonn statt. In einer Form des Science-Slam haben fünf Slammer eine 10-Minütigen Performance auf die Bühne gebracht. In einer unterhaltsamen Form sollte das jeweilige Thema aus dem Bereich der Cybersecurity dem Publikum erklärt werden. Ich hatte das Vergnügen einer dieser Slammer zu sein. Dazu habe mein Know-How aus dem Internet of Things in den Slam: “Sicherheit im Internet der Dinge oder: wie hacke ich meinen Nachbarn” verwurstet.

Losglück

Zu Beginn der Veranstaltung wird die Reihenfolge der Slams ausgelost. Ich hatte mich daher schon vorbereitet als erster zu performen. So kam es dann auch, dass mein Name als erster genannt wurde. Also schnell Mikro-Verkabelung und ab gehts. Im Vorfeld war ich schon etwas nervös und hatte wiederholt mein Intro geprobt. Das ging mir dann recht gut über die Lippen. Dann aber der Schock! Der Präsenter für die Folien funktioniert nicht . Panischer Blick in Richtung Regie. Hektischer Tumult dort, keine akute Hilfe. Kurze Info ans Publikum und weiter gehts. Improvisierte Handzeichen helfen für den Wechsel der Folien und den Start der interaktiven Inhalte, die ich so intensiv mit Timings vorbereitet hatte. Als das Publikum dann wie erhofft auf die witzigen Elemente reagiert, sehe ich: Es läuft. Im Nachhinein fand ich es eigentlich gut, erster zu sein. Durch das Warm-up des Moderators Taner Ekici war das Publikum noch in bester Laune. Mit den letzten Worten meines Slams war ich dann richtig glücklich. Ich war in den 10 Minuten fertig und hatte alles gut rübergebracht. Der ein oder andere Zuschauer wird nun mit mehr Bedacht an den Betrieb seiner Smart Home und IoT Geräte gehen.

Cybersecurity für Alle

Mit den weiteren Slams ging es dann weiter:

• Pascua Theus mit “Bitte entschuldigt!” zum Thema Passwörter
• Marian Corbe mit “Kritische Infrastrukturen: der Motor unserer Gesellschaft?!”
• Daniel Jedecke mit “Auf der Mauer auf der Lauer sitzt ne kleine Attacke” zum Thema Social Engineering
• Holger Reichert mit “Wie ihr den Cyberraum zu euren Gunsten krümmt”

Zum Abschuss musste dann durch das Publikum der Sieger ermittelt werden. Pascua Theus holte sich verdient den Sieg und kann sich über die 500 € Prämie freuen.

Aus meiner Sicht funktioniert der Science-Slam sehr gut zur Vermittlung technisch komplexer Themen. Das anwesende Publikum war bunt gemischt. Die Gestaltung der Slams haben die Zuschauer auf jedem Niveau abgeholt und mal mit mehr oder weniger Humor zu einer Conclusio geleitet. So konnte jeder etwas zum Thema Cybersecurity mitnehmen.

Vielen Dank an Philipp Ackermann vom CASSIS und Christian Schmickler vom CSC Bonn für die Idee und Organisation. Ich freue mich schon auf die nächste Veranstaltung dieser Art.

The post Cybersecurity Slam 2020 – Unterhaltung durch Nerds? appeared first on Patrick Steinert.

Die Herausforderungen im Industrial IoT:

1. Viel Technik
2. Vielfältigkeit der Schnittstellen und Ökosysteme
3. Datenqualität
4. Datenverarbeitung
5. Plattform / Cloud – Ökosysteme

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Accept YouTube Content

The post Herausforderungen im Industrial IoT appeared first on Patrick Steinert.

Want to learn about the Internet of Things and how to work with a sensor? I did too! I’ve been experimenting with the “Internet of Things” (IoT) since 2014 and have learned about the challenges with my sensor project: the AirQuality Lab. In the beginning, I just wanted to create something and work with the components. The scope of my side project was to read values from a sensor, transfer it to a thing-backend and then learning from the data. This post starts with the basic setup of the Thing and the following posts will cover further points.

After finishing a project in late 2014, I played around to learn a bit more about the Internet of Things (IoT) stuff for my next project. So, it was (and is) proposed, that “everything is connected in 2020” and I had to think about a product, product strategy and technical implementation in this area. Our thoughts about a domain model for IoT at this time was, to reduce everything to a source and a drain. Well, as hardware is cheap (but this is not all) I bought a Raspberry PI, a bunch of sensors and a small LCD display. Inspired by the CubeSensors, I wanted to measure air quality with the sensors and work with the derived data. This should help to understand how things process data, how to transfer it, how to analyze and derive information from it. I started the AirQuality Lab.

The sensor for the AirQuality Lab

It all started with the decision of whether to use Arduino or a RaspberryPi. A pro for the RaspberryPi was full Linux, the ability to use every coding language and easy and cheap Wi-Fi. I selected sensors on breakout boards with available source code. I didn’t want to do the lower level myself, so the latest was important. I’m not used to shifting bits around, but it is somewhat familiar, while pitching gains and other stuff is from the last century. I chose I²C sensors when available, to have the values digitally and to reuse the limited pins on the Raspberry Pi. These are the sensors:

• TSL45314
• BMP180 (updated to BMP280)
• SHT15
• Seed Studio Air Quality Sensor 1.0 / 1.3 (via Adafruit ADS 1015)
• I also added an LCD display in the first version for debugging purposes.

The AirQuality Sensor is not digital. An Analog-Digital-Converter was necessary to convert the signal into digital values. I chose the Adafruit ADS 1015 for this task. The SHT15 is also not fully compliant with I²C; it is addressable via an equivalent protocol.

I connected them as shown on the Fritzing wire diagram.

The code for the AirQuality Lab

Step by step I soldered the pins to the sensors and connected everything to the device. If you build up an electronic circuit, the smoke test is a particularly thrilling step and awesome if it works. To see it working on the RaspberryPi, it is easy to observe the sensors working. After setting up the I2C kernel module and installing the i2c Raspian packages, you can execute:

$> sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- 29 -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77

Getting a response at the desired address of the sensor, found in the spec, is a great test to see if the wiring is good.

Next step: read out the sensor values. For some sensors I found Java code, but for others there were only just Python and Arduino C code. To test sensor functionality and correct wiring, it is good to have Python code, because it allows quick testing without compiling something. However, to connect to the Cloud of Things, I wanted the code in Java, so I had to rewrite it. Sometimes it was a nerve-wracking process for me, because there are some differences in bit shifting, data types and pointer arithmetic. In the end, I had all the code to read out the sensor values.

I have put my code for the sensors on Github (rpi-java-sensor-lib), so if you like, you can try it yourself. This is a good time to say thank you to the people who have written the code I used to get it working. If you’d like to try it yourself, use these commands. These steps include the complete build steps, so you need to have some packages installed. You can also package the jar on another computer, then just move the jar file to the Raspberry Pi and run it via the last command.

$> sudo git clone https://github.com/marquies/rpi-java-sensor-lib.git
$> cd rpi-java-sensor-lib
$> mvn package
$> sudo java -cp examples/target/examples-1.0-SNAPSHOT-jar-with-dependencies.jar de.patricksteinert.rpisensorlib.examples.AdafruitBMP280Example
Chip ID : 0x58
Pressure : 999.26 hPa
Temperature : 24.33 °C
Temperature : 75.79 °F
Altitude : 165.04 m

For the first prototype, I put all of the electronic components into a simple case with the prototyping board. I tentatively pulled the sensors to the outside of the case, to allow them to access to the room air. It looks like this:

Finally, I wanted to transfer the data to a thing-backend. I worked on the Cloud of Things, so this was my natural choice. For transferring the data I used a special client, which will be part of another post. The AirQuality Lab has now been running for two years, transferring the sensors’ data every thirty seconds, every minute, hour, day and year. I have a dataset of 630k+ observations to work on with data science tools, which will also be discussed in a future post.

Conclusion

I have learned many things during this project, especially the following:

• I know how to move bits over the wire, read registers and all the basic stuff. It helped me to understand how machines communicate.
• I learned how much work it is to output simple text on an LCD display.
• I understood how to structure payload to transfer sensor values in different ways.
• I have got a sense of how storing and reading “mass” data should be.

If you like this project and want to read further articles, make sure that you have subscribed to the RSS feed of this site or follow me on Twitter. I’d also appreciate feedback in the comments below or on Twitter.

The post The AirQuality Lab: How To Work With IoT Sensors appeared first on Patrick Steinert.

Slogan of the month: The intellectual capital of your business has two legs and walks home every day.

What have I done:

• Had nice workshops at Fraunhofer Institute for Big Data Analytics
• Successfully finished hard work on a internal data center migration with the Cloud of Things team
• Planted the seeds for the hosting quality improvements
• Worked on the performance of my blog. Improved site performance by 40%. PHP upgrade to v7 was the most gain. Performance could be better but for my kind of hosting it’s very good.
• Designed strategy, corner milestones and goals for 2017
• Prepared my talk for Bonn Agile Meetup January: IoT und Bastelprojekte (more on this later in this blog)
• Enjoyed Christmas and New Year’s Eve vacation

Read:

• Your Minimum Viable Product can be more ‘minimum’ than you think
• A simple assessment how agile your team is
• Derek Sievers quits answering questions, but was gorgeous enough to leave with an FAQ. I good reference for various topics about self-development.
• I just read Tim Ferris notes, not listening to his podcasts. One of his recent issue is Testing The “Impossible”: 17 Questions That Changed My Life.
• Benjamin Cabé wrote a review of Eclipse IoT in 2016
• “Innovation” is dead. Long live “innovation” by Alexander Osterwalder.
• Wonder how to improve Battery Life on low-power devices?
• Introduction of Bluetooth 5
• Something about GIT: Comparison of different GIT Workflows

Watched:

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Accept YouTube Content

The post Retrospective December 2016 appeared first on Patrick Steinert.

Nonetheless is the Internet of Things not as ready as the industry states. You can prototype fast, but if you would like to adapt the Internet of Things for your business. If you compare the Gartner Hype Cycle for Emerging Technologies from 2015 and 2016 you may see, that the Internet of Things was dropped. While not sure if intentionally or not, it can’t be found on the plateau of productivity. I would place it in the trough of disillusion. For example, here are some topics, the industry is struggling with.

Product liability (failure, security inside and outside)

A running prototype is good to validate your idea or product improvement. But there is a long way to go until it can be shipped. Especially if the device is integrated into other systems (on the Things side), it must be tested for generating failures in the system. Imagine a device gateway integrated into a vehicle, generating a fault on the bus system which disables the human security systems. Furthermore, especially after the recent hacker attacks, the devices need to be secured for manipulation in all directions, via internet platform into device/system, via device into system and via device into internet platform. This includes physical manipulation as well as networking. But there is help, even for your industry.

Cost of development for world-wide rollout ready solutions

Running a single prototype on a developer board is great, again. But there is a long way to go until it can be shipped globally. If devices are globally distributed, they have to have routines for reset and reconnect, work in situation where network is flaky, slow or even not available sometimes. You need to be able to update devices fast or recover via remote in case of software flaws or security issues. The last thing you want to do is lose control of the devices, let your customers do the work or do it with your workforce.

Business readiness for operating IoT products

Having a nice technical solution is great, again. But does it fit the business case? Are customers willing to pay an additional price or fee? Is the business ready to transform to a pay-as-you-use model, a data-driven business or a B2B2C customer relationship?

Price for connectivity with large number of cheap devices

Even if prototyping hardware is cheap, connectivity is still not. At least mobile connectivity. Ethernet and Wifi are cheaper, but you have to struggle with NAT routing, firewalls and network policies. Mobile network is Plug&Play, with a good provider even worldwide. But a GSM module is at least around 20$ and additional a data plan is necessary. If the Internet of Things product is a low cost device, the connectivity cost don’t fit the business case.

Connecting to legacy machines

In the manufacturing industry and maybe in further industries as well, products are used over 5-10 years. Innovation cycles are longer than elsewhere in the tech industry. There is a huge area of legacy systems to be retro-fitted. It is possible to connect to these systems if there is an interface to use (e.g. RS232/485, Modbus, CAN-bus). Anyway, these systems are not designed to be connected to the internet. Developers need to do expensive try-error-loops and workarounds.

Conclusion

As you can see, there are hurdles to take until an Internet of Things product is ready to launch. This is why I think, despite the statement of cheap hardware, is in the plateau of disillusion. The good news are, there are partners with broad experience in each of the examples. You should select them (carefully), but let help you to solve your problems.

The post IoT hardware is cheap, but other things are difficult appeared first on Patrick Steinert.

What have I done:

• Worked on the Cloud of Things Java Rest SDK
• Been happy to be ranked as a leader in the magic quadrant in Gartner Report of “Managed M2M Services“
• Shook my head about the president election in the USA.
• Proceed in my study of Data Science
• Worked on the strategy & goals for 2017’s Cloud of Things
• Worked on NB-IoT integration

Read:

• Field report of a Docker user: Docker in Production: A History of Failure
• “Because lot of the engineers and researchers in and around “IoT”, me included, are getting quite tired of these sorts of fluff “vision” and “projecting competence” pieces that don’t contribute anything new to the conversation” → Storm the Beaches! Liberate IoT Data!?
• [GER] Eine lesenswerte Kolumne zur Digitalisierung in Deutschland auf t3n.Warum digitale Zerstörung manchmal besser ist als digitale Transformation 
• Want to advance your Maker garage? → Led Tester/Current Limiter

Watched:

• Not the fanciest premium stuff, but hey, whats wrong with being proud about your work:

  Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

  YouTube privacy policy

  If you accept this notice, your choice will be saved and the page will refresh.

  Accept YouTube Content

The post Retrospective November 2016 appeared first on Patrick Steinert.

Favorite slogan: So we are doomed!

What have I done:

• Worked hard on launching new Cloud of Things Features: New Cockpit App is out!
• Wonder how someone can setup a MongoDB Docker Cluster without persistence!?
• Coded on some Cloud of Things API and Client stuff Had a new record on contributing code to Github: Longest streak 7 days
  January 30 – February 5.
• Updating servers for glibc vulnerability.
• Start planning for big CoT team ramp-up. Scale from one to four teams in one month. Big experiment.
• Had a week of vacation. Practiced not to work. Successful.

Read:

• Book: Womit ich nie gerechnet habe by Götz W. Werner
• What you own vs. What you care about – Why your team should care!
• Product Strategy Means Saying No – Inside Intercom 
• The Art of Saying NO
• HowTo annoy users: The Price Of Not Using UX Patterns
• BMW are sending their software updates unencrypted

Watched:

PS: Spring starts next month – yeah!

The post Retrospective February 2016 appeared first on Patrick Steinert.

What have I done:

• Kicked of the first quarter 2016 with hard deadlines for Cloud of Things (watch out for CeBIT)
• Had some weekend & night shifts because of service outages of Cloud of Things. Turned out that a Gelf4J appender for Graylog caused the issues.
• Started to play with JavaFX and build a Cloud of Things Genius Client for testing purposes on CoT. (Thanks code.makery for this helpful JavaFX tutorial)
• Did a talk on our Deutsche Telekom M2M Day 2016
• I have a new record on contributing to Github

Read:

• MQTT Security Fundamentals: MQTT Payload Encryption
• Why Big Companies Keep Failing: The Stack Fallacy
• The evils of chasing Scrum Velocity…

PS: A new try to give a regular update on this blog. Last year I tried a weekly recap, didn’t worked out. But I’m pretty sure that this will work ;-)

The post Retrospective January 2016 appeared first on Patrick Steinert.