GSoC

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

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

FAQ for students

Q: How much time per week will I need to put in for sigrok?

A: We want you to treat it like a full time job. We have some flexibility, in that it is results rather than time that matters, but for sigrok don't plan to be doing a full time job or writing up your thesis and GSoC in your spare time.

Q: What level of technical expertise is required to participate in GSoC?

A: The level that could reasonably be expected of better than average computer science degree students after their first year. Realistically, given that GSoC is competitive, we'd regard the minimum programming skill to be such that at least one programming project of 300+ lines should have been completed as part of coursework. Applicants should mention at least one significant program they have completed on their application. If you don't enjoy writing and debugging programs, don't apply.

Q: Am I good enough for GSoC?

A: Convince us that you are! If you give us evidence that you've compiled libsigrok/PulseView and then made some modification, you're ahead of most people.

Q: I don't know Qt but want to work on PulseView. Is that a problem?

A: Depends. If your work is focusing on the inner workings (e.g. interfacing to something you wrote in libsigrok) then you'll be fine. Everything else requires you to at least know (or willing to learn!) about signals/slots, event-driven design and of course the Qt API. The Qt API itself is documented quite well, you can find the entry page for Qt 4.8 here, for example.

Q: I want to tackle this particular problem from your ideas list. Is it too hard for me? Is it even possible?

A: Only you can tell if its too hard for you. We believe the basic idea is perfectly achievable by an advanced student. Talk it through with us, and spend time understanding the problem. Figure out what needs to be done to complete the task and ask yourself if you can do all of it. When in doubt, use a lesser goal and add optional "if time permits" goals. Keep in mind that you should give us some kind of proof that you can complete the task you claim you will complete. We don't know you and we can only choose very few students, so we want to make sure that everyone benefits.

Q: I've not written a program with more than 300+ lines before. Is that a problem?

A: Yes. Talk it over with us. There may be a way forward all the same. What we really need is evidence that you will be successful in your project. If you're relatively inexperienced it's a rather bad idea to leave contacting us to the last possible moment.

Q: I've posted an application using the GSoC Student Web app, and I'm being asked to clarify what features I'm committing to and what features are optional 'if time permits'. What does it mean to commit to a feature? Does it mean I'll fail if I don't deliver a feature I commit to?

A: At the application stage we need clarity about what you expect to achieve. What you commit to is what we expect to see, and the committed to outcomes need to interest us. If we fail a student who committed to a feature and then didn't deliver, it would usually be because they'd also claimed skills/experience they didn't actually have, not communicated regularly, or otherwise not kept in touch with us throughout their project. We pretty much don't expect the 'if time permits' features to be done, as everyone underestimates how much work is involved in programming. In discussing the proposal we might ask that an 'if time permits' feature be made central and a planned feature we're less interested in be demoted.

Further reading

here you can find a great write-up that explains how to make your application structured and complete.

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.