Hardware

To have a really good really good, satellite-powered reference clock, I have to have access to a 1-pulse-per-second (1PPS) signal from the receiver. The pure USB-connected receivers don’t really seem to do that yet (looks like plenty of opportunities there!), instead I have to use separate hardware for it.

The Navspark module has a 1PPS pin (GPO3 below), and the only other pin I’ll really need is a serial pin to receive the NMEA stream of the satellite lock data (TXD1 below).

These pins have to be connected to a Raspberry Pi 2’s GPIO pins.

Based on the pinout above, and some digging around, the connections I needed to make between the Pi (left) and Navspark (right) were:

• 5V  BATTERY
• Ground GND
• GPIO15 (UART0_RX) TXD1
• GPIO8 P1PPS (GPO3)

Some things to remember here, that on serial connections one side’s RX line is connected to the other’s TX  and vice versa. Also, as much as I gather any other GPIO pins on the Pi could be used to receive the 1PPS signal, I used GPIO8 because it’s been used by other projects and playing it safe…

The adapter board was easy enough to put together (though single-side pads are a pain when the components are on both sides, as it is the case here).

The adapter works well enough, though I’m sure that it could be done nicer.

Software

I found a lot of examples and help from other people’s similar projects but there were still some differences to be figured along the way. The overall setup was to be as follows:

• ArchLinux ARM for base platform
• gpsd for interpreting the Navspark NMEA messages
• LinuxPPS for 1PPS signal passing from GPIO to the userspace
• chrony as time server (as opposed to the usual ntpd)

Installing the system was straightforward enough (well, because I’ve done it so many times, but I digress), and added a few required basic packages: gpsd, chrony, git, the base-devel group, avahi (for easier network discovery).

GPSD

UART0 serial communication is done through the /dev/ttyAMA0 device in Pi, though the default settings needed some change for gpsd to be able to receive the data from Navspark.

Most of the changes our outline in a blogpost where I have learned from as well. First remove all config settings from /boot/cmdline.txt, basically these parts:

console=ttyAMA0,115200 kgdboc=ttyAMA0,115200

Next disable the automatic serial console on that device with removing relevant systemd unit with

sudo systemctl disable serial-getty@ttyAMA0.service

Then have to set up the serial channel’s baud rate to enable communication, and here I’ve done that with udev: create a new rule file at /etc/udev/rules.d/AMA0_serial.rules with the content of

KERNEL=="ttyAMA0", RUN+="/bin/stty -F /dev/ttyAMA0 115200 raw -echo"

which will set the 115200 baud rate used by Navspark when the ttyAMA0 device comes up.

Finally have to add gpsd’s default settings in the /etc/gpsd file:

# Default settings for gpsd.
START_DAEMON="true"
GPSD_OPTIONS="-b -n"
DEVICES="/dev/ttyAMA0"
USBAUTO="true"

Now it’s ready, and should be able to run gpsd and see some communication.

sudo systemctl start gpsd

and if want to start it on boot, then run the same command with “enable” instead “start”. Use gpsmon to see what NMEA data Navspark sends, and hopefully it will lock on soon too (mind the sky visibility!). Can also use cgps to monitor which satellites the system is locked onto.

1PPS

For 1PPS I had to add an item to /boot/config.txt:

dttoverlay=pps-gpio,gpiopin=8

This adds the relevant device tree overlay to enable the pps-gpio driver on GPIO8. Upon boot there was a /dev/pps0 device that can be poked at e.g. with ppstest from pps-tools. Since pps-tools did not have a package on ArchLinux, I made one, and the PKGBUILD is available on Github. That package also adds the timepps.h header file which is required for the chrony PPS driver to work.

The pps signal can be checked by running ppstest:

$ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1448436177.999366423, sequence: 199 - clear  0.000000000, sequence: 0
source 0 - assert 1448436178.999373610, sequence: 200 - clear  0.000000000, sequence: 0
...

but it needs a 3D fix for the signal to show up.

Chrony

Next up is the time server itself. The satellite time will be pulled in using two “reference clock”: the GPS timestamps provided by gpsd through a memory interface, and the PPS data that locks those timestamps. Unfortunately the PPS driver is not built in by default because it needs the timepps.h header. This means after installing pps-tools chrony needs to be recompiled.

Update the chrony configuration by editing the /etc/chrony.conf file. I usually leave the defaults alone, and add my modifications to the end of the file for clarity. Here’s my current setup:

lock_all

logdir /var/log/chrony
log measurements statistics tracking refclocks

# being a server
allow 192.168/16

server 2.tw.pool.ntp.org iburst
server 3.asia.pool.ntp.org iburst
server 2.asia.pool.ntp.org iburst
server 1.europe.pool.ntp.org iburst

# on-boot time setup, from https://news.ycombinator.com/item?id=9796885
makestep 0.1 1

# from https://www.raspberrypi.org/forums/viewtopic.php?f=41&t=1970&start=275
refclock PPS /dev/pps0 lock GPS prefer refid PPS0
# If Beidou, there is a day offset somehow
refclock SHM 0 offset -86400 delay 0.1 refid GPS noselect

leapsectz right/Asia/Taipei

It uses NTP pool servers for initial time setup and a quick on-boot step (as we don’t want to be stuck at 1970, do we?). The time service related settings are the “refclock” parts. The first line sets the 1PPS lock-on and I tell chrony to prefer that over other sources so we’ll switch over to that when there’s good-enough data. The second refclock section uses gpsd’s NMEA data. The large offset there is due to some issues where the reference time shows up with 24h offset. That I still need to investigate. The delay time set needs some fine-tuning too (I think), though from comments 0.1-0.3 (that is seconds) seems to be suitable? I also tell chrony not to use that for reference.

I also set leap seconds timezones (with the “right/…”  TAI time zone, see e.g. the NTP support page and a discussion on the Debian mailing list). And I enable the server on the local network so other can connect to it and get the time.

I’ve enabled logging of the tracking data (so there’s offset and other information available) and refclocks (tailing /var/log/chrony/refclocks.log continuously is a handy way to see when the lock is lost).

Start chrony (or enable if you want to start it on boot)

sudo systemctl start chrony

and the results can be monitored with chronyc.

All together now

If everything worked well, gpsmon should show a good locked signal after not too much time, something like this:

From the interface above I can also see that Navspark has a 3D lock (Mode A3) to satellites number 209, 207, and 206, which are Beidou birds. And that the time offset is 86399.96 seconds (~24h), that is what the chrony configuration compensates for.

Checking the results in chrony I the system time it’s locked to PPS0 where the last sample had 410ns offset (pretty good).  Also printed the sourcestats.

And this is pretty much all that is needed in general to have a Stratum-1 (atomic clock-locked) NTP server in general.

Some extra references:

• NavSpark GPS+GLONASS Stratum-1 NTP Time Source with a Raspberry Pi
• Hackspherelab: NTP GPS Time Server
• GPSD Time Service HOWTO

Experience

Navspark has a GNSS Viewer program (available for download from their website) which can also set the module’s parameters, for example forcing it to only listen to the GPS signal or only Beidou signal. There are a lot of settings, and I think most don’t need any change, but there’s still a bit to explore, and it’s definitely a handy tool.

Running the NTP lock and looking at the tracking lock there are immediately a few lessons in the ~1 day I’ve been playing with the system:

Environment matters a lot: having wind blowing over the system and being exposed to temperature changes (e.g. outdoor setting) is quite bad for frequency/time stability. One could say duh! but it’s good to see. Even a curtain and placing it indoors helps too, though having it in a well air conditioned space is even better. Too bad that in that case the sky visibility and thus the signal strength suffers a lot, but as long as there’s enough signal to have a lock it is worth it.

PPS is lost when 3D fix is lost: this took a while to figure out why did I lose lock every now and then, especially because once chrony loses the PPS signal it won’t pick it up again.

Indoor can work: indoor lock with the default antenna can work, but the building structure matters a lot.

GPS vs Beidou

Of course the most interesting part is comparing GPS and Beidou. What follows here is not very well qualified yet, just first impressions and need more work.

One of the biggest advantage of GPS is having a lot more satellites than Beidou. I wouldn’t be surprised if they are transmitting at a higher power too, or some other ways easier to receive. When locked onto GPS I could have rock-solid indoors time lock with 4-9 satellites visible at any one time. The time precision is judged by the offset frequency distribution that chrony reports (and would love to hear if there’s a better way to do that!), and that had a standard deviation of about 1µs by experience (in an air-conditioned office).

When I’ve enabled both GPS and Beidou then Navspark seemed to have generally locked onto the Beidou signal. When i was lucky I got 5-6 satellites, but generally it’s around 3 – just on the threshold of having a 3D fix, and the source of the PPS-unlock mentioned above. The offset stability on the other hand can be really good, I had runs that had about 5x smaller time offset standard deviation than GPS had (~0.2µs), and that’s quite a bit of improvement!

The issue is, that when I set the Navspark module GPS+Beidou then when there was a low Beidou satellite count (2-3), even though it still kept a (fragile) 3D fix, the time offset stability was pretty much the same as GPS on its own, though with some intervals of improved readings….

This below is a ~35minutes run of GPS+Beidou setup in an air-conditioned office with limited sky-view and 3 more stories above, using the default 12dB antenna. Using cpgs I could see that in general the lock was provided by 2-3 Beidou satellites, and in some intervals switched over to GPS without losing PPS signal (until it did). Thus it’s not the best performance that I’ve seen but still pretty good. Offset is plotted with the reported standard deviation as error bars. The central line is the mean value of the offset readings, and the two bars are the standard deviation calculated from the offsets.

Future

The ideal setup would be a well air-conditioned roof-top location (I think it would be possible to reliably see 6-7 satellites that way), and switching to Beidou only measurements to clearly see the difference between the two satellite network.

Improved reception could probably be achieved by a different Navspark antenna, which provides 25±3dB gain (that’s an extra ~13dB above the current antenna), and should help indoor reception a lot. It’s currently on pre-sale and expected by the end of the year, so will keep an eye on it!

For more advanced improvements, the adapter board would be easy enough to redo on PCB (instead of surface mount soldering), add maybe some more voltage stabilization for the module to improve the noise figure, and probably have cleaner 1PPS signal too (compared to flying wires). Will definitely give it a try as it is so easy to get the boards printed these days, e.g. with Seeed Studio.

Finally some more setting adjustments could improve the final result, such as tweaking the 1PPS pulse length, using the surveying profile for higher precision (though have to figure out what does it mean first, but looks promision), and other little tweaks….

It looks to me that if the satellite reception issues are cleaned up, the Navspark + Beidou 1PPS signal should be interesting to try with laboratory frequency references for long term stability (such as a Rubidium Clock). And of course to run the Pi+Navspark as a local time reference and provide a NTP service, e.g. from the Tapei Hackerspace…. Plenty to do. :)

The post Dual Satellite NTP server with Navspark appeared first on ClickedyClick.

For my field, atomic physics, one needs a lot of different expertise: vacuum systems, computers, electronics, machining, optics are among the ones first to my mind. Today I’m looking at one of the tools that we are using for the last topics: optics.

In some ways, optics is pretty straightforward (both geometrical and diffraction optics), many of the calculations one could write in Python/Numpy just as well, as any software can do it. They are just pretty tedious, and there are a lot of them, optics is not a new profession. Some optics design software is very useful then, and there are not that many of them, lots of work goes into the ones that exist, thus they can be extremely expensive. One of the industry standard seem to be Zemax, and many lens manufacturers provide the specs of their lenses in a Zemax format – though it is fortunately just a relatively simple text file. On the other hand, its cheapest edition is $2500, and goes up to $9500…

Another serious competitor is OSLO (Optics Software for Layout and Optimization) which is still very well known, and fortunately for us, has a dumbed down (limited number of surfaces, not all the functions available), EDU version, for free. It even runs on Linux with Wine.

I instinctively resist any software in science & research that is not free & open source, because I feel that it closes some people out, though had to use something, and in the meantime I have grown to OSLO quite a bit.

Using OSLO, I have found that one big advantage of these software is their catalog: the glasses (oh-very-important for optics) and stock optics of different companies. This alone makes everything much easier.

What does the lens designer software do? You enter the parameters of some lenses by defining different surfaces and materials & distances between those surfaces, give it some lightbeams, and see what comes out of it. Most of this happens in this window:

After these settings, one can run a number of different analytics code, checking the performance and behaviour of the system by calculating a bunch of physics parameters, or can modify the system to optimize that performance one way or another.

This is where the number 1 strangeness – and big bonus – comes in: OSLO can be scripted in a language called Compiled Command Language (CCL), which is a subset of C; and not just scripted, but the whole program is written on top of the CCL compiler (as I understand)! The result of this is that:

• Your scripting can be just as powerful as the entire program, since both sides have the same functions accessible
• There are a bunch of scripts included in the main version and even if CCL itself feels poorly documented, there are plenty of examples to learn from
• Once your script is compiled for OSLO, it can be totally part of the system, your own menuitems, options, defaults, everything
• Scripting is not just bolted on later, but the whole software feels like a result of “eating your own dogfood“, resulting in a much better experience.

Optics design is tedious, so once I figured out how to do the scripting, everything just become nicer. Haven’t had time to do a lot of things, but the script I have so far is open source, and hope to add other things later.

From the programming point of view, there’s one more strangeness. Starts with that the output of numerical calculations looks like this:

Those are all results from different functions, calculating spot sizes and wavefront distortions and what not, and those can be run from your own script – but the return variables are just printed. And they are a table. Those are table values that have to be accessed, so for example if I want to have the Strehl Ratio there, I would have to assign the value of something like “c1” to my internal variable – c for 3rd column, 1 for first row. Though to be this simple my code would have to clear the existing table before running the wavefront function correctly. This results in a lot of counting on the screen to see what row/column output of a function I want to actually use.

Internally, I think most of the calculations are following a finite number of rays. Finite but very high (~1000). The big problem, that could get the unsuspecting people (like I was), that what looks like a continuous calculation, is actually digital. For example if I set an aperture within the system that cuts into the incoming rays, and keep changing the aperture size (which is just a real number), the output results don’t really change unless I exclude or include some of the beams that OSLO is using for calculation – thus the result is changing in steps, and hard to trust. I guess there should be a setting somewhere to change the number of rays used, but still trying to find it.

It is one clever program though. The input and output parameters of a lightbeam are really connected by the system, since practically speaking, the optics are just transforming some parameters of the beam into other values, thus if I set the input parameters, the output is given. With OSLO they do this in a way, that the code just follows what parameters you have changed last time (input beam size? output image angles?…) and that will be a fixed variable, while everything else is adjusted. Some parameters disappear when others take certain values (set your object very far away? then we don’t have to let you set your object size, since it’s not important, instead give you a viewfield angle). It’s funky when I figured it out, but took a while…

I don’t know how much longer I’ll have to use it at work, but this looks something that really tickled my interest learning optical design much more, and once I have the hang of the quirks, it’s pretty neat. If anyone’s interested, there’s a pretty useful mailing list.

Now if only there was an open source solution… : )  (please drop me a line if there’s a good one)

The post OSLO is a strange one appeared first on ClickedyClick.

Also, I’m a lazy person, so want to automate as much as possible. That was on my mind recently when we have been preparing to do a vacuum-system bake-out. It’s essentially a procedure to have a delicate experimental system, mostly made up of steel, glass, and stuff like that, closed up from the atmosphere, all the air pumped out, then heated up to high temperature (~150-300°C). One has to be careful, because things can break, there are temperature limitations for some materials, also on how quickly that temperature can change, requiring careful monitoring of the status of the system. And the whole thing takes something like two weeks or more. Perfect setting for automation.

Set up the electronics

The pressure measurements are done by some expensive other equipment so didn’t have to bother with that one yet, so set to work first on the temperature monitoring. Before it was a bunch of thermocouples and multimeters, requiring manual intervention and lots of labour. Instead, got some inspiration from Adafruit’s Thermocouple Breakout Board, using the MAX31855 chip, and also from the Thermocouple Multiplexer Shield. It can handle only one channel, but can use some other chip together with it to switch between the different thermocouples, and so we can read it out one-by-one. The Adafruit board could only handle 1 channel, and the multiplexer shield was using an older chip for the measurement that I could not buy anymore. In the end, found a good analog multiplexer that one that is sold in the computer market here in Taipei, the CD4067B, and it works pretty well.

Of course, setting it all up was quite a bit of fun times, as there were way too many gotchas along the way.

• MAX31855 is a surface-mount component, and haven’t worked with it before. Not too bad, and can be much neater, just takes some plactice
• MAX31855 is a 3.3V circuit, so the CMOS voltage levels used by my Arduino Mega ADK had to be level shifted
• Unlike the older chip, MAX31855 really needs differential input, and it’s much more sensitive to the environment. This required different kind of analog multiplexer than that board had
• The Arduino Mega is a new model for me, and had some strange behaviour in terms of the serial communication
• Surprisingly there are not too many options for 3.3V voltage regulators over here, just the LM1117, which is different from what others are using elsewhere
• Lots of noise and stability issues until figured out what should be how. For example under no circumstance should touch the thermocouple to conducting surfaces, and avoid ground loops
• While MAX31855 says it’s “cold-point compensated”, meaning that it accounts for the chip-s local temperature when measuring the thermocouple, it doesn’t appear completely compensated, meaning that we can have unexpected measurement change because the chip is heating up for example by being in a closed box.
• Figuring out the right amount of time to wait between switching channels (375ms seems to be good enough, 500ms is totally fine)

This is then saved in a database, and can be accessed from elsewhere.

Visualize!

The thing that my co-workers were most amazed by wasn’t the electronics. Sure, they haven’t worked with Arduinos, but did do similar stuff. Instead they liked the monitoring interface much more, this is the one on the picture right here (can click to enlarge)

It’s the schematic layout of our equipment, with the temperatures positioned where the actual sensors are. Also, the change of the measured values in time are also displayed with live scrolling.

I’m not saying it’s great. Thinking about it, the major insight that made it good for the rest of the people is that I realized how much more people understand visual data: the placement of the values to the corresponding locations on the schematics. That’s the only thing.

So inside it’s a MongoDB database (learned from previous mistakes, using a replica-set at least), with Python scripts talking to the sensors and saving the data, NodeJS / Smoothie Charts for visualization (and plain old CSS positioning of <input> tags for the reading display), nginx‘s upstream module for running two monitoring servers just in case. It’s mostly in the Github repo of the monitoring code, as well as the Arduino sketch for talking to the electronics.

It was actually quite fun to write it all, and the gradual improvements, trying the new tech, trying not to lose to much data, amazed how well it works. Especially had a good time learning about the database, scaling, fault tolerance, performance…

Of course there could be room for a lot more improvements.

• My failover-restart bash scripts are awful, though they do seem to work more or less and counteract the USB unreliablilities
• There were some changes to Smoothie Charts that I could improve on: logarithmic plotting, some display enhancements, wonder if it can be more optimized for performance
• More efficient data loading. 12h data is about 30Mb in JSON format, that I send compressed, apparently it gets down to ~5% in size, but it still takes quite a bit of time to process on the frontend
• The layout now can be changed from config files if the sensors change, so co-workers can do that without programming knowledge. I wonder if that can be simplified even more

Of course, I’m a person who generally overengineers stuff, so maybe it’s good to stop somewhere. And the somewhere might be when I got to the point to use my Kindle for monitoring (craps out on 1h data already, but some real time things are good enough).

Get on with it

I did learn a lot along the way, and I’m sure that with this experience I will be let to do a little bit more in the lab in terms of programming ideas. I don’t like that the rest of the system is currently forced to be LabView, but that’s for another post, and there are so many things that can be improved in general as well. Let’s just go and do that.

The post Laboratory 2.0 – a monitoring system appeared first on ClickedyClick.

For every subject, there are really only two things you really need to know. Everything else is the application of those two things, or just not important.

Of course it is a fascinating idea, and I started to think about my profession, physics. If I simplify my experience and knowledge down to this minimal level, what would be the two things I get to? I do think it is not a straightforward stuff, and one can only get to the bottom of this, can find the hidden truth below, if one spends a lot of time with the subject, gets to know it inside and out. I feel that I’m still just scratching the surface of the wast knowledge of the universe (even after being a physicist for about 12 years now). Still this doesn’t stop me from trying.

I’m an experimental physicist, worked in Solid State Physics first, now mostly in Atomic & Laser Physics – all kind of fun stuff. I had very good professors, great inspiration and I have learnt a lot from them. If I think back all the things I’ve learned there are still things that come to me as my first thoughts, and usually those are the right guesses, for whatever intuition I have.

My Two Things about Physics:

1. Pure math can take you very far along the way, though in the end still need experiment to see whether the results describe something real.
2. Everything is an approximation, but that’s fine. Just pick your approximations carefully.

Maybe it is worth expanding a little bit on that these:

Pure math can be used to describe things extremely well. It’s maybe even too good at that, which got other, much cleverer people to think as well, like a fellow Hungarian physicist, Wigner Jenő (or Eugen Wigner), writing about The Unreasonable Effectiveness of Mathematics in the Natural Sciences. I frequently got myself really excited when after doing some complicated calculation to predict the behaviour of a physical system, the experiment matches up to all of its nuances. Let it be atomic spectroscopy, polarization of light reflected from metallic mirrors, magnetic field of a Zeeman-slower, I had a lot of fun figuring out the physical theories of different phenomena then matching it up with what happens in the lab. Of course, there were loads of times when they didn’t match, but it turns out my math was off. Really, if I want to understand the world, math is one of the most useful and versatile tool to have.

Having that tool is of course not enough. When people come up with new and interesting math trick, it often turns out (to many people’s amusement) that those tricks have some physical meaning, they often also give some insight into the world around us. It’s often, but not always. Mathematics can really easy take one to very strange places and give a result, which is completely aphysical. To complicate things even further, those aphysical results sometimes turn out to be actually correct and predicting real but insofar unobserved things. An example of this is the Dirac equation which gives two solution, one for electron, and one particle with negative mass that first people dismissed, but later it was understood as the representation of positron. How to distinguish between really wrong solution and “wrong as current understanding”, that’s a whole different level of problems.

The second point was really a revelation for me. Whatever equations we have, they all just describe things to a certain level. If we can look closer, we often find differences from the theory, that are harder and harder to explain as we get closer. On the other hand, using intuition and physical understanding, people often choose to ignore certain parts of the situation, or certain features of the problem since it cannot affect the results to a level that would be observed in the given experiment. This makes everything solvable, and once solved, one can advance on top of the new understanding even deeper into the problem. Finding the good approximations is almost as valuable as finding the right theory, that’s why often these approximations are named after the people who came up with them, or given other shorthand names so everyone can quickly recall and use them.

There’s a whole methodology built to help come up with approximations and handle them, called perturbation theory: if the given problem is very similar to a simpler, already solved problem, then treat it as the simple one plus some small effect that changes relatively little on the behaviour of the system. Not everything can be handled like this, but surprisingly many problems fit very well.

Others’ Two Things about Physics

On the original site there were other people’s Two Things as well:

1. Energy is conserved.
2. Photons (and everything else) behave like both waves and particles.
-Tim Lee

1.  Draw a diagram.
2.  Get the dimensions straight.
-Eric Schafer

I personally don’t like these that much. The first one is just stating two theories that can be superseded in the future, and right now they kind of limit instead of enable. The second one is good advice, but can’t say that’s the only thing there about physics. Having said that, I have more adventures with incorrect dimensions and units than I’d prefer to have.

What other Two Things choices one can make, in physics or in other sciences, other topics?

The post The Two Things about Physics appeared first on ClickedyClick.

1. Believe you can change the world.
2. Work quickly, keep the tools unlocked, work whenever.
3. Know when to work alone and when to work together.
4. Share tools, ideas. Trust your colleagues.
5. No Politics. No bureaucracy. (These are ridiculous in a [lab]).
6. The customer defines a job well done. [?]
7. Radical ideas are not bad ideas.
8. Invent different ways of working.
9. Make a contribution every day.
10. If it doesn’t contribute, it doesn’t leave the [lab].
11. Believe that together we can do anything.
12. Invent.

These are so well formulated that they give more of an “aha!” feeling instead of a question that “yeah? why’s that?”. Researchers should have all of this drilled in. Or rather everyone should have.

The only one that I’m not satisfied by is #6: what constitutes a “job well done” in academia? No customers so no direct measurable response to the effort. The commonly used metrics are amount of grants won, number of members who won tenures, number of publications and/or citation, conference invitations, and so on, none of which really captures what science is about and why people should be doing it. But then what is the metric? Maybe this is a problem in general, no clear aim makes unfocused effort. Or is it a strength as people can define their own measures of success? I don’t think that’s the right way either. I usually go by the “amount of curiosity satisfied and new things learned”. But since I feel I have learned an awful lot lately but still barely going forward, maybe I’m not the example of someone who should be followed on this.

Anyway, I wanted to post this, because it needs a bit more thinking and have to start somewhere. And indeed there’s a lot to do…

Now back to work. But better this time, there’s a world to change.

The post Rules of the garage, I mean, lab appeared first on ClickedyClick.