October 2022 - pacsat - mailman.amsat.org

FreeRTOS and other questions
by JIm McCullers 10 Oct '22

10 Oct '22

This is primarily intended for Burns, Rich and possibly Eric Trying to get a head start on the OS. 1. What version of FreeRTOS is being used in GOLF? 2. Compiled objects or heap allocated objects (or variables)? 3. Interrupts or polling? In the GOLF-Tee design docs the most recent version of the RT-IHU is version 1.1. Is that the latest version or is that one of the files Eric mentioned needed updating? In any case what is the proper way to extract a copy of the Kicad files. I want to open them for review. Looking at SVN, I see only a checkout process. I'm not interested in checking it out and adding to the checked out links as I have no intention of updating the files. Thanks Jim McCullers WA4CWI

3 5

ConOps
by Bill Reed 08 Oct '22

08 Oct '22

I started writing the pacsat conops document ( high level description of the scope of the project ), but since I had two surgeries this past week I am moving kind of slow. I would suggest that other ideas that might be appropriate for the conops ( VARA, BPSK, ???? ) be included. Please volunteer to help. I will share my rough draft that is 50% complete. Bill

1 0

Re: Modulation options
by Burns Fisher (AMSAT) 08 Oct '22

08 Oct '22

(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(a)amsat.org> wrote: > > > > ---------- Forwarded message ---------- > From: Bob Stricklin <bstrick(a)n5brg.com> > To: "minyard(a)acm.org" <minyard(a)acm.org> > Cc: Rich Gopstein <rich(a)ourowndomain.com>, Bill Reed <bill(a)brconnect.com>, > "pacsat(a)amsat.org" <pacsat(a)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(a)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(a)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_J1PiUe… > >>>>> 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-t… > >>>>> 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(a)amsat.org > >>>>> View archives of this mailing list at > >>> > https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-j… > >>>>> To unsubscribe send an email to pacsat-leave(a)amsat.org > >>>>> Manage all of your AMSAT-NA mailing list preferences at > >>> > https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi… > >>>> ----------------------------------------------- > >>>> pacsat mailing list -- pacsat(a)amsat.org > >>>> View archives of this mailing list at > >>> > https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-j… > >>>> To unsubscribe send an email to pacsat-leave(a)amsat.org > >>>> Manage all of your AMSAT-NA mailing list preferences at > >>> > https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi… > >>> ----------------------------------------------- > >>> pacsat mailing list -- pacsat(a)amsat.org > >>> View archives of this mailing list at > >>> > https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-j… > >>> To unsubscribe send an email to pacsat-leave(a)amsat.org > >>> Manage all of your AMSAT-NA mailing list preferences at > >>> > https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi… > >>> > > > >> ----------------------------------------------- > >> pacsat mailing list -- pacsat(a)amsat.org > >> View archives of this mailing list at > https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-j… > >> To unsubscribe send an email to pacsat-leave(a)amsat.org > >> Manage all of your AMSAT-NA mailing list preferences at > https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi… > > > > ----------------------------------------------- > > pacsat mailing list -- pacsat(a)amsat.org > > View archives of this mailing list at > https://url.emailprotection.link/?b5qYATJ4AvjJ05toBkiiLaMPlv1Y3QPE5U0sxMp-j… > > To unsubscribe send an email to pacsat-leave(a)amsat.org > > Manage all of your AMSAT-NA mailing list preferences at > https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi… > > > > ---------- Forwarded message ---------- > From: Bob Stricklin via pacsat <pacsat(a)amsat.org> > To: "minyard(a)acm.org" <minyard(a)acm.org> > Cc: Rich Gopstein <rich(a)ourowndomain.com>, Bill Reed <bill(a)brconnect.com>, > "pacsat(a)amsat.org" <pacsat(a)amsat.org> > Bcc: > Date: Fri, 7 Oct 2022 03:16:14 +0000 > Subject: [pacsat] Re: Modulation options > ----------------------------------------------- > pacsat mailing list -- pacsat(a)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(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

4 5

Re: AX5043 Order
by JIm McCullers 07 Oct '22

07 Oct '22

I would agree. Now I can go ahead an order the few I wanted for my use including your board. One things comes to mind relating to PACSAT. We have to make our final design open source which creates a good news - bad news situation. Good news - AMSAT is open source. Bad news, the components are unavailable to reproduce it. I know there are other transceiver chips available but's it's been some time since I've looked into them. Jim WA4CWI

1 0

Modulation options
by Corey Minyard 07 Oct '22

07 Oct '22

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://github.com/wb2osz/direwolf/blob/master/doc/A-Better-APRS-Packet-Dem… 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://github.com/wb2osz/direwolf/blob/master/doc/A-Better-APRS-Packet-Dem… 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

5 8

AX5043 Order
by Jonathan Brandenburg 07 Oct '22

07 Oct '22

With the discussion on this list and consultation with others, it seems prudent to buy a quantity of AX5043 chips. Based on the needs of RT-IHU and assuming PACSAT boards use the AX5043 (and a fair bit of overestimation) I'm going to order 250. It seems like a reasonable investment to push back the need to redesign our boards. In the meantime, of course, we can consider the use of other chips. Jonathan -- Jonathan Brandenburg Radio Amateur Satellite Corporation 1-214-213-1066

1 0

Fwd: BPSK on ax5043 Service Request #242527
by Rich Gopstein 07 Oct '22

07 Oct '22

---------- Forwarded message --------- From: <onhelp(a)onsemi.com> Date: Tue, Dec 17, 2019 at 11:51 AM Subject: Re: BPSK on ax5043 Service Request #242527 To: <rich(a)ourowndomain.com> Response From ON Semiconductor Service Request #242527 ON Semiconductor Technical Support Center Voice Mail: 800-282-9855 (US & Canada) Web Site: http://www.onsemi.com/pub/tech_support **************************************************************** Please do not reply to this email. Please submit any additional questions via our web site or by calling the ON Semiconductor Technical Support Center. Thank you. **************************************************************** Hello Rich Gopstein, Thank you for contacting ON Semiconductor. There is option for PSK mode only, configuration can be created with AX-RadioLab. You need to enter '1962' in the TX Periodic field on the main screen, and press enter. PSK mode, along with other more advanced options will be available in the PHY screen. If you have any further questions, please do not hesitate to contact us back. Regards, Martin ON Semiconductor Technical Support Center Subject: BPSK on ax5043 Description of customer request: I am working on software to drive an AX5043 which needs to transmit and receive BPSK. It doesn't look like AX-RadioLAB has BPSK as an option and I can't find any application notes about using BPSK on the ax5043.

3 6

Message size on these mailing lists
by Burns Fisher (AMSAT) 06 Oct '22

06 Oct '22

All the mailing lists by default have a max size of 40K. I've increased them to 500K to accommodate reasonable size attachments. But please use some care. Not only are there people with slow internet lines (hi John K!) but also limited disk space. I'd suggest it would be good to specify a smaller size if you have a chance (i.e. less resolution). For example a screen shot is often much smaller than a full picture. Another way to work around it is to only send one attachment in an email, or to put the attachment on the SVN and include a link to it. And finally, be sure that if you reply to a big email with embedded pictures, you cut off the pictures before you send it! Thanks and 73 from one of you friendly list moderators, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: [GOLF-TEE] Re: Fwd: BPSK on ax5043 Service Request #242527
by Rich Gopstein 06 Oct '22

06 Oct '22

A big concern regarding the ax5043 is that it requires the use of a proprietary Windows application to configure. If Onsemi stops maintaining that configuration program, we're screwed (unless we stick with configurations we've already generated). Rich On Thu, Oct 6, 2022 at 10:22 AM Zach Metzinger <zmetzing(a)pobox.com> wrote: > On 10/6/22 08:46, Eric Skoog wrote: > > BTW Rich - I saw in the chat room the comment you made about the AX5243 > > ONSEMI chip also being EOL. That's an interesting chip as > > well...........did you note that Digikey has over 38,000 of those in > > stock? I wonder how compatible your AX5043 code would be with those > chips? > > The AX5243 and AX5043 are essentially identical, but the former does not > have the single-ended output (in addition to the normal differential > output). We use both outputs on the RT-IHU right now (SE is 70cm down, > Diff is 2m up). Going with the '5243 means we'd have to rethink the > Cmd/Tlm paradigm between processors -- and, if one '5243 failed, we'd > lose either TX or RX with no backup. > > --- Zach > N0ZGO > > ----------------------------------------------- > Golft mailing list -- golft(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/golft@amsat.org > To unsubscribe send an email to golft-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

3 3