GSoC

This page is about the Google Summer of Code and how sigrok may be able to benefit from taking part in it.

Administrative stuff

For GSoC 2016, sigrok needs to apply between Feb 8th and Feb 19th, 2016.

According to the FAQ, several roles have to be filled by project staff:

• Two organization admins who are google's main point of contact (abraxa, uwe)
• A person or group to review student applications (abraxa, uwe, biot?, jhol?)
• A mentor for each student (abraxa, anyone else?)
• A backup for each mentor (uwe, biot?)

There's also a Mentors Guide that's worth checking out.

Here is our page containing our organization application material.

Project ideas

The following list of ideas contains projects that we think can be managed in the short period of GSoC (3 months) and they cover topics where the sigrok project is wishing to improve. However, these are not the only things that could be done: it's worth checking the to-do list, for example. Or maybe you have a great idea that we just didn't think of yet. Also, if you intend to apply for sigrok, please talk to us on IRC before applying so we can establish a clear and manageable goal to work towards. Don't be shy to ask!

The format is:

• (difficulty)(languages used) description of task that can be completed in 12 weeks

High priority:

• (medium)(C++) Recent developments have forced us to rethink our libsigrok code base. We decided on a flowgraph-based approach in C++ for a libsigrok rewrite. You could help us speed up the process by implementing the framework, basic I/O blocks, driver I/O blocks, transformation blocks (think A->D, D->A and such) and whatever else you can think of. This one is very important to us as future developments and lots of features strongly depend on this infrastructure.
• (easy)(C) Currently, libsigrok uses a single thread per session which leads to problems when drivers stall during transfers and timeouts. We need to have device threads that can run independently of the session thread.
• (medium)(C) Currently, lots of drivers are very similar but differ in details. We could use a "generic" driver model that for example provides a framework for SCPI-based scope interfaces. That way, a driver would only need to provide configuration data and callbacks for the framework. Currently, every driver duplicates said framework internally.
• (easy/medium)(C++) Implement some of the features that PulseView needs in order to be a professional tool: better analog support (e.g. filtering, FFT), a global signal overview, a tabular decoder data view (ideally with export), provide libsigrok output in a message window, etc.
• (easy)(C++) Implement a "pseudo oscilloscope" mode in PulseView so that people can use it to operate their scopes the way they normally would.
• (medium)(C++) PV currently only supports a single data view. However, we need a tabbed GUI with one viewport each, much like a web browser.

Normal priority:

• (medium)(C++) Implement auto-measurements on mouseover, similar to what saleae logic does. (screenshot,implementation details)
• (hard)(8051 asm,C,maybe C++) Add support for analog in/out support in fx2lafw, libsigrok and possibly also PulseView (think of analog capture and replay). Alternatively, you can also start on this by first implementing a fx2lafw-based signal generator that can later be expanded by the capture/replay feature if there's time.
• (medium)(C) Implement the improved configuration enumeration and adapt the drivers to use it
• (medium)(C++) Expand on the PulseView unit tests to increase coverage and allow them to actually reveal bugs.
• (easy)(C++) Work on PulseView in the context of android devices, i.e. improve compatibility and usability.
• (medium/hard)(C++) Figure out a way to perform automated GUI tests of PulseView under Windows (and linux) that can be included in Jenkins. That way we wouldn't rely on Windows users as much to tell us when things break there.
• (unknown)(C) Come up with a sensible method of interfacing libsigrok with GNU Radio so that digitally transmitted data can be examined using libsigrok
• (easy)(C) Enabling sigrok-cli to be an automation tool: e.g. reading one value from a file (could be a voltage), setting it on device A, reading a value from device B and writing it into a file

Potential mentors

While there are lots of people actively working on the sigrok suite, many of us have a full-time job and limited spare time. That's why we want to start small by appointing one or two mentors for now. Abraxa has volunteered already, maybe someone else will join in.