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.
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.
In order to update the firmware of our 3D printer for dual head extrusion and to compile Cura (an alternative gcode slicer) a working AVR crossdev toolchain was needed.
The printer firmware uses the Arduino toolkit so the dependency was obvious, the Cura build unfortunately needs a working avr-gcc as well (not that obvious), because it also ships with Ultimaker firmware, which cannot be disabled, even if you don't have an Ultimaker (kinda stupid).
Currently, the stable crossdev avr-gcc suite with gcc 4.8.3 did not compile so it was a bit of a hassle to get it running again. In order to save somebody else the time to figure this out, here's the install trace that was already tested verbatim on another gentoo amd64 box and worked as well.
Let's start with a clean slate and unmerge any cross-avr chain:
crossdev -C avr
This was used originally:
USE="multilib -cxx" crossdev -v -s1 --without-headers --target avr --gcc 4.5.2 --binutils 2.21 --libc 1.7.0 USE="multilib cxx" crossdev -v -s4 --target avr --gcc 4.5.2 --binutils 2.21 --libc 1.7.0
As of 2015-04-05 the above combination doesn't work anymore, please use this instead:
USE="multilib -cxx" crossdev -v -s1 --without-headers --target avr --gcc 4.5.4 --binutils 2.21.1-r1 --libc 1.7.0 USE="multilib cxx" crossdev -v -s4 --target avr --gcc 4.5.4 --binutils 2.21.1-r1 --libc 1.7.0
And to finish it up:
ln -nsf /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts /usr/avr/lib/ldscripts ln -nsf /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.20.1/ldscripts cd /usr/avr/lib ln -nsf avr5/crtm328p.o . ln -nsf avr6/crtm2561.o . ln -nsf avr6/crtm2560.o . mkdir -p /usr/share/arduino/hardware/tools/avr/bin/ ln -s /usr/bin/avr-gcc /usr/share/arduino/hardware/tools/avr/bin/avr-gcc ln -s /usr/bin/avr-g++ /usr/share/arduino/hardware/tools/avr/bin/avr-g++ ln -s /usr/bin/avr-objcopy /usr/share/arduino/hardware/tools/avr/bin/avr-objcopy ln -s /usr/bin/avr-ar /usr/share/arduino/hardware/tools/avr/bin/avr-ar ln -s /usr/bin/avr-as /usr/share/arduino/hardware/tools/avr/bin/avr-as ln -s /usr/bin/avr-size /usr/share/arduino/hardware/tools/avr/bin/avr-size
If you want to use the Software Serial and monitoring feature, you need to install rxtx-2.2_pre2 or newer. This version is still masked in the main portage tree, so you will need to unmask it by adding
=dev-java/rxtx-2.2_pre2 ~x86 ~amd64
to /etc/portage/package.keywords/arduino and then (re)emerge it
$ emerge dev-java/rxtx
Also, if you don't want to use the crappy JAVA based Arduino IDE, you can simply use a Makefile like this: https://github.com/sudar/Arduino-Makefile
Since it's currently winter in central Europe, it's the perfect time to evaluate the ucsspm for its feasibility/validity. After bringing the VFCC online, it was a simple task to ship prediction metrics and reference measurements into influxdb and create a couple of dashboards to create meaningful graphs to evaluate its performance very easily.
Yesterday was the first full clear sky day since the beginning of data collection and the prediction results definitely look very promising as we can see on the following dashboard screenshot:
The top right graph shows global solar radiation over a 10 hour period. The green line shows what the UCSSPM predicted as a maximum clear-sky value, the yellow bars show the reference measurement of global solar radiation in W per m² over the same period. The bigger graph at the bottom shows how that translates into the context of photovoltaics (conversion of solar radiation into electricity) and since the output is always a derivative value of global solar radiation the graph looks about the same but the output is measured in W. We can see that we are a long way off the 800-1000 W/m² which are often used for baselining. Of course, it cannot predict the weather but it is an enormous help in planning, scaling and operating solar energy conversion systems in order to have a reliable baseline, so that we know what could be obtained as a maximum at a specific location/time, when there are no clouds.
The reference measurements are sourced from a pyranometer operated by the physics/meteorological department of the Ludwig-Maximilians-University in Munich, who were kind enough to share their data online, which saved us the investment of monetary resources to buy or time to build/calibrate our own pyranometer for now. In order to keep the prediction evaluation results consistent, all other metrics needed by the UCSSPM like temperature, humidity, air pressure etc. are also collected from the same station and fed into the UCSSPM.
If time permits, it would be interesting to see if we can make use of our global cloudmap service, to use either historic or live data for an even more accurate prediction, not just clear-sky baselining.
Long term live reference and UCSSPM prediction metrics are contiously collected and publicly accessible on these VFCC dashboards:
In order to have total system control for crew/guests and to be more transparent about the technology and infrastructure in use and to give people another way to get into the detailed aspects and challenges of this project, the Virtual Flight Control Center (VFCC) is now open to the public. This is just a first step, as more technology is implemented, the VFCC will have more features. It's a little bit early in the projects timeline but became necessary as a proving ground for the UCSSPM.
If you want to see more than just screenshots open the Virtual Flight Control Center (VFCC).
Be aware that we do not care about testing/supporting closed-source, IP encumbered browsers at all. Also you'll probably need at least 7“ of display size since it doesn't automatically resize yet and grafana's graph rendering has a tendency to overload mobile browsers, so phones are currently not the best choice to play with it :) For obvious reasons, the public VFCC doesn't allow control and data access is read-only, so you can play with it as much as you like without having to worry about breaking anything.
It's still a very crude and hackish demonstrator, combining the following open-source components: