Main Page

Welcome to Experimental Cosmic-Ray and Diamagnetic Scientific Satellite, or ECOSat! (Enhanced Communication Satellite for ECoSat-III)

All too often, people approaching a university club (particularly those in first and second year) have a particular mindset. This mindset exists somewhere in the vicinity of “Oh boy! A club! I wonder what sort of fun activities the grown-ups have planned for us?”. Inevitably, this attitude is quickly replaced with disillusionment and horror when the only such activity planned involves trading a barrage of acronyms and impenetrable jargon relating to the difficulties of sending a scientific experiment into space. But fear not, my wide eyed and ambitious though somewhat naive friend, for we at ECOSat have recognized this problem and value your interest. This page has been written to slowly ease you into this scalding hot tub of knowledge with minimal scarring. And, if you play your cards right, you might even end up with more to put on your resume than “listened to a bunch of jerks pretend to be smart for an hour every week, also space”.

The remainder of this article will focus on clarifying as many of the commonly referenced ideas and objects as possible, as well as give a starting point for those interested in hardware-level software development with regards to our project.

The Competition

The rules and requirements for the CSDC (Canadian Satellite Design Challenge) can be found at www.csdcms.ca]

Subsystems

The satellite can be separated into a number of main subsystems, below is a list of the main systems and a few topics you may hear people talking about. When designing systems take a look at the process we try and follow at process.

  1. On Board Computer (Called Command and Data Handling and combined with the Communications system in some satellite designs)(OBC)
  2. Communications (Comms.)
  3. Power
  4. Attitude Control and Determination (ADCS)
  5. Payload

ecosat_systems.jpeg

OBC

The On Board Computer or OBC performs a role in several subsystems. The OBC board itself is a TMS570 microcontroller unit (MCU). Most of the OBC board's computing resources are devoted to performing the algorithm that estimates the satellite's orientation (attitude) and generating control commands. The OBC computes a kind of process called a Kalman Filter; this algorithm takes in data from the three OBC peripherals shown in the diagram, as well as data collected from the solar panels by the power subsystem. The generated commands are sent to the ACS board (shown in purple) over the central bold black connection (i.e. CAN bus, to which all five primary subsystem MCUs are connected).

ADCS

The Attitude Determination and Control System or ADCS allows the satellite's attitude to very precisely controlled. The overall system involves the regulation board (in red) and the OBC board (in grey). The primary board in purple is known as the Attitude Control System or ACS. This MCU handles commands generated by the OBC and deals with sending outputs to the satellite's six torque generating electromagnets (magnetorquers), two for each axis. This requires sending commands to six ICs known as H-bridges. Each H-bridge generates an effective voltage in either direction across its magnetorquer, and also holds data regarding this output circuitry's functioning. The ACS also monitors this data and notifies the OBC if there is a problem, such as the H-bridge shutting itself off due to current overload.

Communications

The communications system provides the radio link between the ground station and the satellite. Without it, we would not be able to communicate remotely with the satellite. The system uses a software defined radio (SDR) architecture which allows us to operate several radio services from the satellite. The primary data channel is a 9.6 kBaud convolutionally-coded BPSK channel. In addition to the data channel, there is also an FM repeater, a linear transponder, and a morse code beacon. All services use the 2m amateur band satellite for uplink and the 70cm amateur satellite band for downlink. The only exception is the morse-code beacon, which is transmit (downlink) only. Most of the analog frontend is supplied by the CML Microcircuits CMX973 Quadrature Transceiver IC, while the software modem is implemented on a PIC32 microcontroller.

Power

The Power system generates three voltages to be distributed throughout the satellite (5.5V, 5.3V, and 3.5V) from three switch mode power supplies. These voltages are then regulated by linear regulators to clean 5V, 3.3V, and 1.8V voltages on individual systems. The Power system also includes the 6 arrays of solar panels surrounding the satellite, telemetry monitoring (Battery and regulator temperature, battery charge, and solar panel power generation), Power storage in the form of a 2s8p Li-Ion batteries on two PCB boards. The Power MCU also runs an algorithm that determines sun position from solar panel current, which is monitored and converted into digital data by the Solar ADC (Analog to Digital Converter). This data is used by the ADCS in determining the satellite's attitude.

Payload

The payload for ECOSat2 controls the sensors and actuators for the PGS experiments. This system includes two radiation sensors (a control, and one surrounded by PGS), three lasers directed at sheets of PGS, an IMU for motion detection potentially caused by the optical excitation of the PGS, and a camera to monitor radiation degradation, and collects temperature and IMU telemetry. For control the system uses an AT90CAN128 running ECOSat's port of FreeRTOS.

Ground Station

The ground station controls communications with the satellite from the ground side, using a desktop computer, a USRP for the radio and software defined radio (likely using GNU Radio), and logic from satellite tracking software (Gpredict/Predict) to point the antennas in the correct direction

Software Development for ECOSat

Feel free to swing by our workshop in ELW A221 if you think you might want to learn a bit more about how we use the things described below in practise!

Micro-Controller-Units (MCUs)

  • at90_can128 (Regulation, Payload, Attitude Control System)
  • PIC32MX575 (Modem)
  • TMS570LS (On Board Computer)

FreeRTOS

free_rtos (“free real time operating system”) is the open source operating system used by the satellites MCUs. The primary purpose of an RTOS is to allow the programming of “tasks”. A task is a function that the programmer may think of as running simultaneously with other tasks, even though in reality only one is running at any given instant. This is accomplished by a “scheduler” that efficiently switches between tasks on a time-scale of milliseconds. FreeRTOS also provides a library of functions that enables tasks to wait on and use data from other tasks, timers that execute functions predictably, “hooks” that may run specific functions under specific circumstances, etc. FreeRTOS must be “ported” to run on a specific device, that is to say that many definitions must be defined according to the specific hardware of a particular MCU. Luckily, this already has been handled.

CAN bus

Primary article: can_protocol The Controller Area Network (CAN) bus is the primary means of communication between the satellite's subsystems. It ties all of the subsystems together into one unit and allows them to send requests to each other. For example, when the OBC wants the ACS to apply power to the magnetorquers, it sends a CAN message with the required voltage, start time, and duration, and this message when received by the ACS causes it to take the desired action. Each subsystem is given a particular calling address, and the addresses of the sending and receiving systems are always transmitted first. All devices listen and send on the CAN bus simultaneously, however this address determines which device's message is given priority, and other systems know when to back off and retry again a bit later. The vast majority of this protocol has already been programmed, and functions have been created for its convenient use by coders working on ECOSat.

SPI

Serial Peripheral Interface. This is a kind of data connection used to transfer data between a master device (such as the ACS board) and a slave device (such as a temperature sensor). SPI involves wires for VCC (power), ground, MISO (master in, slave out), MOSI (master out, slave in), SCK (clock that coordinates the transmission of bits), and SS (slave select, one for each slave device used to activate a particular slave). SPI normally sends bits backwards to the way you would write them on paper, and always 8 bits at a time. For instance, in sending “3” from the master to the slave, this would be represented by the bytes “00000011”, but the master would first send a 1 on the first clock tick, then another 1, then zeros for the remaining 6 clock ticks. Every SPI device has an 8-bit register (data container outside of memory) that contains both data to be sent, and data that has been received. Whenever a transfer occurs, the master and slave trade the contents of their registers. SPI connections have two primary settings. These settings are CPHA and CPOL, each of which have to possible selections. The selection of these determines whether data is read on the clock's rising or falling edge, and which voltage value (high or low) constitutes a 1, and which constitutes a 0.

TWI (a.k.a. I2C)

TWI shares some similarities with both CAN bus and SPI. Like SPI it allows the transmission of 8 bits at a time, and transmissions involve both a master and a slave device. The difference with TWI is that there is no slave select, and instead there is an address system. Slave devices have different addresses for reading and writing data. The basic steps of the protocol itself has already been well defined, but the order in which these basic actions are used depends on the the desired action (i.e. writing to peripheral slave, reading from peripheral slave). TWI devices have addresses as well as sub-addresses, which must be used accordingly in the protocol.

UART

Universal Asynchronous Receiver-Transmitter, The key here is Asynchronous, data is transferred between two devices at a pre determined speed, the receiver of the data must know at what baud rate the transmitter is supplying bits so that it can count from the start bit and sample the input pin at the correct rate to determine that data transmitted. UART consists of only two uni directional data lines with no handshaking. While UART does not have the advantage of being synchronous like TWI or SPI it has the advantage of being the simplest, data is sent 1 byte at a time exactly as you want without need of addressing or chip select lines being modified. When using UART the most important things to keep in mind is that you have set the Baud rate (bit rate) correctly and the the Tx pin of one devices is connected to the Rx pin of the other and likewise the Rx pin of the first device needs to be connected to the Tx pin of the second.

Getting to Work

The major software jobs that are underway as of October 29th, 2014 (in no particular order) include:

  • Program the ACS to monitor and drive with the H-Bridges via TWI connection
  • Program every subsystem to handle the jobs requested by incomming CAN messages
  • Program devices to monitor the temperature over using the SPI temperature sensors
  • Modify the existing CAN code to properly handle errors
  • Debugging. Oh the debugging.

For a complete ECASat todo list, please request access to our Trello page.

Design files and documentation

If you need help finding things we are trying to move everything to the structure descrived at file_structure.

The Box

References and documentation as well as mechanical design files and simulation files are commonly saved on our box share drive which can be accessed from www.box.com or optionally using there box application that works the same as the dropbox one by syncing a local copy on your computer, here you can also find and should share images, renders, and photographs. You should be able to request access from this link https://app.box.com/uvicecosat

Subversion

Design files for hardware, software, and internal documentation are controlled by a version software called subversion. Our subversion server and repos is at ecosat3.engr.uvic.ca/svnrepos we most commonly use Tortoise SVN as a client but if you feel comfortable with a different option you are welcome to use it, please watch the below youtube videos.

Checkout and Commit are the two most important methods for working with version controlled design files, they allow you to obtain a copy of the files and commit your changes to version control respectively.

Basic Tortoise SVN use

Branch and Merge allows for multiple people to work on the same software project simultaneously

Branch and Merge with Totoise SVN

Steps to getting started

  1. Join the Mailing list Google Mailing List
  2. Get your keycard activated for A221, you will need to send your name, V00 number, and keycard number to the project manager
  3. Get invited to the box share folder, you should be able to request access from https://app.box.com/uvicecosat
  4. Get a Subversion username and password, send an email to the electrical lead, communication lead, cheif engineer, or project manager.
  5. Get a wiki account
  6. Install Tortoise SVN
  7. Browse through the box and SVN to get use to where things are, read some of the co-op reports and documents on box if you find any of the interesting.
  8. Take a read through coding_guidelines
  9. If you need to use altium, create an Altium account and send your information to Justin to get activated on our licenses
  10. Read through the MPG Altium tutorial on box.
  11. For software we use Code Composer Studio (OBC), Altium Studio (AT90CAN128 systems, Regulation, Payload, ACS), and MPLAB (Modem) install the appropriate IDE for what systems you are interested in looking at.

Other jargon

Take a look at the acronyms page

  • ADCS
    • Amateur Radio
    • SDR
    • Magnetourqers
    • Pyrolytic Graphite/PGS
  • Comms.
    • DSP
    • RF
    • LNA
    • PA
    • TDD
    • ADM
Navigation
Print/export
QR Code
QR Code welcome (generated for current page)