- pacsat - mailman.amsat.org

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/[email protected] > 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 06 Oct '22

06 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 06 Oct '22

06 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 06 Oct '22

06 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/[email protected] > 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

TMS570 eval kits (Launchpad)
by Burns Fisher (AMSAT) 27 Sep '22

27 Sep '22

To help figure out what eval board to get here is some info: First, the processor on the RT-IHU is a TMS570LS0914 The info about the Launchpad that I used to initially develop Golf software is here (thanks to Hemeir to whom I gave it): The processor model in the dev kit is TMS570LS1224CPGE001. The dev kit's part number is: LAUNCHXL2-TMS57012 ------------------------------------ To be honest, I have not really discovered a table showing the differences among the TMS570 versions. All I know is that this one was adequate. Which one do you have Rich? 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

3 4

Fwd: TMS570 eval kits (Launchpad)
by JIm McCullers 27 Sep '22

27 Sep '22

DigiKey has no evaluation kits in stock. Mouser has 17 of the LAUNCHXL2570LC43 (R5F) kits in stock. They expect 95 of the LAUNXL2-TMS57012 (R4F) kits to be available 11/28/2022. Jim WA4CWI more info... the LC is an R5F and the LS is an R4F. https://training.ti.com/hercules-arm-cortex-r-processor-r4-compared-r5 Should we stick with the LS launchpad? Bill

1 0

Serial line for program loader
by Burns Fisher (AMSAT) 26 Sep '22

26 Sep '22

Hi Heimir, It has been so long since I did anything with serial ports on the TMS570 that I totally forgot something important. I'm putting this on the software list too to help anyone else remember what is going on, and especially Zach. Also on the pacsat list mainly because of the info about the HET, which some pacsat people may need (my condolences). Pacsat folks, Heimir has written a code loader that loads over the serial port via the satellite umbilical so we can update code after the satellite is assembled. First you need to know that the TMS570 has a gadget called the HET (High End Timer). This is a programmable peripheral that has a fairly high-speed and accurate clock. The "programmable" part is really microcode in the old computer sense. It uses an "assembly language" to do low level things like wait for a clock tick, raise this pin, and branch to one of 3 or so different places depending (and do something else too by the way). I am pretty good at assembly language in several computers, and this is really horrible. TI gives you a special "HET IDE" to write programs in it but I mainly found example programs and modified them slightly. Here is an example of what it looks like: SCITX CNT { next= Lm10, reg = T, max= 64, irq = OFF,data=0} ;****Baud rate writes to max value here! Lm10 BR { next= SCIRX, cond_addr= Lm11, event = ZERO} ;Every BAUD_DIVIDER + 1 LRP, send out one bit ;DJZ checks if any active bits needs to send out Lm11 DJZ { next=SendOverINT,cond_addr=SCIRX,reg=A,irq=OFF,data=0};***set to number of bit to transfer ;CNT is used to generate the interrupt when sending is done SendOverINT CNT { reg=A,irq=ON,max=9,data=0}; ;SHFT out the data to the TX1_PIN Lm12 SHFT { next=SCIRX,smode=OR0,prv=OFF,cond_addr=SCIRX,cond=UNC,pin=TX1_PIN,reg=A,irq=OFF,data=0x0}; **Data goes here Next, the TMS570 has two serial port hardware devices called SCI and SCILIN (LIN has some fancier capabilities that I don't right now remember). However, we needed three serial ports: 1) The console line and code loader. 2) Talk to the SDR (Ettus E310) 3) Talk to the ADAC What I did was assign the 2 and 3 to the SCI and SCILIN, and the console to one of the two HETs. Yes, that HET has firmware to make it emulate a serial port. (The other HET has firmware to emulate an I2c master peripheral because the TMS570 has only one hardware I2c peripheral). So here is the critical thing, Heimir: We either will need to include the HET firmware as part of the flash loader or else use one of the hardware serial lines for the console. And if we do that, it will mean changes to the V2 RT-IHU (the pins for the two hardware serial ports currently go through a bus switch, while the console for each processor has its own set of bus lines). I don't know where you are now, but I'd suggest you get it working with one of the hardware serial lines--probably just what you did with the LaunchPad--and we can decide how we are going to do this a bit later (but before Zach finishes the layout for RTIHU V2). Just remember that when you are using the hardware serial lines, they go through the bus switch and only connect to one of the processors at a time. Sorry to throw this in...I had totally forgotten, as I said before. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0