Graphical User Interface – the FUNcube Dashboard

The Graphical User Interface (GUI) is the software which will be available to anyone interested (including schools and individuals) which will run on a Windows  computer, and allow the user to do things like display the telemetry.  It will take data from the FUNcube dongle while it is receiving live signals from the satellite and, if so configured, relay any received telemetry to the Data Warehouse via the Internet. In this way we can build up a store of telemetry from all over the world, hopefully!

We have already developed and enginnering version of the FUNcube Dashboard but what is required now is to create some versions suitable for childrens of different age groups. We will be making the core  software generally available under a Creative Commons licence before launch so potential collaborators are encouraged to contact us for more information

Full details of the proposed specification are below (much is yet to be decided, and your comments are welcome). Please note that it is in DRAFT form at present, and subject to change.

FUNcube_GUI Specification_drafta_0510_ver3.pdf

7 Responses to “Graphical User Interface – the FUNcube Dashboard”

  1. gbulmer Says:

    I’v had a look at the FUNcube_GUI Specification_drafta_0510_ver3.pdf

    I found it quite rich on features, but I could not see where the requirement came from.

    For example in the section marked purpose, it describes:
    “The GUI will need to be capable of storing information about the “station” or school receiving (eg Name, callsign if one available, Long, Lat, Height, etc) and registering this data with a central data repository. The system should allocate a unique user name to each instance of register client software, and also require the provision of an email address.”
    But when I put myelf into the position of user, or teacher, it doesn’t tell me what this does for me, and what I am doing that needs this.

    May I suggest taking one step back, and writing some ‘Use Cases’ or Stories to give the specification some context?

    A ‘Use Case’ or story is based on the idea of describing how the thing will be used, rather than how to implement it. A ‘Use Case’ usuall starts off by explaining who the user is, and the context in which it might be used, then it focuses on what they are trying to do.

    I am sure a whole bunch of members can help develop some Use Cases or stories.

    Armed with something describing how it is intended to be used, I think it will be easier to connect with education professionals, and discuss how FUNcube relates to the curiculum, and how it will fit within teaching.


  2. g3wgm Says:

    OK, I’ll try!

    Use Case1: Teacher in playground, surrounded by clamouring kids. Teacher has laptop, FC Dongle and suitable antenna. He knows roughly when FC will appear over the horizon. He hears the signal, and the GUI starts to display the tlm channels in a way that the teacher can explain to the kids what’s going on. When the pass is over, kids plus teacher return to the classroom, and teacher sets them a task of plotting a graph of, say solar panel voltage vs time, and asks them what’s happening. Answer, the sat is spinning. Supplementary question, How fast? Will it be the same tomorrow, next year, etc

    Use Case Two: Satellite owner/ ground station control in UK FRANTIC to know what’s happening on the satellite as the battery voltage has been a bit low recently. Nail biting for the next pass, but remembers that within the GUI was the facility for other listeners to upload data via the internet to a central repository. He accesses the repository, and finds that someone in Australia has just listened to a pass (and uploaded the data to the respository), so he can now look at that data, and determine what the battery voltage is. He also knows exactly where the data came from, because part of the data transmitted to the central repository contains things like lat long of the listener, which could be a school, radio ham, etc. As the repository holds the registration data of the listening station, the sat controller, as admin on the repository, is able to determine the listeners email address, and send them a thank you message.

    Use Case 3. Same senario as Use Case1. But this time in the playground the teacher fails to download any tlm as there is very strong interference that day. Teacher returns with disappointed kids to the classroom, but remembers that there is data available via the internet from the repository. When he searches in the GUI for the most recently uploaded data he finds that another school in the UK was also listening to the same pass, and he is able to say to the kids, “Its OK, because I have a copy of the data from XYZ school in BlankTown who were listening at the same time as us”. Of course they might have been listening last week, and if the teacher is a good one, he might take the trouble to download some data before he goes into the playground, just in case . . .

    Does this help?

    Any more user cases anyone !! ??

    73s Jim G3WGM

  3. gbulmer Says:

    Jim – That is a *very* helpful start. Thank you.

    In response to “Any more use cases !!??”

    Yes their must be. It isn’t possible for some of these Use Cases to work.
    No Use Case mentioned any user registering enough information with a repository to know where they are. No Use Case has a user uploading data to a repository. Also, no Use Case has a user create a data repository, and make it available over the internet (maybe two Use Cases).

    Also, I think Use Case 3 may contains a 4th Use Case which might be picked out as separate, which looks different from 2. Use Case 3 says download some data just in case (things go wrong). What would the criteria be for choosing the repository subset for that download? Is it automatically chosen for them, or do they have a selection of options? Is it likely in the early days that there is no meaningful data to download?

    When the ground station is used outside in the playground, and hence I assume is less likely to have an Internet connection, does it “automatically” record received data? Is their a Use Case where previous data can be purged (as the disk has become full), or is it thrown away automatically somehow?

    It isn’t essential to get all the Use Cases initially, but the Use Cases define the scope of the system, so the main ones need to be there. Also some will need more detail, so that their is a clearer definition of what the system needs to be able to do for the users.

    Other likely Use Cases are things like:
    – Secure the repository against disk or machine failure, i.e. do some form of backup or replication of the repository and user data (if that is outside the repository),
    – Recover from system failure,
    – Recover from ground station failure
    – Maybe recognise an internet attack, and disable some facilities of the repository?
    – Maybe remove a user or ground station from access to the repository for whatever reason?

    A fairy important one for the end users would be “Receive the FUNcube ground station, assemble and test it”. This might be quite complex, and actually be several Use Cases where “test it” is something a user might want to do before or during e.g. Use Case 3.

    It may be part of the goal of the system is for school children to use the system directly, I can’t tell; but if it is, there may be a Use Case where new users to an existing ground station are introduced.
    It may be part of the goal of the system for school children to directly download a subset of the repository to their local PC, for example in Use Case 3, the children retrieve the data rather than sit and watch the teacher.

    Ue Cases about administration are often the last ones to be considered, I’ve mentioned some, but their may be further Use Cases to:
    – support a user needing to recover their security credentials, i.e. password. This one might be quite subtle if you want to make it easy to administer, easy to use, but relatively secure from a simple password cracking attack.
    – Install the repository software on one or more Internet accessible servers, and test it
    – If part of the repository fails, say a server goes down, what happens? Is their a Use Case to alert an administrator to come fix it?
    – Release a new version of the repository software, and migrate users and data to it
    – Release a new version of the Ground Station software, i.e. make it available, maybe from a server on the www, and inform Ground Stations that it is available
    – Install the new version of the Ground Station software
    – Maybe revert to a previous version of the system?

    Maybe some of the Use Cases are not implemented in software, but rely on skilled people ‘doing the right thing’, but it is handy to know that 🙂

    Throughout those Use Cases which involve any aspect of children’s identity, their needs to be some thought put into ensuring their identity is properly protected. I’d suggest retaining as little information as feasible.

    Can the system be used without an Internet connection being available at any point? This might have a significant impact on ‘administration’ Use Cases.

    Anyway, I think you get the idea.

    Armed with a good set of Use Cases, it should be easier to define the specification for the “Ground Station Software”.

    I hope this helps

  4. g3wgm Says:

    Oh yes, I’m not suggesting that there are not (lots) of other use cases, but please dont ask me to write them all! But I do think that its a good way to explain what we are trying to do. I think the admin ones you mention (repository back up, etc) could be of lower priority, as they are pretty ‘specialised’, and to a certain extent obvious to the people running/writing it.
    The repository (or warehouse in FC-speak) is a single instance, which is currently being developed by Dave, G4DPZ, and yes, before you can use it, it will be necessary to register a few details, eg location, username, etc.
    Yes, of course, it is possible for school children (call them students) to use the ground station directly, if they wish/have the expertise, and/or up/download to the warehouse.
    And yes, it SHOULD say in the GUI spec that it CAN be used without an internet connection. (We’ve had that discussion already elsewhere!)
    73 Jim G3WGM

  5. gbulmer Says:

    “But I do think that its a good way to explain what we are trying to do.”
    I agree. It is a document which can be used as a basis for discussion with end users. GUI’s can be ‘mocked up’ from it, and usability tested, etc.

    “I think the admin ones you mention (repository back up, etc) could be of lower priority, as they are pretty ‘specialised’, and to a certain extent obvious to the people running/writing it.”

    I feel it is a mistake ASSuME that at this stage 🙂
    a) if someone becomes ill, it might be a disaster if there is no written down process to satisfy a key Use case
    b) by writing the Use Case, and saying it is by an experienced person who knows what to do, there is a comfort that less functionality will be forgotten.
    c) I have seen assumptions about backup and recovery have huge impact on availability, security, etc. so it is good to get them shared and understood
    d) If there is any sensitive child-related data, then the administrators may have to undergo CRB checks, or something, and the handling and location of backups may need extra consideration.

    “Yes, of course, it is possible for school children (call them students) to use the ground station directly, if they wish/have the expertise, and/or up/download to the warehouse.”
    Okay, so are their likely to be any Use Case which the teacher may be able to use, which the students can’t use? If there are, then there is more than one type of end user, and that can have significant impact on software design and functionality. I am NOT suggesting this is the case; I’m trying to raise a further dimension of consideration to capturing requirements before deciding how to satisfy them

    According to the spec. and Use Case 2. the repository holds the email address for users. Do you know if there are any restrictions which schools, or parents, might apply which would render that impractical? I know my school tends to be very careful about students putting contact information out on the internet, and parents write to the school asking their child to be protected from some activities. For example, some parents might not allow their children to appear in photographs which may be displayed in a public school area.

    “And yes, it SHOULD say in the GUI spec that it CAN be used without an internet connection.”
    It may say that in the GUI spec., but it would say it because one or more Use cases demand it. For me, the Use Cases are a requirements statement. I read the GUI spec as a functional specification.

    I am not saying any of this is hard, just that it takes time, effort, and it is better to capture the need so that we ASSuME less 🙂

  6. gbulmer Says:

    Question/Suggestion: has FUNcube got a wiki, or something very similar, which could be used to capture and publish documentation directly, rather than buried in pdf’s or doc’s?

    It isn’t essential to have a wiki, but it might allow folks to participate when they have a spare 5 minutes available to read and improve a little part of FUNcube.

  7. g3wgm Says:

    Ni WiKI at present, but thats not to say we shouldnt/cant have one

Comments are closed.

%d bloggers like this: