(Removing the individual names which are all on the pacsat mailing list (I hope).
Regarding speed: I think this is all part of what we need to find out in our CONOPS. In particular, is this payload intended to be an experiment to "widen the technology horizon" or is it "functional", i.e. intended mainly to give hams a capability that they want/need. Or where in between.
As I have said before, the most common (need a reference--I could be wrong) satellite radio these days is the ICOM 9700 which stupidly does not support 9600 baud uplinks! So if this payload is intended for function, I'd argue that we need to support a slower speed; specifically a COMMON slower speed. AX.25 1200 is the common denominator here. For purely "expanding the horizons" we would have to accept that fewer hams will use it, at least not at first.
BUT one of the cool things about Bill's design is that it has four programmable receivers. They don't all have to be programmed for the same format. In fact, each individual receiver could also change to (for example) try out different formats each week or month. I guess I'd argue that at least one receiver should always be on AX.25 both for commanding and as the lowest common denominator that most everyone can use.
The single downlink is a different story. That could certainly change from one format to another, but it is possible to receive 9600 baud on the IC9700 so a higher speed downlink is less of an issue.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Thu, Oct 6, 2022 at 11:16 PM Bob Stricklin via pacsat pacsat@amsat.org wrote:
---------- Forwarded message ---------- From: Bob Stricklin bstrick@n5brg.com To: "minyard@acm.org" minyard@acm.org Cc: Rich Gopstein rich@ourowndomain.com, Bill Reed bill@brconnect.com, "pacsat@amsat.org" pacsat@amsat.org Bcc: Date: Fri, 7 Oct 2022 03:16:14 +0000 Subject: [pacsat] Re: Modulation options I would like to see a faster uplink speed for than 1200 baud and possible higher operating frequencies.
1200 baud seems like old technology. The passes on LEO satellites do not offer the user a lot of time to connect and load messages. At one time there was the ability to load/pull parts of message on a pass and fill on a later pass. Thats work. Having a slower upload rate may mean the user will not use any passes but the overhead passes effectively. Higher speeds may mean you only plan to use the near overhead pass with a simpler antenna system or lower power.
Maybe current user base has a larger pool of equipment to support 1200 baud but with newer radios/sdr is it difficult to move them up to higher speeds? Maybe we should be looking at the user requirements and offer a solution. Higher seeds may put more strain on available memory. Higher speeds probably mean more power needed but possibly more speed may mean the transmitter is less active with fewer retries?
I like the idea of using the most advanced modulation which is most efficient if we can expect the user base to embrace the higher speed.
The operating schedule on a LOE seems to be limited due to battery and charge time needed. Speed communicating will impact this.
I have come to understand the falcon sat is so far south and low that there is very limited time to expect to work that system. The control operators are more taxed with limited/no access also. Higher speeds would help when the satellite is near the end of its life cycle.
Just some thoughts I have been having on this.
Bob
On Oct 6, 2022, at 8:50 PM, Corey Minyard minyard@acm.org wrote:
On Tue, Sep 27, 2022 at 04:12:42PM -0400, Rich Gopstein wrote:
Corey brings up a good point - what are we trying to accomplish with
this
board? I might have missed some early discussions about the goal, so forgive me if this has been discussed already.
Yes, it would be nice to have "Commander's Intent" on this. It helps know what to do.
-corey
Are we trying to solve pacsat only, or are we looking to design a more flexible board that might be able to do more than just the pacsat protocol? Is there an advantage to sticking with known off-the-shelf RF parts (i.e. the AX5043), or should we consider doing something more
SDR-ish.
That might help us decide if the TMS570 is the "right" processor to get.
Rich
On Tue, Sep 27, 2022 at 3:42 PM Corey Minyard minyard@acm.org wrote:
On Tue, Sep 27, 2022 at 10:03:27AM -0500, Bill Reed wrote:
I agree that Direwolf is probably a better performer. Can we get an
audio
stream out of an AX5043?
It's not so much that we use direwolf, which we can't do. It's if we are going to consider other options.
It sounds like, from Burn's description, that the AX5043 does FM demodulation then AFSK (and I assume HDLC). The packets from AFSK are then sent to the main processor where unscrambling (is this used to pseudo-ramdomize the data, or whiten it?) and FEC is done. That's not standard, as he said.
The FEC is going to go a long way to improving the performance. You could still do better with OFDM, but the current design is probably good enough.
-corey
On 9/23/2022 2:06 PM, Corey Minyard wrote:
I looked a bit last night at the ax5043; I didn't realize (I should
have
remembered) that it doesn't just convert to baseband, it actually demodulates the signal. Are current designs just using that for FM demodulation and doing the AFSK modem in the TMS570? I don't see a
way
it could do both.
It does appear to do GMSK. The only concern there is if it can
support
the polynomial used by G3RUH for randomization, I think. I'd be surprised if it didn't. But I don't have the programmer's guide. And it doesn't matter, I guess, if it can't do FM and GMSK at the
same
time.
For AFSK, you can do a lot better than what a hardware decoder can
do.
See
https://url.emailprotection.link/?b4KLFBK2m9SvIJAPW7D7wiZKHhCuA-kEbV_J1PiUeM...
for details. direwolf can pull signals out of the noise in a way
that
a
hardware decoder can't. The difference is significant. I've done
some
thing in my modem that can improve things even more.
There is a similar situation for 9600:
https://url.emailprotection.link/?bVHpCyw8iUbEEr6dy6s-3ZNlFwYbJrC-J66q9Qw-ta...
But that's only the receive side, since this would only be
transmitting
it doesn't matter.
You could probably do the AFSK demodulation on a TMS570. Modulation
of
9600 can probably be table driven, so that should be doable.
Note that there are far better modulation techniques than these.
Almost
anything being done now is using OFDM of some type. VARA is taking
over
in the packet world. All modern modulation for cell phones is
OFDM. I
think digital TV is, too. OFDM is certainly better for fading and multipath and since it's using low-baud subcarriers I'd guess it's better for doppler, too, but that's just a guess. It would affect
the
orthogonality (?) of the subcarriers though. Not sure.
You probably couldn't do OFDM on the TMS570. Certainly not 4
channels.
You would probably need one of the TI chips that has a separate DSP.
On the ground side, anyone with a sound card modem and a reasonably modern PC could handle it. It would provide better performance, I'd guess singificantly better, than using AFSK and G3RUH. (It would be even better if you could get rid of putting it inside an FM carrier
and
directly modulate, but that's probably not a practical option.)
Also, on the satellite, if you converted to I and Q directly from RF, and you had a DSP or a fast enough processor, you could get rid of
the
AX5043s and do the FM and modem in the DSP. I remember seeing single chips that could do this, but I would have to hunt to find them.
Anyway, since we are just getting started, I wanted to point out that options are available that are better from a pure technical point of view than what is currently being proposed. I know there are other concerns like the availability of current working circuits, power
budget,
timeframe, etc.
-corey - AE5KM
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
---------- Forwarded message ---------- From: Bob Stricklin via pacsat pacsat@amsat.org To: "minyard@acm.org" minyard@acm.org Cc: Rich Gopstein rich@ourowndomain.com, Bill Reed bill@brconnect.com, "pacsat@amsat.org" pacsat@amsat.org Bcc: Date: Fri, 7 Oct 2022 03:16:14 +0000 Subject: [pacsat] Re: Modulation options
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat@amsat.org To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
At some point we'll need to advance our technology into SDR rather than discrete radios. I guess the question is whether now is that time.
On Fri, Oct 7, 2022 at 9:16 AM Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
(Removing the individual names which are all on the pacsat mailing list (I hope).
Regarding speed: I think this is all part of what we need to find out in our CONOPS. In particular, is this payload intended to be an experiment to "widen the technology horizon" or is it "functional", i.e. intended mainly to give hams a capability that they want/need. Or where in between.
As I have said before, the most common (need a reference--I could be wrong) satellite radio these days is the ICOM 9700 which stupidly does not support 9600 baud uplinks! So if this payload is intended for function, I'd argue that we need to support a slower speed; specifically a COMMON slower speed. AX.25 1200 is the common denominator here. For purely "expanding the horizons" we would have to accept that fewer hams will use it, at least not at first.
BUT one of the cool things about Bill's design is that it has four programmable receivers. They don't all have to be programmed for the same format. In fact, each individual receiver could also change to (for example) try out different formats each week or month. I guess I'd argue that at least one receiver should always be on AX.25 both for commanding and as the lowest common denominator that most everyone can use.
The single downlink is a different story. That could certainly change from one format to another, but it is possible to receive 9600 baud on the IC9700 so a higher speed downlink is less of an issue.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Thu, Oct 6, 2022 at 11:16 PM Bob Stricklin via pacsat pacsat@amsat.org wrote:
---------- Forwarded message ---------- From: Bob Stricklin bstrick@n5brg.com To: "minyard@acm.org" minyard@acm.org Cc: Rich Gopstein rich@ourowndomain.com, Bill Reed bill@brconnect.com, "pacsat@amsat.org" pacsat@amsat.org Bcc: Date: Fri, 7 Oct 2022 03:16:14 +0000 Subject: [pacsat] Re: Modulation options I would like to see a faster uplink speed for than 1200 baud and possible higher operating frequencies.
1200 baud seems like old technology. The passes on LEO satellites do not offer the user a lot of time to connect and load messages. At one time there was the ability to load/pull parts of message on a pass and fill on a later pass. Thats work. Having a slower upload rate may mean the user will not use any passes but the overhead passes effectively. Higher speeds may mean you only plan to use the near overhead pass with a simpler antenna system or lower power.
Maybe current user base has a larger pool of equipment to support 1200 baud but with newer radios/sdr is it difficult to move them up to higher speeds? Maybe we should be looking at the user requirements and offer a solution. Higher seeds may put more strain on available memory. Higher speeds probably mean more power needed but possibly more speed may mean the transmitter is less active with fewer retries?
I like the idea of using the most advanced modulation which is most efficient if we can expect the user base to embrace the higher speed.
The operating schedule on a LOE seems to be limited due to battery and charge time needed. Speed communicating will impact this.
I have come to understand the falcon sat is so far south and low that there is very limited time to expect to work that system. The control operators are more taxed with limited/no access also. Higher speeds would help when the satellite is near the end of its life cycle.
Just some thoughts I have been having on this.
Bob
On Oct 6, 2022, at 8:50 PM, Corey Minyard minyard@acm.org wrote:
On Tue, Sep 27, 2022 at 04:12:42PM -0400, Rich Gopstein wrote:
Corey brings up a good point - what are we trying to accomplish with
this
board? I might have missed some early discussions about the goal, so forgive me if this has been discussed already.
Yes, it would be nice to have "Commander's Intent" on this. It helps know what to do.
-corey
Are we trying to solve pacsat only, or are we looking to design a more flexible board that might be able to do more than just the pacsat protocol? Is there an advantage to sticking with known off-the-shelf
RF
parts (i.e. the AX5043), or should we consider doing something more
SDR-ish.
That might help us decide if the TMS570 is the "right" processor to
get.
Rich
On Tue, Sep 27, 2022 at 3:42 PM Corey Minyard minyard@acm.org wrote:
On Tue, Sep 27, 2022 at 10:03:27AM -0500, Bill Reed wrote:
I agree that Direwolf is probably a better performer. Can we get an
audio
stream out of an AX5043?
It's not so much that we use direwolf, which we can't do. It's if we are going to consider other options.
It sounds like, from Burn's description, that the AX5043 does FM demodulation then AFSK (and I assume HDLC). The packets from AFSK are then sent to the main processor where unscrambling (is this used to pseudo-ramdomize the data, or whiten it?) and FEC is done. That's not standard, as he said.
The FEC is going to go a long way to improving the performance. You could still do better with OFDM, but the current design is
probably
good enough.
-corey
On 9/23/2022 2:06 PM, Corey Minyard wrote: > I looked a bit last night at the ax5043; I didn't realize (I should
have
> remembered) that it doesn't just convert to baseband, it actually > demodulates the signal. Are current designs just using that for FM > demodulation and doing the AFSK modem in the TMS570? I don't see a
way
> it could do both. > > It does appear to do GMSK. The only concern there is if it can
support
> the polynomial used by G3RUH for randomization, I think. I'd be > surprised if it didn't. But I don't have the programmer's guide. > And it doesn't matter, I guess, if it can't do FM and GMSK at the
same
> time. > > For AFSK, you can do a lot better than what a hardware decoder can
do.
> See
https://url.emailprotection.link/?b4KLFBK2m9SvIJAPW7D7wiZKHhCuA-kEbV_J1PiUeM...
> for details. direwolf can pull signals out of the noise in a way
that
a
> hardware decoder can't. The difference is significant. I've done
some
> thing in my modem that can improve things even more. > > There is a similar situation for 9600: >
https://url.emailprotection.link/?bVHpCyw8iUbEEr6dy6s-3ZNlFwYbJrC-J66q9Qw-ta...
> But that's only the receive side, since this would only be
transmitting
> it doesn't matter. > > You could probably do the AFSK demodulation on a TMS570.
Modulation of
> 9600 can probably be table driven, so that should be doable. > > Note that there are far better modulation techniques than these.
Almost
> anything being done now is using OFDM of some type. VARA is taking
over
> in the packet world. All modern modulation for cell phones is
OFDM. I
> think digital TV is, too. OFDM is certainly better for fading and > multipath and since it's using low-baud subcarriers I'd guess it's > better for doppler, too, but that's just a guess. It would affect
the
> orthogonality (?) of the subcarriers though. Not sure. > > You probably couldn't do OFDM on the TMS570. Certainly not 4
channels.
> You would probably need one of the TI chips that has a separate DSP. > > On the ground side, anyone with a sound card modem and a reasonably > modern PC could handle it. It would provide better performance, I'd > guess singificantly better, than using AFSK and G3RUH. (It would be > even better if you could get rid of putting it inside an FM carrier
and
> directly modulate, but that's probably not a practical option.) > > Also, on the satellite, if you converted to I and Q directly from
RF,
> and you had a DSP or a fast enough processor, you could get rid of
the
> AX5043s and do the FM and modem in the DSP. I remember seeing
single
> chips that could do this, but I would have to hunt to find them. > > Anyway, since we are just getting started, I wanted to point out
that
> options are available that are better from a pure technical point of > view than what is currently being proposed. I know there are other > concerns like the availability of current working circuits, power
budget,
> timeframe, etc. > > -corey - AE5KM > ----------------------------------------------- > pacsat mailing list -- pacsat@amsat.org > View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
> To unsubscribe send an email to pacsat-leave@amsat.org > Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
---------- Forwarded message ---------- From: Bob Stricklin via pacsat pacsat@amsat.org To: "minyard@acm.org" minyard@acm.org Cc: Rich Gopstein rich@ourowndomain.com, Bill Reed bill@brconnect.com, "pacsat@amsat.org" pacsat@amsat.org Bcc: Date: Fri, 7 Oct 2022 03:16:14 +0000 Subject: [pacsat] Re: Modulation options
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat@amsat.org To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat@amsat.org To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
On Fri, Oct 07, 2022 at 09:15:32AM -0400, Burns Fisher (AMSAT) wrote:
(Removing the individual names which are all on the pacsat mailing list (I hope).
Regarding speed: I think this is all part of what we need to find out in our CONOPS. In particular, is this payload intended to be an experiment to "widen the technology horizon" or is it "functional", i.e. intended mainly to give hams a capability that they want/need. Or where in between.
As I have said before, the most common (need a reference--I could be wrong) satellite radio these days is the ICOM 9700 which stupidly does not support 9600 baud uplinks! So if this payload is intended for function, I'd argue that we need to support a slower speed; specifically a COMMON slower speed. AX.25 1200 is the common denominator here. For purely "expanding the horizons" we would have to accept that fewer hams will use it, at least not at first.
A few notes here:
Just because you can't do "standard" 9600 baud on an uplink does not limit you to other options. The standard 9600 modulations used is kind of frail. You could do 4800, 7200, or whatever.
I don't completely understand the AX.25 1200 comment. From what others have said here, we are adding convolutional encoding on top of that, so it's non-standard, anyway. If that's the case, you have to have special software, anyway, to run this. If you have to have special software, anyway, the modulation type really doesn't matter. You can't just run soundmodem or direwolf as it is.
Also, the primary limitation of the standard AX.25 1200 modulation isn't really the 1200 baud rate. It's all the overhead added by AX.25 and by the AFSK modulation. Standard AFSK has a 300ms header and 100ms trailer, adding .4 seconds to all packets and carries no data. And a better protocol than AX.25 could carry data in the connect message and close message, use window-based flow control, and probably a few other things to increase efficiency.
Again, the question here is what we are trying to accomplish. If we are going to get something in space in 2024, we probably aren't going to be able to do much new. If we have more time, then we can look at other things. Better modulation will require either new hardware coders or a faster CPU or a CPU with DSPs and that will add time. Plus time to develop the modulation and protocols, which is not easy.
Perhaps 4 uplinks and some sort of protocol to detect and use the unused links is enough for one iteration. That's certainly an improvement.
-corey
BUT one of the cool things about Bill's design is that it has four programmable receivers. They don't all have to be programmed for the same format. In fact, each individual receiver could also change to (for example) try out different formats each week or month. I guess I'd argue that at least one receiver should always be on AX.25 both for commanding and as the lowest common denominator that most everyone can use.
The single downlink is a different story. That could certainly change from one format to another, but it is possible to receive 9600 baud on the IC9700 so a higher speed downlink is less of an issue.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Thu, Oct 6, 2022 at 11:16 PM Bob Stricklin via pacsat pacsat@amsat.org wrote:
---------- Forwarded message ---------- From: Bob Stricklin bstrick@n5brg.com To: "minyard@acm.org" minyard@acm.org Cc: Rich Gopstein rich@ourowndomain.com, Bill Reed bill@brconnect.com, "pacsat@amsat.org" pacsat@amsat.org Bcc: Date: Fri, 7 Oct 2022 03:16:14 +0000 Subject: [pacsat] Re: Modulation options I would like to see a faster uplink speed for than 1200 baud and possible higher operating frequencies.
1200 baud seems like old technology. The passes on LEO satellites do not offer the user a lot of time to connect and load messages. At one time there was the ability to load/pull parts of message on a pass and fill on a later pass. Thats work. Having a slower upload rate may mean the user will not use any passes but the overhead passes effectively. Higher speeds may mean you only plan to use the near overhead pass with a simpler antenna system or lower power.
Maybe current user base has a larger pool of equipment to support 1200 baud but with newer radios/sdr is it difficult to move them up to higher speeds? Maybe we should be looking at the user requirements and offer a solution. Higher seeds may put more strain on available memory. Higher speeds probably mean more power needed but possibly more speed may mean the transmitter is less active with fewer retries?
I like the idea of using the most advanced modulation which is most efficient if we can expect the user base to embrace the higher speed.
The operating schedule on a LOE seems to be limited due to battery and charge time needed. Speed communicating will impact this.
I have come to understand the falcon sat is so far south and low that there is very limited time to expect to work that system. The control operators are more taxed with limited/no access also. Higher speeds would help when the satellite is near the end of its life cycle.
Just some thoughts I have been having on this.
Bob
On Oct 6, 2022, at 8:50 PM, Corey Minyard minyard@acm.org wrote:
On Tue, Sep 27, 2022 at 04:12:42PM -0400, Rich Gopstein wrote:
Corey brings up a good point - what are we trying to accomplish with
this
board? I might have missed some early discussions about the goal, so forgive me if this has been discussed already.
Yes, it would be nice to have "Commander's Intent" on this. It helps know what to do.
-corey
Are we trying to solve pacsat only, or are we looking to design a more flexible board that might be able to do more than just the pacsat protocol? Is there an advantage to sticking with known off-the-shelf RF parts (i.e. the AX5043), or should we consider doing something more
SDR-ish.
That might help us decide if the TMS570 is the "right" processor to get.
Rich
On Tue, Sep 27, 2022 at 3:42 PM Corey Minyard minyard@acm.org wrote:
On Tue, Sep 27, 2022 at 10:03:27AM -0500, Bill Reed wrote:
I agree that Direwolf is probably a better performer. Can we get an
audio
stream out of an AX5043?
It's not so much that we use direwolf, which we can't do. It's if we are going to consider other options.
It sounds like, from Burn's description, that the AX5043 does FM demodulation then AFSK (and I assume HDLC). The packets from AFSK are then sent to the main processor where unscrambling (is this used to pseudo-ramdomize the data, or whiten it?) and FEC is done. That's not standard, as he said.
The FEC is going to go a long way to improving the performance. You could still do better with OFDM, but the current design is probably good enough.
-corey
On 9/23/2022 2:06 PM, Corey Minyard wrote: > I looked a bit last night at the ax5043; I didn't realize (I should
have
> remembered) that it doesn't just convert to baseband, it actually > demodulates the signal. Are current designs just using that for FM > demodulation and doing the AFSK modem in the TMS570? I don't see a
way
> it could do both. > > It does appear to do GMSK. The only concern there is if it can
support
> the polynomial used by G3RUH for randomization, I think. I'd be > surprised if it didn't. But I don't have the programmer's guide. > And it doesn't matter, I guess, if it can't do FM and GMSK at the
same
> time. > > For AFSK, you can do a lot better than what a hardware decoder can
do.
> See
https://url.emailprotection.link/?b4KLFBK2m9SvIJAPW7D7wiZKHhCuA-kEbV_J1PiUeM...
> for details. direwolf can pull signals out of the noise in a way
that
a
> hardware decoder can't. The difference is significant. I've done
some
> thing in my modem that can improve things even more. > > There is a similar situation for 9600: >
https://url.emailprotection.link/?bVHpCyw8iUbEEr6dy6s-3ZNlFwYbJrC-J66q9Qw-ta...
> But that's only the receive side, since this would only be
transmitting
> it doesn't matter. > > You could probably do the AFSK demodulation on a TMS570. Modulation
of
> 9600 can probably be table driven, so that should be doable. > > Note that there are far better modulation techniques than these.
Almost
> anything being done now is using OFDM of some type. VARA is taking
over
> in the packet world. All modern modulation for cell phones is
OFDM. I
> think digital TV is, too. OFDM is certainly better for fading and > multipath and since it's using low-baud subcarriers I'd guess it's > better for doppler, too, but that's just a guess. It would affect
the
> orthogonality (?) of the subcarriers though. Not sure. > > You probably couldn't do OFDM on the TMS570. Certainly not 4
channels.
> You would probably need one of the TI chips that has a separate DSP. > > On the ground side, anyone with a sound card modem and a reasonably > modern PC could handle it. It would provide better performance, I'd > guess singificantly better, than using AFSK and G3RUH. (It would be > even better if you could get rid of putting it inside an FM carrier
and
> directly modulate, but that's probably not a practical option.) > > Also, on the satellite, if you converted to I and Q directly from RF, > and you had a DSP or a fast enough processor, you could get rid of
the
> AX5043s and do the FM and modem in the DSP. I remember seeing single > chips that could do this, but I would have to hunt to find them. > > Anyway, since we are just getting started, I wanted to point out that > options are available that are better from a pure technical point of > view than what is currently being proposed. I know there are other > concerns like the availability of current working circuits, power
budget,
> timeframe, etc. > > -corey - AE5KM > ----------------------------------------------- > pacsat mailing list -- pacsat@amsat.org > View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
> To unsubscribe send an email to pacsat-leave@amsat.org > Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
---------- Forwarded message ---------- From: Bob Stricklin via pacsat pacsat@amsat.org To: "minyard@acm.org" minyard@acm.org Cc: Rich Gopstein rich@ourowndomain.com, Bill Reed bill@brconnect.com, "pacsat@amsat.org" pacsat@amsat.org Bcc: Date: Fri, 7 Oct 2022 03:16:14 +0000 Subject: [pacsat] Re: Modulation options
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat@amsat.org To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat@amsat.org To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
My apologies. I should not have said AX.25. I was really talking about (it you'll let me use OSI terms) the physical layer. I.e. AFSK 1200 but not specifying what the actual headers FEC, etc looks like (i.e. not talking about the data-link layer). I'm also not talking about using software like direwolf or whatever. But if we stick with the pacsat protocol, then we can also use Chris Thompson's software for working with Falconsat-3.
You make a good point that other data rates besides 1200 and 9600 should be possible. My main interest is ensuring that HARDWARE that many hams have can be used, and my example is the ICOM 9700. Oddly, the 9100 or the 910 would work fine with G3RUH, as would a Kenwood TS-2000.
73,
Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software
On Fri, Oct 7, 2022 at 9:37 PM Corey Minyard minyard@acm.org wrote:
On Fri, Oct 07, 2022 at 09:15:32AM -0400, Burns Fisher (AMSAT) wrote:
(Removing the individual names which are all on the pacsat mailing list (I hope).
Regarding speed: I think this is all part of what we need to find out in our CONOPS. In particular, is this payload intended to be an experiment to "widen the technology horizon" or is it "functional", i.e. intended mainly to give hams a capability that they want/need. Or where in between.
As I have said before, the most common (need a reference--I could be wrong) satellite radio these days is the ICOM 9700 which stupidly does not support 9600 baud uplinks! So if this payload is intended for function, I'd argue that we need to support a slower speed; specifically a COMMON slower speed. AX.25 1200 is the common denominator here. For purely "expanding the horizons" we would have to accept that fewer hams will use it, at least not at first.
A few notes here:
Just because you can't do "standard" 9600 baud on an uplink does not limit you to other options. The standard 9600 modulations used is kind of frail. You could do 4800, 7200, or whatever.
I don't completely understand the AX.25 1200 comment. From what others have said here, we are adding convolutional encoding on top of that, so it's non-standard, anyway. If that's the case, you have to have special software, anyway, to run this. If you have to have special software, anyway, the modulation type really doesn't matter. You can't just run soundmodem or direwolf as it is.
Also, the primary limitation of the standard AX.25 1200 modulation isn't really the 1200 baud rate. It's all the overhead added by AX.25 and by the AFSK modulation. Standard AFSK has a 300ms header and 100ms trailer, adding .4 seconds to all packets and carries no data. And a better protocol than AX.25 could carry data in the connect message and close message, use window-based flow control, and probably a few other things to increase efficiency.
Again, the question here is what we are trying to accomplish. If we are going to get something in space in 2024, we probably aren't going to be able to do much new. If we have more time, then we can look at other things. Better modulation will require either new hardware coders or a faster CPU or a CPU with DSPs and that will add time. Plus time to develop the modulation and protocols, which is not easy.
Perhaps 4 uplinks and some sort of protocol to detect and use the unused links is enough for one iteration. That's certainly an improvement.
-corey
BUT one of the cool things about Bill's design is that it has four programmable receivers. They don't all have to be programmed for the same format. In fact, each individual receiver could also change to (for example) try out different formats each week or month. I guess I'd argue that at least one receiver should always be on AX.25 both for commanding and as the lowest common denominator that most everyone can use.
The single downlink is a different story. That could certainly change from one format to another, but it is possible to receive 9600 baud on the IC9700 so a higher speed downlink is less of an issue.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Thu, Oct 6, 2022 at 11:16 PM Bob Stricklin via pacsat pacsat@amsat.org wrote:
---------- Forwarded message ---------- From: Bob Stricklin bstrick@n5brg.com To: "minyard@acm.org" minyard@acm.org Cc: Rich Gopstein rich@ourowndomain.com, Bill Reed bill@brconnect.com, "pacsat@amsat.org" pacsat@amsat.org Bcc: Date: Fri, 7 Oct 2022 03:16:14 +0000 Subject: [pacsat] Re: Modulation options I would like to see a faster uplink speed for than 1200 baud and possible higher operating frequencies.
1200 baud seems like old technology. The passes on LEO satellites do not offer the user a lot of time to connect and load messages. At one time there was the ability to load/pull parts of message on a pass and fill on a later pass. Thats work. Having a slower upload rate may mean the user will not use any passes but the overhead passes effectively. Higher speeds may mean you only plan to use the near overhead pass with a simpler antenna system or lower power.
Maybe current user base has a larger pool of equipment to support 1200 baud but with newer radios/sdr is it difficult to move them up to higher speeds? Maybe we should be looking at the user requirements and offer a solution. Higher seeds may put more strain on available memory. Higher speeds probably mean more power needed but possibly more speed may mean the transmitter is less active with fewer retries?
I like the idea of using the most advanced modulation which is most efficient if we can expect the user base to embrace the higher speed.
The operating schedule on a LOE seems to be limited due to battery and charge time needed. Speed communicating will impact this.
I have come to understand the falcon sat is so far south and low that there is very limited time to expect to work that system. The control operators are more taxed with limited/no access also. Higher speeds would help when the satellite is near the end of its life cycle.
Just some thoughts I have been having on this.
Bob
On Oct 6, 2022, at 8:50 PM, Corey Minyard minyard@acm.org wrote:
On Tue, Sep 27, 2022 at 04:12:42PM -0400, Rich Gopstein wrote:
Corey brings up a good point - what are we trying to accomplish with
this
board? I might have missed some early discussions about the goal, so forgive me if this has been discussed already.
Yes, it would be nice to have "Commander's Intent" on this. It helps know what to do.
-corey
Are we trying to solve pacsat only, or are we looking to design a more flexible board that might be able to do more than just the pacsat protocol? Is there an advantage to sticking with known off-the-shelf RF parts (i.e. the AX5043), or should we consider doing something more
SDR-ish.
That might help us decide if the TMS570 is the "right" processor to get.
Rich
On Tue, Sep 27, 2022 at 3:42 PM Corey Minyard minyard@acm.org wrote:
On Tue, Sep 27, 2022 at 10:03:27AM -0500, Bill Reed wrote: > I agree that Direwolf is probably a better performer. Can we get an audio > stream out of an AX5043?
It's not so much that we use direwolf, which we can't do. It's if we are going to consider other options.
It sounds like, from Burn's description, that the AX5043 does FM demodulation then AFSK (and I assume HDLC). The packets from AFSK are then sent to the main processor where unscrambling (is this used to pseudo-ramdomize the data, or whiten it?) and FEC is done. That's not standard, as he said.
The FEC is going to go a long way to improving the performance. You could still do better with OFDM, but the current design is probably good enough.
-corey
> > On 9/23/2022 2:06 PM, Corey Minyard wrote: >> I looked a bit last night at the ax5043; I didn't realize (I should have >> remembered) that it doesn't just convert to baseband, it actually >> demodulates the signal. Are current designs just using that for FM >> demodulation and doing the AFSK modem in the TMS570? I don't see a
way
>> it could do both. >> >> It does appear to do GMSK. The only concern there is if it can
support
>> the polynomial used by G3RUH for randomization, I think. I'd be >> surprised if it didn't. But I don't have the programmer's guide. >> And it doesn't matter, I guess, if it can't do FM and GMSK at the
same
>> time. >> >> For AFSK, you can do a lot better than what a hardware decoder can
do.
>> See
https://url.emailprotection.link/?b4KLFBK2m9SvIJAPW7D7wiZKHhCuA-kEbV_J1PiUeM...
>> for details. direwolf can pull signals out of the noise in a way
that
a >> hardware decoder can't. The difference is significant. I've done
some
>> thing in my modem that can improve things even more. >> >> There is a similar situation for 9600: >>
https://url.emailprotection.link/?bVHpCyw8iUbEEr6dy6s-3ZNlFwYbJrC-J66q9Qw-ta...
>> But that's only the receive side, since this would only be
transmitting
>> it doesn't matter. >> >> You could probably do the AFSK demodulation on a TMS570. Modulation
of
>> 9600 can probably be table driven, so that should be doable. >> >> Note that there are far better modulation techniques than these. Almost >> anything being done now is using OFDM of some type. VARA is taking over >> in the packet world. All modern modulation for cell phones is
OFDM. I
>> think digital TV is, too. OFDM is certainly better for fading and >> multipath and since it's using low-baud subcarriers I'd guess it's >> better for doppler, too, but that's just a guess. It would affect
the
>> orthogonality (?) of the subcarriers though. Not sure. >> >> You probably couldn't do OFDM on the TMS570. Certainly not 4
channels.
>> You would probably need one of the TI chips that has a separate DSP. >> >> On the ground side, anyone with a sound card modem and a reasonably >> modern PC could handle it. It would provide better performance, I'd >> guess singificantly better, than using AFSK and G3RUH. (It would be >> even better if you could get rid of putting it inside an FM carrier
and
>> directly modulate, but that's probably not a practical option.) >> >> Also, on the satellite, if you converted to I and Q directly from RF, >> and you had a DSP or a fast enough processor, you could get rid of
the
>> AX5043s and do the FM and modem in the DSP. I remember seeing single >> chips that could do this, but I would have to hunt to find them. >> >> Anyway, since we are just getting started, I wanted to point out that >> options are available that are better from a pure technical point of >> view than what is currently being proposed. I know there are other >> concerns like the availability of current working circuits, power budget, >> timeframe, etc. >> >> -corey - AE5KM >> ----------------------------------------------- >> pacsat mailing list -- pacsat@amsat.org >> View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
>> To unsubscribe send an email to pacsat-leave@amsat.org >> Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
> ----------------------------------------------- > pacsat mailing list -- pacsat@amsat.org > View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
> To unsubscribe send an email to pacsat-leave@amsat.org > Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at
https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-jM...
To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik...
---------- Forwarded message ---------- From: Bob Stricklin via pacsat pacsat@amsat.org To: "minyard@acm.org" minyard@acm.org Cc: Rich Gopstein rich@ourowndomain.com, Bill Reed bill@brconnect.com, "pacsat@amsat.org" pacsat@amsat.org Bcc: Date: Fri, 7 Oct 2022 03:16:14 +0000 Subject: [pacsat] Re: Modulation options
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat@amsat.org To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
pacsat mailing list -- pacsat@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat@amsat.org To unsubscribe send an email to pacsat-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
I've been in contact with Chris who has supplied me with an information trove he used developing the FalconSat-3 ground station software. I'll be sorting though it the next several nights, several being the variable.
I also want to study FX.25 to determine if the overhead (link) justifies the improvement in throughput. Chris is planning to do the same.
Jim McCullers WA4CWI
My apologies. I should not have said AX.25. I was really talking about
(it you'll let me use OSI terms) the physical layer. I.e. AFSK
1200 but not specifying what the actual headers FEC, etc looks like (i.e.
not talking about the data-link layer). I'm also not talking about using software like direwolf or whatever. But if we stick with the pacsat protocol, then we can also use Chris Thompson's >software for working with Falconsat-3.
You make a good point that other data rates besides 1200 and 9600 should be
possible. My main interest is ensuring that HARDWARE that many hams have can be used, and my example is the ICOM 9700. Oddly, the 9100 or the 910 would work fine with >G3RUH, as would a Kenwood TS-2000.
73,
Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software t https://mailman.amsat.org
I've been in contact with Chris who has supplied me with an information trove he used developing the FalconSat-3 ground station software. I'll be sorting though it the next several nights, several being the variable.
I also want to study FX.25 to determine if the overhead (link) justifies the improvement in throughput. Chris is planning to do the same.
Jim McCullers
WA4CWI
Oh, that's great, Jim. I also asked him if he was willing to be on this mailing list. He is no longer in the US, so he wanted to be off many of them which might have some ITAR limitiations. But this one should be all open source/ITAR-free.
participants (4)
-
Burns Fisher (AMSAT) -
Corey Minyard -
JIm McCullers -
Rich Gopstein