Visiting HE Moste

22.06.2014 15:09

When you're driving from central Slovenia towards the mountains, the Gorenjska highway crosses the valley of the Sava river. From the viaduct you can see a high dam wedged between sides of a narrow gorge. Behind it is the water reservoir for the Hidroelektrarna Moste.

Viadukt Moste and HE Moste dam.

I've been watching this dam every time I was traveling on that road. For years I wanted to see it up close and the power plant below it. My wish came true when my mum got a contact at the plant and arranged for a guided tour. So my parents and I drove up to Žirovnica last week and visited the facility.

Hidroelektrarna Moste

To my surprise, turbines and the generator hall of the power plant are actually located quite a bit down river from the dam, not directly underneath it as I expected. Water from river Sava is routed through a tunnel under the nearby town Moste, from which the facility also got its name.

What you see above is the steep railway with which heavy machinery has been lowered into the valley during construction.

Safety valve on the high-pressure pipeline for HE Moste

This safety valve on the high-pressure pipe in the tunnel was the first impression of the scale of engineering of this place.

The valve is designed to operate in a fail-safe manner: in case of an emergency, it uses stored potential energy without the need for any external power. The huge red weight shuts off the water supply if electric power is lost or if sensors detect flooding in the facility. Later on in the generator hall we saw emergency buttons similar to fire alarms that would manually trigger it.

Behind the valve is a huge vertical surge tank embedded in rock. Its purpose is to absorb the kinetic energy of the water in the pipeline which could cause damage if the valve would suddenly close.

Even though around 20 m3 of water were flowing per second through the large pipe, there was surprisingly little sound to be heard.

Flotation device near the turbine of HE Moste

The site is actually home to two power plants:

In 1915 Hidroelektrarna Završnica was built here to become the first public power plant in the area. It used water from the river Završnica which was routed from a reservoir higher up in the mountains and discharged into the river Sava.

Later on, river Sava was dammed in 1952 and Hidroelektrarna Moste built alongside the old power plant. Now HE Završnica is no longer in use and is being slowly converted to a museum. Its water supply however has been routed to one of the turbines in HE Moste and is still used intermittently to generate electricity.

Francis turbine in HE Završnica.

This is one of the three 10 MW Francis turbines currently in operation. In contrast to the quiet flow of water in the pipeline, turbine wells were noisy enough that you had to shout to talk to someone.

While we were visiting, one of the generators had to be stopped because of a problem with one of the oil pumps. Our tour was put on hold while repairs were made. After the pump was fixed, the turbine was spun up, generator synchronized with the grid and control of the power plant handed back to the remote operations center in Ljubljana.

Modern hydraulic turbine speed governor.

This is one of the modern hydraulic turbine speed governors that are currently in use in the power plant.

All aspects of the power plant are remotely monitored using a SCADA system. Status of every temperature sensor and pump can be accessed from a central control room. Apart from electrical parameters they also measure and record structural status of the dam and its surroundings. They have automatic strain gauges and a grid of reference points where geometers regularly check for any unexpected earth movements.

In theory the plant could be operated entirely by remote control, but we were told that the company will continue to keep the site staffed round-the-clock. Problems can be detected and solved faster and cheaper if experienced engineers are around. Otherwise a maintenance team would have to be dispatched from somewhere else, which could lead to more downtime or a small problem growing into a more expensive one.

HE Moste, generator 4

In conclusion, I would like to thank the friendly staff of HE Moste for taking the time for us in a busy day and Mr. Pirjevec for guiding us on this tour. We were shown every nook and cranny of the power plant and he gave us a thorough description of the machinery and answered every question we had.

It was a pleasant and informative way to spend a morning and a welcome step away from all the low-power electronics I deal with each day.

Posted by Tomaž | Categories: Life | Comments »

vesna-drivers git visualization

16.06.2014 17:41

Further in the context of two years in development of firmware for VESNA sensor nodes in Logatec, here's another view on the firmware. I used git-big-picture to graph the branching and merging of the source code.

We use a private GitHub repository to collaborate on the code. At the time of writing, it had 16 forks and 7 contributors to the master branch. Before that we used Subversion, but switched to git soon after I joined the team.

vesna-drivers repository branching visualization

Red are commits pointed to by tags, blue are branch heads and white are merge and bifurcation commits. Other uninteresting commits are not shown - zero or more intermediary commits are implied by graph edges. Time, or rather entropy, roughly increases from left to right.

Below is a detail from that picture. If you're curious, you can also download the complete graph as a rather large PDF (most branch names and tags have been redacted though).

vesna-drivers repository branching visualization, detail

At the first glance, this looks pretty chaotic. Definitely our academic environment is a bit less strict regarding the code structure than what you might see in a production project. That's not necessarily a bad thing. Many people here are researchers first and software developers second. For many, this has been their first encounter with source version control.

On the other hand, the whole point of this repository is that work can be shared. Pieces that have been useful in one project are often useful again in another. Searching 16 repositories and countless branches for a driver you might reuse isn't very fun. So some kind of structure is a must.

It's hard to get this balance right tough. On one hand you don't want to be too strict when accepting code to the git master, since then you have less code to share. Often it's even impossible for the reviewer to run-test the code since he might not have the hardware necessary. On the other hand, merging code that will be a maintenance hell later on is counter productive as well. There's no use trying to share code that will cost people more time to debug it than it would to rewrite it from scratch.

We're currently trying to go with a system of GitHub pull requests and a Wiki page that lists all the projects in private branches and I think setting up automated builds was worth the effort. But I guess after two years we're still trying to find the sweet spot.

Posted by Tomaž | Categories: Code | Comments »

Evolution of VESNA firmware size

11.06.2014 21:23

Yesterday I got an idea to plot how the size of the firmware images for VESNA sensor nodes evolved over time. Thanks to my diligent tagging of releases in git and making sure binaries can be built with a single make, all it took was a short bash script to come up with this:

Size of binary firmware image over time.

Only now do I realize that we've been polishing this code base for two years now.

When we originally started working on firmware that would run on spectrum sensing nodes in the Logatec testbed, a decision was made to develop everything from scratch and not go with an existing operating system like Contiki. The rationale was that we don't need all of its facilities and making something from scratch will be simpler than learning and building on existing work.

As it usually happens in such cases, over time we basically developed our own, small operating system. Given all the invested time, it is now hard to make a break from it, even when we have applications that would benefit from a standard platform like Contiki.

Looking at the graph, I'm actually surprised that the size of the firmware didn't increase more than it has. Keep in mind that these binary images are uploaded over a flaky ZigBit network where the best throughput is in the hundreds-of-bytes-per-second range. From the upload times to 50 nodes it certainly felt like it has increased a lot.

I didn't look into what features caused the most size increase. I'm pretty sure the recent large jump between versions 2.40 and 2.42 was because of a new SPI and microSD card driver. Also, one of the size decreases early on was after we added -ffunction-sections and -fdata-sections options to the GCC.

Posted by Tomaž | Categories: Code | Comments »

Testing VESNA's power supply

08.06.2014 18:22

Now that I have Re:load, I seem to end up checking every power supply that lands on my desk if it meets its specifications. I put VESNA's to the test yesterday.

VESNA core board has a switching power supply that supplies around 5V and 3.3V to any expansion boards connected to it. The source can be a battery, solar cell, USB cable or a DC voltage from some external supply. I tested it with a 12V external supply, which is the most common case when you power a node from the grid using a wall wart or something like that.

Testing VESNA SNC source current capabilities on expansion connector.

VCC pin on the expansion connector supplies 3.3V. This line also powers VESNA's main ARM CPU. Datasheet says it can supply at most 500 mA to the expansion board and this is approximately what I've also seen in my test. With a setting on Re:load higher than 500 mA, the voltage fell sharply to around 2 V where Re:load wasn't acting as a current source anymore.

I've measured the voltage using my oscilloscope, so the resolution on the vertical axis isn't as good as it could be. Still, I think 40 mΩ is a fair estimate of the internal resistance for VCC.

VCC voltage versus output current.

Voltage on the VPP pin is typically around 4.5 V. This pin is also supposed to supply a maximum of 500 mA to the expansion board. In my test it managed just a little bit below that, but considering the accuracy of my measurements that's within the margin of error.

VPP voltage versus output current.

I also checked the ripple on both VCC and VPP pins. With low loads the power supply seems to operate in discontinuous mode and the ripple is a bit high at 100 mV peak-to-peak. With higher loads, it goes into continuous mode and the peak-to-peak voltage falls. This is how it looks like on the VPP pin with near maximum load:

VPP voltage ripple when under load.

So, I'm happy to say that everything looks here as it should. The ripple is a bit high for my taste, especially when powering analog electronics.

Part of why I tested this is because my new UHF receiver will put a higher load on this power supply than other expansions I've worked with on VESNA. With around 350 mA of load my board puts on the VPP line, it looks like VESNA will be able to power it without problems. It won't be able to power two receivers at once however and some auxiliary power supply will be necessary for that.

Posted by Tomaž | Categories: Analog | Comments »

On ICT Seminars at IPS

05.06.2014 1:04

Today was the last day of seminars on Information and Communication Technologies for this year at the Jožef Stefan International Postgraduate School. I believe I managed to attend 77.7% of the 18 talks given by other PhD students and gave one short presentation on spectrum sensing. That should bring me above the mandatory attendance with a sufficient margin of error.

With a few exceptions, most of these talks were wrist-cuttingly boring. Considering that the final conclusion was that this year's presentations were better than usual I dread to think what previous years had to endure.

It was suggested to me that I might not understand all the finer nuances of the pedagogic process. However I still believe that if students are giving these talks to learn how to a present their research topic, more realistic feedback on their performance might be helpful. So here is mine.

I think two mistakes were prevalent:

First was gross mismatch between audience and the basic knowledge required to follow presentations. ICT field of study at this school is so broad that you will have someone parsing tweets about celebrities on one side of the classroom, someone working on protein databases in the center and someone doing motor bearing fault prediction on the other side. As an electronics engineer I had the misfortune of acquainting myself with sentiment analysis before. Still it doesn't make sense to talk to me about Segmented Discourse Representation Theory if you can't introduce it in a way that someone who has not been studying it for the past 6 months can understand.

Personally, I like best the format where presentation is roughly split into three parts: the first one can be followed by anyone with an elementary education, second one by someone familiar with the field and third one by your supervisor and colleagues from your research group. I find that I can follow such presentations with interest even when topic is completely outside of my specialties.

I realize that with the suggested 15 - 30 minute length of these ICT seminars this might not be possible. But I think it's better to drop the last third than the first. Your supervisor already knows what you are doing and will skip the talk anyway. Others can read your paper.

"Because Magic" by Egophiliac

"Because Magic" by Egophiliac

And that brings me to the other problem I noticed. I know that it is the de facto standard that academic slides are walls of text and are expected to stand alone relatively well without the accompanying speech (as much as I like LaTeX, Beamer was a terrible invention). I also know I enjoy every talk that breaks this mold. Don't recite a table of contents of your talk at the beginning. Make slides colorful - you're not paying Springer's color print fees here. Explain the topic using examples, plots, photographs. Don't fill up slides with 10 pt text that I can't even read from the back row. Use slide notes if the slide deck must be usable as a stand-alone publication (by the way, it doesn't in these seminars - the school doesn't even publish slides on the web).

Presentations in an academic setting certainly must be on a much higher level than your usual marketing pitch with stock photos, cute kittens and a stevejobsian act, but that doesn't mean they must make me sorry I didn't rather spend the afternoon debugging some PHP code.


In conclusion, I think everyone would be better off if these seminars would be given a bit more exposure. Obviously there is a lot of interesting research being done in the offices at our Institute. But as long as presenting it is viewed strictly as a formality and there is no push towards teaching people how to talk about their work in an understandable way, it will stay behind those closed lab doors. Presenting scientific discoveries to the public can be done by postgraduate students at informal seminars as well as by big-name professors with 3-hour extravaganzas in the large auditorium.

Maybe if that would be the case, the school wouldn't need mandatory attendance and enforce one (1) mandatory insightful question per student after the talk to give an impression of an academic debate. We might even get some of that much-sought-after cooperation between departments.

Posted by Tomaž | Categories: Ideas | Comments »