GSoC

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

What to do as a student

You want to help us make sigrok even better? Great! This is what we recommend:

• Check the GSoC ideas below
• Think of/choose a project that ideally benefits you and us alike
• Hang out on IRC with us and say hi (#sigrok@freenode)
• Familiarize yourself with the code base and ask questions about it
• Apply to GSoC! :)

We'll gladly help you with refining your proposal or application, so communication is key. If we don't know you, we can't assist you.

For us, a strong application contains the following information:

• Who are you? Where are you? What are you studying?
• Have you used sigrok before?
• What do you intend to work on / NOT intend to work on?
• What motivates you to work on sigrok?
• How familiar are you with the language you will have to write code in? Is there proof?
• Did you have a look at the code you'll need to modify? What was your impression?
• How many hours per week are you going to dedicate to the GSoC project?
• Are you aware that mentors will be several time zones away and won't be able to answer all your questions as soon as they arise?

Before you apply, we'd like you to know that we will give feedback on your progress once a week. Also, we assume that you're self-sufficient most of the time but that you're not shy asking questions when you're stuck or need to make a decision you're unsure about. Our IRC channel is full of people who like to help, so hanging out there is beneficial to you as much as it's beneficial to us.

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,C++,python) PV should offer a tabular display of decoded data packets. However, the information currently provided by libsigrokdecode is too limited to allow for a user-friendly display. In this project, you would allow decoders to submit relational data about different so-called annotations, so that PV can use the data to figure out which annotations belong to a single logical data packet (think header-data-checksum). Then, you'd work on the existing tabular decode window in PV to make it more feature-complete and user-friendly, as much as time allows.

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
• (easy)(none) Update and complete the on- and offline documentation for sigrok-cli, sigrok-meter and PulseView, esp. the Getting started pages

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 doing the GSoC project 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, completing the project may be difficult. If you're stuck with something, we'll of course try to help you, though.

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 be 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 implementations are 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 haven't written a program with more than 300 lines before. Is that a problem?

A: Yes. Talk it over with us, chances are we'll work something out. What we really need is evidence that you will be successful in your chosen project goals. 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 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

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.