(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