More on Linear Transponder Calculations
In my last post on the subject, I'd concluded
I was still flummoxed by this until I tried a bit of algebra, like this:
`(up_x) / (1- v_r/c) = (up_x)(1+ v_r/c)/((1- v_r/c)(1+v_r/c))`
`= up_x(1 + v_r/c)/(1 + (v_r/c)^2)`
So now all that's left over is the `(v_r/c)^2`. How can InstantTune safely ignore that? Well, compared to `c`, the speed of light, `v_r` (the observed speed of our satellite) is always really, really small, so the ratio comes out to a max of around 2E-5. That means that the embarrassing `(v_r/c)^2` is vanishingly small and has virtually no impact on the calculation.
How little impact? Well, I ran some spreadsheets, and concluded that an average LEO satellite (the closest to the earth, and therefore the ones with the highest sustained `v_r`) operating in the C-band (a very high frequency, which therefore makes doppler worse), would be miscalculated by only 6 Hz or so.
This is all great news for the satpack project, since the original formula was going to require some 8 byte variables and all the math libraries that go with them, adding 2kB of program size which I didn't have to offer. Now I can do the calculations through multiplication and shifting variables around, keeping everything down to 4 byte (unsigned long) integer math.
The result is that for non-inverting transponders, the equation is this:Soon after, I received a kind email from Tony AA2TX, with an offprint of his 1997 Space Symposium paper that describes the object-oriented computational approach that is built into the InstantTune code.[1] Since I've been happily pillaging the IT code for some time now, I'd noticed what this article confirms, namely that instead of using `(up_x) / (1- v_r/c)` to get the value of the origin signal from the received signal, InstantTune uses `(up_x) (1+ v_r/c)`.
`up_o = (dl_o - bc_d + bc_u)/(1-v_r/c)`
For inverting transponders:
`up_o = (bc_d + bc_u - dl_o) / (1 - v_r/c)`
I was still flummoxed by this until I tried a bit of algebra, like this:
`(up_x) / (1- v_r/c) = (up_x)(1+ v_r/c)/((1- v_r/c)(1+v_r/c))`
`= up_x(1 + v_r/c)/(1 + (v_r/c)^2)`
So now all that's left over is the `(v_r/c)^2`. How can InstantTune safely ignore that? Well, compared to `c`, the speed of light, `v_r` (the observed speed of our satellite) is always really, really small, so the ratio comes out to a max of around 2E-5. That means that the embarrassing `(v_r/c)^2` is vanishingly small and has virtually no impact on the calculation.
How little impact? Well, I ran some spreadsheets, and concluded that an average LEO satellite (the closest to the earth, and therefore the ones with the highest sustained `v_r`) operating in the C-band (a very high frequency, which therefore makes doppler worse), would be miscalculated by only 6 Hz or so.
This is all great news for the satpack project, since the original formula was going to require some 8 byte variables and all the math libraries that go with them, adding 2kB of program size which I didn't have to offer. Now I can do the calculations through multiplication and shifting variables around, keeping everything down to 4 byte (unsigned long) integer math.
- Monteiro, T. "An Object Oriented Approach To Automatic Radio Tuning." Proceedings of the AMSAT-NA 15th Space Symposium, and AMSAT-NA annual meeting : October 17-19, 1997, Toronto, Ontario Canada. (Newington CT: American Radio Relay League, 1997). pp. 46-55.
Bruce, excellent work. I was fascinated by the doppler tuning stability shown in spectran. I have an arduino kit that Brian N1BQ sells, you're getting me motivated to start experimenting with it. 73 de John K2ZA
ReplyDeleteJohn --
ReplyDeleteThe stability is largely due to James Miller's G3RUH Plan13 code. I've just ported it to this platform. (James also kindly gave me some updated constants that I think put the finishing touches on.) I find HO-68 a good bird to test stability with. Probably it has a good amount of mass, and is new and well constructed. Some of the cubesats are charmingly chirpy. ITU, for instance, whoops up and down the band.
If you get the arduino running, let me know and I'll modify this satpack code so that you can alternatively use an internal timer rather than building in a realtime clock. Obviously the latter is necessary for any serious use, but you might enjoy playing with satpack without going to the expense of getting the rtc.