Rustic Retreat
Hot Projects
Live broadcasts and documentation from a remote tech outpost in rustic Portugal. Sharing off-grid life, the necessary research & development and the pursuit of life, without centralized infrastructure.
Subscribe to our new main project Rustic Retreat on the projects own website.
Apollo-NG is a mobile, self-sustainable, independent and highly-experimental Hackbase, focused on research, development and usage of next-generation open technology while visiting places without a resident, local Hackerspace and offering other Hackers the opportunity to work together on exciting projects and to share fun, food, tools & resources, knowledge, experience and inspiration.
Image creation/manipulation is an essential part of UI design and, with Photoshop gone, GIMP and Inkscape came to the rescue. Almost all graphics used in the Apollo-NG realm are created with Inkscape. With many people already using Inkscape and it being a vector oriented tool creating SVGs, it was just a matter of time until the SVG standard and its implementations matured and spread. Some features, such as SMIL animation and SVG Fonts are not as widely supported. There are many SVG authoring tools, and export to SVG is supported by all major vector graphics authoring tools.
SVG 2 is currently under development, and will add new ease-of-use features to SVG, as well as more closely integrating with HTML, CSS, and the DOM, and deprecating features not supported by all browsers. The SVG Working Group is currently working in parallel on a set of modules for extending prior specifications and adding functionality to CSS, and the new SVG 2 specification will combine those modules with the rest of the SVG framework to work across the full range of devices and platforms.
Let's see about bypassing even Inkscape and learn with a simple real-world example about programming UI elements directly, as opposed to manually drawing in Inkscape and thereby giving our code the means to control the design itself, making another step towards better SDUI.
Tonight's work will be another live-stream, hacking on F3l1ks. After the 3d-printer-extruder-peek-insulator-meltdown, it seemed prudent to verify that the temperatures, shown and logged by octoprint are actually the temperatures of the bed or the hot-end.
In theory it works like this: The Bed and the hot-ends have so called thermistors built-in, which are, in simple terms, just a certain kind of resistors that change their resistance (in ohm) proportional to their temperature. A specific temperature will result in a specific and predictable resistance. When we know the linearity and parameters/curve of the thermistor we can use the ADC of any uC to measure the Voltage which will change proportionally with the resistance. With a little math we can convert the digital value back to °C. So far my understanding of the principle and could/should also be reviewed in the Firmware code (reminder).
Theory is all good, but in theory the PEEK element also never should have melted. But it did. Now it's time to gather and verify data to make sure it wasn't some error in the firmware configuration, wiring or setup that led to instrumentation errors, where the temperature readouts actually were much lower than the actual temperatures to reach way above 245°C to melt the PEEK. So let's wire up an external thermometer with a K-Type temperature sensor and verify the data of the bed and the hot-end thermistors through the whole chain:
Thermistor → Cable → Connector → ADC → Firmware → USB → OctoPrint → VFCC
Since the cam and metrics shipping is already in place you can follow it live:
When you leave the commercial/proprietary software ecosphere and jump into open-source operating systems, you will have to learn how to handle daemons. And once you've created a couple of those daemons yourself, taught them what to do and let them work in production, you gain a lot of experience and confidence in dealing with all kinds of daemons.
Yesterday, a couple of friends from the awesome http://co-munity.net/ecobytes project seemed to be in some sort of possible DDoS trouble and asked for my advice and experience to mitigate the issue. Now, to me, it is a very amazing experience to simply get root access to a lot of machines lately, operated by people which I have never physically met but in this case we are connected by elf-pavlik. And in today's world, voluntarily giving root access to someone else, is the ultimate token of trust or/and friendship. So I'd like to thank you guys for that vote of confidence.
Since it was supposed to be a DDoS, I've had my input filters clamped too early and saw that something was going on and a lot of traffic was moving but it somehow seemed wrong compared to other DDoS investigations I had to do in the past. After some failed attempts to block/null-route a couple of offensive networks, our analysis focus shifted to traffic distribution where we saw that one of the VMs seemed to be the top talker. And it also became clear that the traffic wasn't coming in, it was going out. I didn't take care to look at flow direction at all because I already assumed it was incoming traffic (DDoS).
Here's where Dashboards like this come in handy. You have all relevant metrics at a glance and can compare the current to some “normal” state in the past. Matching graphs and colors visually takes much less time than working on the console to aggregate everything manually for a quick situation overview.
It then quickly became apparent, that one of the VMs was the top talker so we moved onto that box and what started out as DDoS mitigation turned into digital exorcism. You know, when there are daemons that are possessed and controlled by some evil spirit to create some form havoc, mostly motivated purely by the ultimate overlord of all evil: Financial Profit. And what do you do when dealing with evil daemons? You go Exorcist on them.