Upadate on the powquty project
please allow me to update you on the progress if the powquty Project within Google Summer of Code 2016 at Freifunk.
As mentioned in my last blog the goal of the project is to create a LEDE package which ensures three functionalities:
- Retrieving sampled voltage data from the power quality measurement device via USB
- Calculating statistical power quality parameters (such as: avg. voltage, harmonics, ect.) form the retrieved voltage samples
- Provisioning of the calculated parameters for retrieval and graphical representation
Herein I will give a short update about the progress of these functionalities.
For this project we are using an off-the-shelf USB-based oscilloscope “WeSense” from the company A.Eberle. The oscilloscope provides real time samples of measured voltage from the power plug via USB bus, using a binary protocol and a sample frequency up to 10kHz. Initially the oscilloscopes USB bus supported the host functionality only. Hencethe router would need to act in USB device mode, which is a rather unusual mode to be supported by todays WiFi router platforms. To overcome this limitation, aforementioned company agreed to provide us with another hardware implementation that implements the USB device functionality with optional five volts power feeding functionality. The new hardware is expected on my desk in mid July.
As a counter measure for this delay, we started implementing an emulator, that locally generates a signal-samples, which are then organised in packets as similar to the binary protocol.
Regarding the calculation of the power quality parameters functionality, we successfully ported the power quality library (in Ansi C) from A.Eberle to compile and run under Linux LEDE. The libraries functionality allows to calculate the frequency, effective voltage, harmonics, and phase shift, from the signal samples in an efficient way. We provide this library as binary blob, since it is basically not open sourced (yet), and originated from the manufacturer himself. Now it is ported for LEDE, and can be used for our purposes.
For the provisioning of the calculated parameters, we intend to implement a luci app that shows the calculated parameters.
The rest of the project timeline is depicted below:
Working phase: June 20th – July 10th
- Finalize the emulator
- Integration with the power quality library.
- first prototype of the provisioning functionality
Working phase: July 11th – July 24th
- Finalize the provisioning functionality
- prototype implementation of sample retrieval (given that the hardware is delivered)
Working phase: July 25th – August 7th
- Integration of the three functionalities into a working implementation
- Software Testing and bug fixing
- Documentation of the integrated functionalities
Working phase: August 8th – August 21st
- Buffer for possible delays
More updates in the upcoming weeks.
Implementing Pop-Routing - Midterm Updates
Today has started the midterm evaluation, the deadline Is next Monday, so I have to show the work I have done ‘till now. It can be resumed in the following parts:
1) Refactoring of graph-parser and C Bindings
During the community bonding period I started working on the code of Quynh Nguyen’s M.Sc. Thesis. She wrote a C++ program capable of calculating the BC of every node of a topology . I re-factored the code, and now it is a C/C++ shared Library . I’ve also applied some OOP principles (Single responsibility and inheritance) and unit tests to make it more maintainable.
The interface of the library Is well defined and it can be re-used to implement another library to perform the same tasks (parsing the json and calculating the BC).
2)Prince Basic functionalities
After I completed the library a started working on the main part of the project. the daemon. We decided to call it Prince in memory of the Popstar.
This daemon connect to the routing protocol using the specific plugin (see below), calculate the BC using graph-parser, computes the timers and then it push them back using again the specific plugin. With this architecture it can be used with any routing protocol.I wrote the specific plugin for OONF and OLSRd. At the moment it has been tested with both, but I need to write a plugin for OLSRd to change the timers at runtime. For OONF I used the RemoteControl Plugin.
With these feature Prince is capable of pulling the topology, calculate the BC and Timers and push them back to the routing protocol daemon.
3) Additional Features: Configuration file, Dynamic plugins,
I wrote a very simple reader for a configuration file. Using the configuration file the user can specify: routing protocol host and port, routing protocol (olsr/oonf), heuristic, (un)weighted graphs.
As you can see from this Issue , I’m going to use INI instead of this home-made format.
As I said before I moved to a specific plugin all the protocol specific methods (pulling the topology and pushing the timers), to keep the daemon light I decided to load this plugin dynamically at runtime. So if you specify “olsr” in the configuration file just the OLSRd specific plugin will be loaded.
At the moment I consider this an “alpha” version of Prince. In the next 2 months I’ll be working on it to make it stable and well tested. The next steps will be:
- Write tests and documentation for Prince.
: https://github.com/gabri94/poprouting/issues >> weiterlesen
Sharable Plugin System for qaul.net - Midterm Updates
As we are on the midterm evaluation process, I would like to share what I have done so far. I created a small HTML5 application to share the location of a user, it uses geolocation API for this purpose. This will work online but, if we are offline it will work only if the device had a browser which communicated directly with the GPS hardware. This is how the application looks like when the location is found out:
Anu >> weiterlesen