29 Aug
2020
29 Aug
'20
9:15 a.m.
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
29 Aug
29 Aug
1:52 p.m.
New subject: [amsat-bb] Doppler Tracking Discontinuity at TCA - Problem Solved
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 <amsat-bb(a)amsat.org>
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 AMSAT-BB(a)amsat.org. 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
2:15 p.m.
New subject: [amsat-bb] Doppler Tracking Discontinuity at TCA - Problem Solved
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 <bruce(a)perens.com> 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 <amsat-bb(a)amsat.org>
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 AMSAT-BB(a)amsat.org. 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
3:11 p.m.
New subject: [amsat-bb] Doppler Tracking Discontinuity at TCA - Problem Solved
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 <hbasri.schiers6(a)gmail.com> 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 <bruce(a)perens.com> 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 <amsat-bb(a)amsat.org>
> 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 AMSAT-BB(a)amsat.org. 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
>>
>
6:57 p.m.
New subject: [amsat-bb] Doppler Tracking Discontinuity at TCA - Problem Solved
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
6:31 p.m.
New subject: [amsat-bb] Doppler Tracking Discontinuity at TCA - Problem Solved
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
7:02 p.m.
New subject: [amsat-bb] Doppler Tracking Discontinuity at TCA - Problem Solved
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 <amsat-bb(a)amsat.org>
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 AMSAT-BB(a)amsat.org. 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
8:08 p.m.
New subject: [amsat-bb] Doppler Tracking Discontinuity at TCA - Problem Solved
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
<bruce(a)perens.com> 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.
9:19 p.m.
New subject: [amsat-bb] GPS limits
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 <karn(a)ka9q.net> 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
<bruce(a)perens.com> 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.
636
days inactive
637
days old
8 comments
3 participants
participants (3)
-
Bruce Perens -
Hasan N0AN -
Phil Karn