SOURCEFORGE » RALF » 2014 Sputnik strikes back

h1. Software Design

{{>toc}}

System behavior is controlled by the MCU integrated in the motherboard, which communicates with other subsystems through the Cubesat Kit Bus. The MCU is programmed in C language based on the RTOS Salvos. Therefore, the stack implementation is programmed under these constraints. 

h2. Communication stack

Figure below presents the final implemented communication stack of the system as part of the communication chain design.

p=. !{width:40%}cubesat_stack.png!

_Communication stack._

L4, L3 and L1 are determined from mission objectives and technical requirements (i.e. the goal of the mission is to send telemetry data in RTTY format using a 2-FSK modulation). However, L2, which is a Manchester digital modulation, is introduced in the stack in order to overcome a limitation of the RF transmitter.

This transmitter is not suited to low bit rates because of the internal power management. Since it does not have any ENABLE pin nor any clock reference, it handles the power consumption shutting down the module after 9.8 msec. having a digital 0 at the input. So, this limits the maximum pulse width that can be sent.

Manchester encoding ensures one transition per each bit, therefore lower bit rates can be reached.

|_. Data format                     |_. Min. bit rate w/Manchester            |_. Min. bit rate w/no Manchester         |

| ASCII, USART: 8 bits + no parity  | 103 bps                                 | 918 bps                                 |

| Baudot 1+5+1                      | 103 bps                                 | 612 bps                                 |

The figure below presents a comparison of the modulate RF signal at low bit rates with (left) and without (right) Manchester.

h3. NMEA sentences

The National Marine Electronics Association (NMEA) has defined a standard intended to allow marine electronics to send navigation information to computers and to other marine equipment. Most GPS receivers communicate with other devices using this specification. Thus, most computer programs and applications which provide real time position information understand and expect data to be under NMEA specifications.

NMEA0183 is provided as a series of comma-delimited ASCII strings, each preceded with an identifying header. This set of strings are usually sent through a serial bus, which lets any microcontroller with a USART port extract data from and communicate to a GPS receiver module.

Each line of data is a sentence that is totally self contained and independent from other sentences. Each sentence begins with a '$' and ends with a carriage return/line feed sequence and can be no longer than 80 characters.

Inside a sentence, data fields are separated by commas. There is a provision for a checksum at the end of each sentence which may be used to verify the data integrity. The checksum field consists of a '*' and two hex digits representing an 8 bit exclusive OR of all characters between, but not including, the '$' and '*'.

There are standard sentences for each device category. For instance, for GPS receivers the prefix is GP.

Some standardized "sentences" from GPS devices are:

* <notextile>$GPGGA,170834,4124.8963,N,08151.6838,W,1,05,1.5,280.2,M,-34.0,M,,,*75</notextile>

* <notextile>$GPGSA,A,3,19,28,14,18,27,22,31,39,,,,,1.7,1.0,1.3*34</notextile>

* <notextile>$GPGSV,3,2,11,14,25,170,00,16,57,208,39,18,67,296,40,19,40,246,00*74</notextile>

* <notextile>$GPRMC,220516,A,5133.82,N,00042.24,W,173.8,231.8,130694,004.2,W*70</notextile>

The most important NMEA sentences include the GGA which provides the current Fix data, the RMC which provides the minimum gps sentences information, and the GSA which provides the Satellite status data.

h4. Details of a GGA NMEA sentence

GGA sentences carry essential fix data which provide 3D location and accuracy data.

Example: _$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47_

|_.Field value				|_.Data							|

| GGA 					| Global Positioning System Fix Data			|

| 123519				| Fix taken at 12:35:19 UTC				|

| 4807.038,N				| Latitude 48 deg 07.038' N				|

| 01131.000,E				| Longitude 11 deg 31.000' E				|

| 1					| Fix quality:						

					 0 = invalid						

					 1 = GPS fix (SPS)					

					 2 = DGPS fix						

					 3 = PPS fix						

					 4 = Real Time Kinematic				

					 5 = Float RTK						

					 6 = estimated (dead reckoning) (2.3 feature)		

					 7 = Manual input mode					

					 8 = Simulation mode					|

| 08					| Number of satellites being tracked			|

| 0.9					| Horizontal dilution of position			|

| 545.4,M				| Altitude, Meters, above mean sea level		|

| 46.9,M				| Height of geoid (mean sea level) above WGS84	ellipsoid |

| (empty field)				| time in seconds since last DGPS update		|

| (empty field)				| DGPS station ID number				|

| *47				| the checksum data, always begins with *		|

h3. Manchester encoding

In telecommunication, Manchester coding assigns for each data bit one transition and both states last the same time. Since there is at least one transition per bit, this allows the signal to be self-clocking, and the receiver to synchronize itself with the sender clock. The main drawback is that Manchester encoding requires the double of the bandwidth compared to a simple unipolar coding scheme.

There are two opposing conventions for the representations of data. The first of these was first published by G. E. Thomas and is followed by numerous authors. It specifies that for a 0 bit the signal levels will be low-high, with a low level in the first half of the bit period, and a high level in the second half. For a 1 bit the signal levels will be high-low.

The second convention is followed by numerous authors as well as by lower speed versions of IEEE 802.3 (Ethernet) standards. It states that a logic 0 is represented by a high-low signal sequence and a logic 1 is represented by a low-high signal sequence.

Let $x(t)$ be the unmodulated binary signal, $y(t)$ the modulated binary signal and $ck(t)$ the clock signal. Where the clock signal is a square wave signal with duty cycle of 50%. If $R_b$ is the bitrate for $x(t)$, then the bit period is $T_b = 1/R_b$.

Thus, Manchester (Thomas convention) defines:

$$y(t) = x(t) \textbf{ xor } (\textbf{ not } ck(t))$$

In the same way, Manchester (IEEE convention) defines:

$$y(t) = x(t) \textbf{ xor } ck(t)$$

For Thomas convention, this means that:

* If $x(t) = 0$, for $t_0 < t < t_0 + T_b$, then

** $y(t) = 0$, for $t_0 < t < t_0 + T_b/2$

** $y(t) = 1$, for $t_0 + T_b/2 < t < t_0 + T_b$

* If $x(t) = 1$, for $t_0 < t < t_0 + T_b$, then

** $y(t) = 1$, for $t_0 < t < t_0 + T_b/2$

** $y(t) = 0$, for $t_0 + T_b/2 < t < t_0 + T_b$

h2. Overall program description

The Salvo OS is a multitask operating system, based on the definition of multiple tasks. Each task is implemented inside an infinite loop.

The system main program is composed by two tasks. One in charge of L2+L1, controlling the physical layer and the other one in charge of acquiring plus filtering data from the GPS module, and formatting it (L4). In addition, a specific function is in charge of mapping the native ASCII messages coming from L4, into Baudot alphabet (L3) to be sent to L2+L1.

h3. Tasks, functions and main data structures description

Task and functions:

* _task_gps_update()_

* _task_rtty_phy()_

* _baud_coding()_

* _baudTranslate()_

* _inc_pointer()_

Data buffers:

* _asciiCharBuf[RTTY_BUFFER_SIZE]_: stores data at L4 to be sent to lower layers.

* _rtty_buffer[2*RTTY_BUFFER_SIZE]_: stores data at L3 which is the data coming from L4 mapped into Baudot alphabet.

Main system flags:

* _rts_flag_: flag which controls the behavior of the task _task_rtty_phy()_. When it is set, data stored in _rtty_buffer_ is modulated and sent to the physical layer L1. When it is not, an IDLE state signal is sent to L1.

* _cod_flag_: flag which controls the behavior of the task _task_gps_update()_. When it is set, data comming from GPS module is processed and filtered. When it is not, there is no processing and characters are discarded.

h3. Program workflow

Data coming from GPS is retrieved from the USART CSK_0 register. Since data is continuously sent character by character at a rate of 1 NMEA sentence per second, the _task_gps_update()_ has to filter the incoming characters waiting the right sequence which represents the start of a valid NMEA sentence. Then, characters must be stored in a buffer until the reception of the end of sentence indicator. The string stored in the ASCII buffer (_asciiCharBuf_) is the message that has to be sent later to the lower layers, representing the information held by the beacon. Optionally, an additional fixed messaged can be added to this buffer.

Once beacon message is defined, the task call the function _baud_coding()_, which maps the stored chars in the ASCII buffer to the Baudot alphabet. Finally, the output (the message in Baudot format) is stored in another buffer (_rtty_buffer_). This function, is supported by another one, _baudTranslate()_, which is called to perform a search and translation of symbols for each character using a look-up table.

Once data in the Baudot buffer is completed, a ready to send flag (_rts_flag_) is set to indicate the task which manage L2-L1 that there is data available ready to be sent.

_task_rtty_phy()_ is in charge of controlling lower layers and generate the output signal (at _IO.0_) which controls the 2-FSK transmitter. This task runs continuously and has the highest priority. Since a clock is required to generate the output signal, the task uses the OS timer. This timer is set to one tick per millisecond, this is 1000 ticks per second. Since required baudrate is 125, the bit period $T_b$ is 8 msec and the task uses 8 OS ticks per bit.

Each bit period $T_b$, the task performs an iteration and retrieves the bit to be sent at L3. Then it implements Manchester by setting the output signal at 0 (or 1) during $T_b/2$ and then switching to 1 (or 0) during other $T_b/2$.

p=. !{width:60%}main_program_states_mch.png!

_Main program states machine._

h3. Task task_gps_update()

p=. !{width:40%}gps_update_task_flow.png!

_Flowchart of the task "task_gps_update()"._

p=. !{width:75%}gps_rx_states_mch.png!

_States machine of the GPS module communication task._

h3. Task task_rtty_phy()

p=. !{width:40%}phy_task_flow.png!

_Flowchart of the task "task_rtty_phy()"._

h3. Function baud_coding()

h3. Function baudTranslate()

h3. Function inc_pointer()

h2. References

[1] http://www.gpsinformation.org

[2] Parallax #28146 GPS Receiver Datasheet (attachment:GPS_Parallax_ManualV2.0.pdf)