Proposed Test Cases for Link Budget Library
Added by Skylar Hoffert over 6 years ago
1) GS Mk 3
- This is the one described in our documentation already
2) GS Mk 3 High Elevation Angle
- Mostly the same as #1, but his a higher elevation angle, and therefore less pointing loss for the antenna
3) GS Mk 3 Low Elevation Angle
- Similar to #2, but with a low elevation angle, and greater pointing loss
- This link budget may generate a negative margin, which is fine as a point of test
4) GS Mk 3 High Gain Antenna, With Tracking
- For example, the Ground Station at VT 3m antenna
- Tracking allows for minimal pointing loss
5) GS Mk 3 High Gain Antenna, No Tracking
- Probably will have an extremely negative value due to the high directionality of high gain antennae
- Could again use the Ground Station at VT, but without tracking
6) GS Mk 3 Ground Plane Dipole Antenna, Optimal Elevation Angle
- Similar to the eggbeater, but with different gain characteristics
- Optimal elevation angle to maximize gain
7) GS Mk 3 Ground Plane Dipole Antenna, High Elevation Angle
- Same antenna, but with a high elevation angle
- Could also use a low elevation angle
- This would show the egg beater is well suited for a variety of elevation angles
8) AMSAT Example Link Budget
- To test we find the same result using a known example
- https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwje4ZGg5IvVAhVEGD4KHbEpD_oQFggxMAI&url=ftp%3A%2F%2Fftp.amsat.org%2Famsat%2Fsoftware%2Fspreadsheet%2FAMSAT-IARU_Link_Budget_Rev1.xls&usg=AFQjCNF1uEoVwNVy-oGRZ0leY6jJ2Cj-NA
9) Using NOAA EMWIN-N Budget I found
- http://www.nws.noaa.gov/emwin/emwin-n-link-budget.htm
- Ground Station values are a little strange compared to ours
- I am not sure if this one would work?
10) Link Budget for a separate completely different system
- DSN receiving signals from Voyager spacecraft
- VCC (USIP) Cubesat Link Budget
- Another Ground Station at VT link budget Zach may know about
Cases that should break the LB
11) Elevation Angle Below the horizon
12) Frequency outside of realistic limits (this is optional, requesting feedback)
- 100 GHz probably isn't realistic, maybe some sort of warning
- 3 Hz also isn't realistic
- Maybe okay between 30 MHz and 30 GHz
13) Incorrectly signed values
- Losses MUST be <= 0
- Gains could be positive or negative, but are usually positive
- Distance must be positive
- Noise figure >= 0
- Certain bandwidths wouldn't make sense, i.e. < 0 or > 10G
Replies (2)
RE: Proposed Test Cases for Link Budget Library - Added by J. Simmons over 6 years ago
This looks like a great list to me. Going to leave comments for each proposed case for completeness.
1) Concur
2) Agree with the concept, but I have a quick question. How would this be implemented in the test case? Just by supplying a different value for pointing loss?
3) Same comment as (2)
4) Same comment as (2)
5) Same comment as (2)
6) Same comment as (2)
7) Same comment as (2); really like the idea of getting in some antenna comparisons ahead of prototype design
8) Concur, assuming we can match inputs well enough
9) I think this one is worth running by hand to see how it compares to our process and if we can make sense of it we make it part of the test suite
10) I would like to see if we can find a good cubesat example for this proposed case
11) Concur
12) I like the idea of bounding the frequency and asserting we report the appropriate warning in place of performing the calculation
13) Concur, but note this should be broken into multiple test cases for each value being tested
We may also want to add the KickSat Link Budget
Great work!
RE: Proposed Test Cases for Link Budget Library - Added by Skylar Hoffert over 6 years ago
2, 3, 4, 5, 6, 7 are all just changing one or two values of the input variables. It is just to show that by having different input values, we may see better or worse performance.
I definitely agree that we should check out KickSat! I will start looking through their link budget to see if we can match their values.
13 will have to be broken into several test cases, thank you for mentioning that.
(1-2/2)