Software » History » Version 30

PRIETO, Matías, 03/22/2015 07:09 PM

1 1 PRIETO, Matías
h1. Software Design
2 1 PRIETO, Matías
3 2 PRIETO, Matías
{{>toc}}
4 2 PRIETO, Matías
5 1 PRIETO, Matías
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. 
6 1 PRIETO, Matías
7 3 PRIETO, Matías
h2. Communication stack
8 3 PRIETO, Matías
9 1 PRIETO, Matías
Figure below presents the final implemented communication stack of the system as part of the communication chain design.
10 1 PRIETO, Matías
11 1 PRIETO, Matías
p=. !{width:40%}cubesat_stack.png!
12 1 PRIETO, Matías
_Communication stack._
13 1 PRIETO, Matías
14 27 PRIETO, Matías
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.
15 27 PRIETO, Matías
16 29 PRIETO, Matías
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.
17 27 PRIETO, Matías
18 27 PRIETO, Matías
Manchester encoding ensures one transition per each bit, therefore lower bit rates can be reached.
19 27 PRIETO, Matías
20 27 PRIETO, Matías
|_. Data format                     |_. Min. bit rate w/Manchester            |_. Min. bit rate w/no Manchester         |
21 27 PRIETO, Matías
| ASCII, USART: 8 bits + no parity  | 103 bps                                 | 918 bps                                 |
22 27 PRIETO, Matías
| Baudot 1+5+1                      | 103 bps                                 | 612 bps                                 |
23 27 PRIETO, Matías
24 1 PRIETO, Matías
25 1 PRIETO, Matías
h3. NMEA sentences
26 1 PRIETO, Matías
27 19 Muguerza, Joaquin
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.
28 3 PRIETO, Matías
29 3 PRIETO, Matías
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.
30 3 PRIETO, Matías
31 10 PRIETO, Matías
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.
32 3 PRIETO, Matías
33 11 PRIETO, Matías
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 '*'.
34 3 PRIETO, Matías
35 3 PRIETO, Matías
There are standard sentences for each device category. For instance, for GPS receivers the prefix is GP.
36 1 PRIETO, Matías
Some standardized "sentences" from GPS devices are:
37 12 PRIETO, Matías
* <notextile>$GPGGA,170834,4124.8963,N,08151.6838,W,1,05,1.5,280.2,M,-34.0,M,,,*75</notextile>
38 12 PRIETO, Matías
* <notextile>$GPGSA,A,3,19,28,14,18,27,22,31,39,,,,,1.7,1.0,1.3*34</notextile>
39 12 PRIETO, Matías
* <notextile>$GPGSV,3,2,11,14,25,170,00,16,57,208,39,18,67,296,40,19,40,246,00*74</notextile>
40 12 PRIETO, Matías
* <notextile>$GPRMC,220516,A,5133.82,N,00042.24,W,173.8,231.8,130694,004.2,W*70</notextile>
41 3 PRIETO, Matías
42 3 PRIETO, Matías
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.
43 1 PRIETO, Matías
44 3 PRIETO, Matías
h4. Details of a GGA NMEA sentence
45 3 PRIETO, Matías
46 1 PRIETO, Matías
GGA sentences carry essential fix data which provide 3D location and accuracy data.
47 3 PRIETO, Matías
48 12 PRIETO, Matías
Example: _&#36;GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,&#42;47_
49 3 PRIETO, Matías
50 3 PRIETO, Matías
|_.Field value				|_.Data							|
51 3 PRIETO, Matías
| GGA 					| Global Positioning System Fix Data			|
52 3 PRIETO, Matías
| 123519				| Fix taken at 12:35:19 UTC				|
53 3 PRIETO, Matías
| 4807.038,N				| Latitude 48 deg 07.038' N				|
54 3 PRIETO, Matías
| 01131.000,E				| Longitude 11 deg 31.000' E				|
55 3 PRIETO, Matías
| 1					| Fix quality:						
56 3 PRIETO, Matías
					 0 = invalid						
57 3 PRIETO, Matías
					 1 = GPS fix (SPS)					
58 3 PRIETO, Matías
					 2 = DGPS fix						
59 3 PRIETO, Matías
					 3 = PPS fix						
60 3 PRIETO, Matías
					 4 = Real Time Kinematic				
61 3 PRIETO, Matías
					 5 = Float RTK						
62 3 PRIETO, Matías
					 6 = estimated (dead reckoning) (2.3 feature)		
63 3 PRIETO, Matías
					 7 = Manual input mode					
64 3 PRIETO, Matías
					 8 = Simulation mode					|
65 3 PRIETO, Matías
| 08					| Number of satellites being tracked			|
66 1 PRIETO, Matías
| 0.9					| Horizontal dilution of position			|
67 3 PRIETO, Matías
| 545.4,M				| Altitude, Meters, above mean sea level		|
68 3 PRIETO, Matías
| 46.9,M				| Height of geoid (mean sea level) above WGS84	ellipsoid |
69 3 PRIETO, Matías
| (empty field)				| time in seconds since last DGPS update		|
70 3 PRIETO, Matías
| (empty field)				| DGPS station ID number				|
71 11 PRIETO, Matías
| &#42;47				| the checksum data, always begins with &#42;		|
72 3 PRIETO, Matías
73 1 PRIETO, Matías
h3. Manchester encoding
74 1 PRIETO, Matías
75 3 PRIETO, Matías
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.
76 3 PRIETO, Matías
77 3 PRIETO, Matías
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.
78 3 PRIETO, Matías
79 3 PRIETO, Matías
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.
80 3 PRIETO, Matías
81 3 PRIETO, Matías
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$.
82 3 PRIETO, Matías
83 3 PRIETO, Matías
Thus, Manchester (Thomas convention) defines:
84 3 PRIETO, Matías
$$y(t) = x(t) \textbf{ xor } (\textbf{ not } ck(t))$$
85 3 PRIETO, Matías
86 3 PRIETO, Matías
In the same way, Manchester (IEEE convention) defines:
87 3 PRIETO, Matías
$$y(t) = x(t) \textbf{ xor } ck(t)$$
88 3 PRIETO, Matías
89 1 PRIETO, Matías
For Thomas convention, this means that:
90 1 PRIETO, Matías
* If $x(t) = 0$, for $t_0 < t < t_0 + T_b$, then
91 15 PRIETO, Matías
** $y(t) = 0$, for $t_0 < t < t_0 + T_b/2$
92 15 PRIETO, Matías
** $y(t) = 1$, for $t_0 + T_b/2 < t < t_0 + T_b$
93 3 PRIETO, Matías
* If $x(t) = 1$, for $t_0 < t < t_0 + T_b$, then
94 15 PRIETO, Matías
** $y(t) = 1$, for $t_0 < t < t_0 + T_b/2$
95 15 PRIETO, Matías
** $y(t) = 0$, for $t_0 + T_b/2 < t < t_0 + T_b$
96 1 PRIETO, Matías
97 1 PRIETO, Matías
h2. Overall program description
98 1 PRIETO, Matías
99 18 PRIETO, Matías
The Salvo OS is a multitask operating system, based on the definition of multiple tasks. Each task is implemented inside an infinite loop.
100 1 PRIETO, Matías
101 1 PRIETO, Matías
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.
102 1 PRIETO, Matías
103 20 PRIETO, Matías
104 1 PRIETO, Matías
h3. Tasks, functions and main data structures description
105 1 PRIETO, Matías
106 20 PRIETO, Matías
Task and functions:
107 30 PRIETO, Matías
* _task_gps_update()_: task which performs data acquisition and filtering from GPS module.
108 30 PRIETO, Matías
* _task_rtty_phy()_: task which modulates the signal which controls the RF module.
109 30 PRIETO, Matías
* _baud_coding()_: function which performs the mapping from the ASCII buffer to the Baudot buffer.
110 30 PRIETO, Matías
* _baudTranslate()_: function which perform character translation based on a lookup table.
111 30 PRIETO, Matías
* _inc_pointer()_: function which handles the dual-pointer in charge of pointing the bit to be sent from the Baudot buffer.
112 1 PRIETO, Matías
113 20 PRIETO, Matías
Data buffers:
114 20 PRIETO, Matías
* _asciiCharBuf[RTTY_BUFFER_SIZE]_: stores data at L4 to be sent to lower layers.
115 20 PRIETO, Matías
* _rtty_buffer[2*RTTY_BUFFER_SIZE]_: stores data at L3 which is the data coming from L4 mapped into Baudot alphabet.
116 1 PRIETO, Matías
117 1 PRIETO, Matías
Main system flags:
118 20 PRIETO, Matías
* _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.
119 20 PRIETO, Matías
* _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.
120 1 PRIETO, Matías
121 1 PRIETO, Matías
h3. Program workflow
122 1 PRIETO, Matías
123 19 Muguerza, Joaquin
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.
124 1 PRIETO, Matías
125 17 PRIETO, Matías
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.
126 1 PRIETO, Matías
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.
127 1 PRIETO, Matías
128 1 PRIETO, Matías
_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.
129 1 PRIETO, Matías
130 1 PRIETO, Matías
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$.
131 1 PRIETO, Matías
132 30 PRIETO, Matías
The figure below shows the state machines which models the behavior of the main program.
133 30 PRIETO, Matías
134 1 PRIETO, Matías
p=. !{width:60%}main_program_states_mch.png!
135 1 PRIETO, Matías
_Main program states machine._
136 1 PRIETO, Matías
137 20 PRIETO, Matías
h3. Task task_gps_update()
138 1 PRIETO, Matías
139 30 PRIETO, Matías
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).
140 1 PRIETO, Matías
141 30 PRIETO, Matías
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.
142 30 PRIETO, Matías
143 1 PRIETO, Matías
p=. !{width:75%}gps_rx_states_mch.png!
144 1 PRIETO, Matías
_States machine of the GPS module communication task._
145 30 PRIETO, Matías
146 30 PRIETO, Matías
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. From now, the task does not perform acquisition while _cod_flag_ is kept at 0.
147 30 PRIETO, Matías
148 30 PRIETO, Matías
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.
149 30 PRIETO, Matías
150 30 PRIETO, Matías
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.
151 30 PRIETO, Matías
152 30 PRIETO, Matías
A flowchart representing the task behavior is shown below.
153 30 PRIETO, Matías
154 30 PRIETO, Matías
p=. !{width:40%}gps_update_task_flow.png!
155 30 PRIETO, Matías
_Flowchart of the task "task_gps_update()"._
156 30 PRIETO, Matías
157 21 PRIETO, Matías
158 20 PRIETO, Matías
h3. Task task_rtty_phy()
159 20 PRIETO, Matías
160 26 PRIETO, Matías
p=. !{width:40%}phy_task_flow.png!
161 26 PRIETO, Matías
_Flowchart of the task "task_rtty_phy()"._
162 20 PRIETO, Matías
163 20 PRIETO, Matías
h3. Function baud_coding()
164 20 PRIETO, Matías
165 20 PRIETO, Matías
166 20 PRIETO, Matías
h3. Function baudTranslate()
167 20 PRIETO, Matías
168 20 PRIETO, Matías
169 20 PRIETO, Matías
h3. Function inc_pointer()
170 20 PRIETO, Matías
171 1 PRIETO, Matías
h2. References
172 13 PRIETO, Matías
173 14 PRIETO, Matías
[1] http://www.gpsinformation.org
174 25 PRIETO, Matías
[2] Parallax #28146 GPS Receiver Datasheet (attachment:GPS_Parallax_ManualV2.0.pdf)