Software » History » Version 35

PRIETO, Matías, 03/22/2015 07:51 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 34 PRIETO, Matías
p=. !{width:50%}manchester.png!
98 35 PRIETO, Matías
_Manchester encoding [3]._
99 33 PRIETO, Matías
100 1 PRIETO, Matías
h2. Overall program description
101 1 PRIETO, Matías
102 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.
103 1 PRIETO, Matías
104 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.
105 1 PRIETO, Matías
106 20 PRIETO, Matías
107 1 PRIETO, Matías
h3. Tasks, functions and main data structures description
108 1 PRIETO, Matías
109 20 PRIETO, Matías
Task and functions:
110 30 PRIETO, Matías
* _task_gps_update()_: task which performs data acquisition and filtering from GPS module.
111 30 PRIETO, Matías
* _task_rtty_phy()_: task which modulates the signal which controls the RF module.
112 30 PRIETO, Matías
* _baud_coding()_: function which performs the mapping from the ASCII buffer to the Baudot buffer.
113 30 PRIETO, Matías
* _baudTranslate()_: function which perform character translation based on a lookup table.
114 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.
115 1 PRIETO, Matías
116 20 PRIETO, Matías
Data buffers:
117 20 PRIETO, Matías
* _asciiCharBuf[RTTY_BUFFER_SIZE]_: stores data at L4 to be sent to lower layers.
118 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.
119 1 PRIETO, Matías
120 1 PRIETO, Matías
Main system flags:
121 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.
122 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.
123 1 PRIETO, Matías
124 1 PRIETO, Matías
h3. Program workflow
125 1 PRIETO, Matías
126 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.
127 1 PRIETO, Matías
128 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.
129 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.
130 1 PRIETO, Matías
131 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.
132 1 PRIETO, Matías
133 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$.
134 1 PRIETO, Matías
135 30 PRIETO, Matías
The figure below shows the state machines which models the behavior of the main program.
136 30 PRIETO, Matías
137 1 PRIETO, Matías
p=. !{width:60%}main_program_states_mch.png!
138 1 PRIETO, Matías
_Main program states machine._
139 1 PRIETO, Matías
140 20 PRIETO, Matías
h3. Task task_gps_update()
141 1 PRIETO, Matías
142 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).
143 1 PRIETO, Matías
144 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.
145 30 PRIETO, Matías
146 1 PRIETO, Matías
p=. !{width:75%}gps_rx_states_mch.png!
147 1 PRIETO, Matías
_States machine of the GPS module communication task._
148 30 PRIETO, Matías
149 33 PRIETO, Matías
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.
150 33 PRIETO, Matías
151 31 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. Therefore, the main program goes to state B, in which the task does not perform acquisition while _cod_flag_ is kept at 0.
152 30 PRIETO, Matías
153 31 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. Thus, the main program goes to state C.
154 30 PRIETO, Matías
155 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.
156 30 PRIETO, Matías
157 32 PRIETO, Matías
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.
158 32 PRIETO, Matías
159 30 PRIETO, Matías
A flowchart representing the task behavior is shown below.
160 30 PRIETO, Matías
161 30 PRIETO, Matías
p=. !{width:40%}gps_update_task_flow.png!
162 30 PRIETO, Matías
_Flowchart of the task "task_gps_update()"._
163 21 PRIETO, Matías
164 33 PRIETO, Matías
165 20 PRIETO, Matías
h3. Task task_rtty_phy()
166 20 PRIETO, Matías
167 26 PRIETO, Matías
p=. !{width:40%}phy_task_flow.png!
168 26 PRIETO, Matías
_Flowchart of the task "task_rtty_phy()"._
169 20 PRIETO, Matías
170 33 PRIETO, Matías
171 20 PRIETO, Matías
h3. Function baud_coding()
172 20 PRIETO, Matías
173 20 PRIETO, Matías
174 33 PRIETO, Matías
175 20 PRIETO, Matías
h3. Function baudTranslate()
176 20 PRIETO, Matías
177 33 PRIETO, Matías
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.
178 20 PRIETO, Matías
179 20 PRIETO, Matías
h3. Function inc_pointer()
180 20 PRIETO, Matías
181 33 PRIETO, Matías
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.
182 33 PRIETO, Matías
183 1 PRIETO, Matías
h2. References
184 13 PRIETO, Matías
185 14 PRIETO, Matías
[1] http://www.gpsinformation.org
186 25 PRIETO, Matías
[2] Parallax #28146 GPS Receiver Datasheet (attachment:GPS_Parallax_ManualV2.0.pdf)
187 33 PRIETO, Matías
[3] https://en.wikipedia.org/wiki/Manchester_code