Home
TechEdSat is a 1U CubeSat that will be launched on 21 July 2012 from Tanegashima, Japan aboard the HTV-3 ISS resupply mission. TechEdSat will be among the first CubeSats to be deployed from the ISS, and is investigating the use of Plug and Play software/hardware and intersatellite communication via Iridium and Orbcomm networks.
For this challenge, space hackers must implement a command and control system, utilizing both the OrbComm and Iridium modems as uplink and downlink. The software should be modular to facilitate the easy implementation of future commands, and should be fault tolerant.
A ground segment of the software should include the ability for a laptop (or bonus points for an Apple or Android phone) to issue commands to the spacecraft over Iridium/Orbcomm. The spacecraft segment should be written for a Linux environment able to listen for commands, and have the ability to send arbitrary data packages back to the ground.
Bonus points for relaying data received from the spacecraft automatically to Twitter.
Space hackers will be issued interface documentation for Iridium and OrbComm modems, and engineering development hardware for testing. This software has the potential to fly on the TechEdSat mission if completed.
ANNOUNCEMENT AREA:
Next group thing will be xx. (Looking for this sort of thing, or next team meeting)
Relevant links and reminder of tags
- Recorded video
- Interviews with people
- Formal talks
- Explanations and tutorials from team
- spaceapps_sanfrancisco :
- spaceapps_lausanne: http://piratepad.net/Gqpg6lqRBA
The project is based upon four components:
- packet generator: As we cannot access real satellite intercomm and the software build at EPFL, we had to write a packet generator to create TC / TD packets, TC-Transfer segments and frames, introduce some noise and error. The generator creates packets, transforms them into segments and frames and creates noise on the frames. The (partly corrupted) frames are then read by the real library for handling frames. The library itself will then reconstruct frames to segments and segments to packets in the process. The resulting packets are put into a database. (This is about the libcubesat)
- Database-Adapter: A tool to receive packets and puts them into the database.
- API-Layer: A program exposing a bunch of methods to serve data from the database to client-applications. Maybe this will be some kind of RESTful service offered to client-apps
- A client-app to actually access and interact with data collected from the satellite (and, maybe later on) issue commands to the satellite.
- SwissCube communication docs: http://ctsgepc7.epfl.ch/07%20-%20Telecommunications/
- Swisscube ground segment docs: http://ctsgepc7.epfl.ch/08%20-%20Ground%20segment/
- Docs for packet formats: https://www.google.ch/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCgQFjAA&url=http%3A%2F%2Fgtb.iasfbo.inaf.it%2Fpublic%2Fgtb_manuals%2FECSS-E-70-41A(30Jan2003).pdf&ei=Z8GST5KgB4iEOq2Y7IQE&usg=AFQjCNF3VC7IeLDGIQ89tZHWhgFEr2VO9g&sig2=n6NNYHPj02HoNdo_IYBVPA
- Telecommand-Packet-Format: http://public.ccsds.org/publications/archive/203x0b2s.pdf Packets in our application (and in the specs) are little-endian
Group working on open source cube sat at https://github.com/LiftportGroup/LiftPort/wiki/Open-Source-Cube-Sat
Remarks: We think the underlying protocol, AX.25, is pretty well-known, so we do not tackle this, we're starting at the Packetization-Layer described in CCSDS 203.0-B-2 and ECSS-E-70-41A. In our scenario, we're skipping out the SourceID and spare-padding fields (described in ECSS-E-70-41A Section 5.3.3) and set "implicitely known for the mission" lengths of fields to 8 bit. Details - the packet generator uses the libcubesat
- Database adapter
Entities:
- Available spacecrafts
- Available data categories per spacecraft / range classification
- Package header and package data as raw
- API-Layer
We started to implement some pretty simple mocking Node.JS app, needs to be reconstructed entirely as soon package formats an UI use cases are well defined.
methods:
-
GET: /available_spacecrafts returns a list of available spacecrafts, along with the information on which classes of data are available
-
GET: /available_categories returns a list of general available categories of data
-
GET: /lastsignal/:spacecraftid returns the last received packges of a specific spacecraft along with the packages headers
params: :spacecraftid - string - The ID of the spacecraft
-
GET: /getlatestdata/:spacecraftid/:category returns the package headers for a specific spacecraft and category of data params: :spacecraftid - string - The ID of the spacecraft params: :category - string - The ID of the data class category
-
GET: /getpackage/:packages returns the packages defined by the parameter packages (JSON array) params: :packages JSON array, listing the IDs of packages
-
GET: /latestpackages returns the most recent received packages
- Client-App
DOWNLOAD A FREE DEMO HERE: (http://www.silverthorax.com)
Screenshots:
