Doppler Tracking Discontinuity at TCA - Problem Solved
Over the last week or two, I have been getting a 200 Hz discontinuity jump in my uplink frequency at TCA (Time of Closest Approach), also known as the zero doppler point. This happened on every bird, every pass. (all mode B, 70cm up, 2m down)
AOS was early, LOS was late, and doppler tracking was non-linear and had the bad jump at TCA.
Today, thanks to K5GZR and KB7IJ, the problem source was identified and corrected.
It was caused by a terrible error in the definition of my Home Altitude. I typed in, 350 meters. The program took it 35,000 meters.
I corrected it and now doppler tracking in SDRC v3.x is perfect.
If anyone else ever gets a set of symptoms like mine, take a look at your Home QTH altitude setting. Being off by a factor of 100:1 makes a difference.
73, N0AN
Hasan
It's a software bug when the software quietly accepts an impossible parameter.
On Sat, Aug 29, 2020, 6:17 AM Hasan N0AN via AMSAT-BB [email protected] wrote:
Over the last week or two, I have been getting a 200 Hz discontinuity jump in my uplink frequency at TCA (Time of Closest Approach), also known as the zero doppler point. This happened on every bird, every pass. (all mode B, 70cm up, 2m down)
AOS was early, LOS was late, and doppler tracking was non-linear and had the bad jump at TCA.
Today, thanks to K5GZR and KB7IJ, the problem source was identified and corrected.
It was caused by a terrible error in the definition of my Home Altitude. I typed in, 350 meters. The program took it 35,000 meters.
I corrected it and now doppler tracking in SDRC v3.x is perfect.
If anyone else ever gets a set of symptoms like mine, take a look at your Home QTH altitude setting. Being off by a factor of 100:1 makes a difference.
73, N0AN
Hasan _______________________________________________ Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
Hi Bruce, I'm sure it should be error trapped when an absolutely crazy value is input, but I'm not pointing the finger at any programmer, when I, in fact, input the wrong, really wrong, value.
I'm just glad I found it and now doppler tracking is perfectly even on an 89 degree overhead pass.
Considering all the things done right in the software, way beyond any other program I've seen, I'm not going to complain.
The program auto-schedules, tracks, prioritizes and presents for decoding AO-73, EO-88, JO-97, AO-91 and AO-92, with no operator intervention whatsoever. Any number of birds can be added or deleted.
I can let it run overnight and come down and see every bird's TLM perfectly decoded.
If I chose to, I could have it IQ record every pass and go back and decode it again later.
The program is absolutely amazing. The fact that it accepted a ridiculous input value from me without warning me, is to my way of thinking, small potatoes. :-)
(SDR-Radio Console v 3.x )
5 EL Yagi > 60' Hardline > Duplexer > ARR GasFET > Funcube Pro+ SDR > SDRConsole v3
Rotor control by SDRC > PSTrotator 15 deg uptilt yagi (5 EL on 2m, 8 EL on 70cm, interlaced, common feedpoint)
Anyone using an SDR that has not used SDRC for controlling it, for satellite work, has no idea how enriching an SDR setup with good software can be.
73, N0AN Hasan
On Sat, Aug 29, 2020 at 12:52 PM Bruce Perens [email protected] wrote:
It's a software bug when the software quietly accepts an impossible parameter.
On Sat, Aug 29, 2020, 6:17 AM Hasan N0AN via AMSAT-BB [email protected] wrote:
Over the last week or two, I have been getting a 200 Hz discontinuity jump in my uplink frequency at TCA (Time of Closest Approach), also known as the zero doppler point. This happened on every bird, every pass. (all mode B, 70cm up, 2m down)
AOS was early, LOS was late, and doppler tracking was non-linear and had the bad jump at TCA.
Today, thanks to K5GZR and KB7IJ, the problem source was identified and corrected.
It was caused by a terrible error in the definition of my Home Altitude. I typed in, 350 meters. The program took it 35,000 meters.
I corrected it and now doppler tracking in SDRC v3.x is perfect.
If anyone else ever gets a set of symptoms like mine, take a look at your Home QTH altitude setting. Being off by a factor of 100:1 makes a difference.
73, N0AN
Hasan _______________________________________________ Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
Well I guess it could be used in geosynchronous orbit, although it hasn't been tested to operate with all of the satellites under it :-) wrong unit and scale selection are a common user error. Not really your fault.
On Sat, Aug 29, 2020, 11:16 AM Hasan N0AN [email protected] wrote:
Hi Bruce, I'm sure it should be error trapped when an absolutely crazy value is input, but I'm not pointing the finger at any programmer, when I, in fact, input the wrong, really wrong, value.
I'm just glad I found it and now doppler tracking is perfectly even on an 89 degree overhead pass.
Considering all the things done right in the software, way beyond any other program I've seen, I'm not going to complain.
The program auto-schedules, tracks, prioritizes and presents for decoding AO-73, EO-88, JO-97, AO-91 and AO-92, with no operator intervention whatsoever. Any number of birds can be added or deleted.
I can let it run overnight and come down and see every bird's TLM perfectly decoded.
If I chose to, I could have it IQ record every pass and go back and decode it again later.
The program is absolutely amazing. The fact that it accepted a ridiculous input value from me without warning me, is to my way of thinking, small potatoes. :-)
(SDR-Radio Console v 3.x )
5 EL Yagi > 60' Hardline > Duplexer > ARR GasFET > Funcube Pro+ SDR > SDRConsole v3
Rotor control by SDRC > PSTrotator 15 deg uptilt yagi (5 EL on 2m, 8 EL on 70cm, interlaced, common feedpoint)
Anyone using an SDR that has not used SDRC for controlling it, for satellite work, has no idea how enriching an SDR setup with good software can be.
73, N0AN Hasan
On Sat, Aug 29, 2020 at 12:52 PM Bruce Perens [email protected] wrote:
It's a software bug when the software quietly accepts an impossible parameter.
On Sat, Aug 29, 2020, 6:17 AM Hasan N0AN via AMSAT-BB [email protected] wrote:
Over the last week or two, I have been getting a 200 Hz discontinuity jump in my uplink frequency at TCA (Time of Closest Approach), also known as the zero doppler point. This happened on every bird, every pass. (all mode B, 70cm up, 2m down)
AOS was early, LOS was late, and doppler tracking was non-linear and had the bad jump at TCA.
Today, thanks to K5GZR and KB7IJ, the problem source was identified and corrected.
It was caused by a terrible error in the definition of my Home Altitude. I typed in, 350 meters. The program took it 35,000 meters.
I corrected it and now doppler tracking in SDRC v3.x is perfect.
If anyone else ever gets a set of symptoms like mine, take a look at your Home QTH altitude setting. Being off by a factor of 100:1 makes a difference.
73, N0AN
Hasan _______________________________________________ Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
On 8/29/20 10:52, Bruce Perens via AMSAT-BB wrote:
It's a software bug when the software quietly accepts an impossible parameter.
It's not an impossible value. Balloons can reach 35 km without too much trouble. I don't like software with arbitrary limits imposed by authors who lack the imagination as to how people might use it. Ballooners already have enough problems with arbitrary altitude limits in GPS receivers.
Phil
On 8/29/20 11:15, Hasan N0AN via AMSAT-BB wrote:
Anyone using an SDR that has not used SDRC for controlling it, for satellite work, has no idea how enriching an SDR setup with good software can be.
Does it do fine Doppler tuning in software, or does it only retune in steps?
A few years ago I wrote an SDR for the AMSAT UK Funcube Pro+ dongle with a local oscillator in software that can generate a frequency sweep with no abrupt phase or frequency jumps. This is actually pretty easy to do, taking only two complex multiplies per sample instead of one. This is important when coherently demodulating a digital signal.
My software LO does all tuning within a pass. I tune the hardware LO in the SDR front end close enough so that it doesn't have to be retuned during the pass. Because that hardware LO is synthesized, retuning it causes uncontrolled jumps in phase and frequency. As long as the SDR front end has enough bandwidth to handle the signal bandwidth plus the total Doppler, there's no need to retune it. The Funcube dongle samples at 192 kHz. This is low by comparison to other front ends but it's still wide enough up to 70cm or so.
Because the Funcube dongle is direct conversion you want to avoid the noisy region around DC in the IF. That cuts the usable bandwidth to ~96 kHz on either side of DC. Take off another 10 kHz to avoid the aliased region near +/- 96 kHz and you're down to 86 kHz. 3 kHz SSB + 2 * 10 kHz = 23 kHz, so there's plenty of room for tracking an entire pass without ever retuning the front end.
I set the oscillator frequency rate (corresponding to Doppler acceleration) with a tracking program every second or two, which was frequent enough to keep a 70cm mode J CW beacon within a 100 Hz filter for an entire pass. It's so rock stable as to be eerie. But you do need accurate elements, accurate station position (including altitude!) and an accurate clock.
I had considered adding another order to the oscillator (ie. set frequency, frequency rate, and rate squared) but it just wasn't necessary.
My tracking program calculates relative velocity (Doppler frequency) analytically from the velocity vectors computed by the orbit and earth models, rather than by finite differencing position as a lot of the older AMSAT tracking programs did. Do any of the newer programs do it this way?
I (with n4hy's help) also did the math to calculate relative acceleration (Doppler sweep rate) analytically. One of the terms was the actual inertial acceleration of the satellite due to gravity. That meant modeling the earth's gravity field, which is most of what it takes to do a full-blown state vector propagator. This seemed like too much work so I stuck with the NORAD keplerian orbit model.
Phil
The ITAR limits on GPS altitude and speed were rescinded in 2014, which doesn't mean every manufacturer has removed them. But they were not arbitrary, they were government-imposed. It just happened that some manufacturers implemented them as limits on both being over 60,000 feet and 1000 miles per hour at the same time, others on exceeding either the speed or the altitude.
It's perfectly fine to have a check box that says "the station will not be on the surface of the Earth", if your program is actually capable of that sort of operation (I doubt this one really is), but in general it is good practice to protect the user from foolish inputs unless they check that kind of box.
On Sat, Aug 29, 2020, 3:37 PM Phil Karn via AMSAT-BB [email protected] wrote:
On 8/29/20 10:52, Bruce Perens via AMSAT-BB wrote:
It's a software bug when the software quietly accepts an impossible parameter.
It's not an impossible value. Balloons can reach 35 km without too much trouble. I don't like software with arbitrary limits imposed by authors who lack the imagination as to how people might use it. Ballooners already have enough problems with arbitrary altitude limits in GPS receivers.
Phil
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
I know about the Itar limits, but the fact that some manufacturers implemented the limits as altitude AND velocity while others did it as altitude OR velocity was certainly arbitrary.
I didn’t know that these limits had been removed entirely, that’s good news. I’d noticed that the kiwi sdr has an open GPS receiver in it, which got me thinking about extracting and using it independently.
On Aug 29, 2020, at 16:02, Bruce Perens [email protected] wrote:
The ITAR limits on GPS altitude and speed were rescinded in 2014, which doesn't mean every manufacturer has removed them. But they were not arbitrary, they were government-imposed.
I believe the Missile Technology Control Regime, a 35 nation informal agreement, not a treaty, was updated in 2016 to limit civilian GPS system speed two 600 meters per second, and to exclude from consumer equipment those GPS designed for missiles and autonomous aircraft carrying more than 500 kg payload.
How or whether each country implements this is entirely up to them.
I have a feeling there might still be a regulation in the EAR. But I haven't found it yet.
On Sat, Aug 29, 2020, 5:08 PM Phil Karn [email protected] wrote:
I know about the Itar limits, but the fact that some manufacturers implemented the limits as altitude AND velocity while others did it as altitude OR velocity was certainly arbitrary.
I didn’t know that these limits had been removed entirely, that’s good news. I’d noticed that the kiwi sdr has an open GPS receiver in it, which got me thinking about extracting and using it independently.
On Aug 29, 2020, at 16:02, Bruce Perens [email protected] wrote:
The ITAR limits on GPS altitude and speed were rescinded in 2014, which
doesn't mean every manufacturer has removed them. But they were not arbitrary, they were government-imposed.
participants (3)
-
Bruce Perens -
Hasan N0AN -
Phil Karn