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, it handles the power consumption shutting down the module after 9.8 msec. (measured at the laboratory) 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                                 |

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$

p=. !{width:50%}manchester.png!

_Manchester encoding [3]._

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 which performs data acquisition and filtering from GPS module.

* _task_rtty_phy()_: task which modulates the signal which controls the RF module.

* _baud_coding()_: function which performs the mapping from the ASCII buffer to the Baudot buffer.

* _baudTranslate()_: function which perform character translation based on a lookup table.

* _inc_pointer()_: function which handles the dual-pointer in charge of pointing the bit to be sent from the Baudot buffer.

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$.

The figure below shows the state machines which models the behavior of the main program.

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

_Main program states machine._

h3. Task task_gps_update()

The task is active when the program is in states A or B, this is when _task_rtty_phy()_ is in IDLE (_rts_flag_ is not set).

When _cod_flag_ is set, the task performs data acquisition from the GPS module. Once the sequence of characters "$GP" has been detected, the incoming data is stored in the ASCII buffer (_asciiCharBuf_) up to receive the character which indicates the end of the sentence ('\n'). The sequence detection is implemented as a states machine, shown in the figure below.

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

_States machine of the GPS module communication task._

The task uses static variables to store the state of the sequence detector and the pointer which indicates where the incoming data must be stored inside the ASCII buffer.

As explained before, once data in the ASCII buffer is defined and ready to be processed, the task indicates that acquisition is finished by setting _cod_flag_ to 0. Therefore, the main program goes to state B, in which the task does not perform acquisition while _cod_flag_ is kept at 0.

In the next iteration the task calls _baudTranslate()_ to map the data into Baudot and then, when mapping is finished, signals to the task _task_rtty_phy()_ that there is data ready to be sent in the Baudot buffer by setting _rts_flag_ to 0. Thus, the main program goes to state C.

While _rts_flag_ is equal to 0, the task is inactive and discards characters coming from the GPS module in order to keep the USART register empty.

At the end of each task iteration, the task calls the Salvo OS macro _OS_Yield()_ which performs context switching, letting the task scheduler to pass the control of the processor to another task.

A flowchart representing the task behavior is shown below.

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

_Flowchart of the task "task_gps_update()"._

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()

This function searches either in the figure or letter tables of the Baudot alphabet, if there is a match between the input character and any symbol in the specified table. Then, the function returns the equivalent Baudot symbol of the match. If there is no matching, then the function returns the code BAUD_NULL in order to indicate that situation.

h3. Function inc_pointer()

The task _task_rtty_phy()_ uses a dual-pointer to retrieve the bit to be sent from the Baudot buffer. it is composed by a pointer to indicate the byte and other to indicate the bit inside the byte. For each iteration of the task, the dual-pointer must be incremented to the next bit. Therefore, the function _inc_pointer()_ computes the right values of each pointer for the next iteration of the task.

h2. References

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

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

[3] https://en.wikipedia.org/wiki/Manchester_code