Implementation » History » Version 33
Version 32 (SERRA FONT, Anna, 03/22/2015 08:45 PM) → Version 33/74 (RIBAS MACHADO, Ederson , 03/22/2015 09:41 PM)
h1. Implementation
{{>toc}}
At this point we were familiar with the system analyse of a link budget, knowledge acquired throughout the different subjects imparted in the master course and especially thanks to the realisation of the project 2 (_Design of a regional multi-beam satellite system_), that has an strong bond with the present project.
h2. Diagram block of application development
The diagram below shows the planning with the different phases we have designed in order to perform the successful and coherent development of the tool.
p=. !{width: 70%}plan_application.png!
<div style="margin-left: auto; margin-right: auto; width: 25em">Figure 1: Project plan diagram.
</div>
In short, the first steps were to decide what would be the basic structure of our link budget program and identify all the parameters and possible calculations, as well as the logical place to perform them in this structure. Thus, a preliminary design with the fundamental and simplest conditions has been performed, to then add gradually other features in order to improve its capabilities. Finally, verification of results and testing with subjects has been done in order to finish the complete design of the tool. These steps are further explained below.
h2. Overview Application Plan
At the beginning of this project it was essential to ask ourselves about what we would expect of tool a Link Budget Tool. For instance, some thoughts we considered were: _If I had an analysis tool... what would I do with it? What would be the settings I give? What would be the results that I expect?_
Hence, in order to design a tool to help with the comprehension of the link budget analysis, we have had to ask each time the question _"How will I present my results and information?”_. This leads us to the *GUI (Graphical User Interface)*, one of the key points of this project.
When we thought about all this aspects, we know what it has to do, which are the necessary parameters and results we want to show, etc. At this point, we can start to design our screen according to this. Thus, we identified the topology of the satellite communication system and we divided it in the following block groups, that corresponds to different tabs in the software tool:
* *Service:* The user introduces the requirements of his system (i.e. modulation, channel BW, code rate, margin, etc.), and the tool gives as outputs the required information bit rate, overall link carrier-to-power noise power ratio, etc.
* *System Geometry:* The user introduces the latitude and longitude of the earth stations and the satellite and he obtains as outputs the corresponding azimuth and elevation angles and the range between satellite and each earth station.
* *Uplink:* The user introduces all the parameters involved from the transmission on earth station A to the reception at the satellite, including the uplink path losses depending on the weather conditions. All the results associated with uplink are computed, being the uplink carrier-to-power noise spectral density the most important result.
* *Payload:* The user introduces the input back-off and the carrier-to-power intermodulation power ratio is computed.
* *Downlink:* Similar to uplink, but here the parameters introduced by the user are those involved from the satellite transmission to the reception on earth station B.
* *Overall link:* The user can see a summary of the principle results obtained in the previous tabs and introducing the carrier power-to-interference power ratio of the system the tool determines if the link budget requirements are achieved with the given specifications or not.
h2. Preliminary design
It is known that link budget equations can become messy and complex and this calculus involve several aspects and conditions, furthermore, link budget can be analysed from different points of view. Globally, it can be defined with the following approaches:
* The first approach is a feasibility study: The user gives the features of the system, the targeted service, the bit rate, the bit error rate, etc., and the link budget says either if it is possible with this margin or if this is not possible (negative margin).
* In the second approach the user also defines the features of the system, and then the link budget says what is possible to do in terms of bit rate, bit error rate, etc.
* Finally there is a third approach where the user says which is the service he would like to have, and the link budget tool finds all the system settings. But this approach is much more complex, because as there are several parameters to define, it turns into a lot of different configuration options.
In the interest of simplification we have implemented the link budget using the first approach: the *feasibility study*.
Thus, once defined what would be the program structure, we started implementing the calculations starting from a first basic implementation. I.e. calculating the basic parameters for each tab and taking the simplest hypothesis (e.g. clear sky conditions rather than rain conditions), and finally by assembling the individual results for the overall link budget.
At this early stage we had a first implementation, comprehensive and simplified, but only with the numerical values. From here we started, in the one hand, to focus on the visual and clear interface aspect of the program and, in the second hand, to add more complex equations and conditions, as well as new LabVIEW features that are listed below.
h2. Added features
tip. Citar y detallar un poco todas las características añadidas durante el proyecto...
- Por una parte, mejoras en el cálculo del link budget:
* Service
** multicarrier/singlecarrier
This feature allows to select between a multicarrier and singlecarrier mode. If the singlecarrier is selected there will be only one carrier per transponder which means that all transponder Bandwith will be used by this carrier. In multicarrier mode, we have only the option of 3 carrier per transponder. Then the transponder BW will be divided by 3 and we'll have different formulas to compute the IBO, OBO, there will be an inter modulation product and ${(C/No)}_{IM}$ will affect the available ${(C/No)}_{T}$. When each mode is selected the payload transponder window will use the corresponding formulas, and actions (if the payload transponder window is open an indication of the mode is exposed in a dialog box).
**Selection of BER ** possibilidad de elegir entre varios BER y code rate (Quasi error free)
* System Geometry
** Mapa con las 2 estaciones terrenas señalizadas en el mapa cartográfico.
* Payload
** depointing
** cálculo de intermodulación dependiendo de si es single o multicarrier
* Tanto en Uplink como Downlink el usuario puede elegir entre clear sky o Rain conditions
** En rain conditions el usuario tiene la posibilidad de ver un mapa con valores de R001 según la la localización de la estación terrena.
** cálculo de h0 con documentación de ITU Recommendation
* Overall
** Led que se enciende si se cumplen las especificaciones
** Además el usuario puede ver una gráfica según el resultado obtenido (poner captura de los 3 tipos de gráficas que pueden aparecer).
- Por otra parte, se han añadido funcionalidades como:
* los botones de CLEAR VARIABLES
* SET TO DEF
* HELP POP-UP en todos los parámetros para ayudar a la correcta comprensión del usuario.
* Dibujos esquemáticos/diagramas para ayudar a la comprensión de los parámetros.
h2. Final design
In Figures 2 to 8 are shown the captures with the final design of each of the different tabs of the _SatToolLink_.
h3. Service:
p=. !{width: 60%}servicePage.png!
<div style="margin-left: auto; margin-right: auto; width: 30em">Figure 2: First window of SatlinkTool - _Service_.
</div>
h3. System Geometry:
p=. !{width: 61%}SystemGeometryPage.png!
<div style="margin-left: auto; margin-right: auto; width: 30em">Figure 3: Second window of SatlinkTool - _System Geometry_.
</div>
h3. Uplink:
p=. !{width: 60%}uplinkpage.png!
<div style="margin-left: auto; margin-right: auto; width: 25em">Figure 4: Third window of SatlinkTool - _Uplink_.
</div>
h3. Payload:
* Transponder window:
p=. !{width: 60%}PayloadTransponderPage.png!
<div style="margin-left: auto; margin-right: auto; width: 30em">Figure 5: Fourth window of SatlinkTool - _Payload: Transponder_.
</div>
* Antenna window:
p=. !{width: 60%}PayloadAntennaPage2.png!
<div style="margin-left: auto; margin-right: auto; width: 30em">Figure 6: Fourth window of SatlinkTool - _Payload: Antenna_.
</div>
h3. Downlink:
p=. !{width: 60%}downlinkPage.png!
<div style="margin-left: auto; margin-right: auto; width: 25em">Figure 7: Fifth window of SatlinkTool - _Downlink_.
</div>
h3. Overall link:
p=. !{width: 60%}overallPage.png!
<div style="margin-left: auto; margin-right: auto; width: 25em">Figure 8: Sixth window of SatlinkTool - _Downlink_.
</div>
Finally, the figure below (Figure 8) shows the window where the user will have to attach the files needed for the correct functioning of the SatLinkTool.
* _map.txt_: File needed to show the map with the two earth station locations corresponding to the parameters entered in the System Geometry tab.
* _h01.txt_ and _h02.txt_: These files are used when the _Rain Condition_ is selected either in the Uplink tab or the Downlink tab in order to compute the 0 degree isotherm height (see section _Added Features_ above for more information) [1].
p=. !{width: 30%}AttachFiles.png!
<div style="margin-left: auto; margin-right: auto; width: 20em">Figure 9: Attach file window of SatlinkTool.
</div>
h2. Validation & Final tests
As the calculations were implemented in the different tabs, the results were also checked. Finally, once all the SatLinkTool design and implementation was completed, all tests were remade in order to verify the correct results. Tests with other students were also made in order to verify if the operation program was understood. This allowed us to detect the weak points of the tool and where we should modify the design or add additional explanation in the help pop-up. These steps are more detailed in section [[Tests and results]].
h2. Delivery Application
SatLinkTool is intended to be distributed out of charge through the website of the SCS program for future students. The files needed to use this tool are the following:
* File name: *SatLinkTool.vi* - File format: _LabVIEW Instrument (.vi)_
* File name: *map.txt* - File format: _Text file (.txt)_
* File name: *h01.txt* - File format: _Text file (.txt)_
* File name: *h02.txt* - File format: _Text file (.txt)_
A user manual of the SatLinkTool Software is also provided in order to support the users for the correct understanding of the tool and the process to follow. The User Manual is presented [[How to use it|here]].
h1. REFERENCES
[1] Rec. ITU-R P.839-4 {UPDATE} Para el cálculo de h0
{{>toc}}
At this point we were familiar with the system analyse of a link budget, knowledge acquired throughout the different subjects imparted in the master course and especially thanks to the realisation of the project 2 (_Design of a regional multi-beam satellite system_), that has an strong bond with the present project.
h2. Diagram block of application development
The diagram below shows the planning with the different phases we have designed in order to perform the successful and coherent development of the tool.
p=. !{width: 70%}plan_application.png!
<div style="margin-left: auto; margin-right: auto; width: 25em">Figure 1: Project plan diagram.
</div>
In short, the first steps were to decide what would be the basic structure of our link budget program and identify all the parameters and possible calculations, as well as the logical place to perform them in this structure. Thus, a preliminary design with the fundamental and simplest conditions has been performed, to then add gradually other features in order to improve its capabilities. Finally, verification of results and testing with subjects has been done in order to finish the complete design of the tool. These steps are further explained below.
h2. Overview Application Plan
At the beginning of this project it was essential to ask ourselves about what we would expect of tool a Link Budget Tool. For instance, some thoughts we considered were: _If I had an analysis tool... what would I do with it? What would be the settings I give? What would be the results that I expect?_
Hence, in order to design a tool to help with the comprehension of the link budget analysis, we have had to ask each time the question _"How will I present my results and information?”_. This leads us to the *GUI (Graphical User Interface)*, one of the key points of this project.
When we thought about all this aspects, we know what it has to do, which are the necessary parameters and results we want to show, etc. At this point, we can start to design our screen according to this. Thus, we identified the topology of the satellite communication system and we divided it in the following block groups, that corresponds to different tabs in the software tool:
* *Service:* The user introduces the requirements of his system (i.e. modulation, channel BW, code rate, margin, etc.), and the tool gives as outputs the required information bit rate, overall link carrier-to-power noise power ratio, etc.
* *System Geometry:* The user introduces the latitude and longitude of the earth stations and the satellite and he obtains as outputs the corresponding azimuth and elevation angles and the range between satellite and each earth station.
* *Uplink:* The user introduces all the parameters involved from the transmission on earth station A to the reception at the satellite, including the uplink path losses depending on the weather conditions. All the results associated with uplink are computed, being the uplink carrier-to-power noise spectral density the most important result.
* *Payload:* The user introduces the input back-off and the carrier-to-power intermodulation power ratio is computed.
* *Downlink:* Similar to uplink, but here the parameters introduced by the user are those involved from the satellite transmission to the reception on earth station B.
* *Overall link:* The user can see a summary of the principle results obtained in the previous tabs and introducing the carrier power-to-interference power ratio of the system the tool determines if the link budget requirements are achieved with the given specifications or not.
h2. Preliminary design
It is known that link budget equations can become messy and complex and this calculus involve several aspects and conditions, furthermore, link budget can be analysed from different points of view. Globally, it can be defined with the following approaches:
* The first approach is a feasibility study: The user gives the features of the system, the targeted service, the bit rate, the bit error rate, etc., and the link budget says either if it is possible with this margin or if this is not possible (negative margin).
* In the second approach the user also defines the features of the system, and then the link budget says what is possible to do in terms of bit rate, bit error rate, etc.
* Finally there is a third approach where the user says which is the service he would like to have, and the link budget tool finds all the system settings. But this approach is much more complex, because as there are several parameters to define, it turns into a lot of different configuration options.
In the interest of simplification we have implemented the link budget using the first approach: the *feasibility study*.
Thus, once defined what would be the program structure, we started implementing the calculations starting from a first basic implementation. I.e. calculating the basic parameters for each tab and taking the simplest hypothesis (e.g. clear sky conditions rather than rain conditions), and finally by assembling the individual results for the overall link budget.
At this early stage we had a first implementation, comprehensive and simplified, but only with the numerical values. From here we started, in the one hand, to focus on the visual and clear interface aspect of the program and, in the second hand, to add more complex equations and conditions, as well as new LabVIEW features that are listed below.
h2. Added features
tip. Citar y detallar un poco todas las características añadidas durante el proyecto...
- Por una parte, mejoras en el cálculo del link budget:
* Service
** multicarrier/singlecarrier
This feature allows to select between a multicarrier and singlecarrier mode. If the singlecarrier is selected there will be only one carrier per transponder which means that all transponder Bandwith will be used by this carrier. In multicarrier mode, we have only the option of 3 carrier per transponder. Then the transponder BW will be divided by 3 and we'll have different formulas to compute the IBO, OBO, there will be an inter modulation product and ${(C/No)}_{IM}$ will affect the available ${(C/No)}_{T}$. When each mode is selected the payload transponder window will use the corresponding formulas, and actions (if the payload transponder window is open an indication of the mode is exposed in a dialog box).
**Selection of BER ** possibilidad de elegir entre varios BER y code rate (Quasi error free)
* System Geometry
** Mapa con las 2 estaciones terrenas señalizadas en el mapa cartográfico.
* Payload
** depointing
** cálculo de intermodulación dependiendo de si es single o multicarrier
* Tanto en Uplink como Downlink el usuario puede elegir entre clear sky o Rain conditions
** En rain conditions el usuario tiene la posibilidad de ver un mapa con valores de R001 según la la localización de la estación terrena.
** cálculo de h0 con documentación de ITU Recommendation
* Overall
** Led que se enciende si se cumplen las especificaciones
** Además el usuario puede ver una gráfica según el resultado obtenido (poner captura de los 3 tipos de gráficas que pueden aparecer).
- Por otra parte, se han añadido funcionalidades como:
* los botones de CLEAR VARIABLES
* SET TO DEF
* HELP POP-UP en todos los parámetros para ayudar a la correcta comprensión del usuario.
* Dibujos esquemáticos/diagramas para ayudar a la comprensión de los parámetros.
h2. Final design
In Figures 2 to 8 are shown the captures with the final design of each of the different tabs of the _SatToolLink_.
h3. Service:
p=. !{width: 60%}servicePage.png!
<div style="margin-left: auto; margin-right: auto; width: 30em">Figure 2: First window of SatlinkTool - _Service_.
</div>
h3. System Geometry:
p=. !{width: 61%}SystemGeometryPage.png!
<div style="margin-left: auto; margin-right: auto; width: 30em">Figure 3: Second window of SatlinkTool - _System Geometry_.
</div>
h3. Uplink:
p=. !{width: 60%}uplinkpage.png!
<div style="margin-left: auto; margin-right: auto; width: 25em">Figure 4: Third window of SatlinkTool - _Uplink_.
</div>
h3. Payload:
* Transponder window:
p=. !{width: 60%}PayloadTransponderPage.png!
<div style="margin-left: auto; margin-right: auto; width: 30em">Figure 5: Fourth window of SatlinkTool - _Payload: Transponder_.
</div>
* Antenna window:
p=. !{width: 60%}PayloadAntennaPage2.png!
<div style="margin-left: auto; margin-right: auto; width: 30em">Figure 6: Fourth window of SatlinkTool - _Payload: Antenna_.
</div>
h3. Downlink:
p=. !{width: 60%}downlinkPage.png!
<div style="margin-left: auto; margin-right: auto; width: 25em">Figure 7: Fifth window of SatlinkTool - _Downlink_.
</div>
h3. Overall link:
p=. !{width: 60%}overallPage.png!
<div style="margin-left: auto; margin-right: auto; width: 25em">Figure 8: Sixth window of SatlinkTool - _Downlink_.
</div>
Finally, the figure below (Figure 8) shows the window where the user will have to attach the files needed for the correct functioning of the SatLinkTool.
* _map.txt_: File needed to show the map with the two earth station locations corresponding to the parameters entered in the System Geometry tab.
* _h01.txt_ and _h02.txt_: These files are used when the _Rain Condition_ is selected either in the Uplink tab or the Downlink tab in order to compute the 0 degree isotherm height (see section _Added Features_ above for more information) [1].
p=. !{width: 30%}AttachFiles.png!
<div style="margin-left: auto; margin-right: auto; width: 20em">Figure 9: Attach file window of SatlinkTool.
</div>
h2. Validation & Final tests
As the calculations were implemented in the different tabs, the results were also checked. Finally, once all the SatLinkTool design and implementation was completed, all tests were remade in order to verify the correct results. Tests with other students were also made in order to verify if the operation program was understood. This allowed us to detect the weak points of the tool and where we should modify the design or add additional explanation in the help pop-up. These steps are more detailed in section [[Tests and results]].
h2. Delivery Application
SatLinkTool is intended to be distributed out of charge through the website of the SCS program for future students. The files needed to use this tool are the following:
* File name: *SatLinkTool.vi* - File format: _LabVIEW Instrument (.vi)_
* File name: *map.txt* - File format: _Text file (.txt)_
* File name: *h01.txt* - File format: _Text file (.txt)_
* File name: *h02.txt* - File format: _Text file (.txt)_
A user manual of the SatLinkTool Software is also provided in order to support the users for the correct understanding of the tool and the process to follow. The User Manual is presented [[How to use it|here]].
h1. REFERENCES
[1] Rec. ITU-R P.839-4 {UPDATE} Para el cálculo de h0