In photography most optical lenses use mechanical diaphragms for aperture control. They are traditionally manufactured from metal blades and works quite good. However metal blades exposes some disadvantages:

• mechanical parts will sooner or later fail
• the cheaper forms give strong diffraction spikes
• manufacturers need more metal blades for a round iris, which is expensive
• a metal blade with its sharp edges give artefacts, which are visible in out of focus regions.
• but, contrast is very high by using opaque metal

In order to obtain a better bokeh, some lenses are equipped with apodization filters. Those filters work mostly for fully open arperture and are very specialised and thus relatively expensive.

A digital arperture build as a transparent display with enough spatial resolution can not only improve the shape of the diaphragm. It could feature as a apodisation filter, if it supports enough gray levels. And it can change its form programatically.

Two possible digital diaphragm forms:

• leverage existing display technology
• better aperture shape for reduced artefacts
• apodisation filter on demand for best bokeh or faster light
• programmable or at least updateable aperture pattern (sharp/gausian/linear/…)
• no metal blades or other mechanical parts to fail
• over the years get cheaper than mechanical counterpart
• reduce number of glas to air surfaces in optical lens design
• integratable aperture into lens groups
• display transparency increases quickly and is for OLED at 45% by 2016, which means at the moment just one f-stop
• mobile demands high display resolutions anyway

The digital arperture can easily be manufactured as a monochrome display and be placed traditionally between two optical lens groups, where today the diaphragm is located. Or it is even possible to optically integrate the aperture into one lens group, without additional glas to air surfaces, as is needed with moving blades. Once the optical quality of the digital filter display is good enough a digital diaphragm can be even cheaper than a high quality mechanical counterpart.

More and more security incidents in Free Software projects get publicized in a way that anyone & their grandma understand the impact. Some of these carefuly crafted "campaigns" even make it to the main stream media. This trend, among other things, has sparked a discussion about funding Free Software to sustain the infrastructure everyone is building upon. A discussion which, in our venture capital driven tech world, mostly evolves around financing as a means for getting resources. Who can/should pay whom, to develop Free Software and how. I would like to add another view at funding, one that in my opinion has way more to do with Free Software ecosystem than cold, hard cash: collaboration of free people.

Freedom and what you make of it

The ability to run, copy, distribute, study, change and improve software. This is the essence of it, without these fundamental rights, software is not Free Software. And these fundamentals imply a purpose: Freedom, the ability to do as one wills. To do to software as one wills.

As always, what people make of their freedom is up to them. Some go an preach about it, most ignore it, some use it for their personal gain. However, it's undeniable that the Free Software movement has entailed a community of systematic world wide collaboration. In software development, and I would argue in many other aspects of todays life. We all know the examples of hundreds of developers hacking together on Linux, thousands of authors on Wikipedia per month, millions of pictures in the creative commons and so on. Obviously, if you give people the freedom to do as they want, many of them are inspired to work together for the common benefit. And because Free Software entails collaboration and collaboration is about individuals, making projects sustainable has many dimensions. Money is one.

Challenges and what you do about them

Of course there are many things going wrong today with making Free Software projects sustainable. For instance a growing imbalance between developers and users (Noah Kantrowitz), that developers think they are not getting fairly compensated (Ryan Bigg) or that everybody is waiting for someone else to do something (Marijn Haverbeke). Contributor burn-out. There are many, many more.

The solutions to these shortcomings, discussed in the past months, most exclusively focus on monetizing work. Be it through business models, crowd funding, grants and other forms of injecting money into the equasion. In a recent piece, Nadia Eghbal even argues that somehow venture capital must flow back because all of the VC funded software companies somehow base their work on Free Software. Steve Klabnik thinks this is already happening. Here is the thing: Money will buy you people who contribute, sure thing. But is it money for contributions that made the present? For sure not. Collaborative contributions are the currency of Free Software.

openSUSE Community by Henne Vogelsang licensed CC BY 4.0

People and how you treat them

People have made Free Software as big as it is. Active contributor communities. Humans from all over the world, with different talents, levels of expertise and cultural backgrounds collaborating. All with their own motivations. Some want to learn from others, some scratch their itch, some want to train their skills, some want to boost their resume, some contribute on behalf of a company, some just try to avoid being bored on a Saturday afternoon. If your project does not actively channel all of these ambitions into contributions, if it does not organize the collaboration, if it is not offering shared responsibility and if it does not attract new contributors it's doing something wrong.

An individual/company slapping a license onto code, uploading it to github, merging pull-requests and answering issues is not making a sustainable Free Software project. Yet this is what many do today.

If you look at the most prominent examples of the software people worry about, openssl or NTP, they are failed communities. They disintegrated to a point where collaboration ceased to exist, the remainaing people were not able to do anything to change this (I'm sure they tried hard) and in the end something bad happened, and now they are clearly not sustained. Now we all can throw some bucks together to keep developers developing but that wont make those projects sustainable Free Software communities. In my opinion paying for contributions is to capitulate in the face of to the task of building a sustainable community. There are other things which are more important.

Fund Free Software without money

I guess the most obvious way to fund Free Software projects without money is to contribute in any way possible for you, duuhh. But apart from that I think there are more things we as the Free Software community at large can do better.

In my opinion it's time we help each other to organize collaboration. We need to share best pratices about creating sustainable contributor communities that attract new people.

We also should be more upfront with each other when we notice communities failing. I have contributed code to NTP a couple of years ago and didn't care that it was such a bleak place. Someone merged my patches, I was off again. In retrospecitve this feels like not telling someone their flap is open.

I also think that we need to do better with copyleft project resources. We have the choice between 27 different C++ compilers but if you're looking for marketing materials, web site themes or templates of contributor guidelines you will draw mostly blanks. Convincing prospective users and contributors that our Free Software does something significantly better than the competition is very important, yet we leave each other hanging with this.

Now go do something

Luckily somewhere Free Software people already have started with all of this. There is the community leadership forum where you can talk about all the aspects of your community. opensource.com curates a blog of best practices. Designers started to rally around opensourcedesign.net. People all over start to address the obvious diversity problem our community has. Next month (July 2016) there is a conference to talk with other Free Software people about Open Source & Feelings and I'm sure there is more going on out there.

What do you think about financing Free Software projects? Are you going to do something about making Free Software sustainable?

Yours truly, Henne 💚

Every day, a sizable number of people posts problems on the KDE Community Forums and the ever-helpful staff does their best to solve whatever issues they’re facing. But what exactly does one do when this happens? This post provides more insights on the process.

NOTE: The following applies to my workflow for the Kontact & PIM subforum.

Step 1: Someone posts a problem

The questions posted are various, and range from simple tasks (“how I do XXX”) to very specific workflows. It covers a large spectrum.
The first thing I do when reading a post, is to go through a “mental checklist”:

1. Is this known already?
2. Are there enough information?
3. What distro is this user on?

Answering point 1 means I have to keep up with development of KDE software, or if I don’t know, check the mailing lists and blog posts to see if other people have raised the issue (checking Bugzilla is a last resort, due to the very large number of bugs posted there). It also helps running the latest KDE software.

If point 2 isn’t satisfied, I ask a few more questions following the General Troubleshooting guidelines. These include conditions for reproduction of the issue, if it still occurs with a new user account, and so on.

Point 3 is related to point 2: not all distros are equal, so knowing on which distro the user in may reveal distribution-specific issues that need to be addressed directly downstream.

Step 2: Going deeper

If the issue isn’t solved even like this, “we need to go deeper”. Usually, time permitting, I try to reproduce the issue myself if it is within my reach (for example, if it doesn’t involve company secrets on an internal server ;).

If I can reproduce it, I tell the user to file a bug, or workarounds, if I found any. If I can’t, I ask a few more details. Usually this can lead to the issue being solved, or to a bug report being filed.

Step 3: Communicating

Sometimes the issue is unclear, or it is behavior where the line between feature and bug is very blurred. In this case, I need to get information straight from the horse’s mouth. I hop on IRC, and I address the developers directly, usually pointing at the forum thread, and asking for details.

Sometimes they follow up directly, sometimes they report me useful information, and sometimes they tell me its’ a feature or a bug. In either case, I report the information to the thread starter. In rare cases, the issue is simple enough that it gets fixed shortly afterwards.

Stem 4: Following up

Unfortunately not all bugs can be addressed straight away, so sometimes issues stay lingering for a long period of time. However, sometimes a commit or two may fix it, with or without a bug being filed. If I notice this (I do read kde-commits from time to time ;) I follow up on the thread writing about it being fixed, workarounded, or whatever.

What’s the point of this post, anyway?

Good question. ;) I mean this to show how much work can go into a “simple” user support request post on the KDE Community Forums. This is even more important to point out since apparently, frustration can make people tell that others’ work is worthless.

So, if you ever bump in any of the forum staff, be sure to offer them a beverage of their choice. ;)

Example

$ ./call-graph ../yast/packager/src/modules/Packages.rb
$ dot -Tpng -oPackages.png ../yast/packager/src/modules/Packages.dot

$ convert Packages.png -resize 1200 Packages-small.png

Packages.png, an example output

Requirements

• Ruby
• parser gem
• Graphviz

License

Guest post by Petr Marek (source)

Everybody driving a car needs the navigation to get to the destination fast and avoid traffic jam. One of the biggest problems is how to enter fast the destination and how to find where are the congestions, what is the traffic situation. YodaQA Traffic is a project attempting to answer the traffic related questions quickly and efficiently. Drivers may ask questions in natural language like: “What is the traffic situation in the Evropská street?” or “What is the fastest route from Opletalova street to Kafkova street?” You can try out the prototype (demo available only for limited time) – try to ask for example “traffic situation in the Wilsonova street” .

YodaQA Traffic still has some limitations. Currently we only have a browser version not suitable for smart phones. It is answering traffic questions for Prague’s streets only.

But as usual, this whole technology demo is open source – you can find it in the branch f/traffic-flow of our Hub project.

How does it work and where we get the data from?

All YodaQA are first analyzed to recognize and select traffic questions. We do it in two steps. The first step is to recognize the question topic. We use six topics like traffic situation, traffic incident or fastest route. The topic is determined by comparing semantic similarity of the user’s question with a set of reference questions. We estimate the similarity with our Dataset-STS Scoring API. Each reference question is labeled by a “topic”. The Sentence Pair Similarity algorithm selects the reference question “topic” with the highest similarity to the question.

Next we need to recognize the location, i.e. to recognize the street name. This is handled by another tool called the Label-lookup which we normally use for entity linking in YodaQA. It compares questions words with a list of all street names in the Prague. We exported the list of streets names in Prague from OpenStreetMap. We do not do exact match, we try to select the closest street name from the list.

The last step is to decide whether the question is really the traffic question, because the Dataset-STS API and Label-lookup can find topic and street name even in a pure movie question like “When was the Nightmare on Elm Street released?”. The Dataset-STS and Label-lookup return not only topic or street name but also the score, fortunately. We created dataset of over 70 traffic questions and over 300 movies questions and founded the minimal score thresholds, with which the recognition makes the lowest classification error on this dataset.

Once we know the type of question and the location we start a small script accessing the traffic situation data from HERE Maps. The only complication is that the the API doesn’t return traffic situation for particular street, but bounding box only. To overcome this problem we have to find a bounding box for a desired location, using an algorithm we developed for this purpose. Then we call the traffic flow API to acquire the information for all streets in the bounding box. Finally, we filter out the traffic situation for the desired street.

It was great fun to work on this application, it is not perfect but it shows how to create intelligent assistants helping people solving various everyday situations. We are also excited to see, how the users will use the new functionality of YodaQA and how it will help them.

Guest post by Petr Marek (source)

Everybody driving a car needs the navigation to get to the destination fast and avoid traffic jam. One of the biggest problems is how to enter fast the destination and how to find where are the congestions, what is the traffic situation. YodaQA Traffic is a project attempting to answer the traffic related questions quickly and efficiently. Drivers may ask questions in natural language like: “What is the traffic situation in the Evropská street?” or “What is the fastest route from Opletalova street to Kafkova street?” You can try out the prototype (demo available only for limited time) – try to ask for example “traffic situation in the Wilsonova street” .

YodaQA Traffic still has some limitations. Currently we only have a browser version not suitable for smart phones. It is answering traffic questions for Pragueâ€s streets only.

But as usual, this whole technology demo is open source – you can find it in the branch f/traffic-flow of our Hub project.

How does it work and where we get the data from?

All YodaQA are first analyzed to recognize and select traffic questions. We do it in two steps. The first step is to recognize the question topic. We use six topics like traffic situation, traffic incident or fastest route. The topic is determined by comparing semantic similarity of the userâ€s question with a set of reference questions. We estimate the similarity with our Dataset-STS Scoring API. Each reference question is labeled by a “topic”. The Sentence Pair Similarity algorithm selects the reference question “topic” with the highest similarity to the question.

Next we need to recognize the location, i.e. to recognize the street name. This is handled by another tool called the Label-lookup which we normally use for entity linking in YodaQA. It compares questions words with a list of all street names in the Prague. We exported the list of streets names in Prague from OpenStreetMap. We do not do exact match, we try to select the closest street name from the list.

The last step is to decide whether the question is really the traffic question, because the Dataset-STS API and Label-lookup can find topic and street name even in a pure movie question like “When was the Nightmare on Elm Street released?”. The Dataset-STS and Label-lookup return not only topic or street name but also the score, fortunately. We created dataset of over 70 traffic questions and over 300 movies questions and founded the minimal score thresholds, with which the recognition makes the lowest classification error on this dataset.

Once we know the type of question and the location we start a small script accessing the traffic situation data from HERE Maps. The only complication is that the the API doesnâ€t return traffic situation for particular street, but bounding box only. To overcome this problem we have to find a bounding box for a desired location, using an algorithm we developed for this purpose. Then we call the traffic flow API to acquire the information for all streets in the bounding box. Finally, we filter out the traffic situation for the desired street.

It was great fun to work on this application, it is not perfect but it shows how to create intelligent assistants helping people solving various everyday situations. We are also excited to see, how the users will use the new functionality of YodaQA and how it will help them.

I have some 2” wooden blinds in my house that I’ve been wanting to motorize. Why? I’m lazy and I thought it would be cool to have.

The best commercial solution for retrofitting existing blinds seems to be Somfy. They have wireless battery-powered systems and fancy-looking remotes. For new motorized blinds, Bali seems to be popular, and they use Somfy for the motorization. There are also some kickstarter things (MOVE, MySmartBlinds), but the last time I looked those didn’t really do what I want. Somfy likely has a good product, but it’s very expensive. It looks like it would cost about $150 per blind, which is just way too much for me. They want $30 just for the plastic wand that holds the batteries (8 x AA). We’re talking about a motor and a wireless controller to tell it what to do. It’s not rocket surgery, so why should it cost $150?

My requirements are:

• Ability to tilt the blinds to one of three positions (up, middle, down) remotely via some wireless interface. I don’t care about raising or lowering the entire blind.
• There must be some API for the wireless interface such that I can automate them myself (close at night, open in morning)
• Tilt multiple blinds at the same time so they look coordinated.
• Be power efficient – one set of batteries should last more than a year.

Somfy satisfies this if I also buy their “Universal RTS Interface” for $233, but that only makes their solution even more expensive. For the 6 blinds I wanted to motorize, it would cost about $1200. No way.

I’ve been meaning to get into microcontrollers for a while now, and I thought this would be the perfect project for me to start. About a year ago I bought a RedBear BLE Nano to play with some Bluetooth stuff, so I started with that. I got a hobby servo and a bunch of other junk (resistors, capacitors, etc) from Sparkfun and began flailing around while I had some time off around Christmas. The Arduino environment on the BLE Nano is a little weird, but I got things cobbled together relatively quickly. The servo was very noisy, and it’s difficult to control the speed, but it worked. Because I wanted to control multiple devices at once, BLE was not a really great option (since AFAIK there is no way to ‘broadcast’ stuff in a way that is power-efficient for the listeners), and I started looking at other options. Eventually I ran across the Moteino.

The Moteino is an Arduino clone paired with a RFM69W wireless radio, operating at either 915Mhz or 433Mhz. It also has a very efficient voltage regulator, making it suitable for battery powered applications. The creator of the board (Felix Rusu) has put in a lot of work to create libraries for the Moteino to make it useful in exactly my type of application, so I gave it a try. The RFM69 library is lovely to work with, and I was sending messages between my two Moteinos in no time. The idea is to have one Moteino connected via USB to a Linux box (I already have a BeagleBone Black) as a base station which will relay commands to the remote devices. I got my servo working again with the Moteino quickly, as most of the code Just Worked.

I started out with a hobby servo because I knew it would be easy to control, but the noise and lack of speed control really bothered me. I needed to try something else. I considered higher quality servos, a gear motor with encoder or limit switches, stepper motors, worm gear motors, etc. I was going to end up building 6 of these things to start with, so cost was definitely a big factor. I ended up settling on the 28BYJ-48 stepper motor because it is extremely cheap (about $2), relatively quiet, and let me control the speed of rotation very precisely. There is a great Arduino library for stepper motors, AccelStepper, which lets you configure acceleration/deceleration, maximum speed, etc. It also has an easy-to-use API for positioning the motor. I found a 5mm x 8mm aluminum motor coupling to connect the motor to the blinds shaft. I then used a zip tie and a piece of rubber to secure the motor to the blinds rail. This doesn’t look very professional, but it’s not something you really see (my blinds have a valance that covers the rail). A better solution involving some kind of bracket would be great, but would increase the cost and require a lot more time. Using the stepper, I was able to smoothly, quietly, and cost-effectively control the blinds.

I then started to look into power consumption. If you don’t do put anything to sleep, the power usage is pretty high. The LowPower library from Felix makes it easy to put the CPU to sleep, which helps a lot. When sleeping, the CPU uses very little power (about 3µA I think), and the radio will wake you up via interrupt if a message arrives. The radio uses roughly 17mA in receive mode, however, so that means we’d only get about a week of battery life if we used a set of high-quality AAs (3000mAh / 17mA = 176h). We need to do a lot better.

The RFM69 has a useful feature called Listen Mode that some folks on the LowPowerLabs forums have figured out how to use. In this mode, you can configure the radio to cycle between sleeping and receiving in order to reduce power consumption. There are a lot of options here, but it was discovered that you only need to be in the RX phase for 256µS in order for a message to be detected. When the radio is asleep it uses about 4µA. So if you sleep for 1s and receive for 256µS, that means your average power consumption for the radio is about 12µA. This is a dramatic improvement, and it means that the device can still respond in roughly one second, which is certainly adequate for my application. Of course, you can always trade even more responsiveness for power efficiency, and people using this method on coin cell batteries certainly do that. There is one user on the forums who has an application with an expected battery life of over 100 years on a single coin cell! I have an extension of the RFM69 library, RFM69_WL, which collected some of the other listen mode code that was floating around and extends it so you can set your own sleep/RX durations.

I’ve measured/calculated my average power consumption to be about 46µA if I run the motor for 12s per day. That comes out to over 7 years of life on a set of 4 AA batteries (Energizer Ultimate Lithium), which is an almost unbelievable number. There are several factors I am not really considering, however, such as RF noise (which wakes the radio causing increased power consumption), so the real life performance might not be very close to this. Still, if I can get 2 years on a set of 4 AAs I’ll be pretty happy.

Usually when you buy a 28BYJ-48 it will include a driver board that has a ULN2003A, some connectors, and a set of LEDs for showing which phase of the stepper is active. This is fine for testing and development, but it was going to be pretty clunky to use this in a final solution. It was time to design my first PCB!

I found out early on that it was pretty difficult to talk to other people about problems with your project without having a schematic, so I made one of those. I started with Fritzing, but moved to EAGLE when it was time to do the PCB. It seemed to be the standard thing to use, and it was free. EAGLE has a pretty steep learning curve, but some tutorials from Sparkfun helped a lot. I also got some help from the folks on the LowPowerLabs forums (TomWS, perky), who I suspect do this kind of thing for a living. You can get the EAGLE schematic and board design here.

View post on imgur.com

View post on imgur.com

I ordered my first batch of boards from Seeed Studio, as well as a bunch of supporting components from Digikey. The PCB orders typically take a little over two weeks, which is quite a bit more waiting than I’m accustomed to. I was pretty excited when they arrived, and started checking things out. I soon realized I had made a mistake. The component I had in my design for the motor connector (which is a JST-XH 5-pin) was the wrong pitch and size, so the socket I had didn’t fit. Whoops. The hardware world does not play well with my “just try some stuff” mentality from working with software. I found an EAGLE library for the JST-XH connectors, used the correct part, and ordered another batch of PCBs. This time I actually printed out my board on paper to make sure everything matched up. I had run across PCBShopper while waiting for my first batch of boards, so I decided to use a different fabricator this time. I chose Maker Studio for the second order, since I could pay about the same amount and get red boards instead of green. Another two weeks went by, and finally last week I received the boards. I assembled one last weekend using my fancy (and cheap!) new soldering station. It didn’t work! Shit! The Moteino was working fine, but the motor wasn’t moving. Something with the motor driver or connection was hosed. After probing around for a pretty long time, I finally figured out that the socket was installed backwards. It seems the pins in the EAGLE part I found were reversed. Ugh. With a lot of hassle, I was able to unsolder the connector from the board and reverse it. The silkscreen outline doesn’t match up, but whatever. It works now, which was a big relief.

View post on imgur.com

I thought about putting the board in some kind of plastic enclosure, but it was hard to find anything small enough to fit inside the rail while also being tall enough to accomodate the Moteino on headers. I’m planning to just use some extra-wide heat shrink to protect the whole thing instead, but haven’t done that yet.

Below are some photos and videos, as well as the entire list of parts I’ve used and their prices. Each device costs about $40, which is a pretty big improvement over the commercial options (except maybe the kickstarter stuff). Also important is that there are no wires or electronics visible, which was critical for the Wife Acceptance Factor (and my own, honestly).

I’m sure a real EE will look at this and think “pfft, amateur!”. And that’s fine. My goals were to learn and have fun, and they were definitely accomplished. If I also produced something usable, that’s a bonus.

View post on imgur.com

View post on imgur.com

View post on imgur.com

Bill of Materials

In order to talk to the devices from a host computer, you’ll also need a Moteino USB ($27). To program the non-USB Moteinos you’ll need a FTDI adapter. LowPowerLabs sells one of those for $15, but you may be able to find a better deal elsewhere.