- pacsat - mailman.amsat.org

Introduction and Falconsat-3 question
by Mark L. Hammond 27 Oct '22

27 Oct '22

Hello PACSAT Team---it was great to learn about this project from Jonathan at the recent AMSAT Symposium. I'm delighted to hear that you're working on a PACSAT version of something new... It was the original microsats/pacsats project and launch that got me interested in satellite communications, so I've been doing it for a while. Happy to give opinions or suggestions when needed--don't be afraid to ask. My question--is there one day each week where you'd like me to turn ON Falconsat-3 for about 24 hours of operations? I think it'll take this 'abuse' for a while; it's predicted to reenter around April next year, so we have a few months before it's gone.... Putting the satellite on an operation schedule will help people know when to expect it to be on. I though you all might enjoy listening/working it, making recordings, tests, whatever, while we still have it working. A challenge is that the orbit precesses like 30 mins per day, so eventually it shifts where all passes are during the sleeping hours...so there will some weeks where it might not be turned on... So, can you all pick the day when you'd like it on? I'll do my best to keep it going per schedule...Drew KO4MA is also on the list, and he'll help as needed I'm sure. Both of us are interested in an outline/overview of what you all imagine. I think I learned 1200 AFSK uplink (four frequencies/channels), 9600 baud FSK downlink. My preferred is 2M uplink, 70cm downlink (since it's so quiet). It'll take about 500mw to 1W on the downlink to be useable at 9600. Even more is desirable or necessary if you want to go higher than 9600... I think I'm one of the remaining dinosaurs that has experience and equipment to do 38k4 on the downlink...although wideband SDRs has changed that! 73! Mark L. Hammond [N8MH] (formerly KC4EBR) AMSAT Director and Command Station

4 3

Pacsat ConOPS document
by Bill 26 Oct '22

26 Oct '22

Attached is version 1.0 of the AMSAT PACSAT Payload conops document. We will discuss this briefly at tomorrows dev meeting. Bill

1 0

Pacsat Dev Meeting
by Bill 26 Oct '22

26 Oct '22

Pacsat Dev Meeting #2 Thu, Oct 27, 2022 8:00 PM - 10:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/909715813 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (872) 240-3212 - One-touch: tel:+18722403212,,909715813# Access Code: 909-715-813 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install Agenda: * Conops discussion * Engineering process * Task List

1 0

Prototype Code
by Chris Thompson 26 Oct '22

26 Oct '22

I mentioned to Jim and some others that I was working on some Pacsat code for an ARISS project. This is just a prototype but it may be useful, especially for those seeking to understand the protocols. I cleaned up the code a bit and checked it all in to here: https://github.com/ac2cz/Pacsat/ I leveraged some of the old 1990s code from programs like PG and PB, but they are written in an old style of C that modern gcc does not like. They also rely on the bit size of char, int and long (and time_t it seems) in a way that does not work with modern computers. So I updated much of that to use uint32_t etc. Also PB/PG are for a ground station whereas this code is for the server. So there were just a few structures and routines to leverage, but most of this is new code. This runs on Linux and has been tested on Ubuntu and the Raspberry PI. I have assumed a little endian machine, there is no code to cope with big endianess It works with Direwolf's AGW engine as the TNC. I picked that over the KISS interface so I do not have to implement the connected mode state machine for AX25. Right now this just implements the broadcast protocol. Specifically it stores the PB status for up to 10 stations, it transmits the PB status periodically, handles directory broadcast requests and file broadcast requests. The functionality to handle holes in the directory and files is not fully tested, but the broadcast of a new directory or of a new file seem to work well. I have no idea how these things were done in previous spacecraft, so I chose a linked list for the directory, which is rebuilt at startup, and a fixed structure to hold 10 stations on the PB, with memory allocated and freed for the list of holes that they supply. If the directory grows to a large size then a hash table index by file id may be useful to save CPU at the expense of memory, but it is probably not needed given the frequency of requests is likely low (per second). The code it split into files to handle the creation or parsing of Pacsat Headers and Files, the creation and maintenance of a directory and the broadcast protocol. There are also test routines for each file, which you can see at the end. These demonstrate how most of the functions work. The Pacsat header/file routines may be the most useful to leverage as they are a pain to write and probably very portable. Though I have assumed a normal C file system to load/save the files. I'm happy to answer questions or discuss with anyone if that is helpful. I don't claim any great skill in the C language, so feel free to point out any issues or make suggestions if you want. Next I am going to finish up the handling of holes and then implement FTL0 for file uploads. I want to setup a test loop to measure the relative performance of AX25 vs FX25 under simulated LEO conditions. I also want to see if this prototype will work for the mission objectives of the ARISS Student Sensor project. 73 Chris -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

3 2

Re: PACSAT Components in My Possession
by Chris Thompson 25 Oct '22

25 Oct '22

Assuming you can ship some of the parts to me in Canada then I am willing to help in whatever way I can. Either testing with the ground station I developed, porting some of the Pacsat server code that I have written for ARISS or whatever else helps. Let me know. 73 Chris G0KLA / AC2CZ On Tue, Oct 25, 2022 at 11:30 AM Jonathan Brandenburg via pacsat < pacsat(a)amsat.org> wrote: > > > > ---------- Forwarded message ---------- > From: Jonathan Brandenburg <jbrandenburg(a)amsat.org> > To: pacsat(a)amsat.org > Cc: > Bcc: > Date: Tue, 25 Oct 2022 10:29:55 -0500 > Subject: [pacsat] Re: PACSAT Components in My Possession > On 10/24/2022 4:36 PM, JIm McCullers wrote: > > Is some of each acceptable? > Absolutely! > > I need a couple Launchpad boards to work out the dimensions and header > sizes needed for a daughter board. > > The documentation is sketchy to none. > That makes sense. I figure each active pacsat developer needs at least > one and perhaps two Launchpad boards. > > When do you believe the Raspberry Pi boards will be in? > > I want to do one while working on the Launchpad daughter board. > > If it's soon that would save one shipping. > OSHPark expects the panel on Thursday and will likely ship the boards to > me quickly after receiving the panel. I expect the Raspberry Pi boards > early next week. I'd expect each pacsat developer to need three boards > at peak development to implement a two-up-one-down system. If I'm right, > it might make sense to wait until the Raspberry Pi boards arrive. (For > those that might be confused, the Raspberry Pi boards are a convenient > way to develop using the AX5043 and can be jumpered to the LaunchPad... > I've done that before.) (Also, to be clear, the Raspberry Pi boards > require assembly with surface mount components. In particular the AX5043 > has a ground pad making the use of a reflow oven beneficial. Admittedly > it could be done with hot air and hand-soldering, too.) > > As to the board you sent me, do you have the schematic available? > > I'll assume it's Kicad. Package it together with any support libraries > and send it to me. > > I'll switch to my other computer and pull up what I have. I won't have > any software specifically written for that prototype board I > accidentally sent you as I hadn't assembled one. But I think you'll find > the AX5043 portion to be a lot like the V1.3 board with the addition of > the second antenna connection. Thus, the software written for the V1.3 > board should be functional on the prototype board. > > Jonathan > > -- > Jonathan Brandenburg, KF5IDY > > > > > ---------- Forwarded message ---------- > From: Jonathan Brandenburg via pacsat <pacsat(a)amsat.org> > To: pacsat(a)amsat.org > Cc: > Bcc: > Date: Tue, 25 Oct 2022 10:29:55 -0500 > Subject: [pacsat] Re: PACSAT Components in My Possession > ----------------------------------------------- > 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 > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

2 1

Re: PACSAT Components in My Possession
by Rich Gopstein 25 Oct '22

25 Oct '22

I believe the license allowed for the code to be ported to another processor if you were talking to an ax5043. The language was ambiguous, but I believe that was the intent. Rich On Tue, Oct 25, 2022 at 12:02 PM Jonathan Brandenburg via pacsat < pacsat(a)amsat.org> wrote: > > > > ---------- Forwarded message ---------- > From: Jonathan Brandenburg <jbrandenburg(a)amsat.org> > To: pacsat(a)amsat.org > Cc: > Bcc: > Date: Tue, 25 Oct 2022 11:02:11 -0500 > Subject: [pacsat] Re: PACSAT Components in My Possession > On 10/25/2022 10:50 AM, JIm McCullers wrote: > > Do you have any files from Ax-RadioLab you used on the original board? > > I've installed the IDE but yet to have time to play with it > > I probably do have the files I originally used to investigate the AX5043 > radio. I believe they're in a virtual machine I just stumbled across > last week. I didn't post those to the repository because I used them > only as a supplement for the documentation and didn't use them to > specifically implement the software in > https://github.com/BrandenburgTech/DigitalTxRxRPi. > > I recall an interesting license restriction when using the output of > Ax-RadioLab... I believe the generated software cannot be ported to > another processor. Thus, I used the output of Ax-RadioLab only as a > supplement to documentation and didn't port the generated software. > > Jonathan > > -- > Jonathan, KF5IDY > > > > > ---------- Forwarded message ---------- > From: Jonathan Brandenburg via pacsat <pacsat(a)amsat.org> > To: pacsat(a)amsat.org > Cc: > Bcc: > Date: Tue, 25 Oct 2022 11:02:11 -0500 > Subject: [pacsat] Re: PACSAT Components in My Possession > ----------------------------------------------- > 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 >

1 0

Re: PACSAT Components in My Possession
by Jonathan Brandenburg 25 Oct '22

25 Oct '22

On 10/25/2022 10:50 AM, JIm McCullers wrote: > Do you have any files from Ax-RadioLab you used on the original board? > I've installed the IDE but yet to have time to play with it I probably do have the files I originally used to investigate the AX5043 radio. I believe they're in a virtual machine I just stumbled across last week. I didn't post those to the repository because I used them only as a supplement for the documentation and didn't use them to specifically implement the software in https://github.com/BrandenburgTech/DigitalTxRxRPi. I recall an interesting license restriction when using the output of Ax-RadioLab... I believe the generated software cannot be ported to another processor. Thus, I used the output of Ax-RadioLab only as a supplement to documentation and didn't port the generated software. Jonathan -- Jonathan, KF5IDY

1 0

PACSAT Components in My Possession
by Jonathan Brandenburg 25 Oct '22

25 Oct '22

Howdy! I confirmed the package I received this past week was the 10 x Launchpad boards That means I have the following: * 10 x TMS570 Launchpad boards * 250 x AX5043 chips * 2 x Raspberry Pi Radio Board V1.3 stencils Do I need to provide these to anybody local or remote? On the way are still: * 9 x Raspberry Pi Radio Board V1.3 PCBs -- Jonathan, KF5IDY

2 3

AMSAT Symposium?
by Rich Gopstein 20 Oct '22

20 Oct '22

Just curious who else will be attending. I'm flying out later tonight. It would be nice to meet up at some point. Rich, KD2CQ

4 7

Launchpads
by Jonathan Brandenburg (KF5IDY) 20 Oct '22

20 Oct '22

Kari (my wife) tells me 10 Launchpads arrived yesterday. Hooray! I’ve also ordered some AX5043 PCBs and a couple solder stencils. Along with the previously received AX5043 chips that should be getting us well on our way to development environments. Jonathan Sent from my iPhone

1 0

GOLF-ASCENT-FOX+ Eng Coord Session CANX
by Eric Skoog 12 Oct '22

12 Oct '22

As I mentioned at tonight's session, we will NOT hold a meeting next Wednesday as several principal team members will be attending the AMSAT Space Symposium. Consequently, our next Eng Coord Session will be on 26 October. eric (K1TVV)

1 0

Re: Pacsat conops
by Burns Fisher (AMSAT) 11 Oct '22

11 Oct '22

Brilliant. After saying it should be on the pacsat list, I did not put it there. I have now. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Sun, Oct 9, 2022 at 5:12 PM Bob Stricklin <bstrick(a)n5brg.com> wrote: > The original PACSAT software was written by Chris Jackson ZL2TPO/G7UPN. > > The open source package was written by Chris Thompson, AC2CZ. I just > downloaded his package on GitHub and noticed he made changes in it 8 days > ago. > > I think people have been working with AC2CZ software on Pacsat. > > Bob > > On Oct 9, 2022, at 2:44 PM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> wrote: > > This all needs to be on the PACSAT list, especially so Chris will see it > and so we are openly sharing the info. Unless there is different > FalconSat-3 ground software, Chris wrote it as a variant of FoxTelem, and > it is totally open source. I don't know of any FalconSat-3 software that > we sell, unless that was sometime ago. > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Sun, Oct 9, 2022 at 3:35 PM Bob Stricklin <bstrick(a)n5brg.com> wrote: > >> >> >> Includes some minor changes in wording a spelling change and comments on >> PACSAT protocol. >> >> I have found some of the info on FalconSat on the web but maybe this >> needs more understanding. >> >> Probably will make enough changes in the software of PACSAT that the >> ground station software needs to be different. >> I think early on AMSAT was controlling the ground station software for >> some revenue. Will need to decide if it is open source or still controlled. >> >> Bob >> >> >> > On Oct 9, 2022, at 11:38 AM, Bill <bill(a)brconnect.com> wrote: >> > >> > My project objectives are simple: >> > >> > Phase I - build something simple, using existing and proven bbs >> protocols. Have it available ASAP for the next launch opportunity. >> > >> > Phase II - build it better....... >> > >> > Here is my conops so far. Thanks for helping me author it. Either edit >> this doc and redistribute, or send changes and additions to me and I will >> incorporate them... >> > >> > Lets try and meet using GoToMeeting next Thursday. >> > >> > Thanks for helping me. My skin cancer surgery was simple and provided >> a complete cure, but the follow-on plastic surgery to repair things is >> extensive. >> > ( 2.5 hrs in surgery. 2nd surgery in a few weeks....) >> > >> > Bill >> > >> > >> > <PacsatConOps2.odt> >> >> >

2 1

AX5043 Stock
by Jonathan Brandenburg 10 Oct '22

10 Oct '22

Hello, I received our order of 250 x AX5043 chips today. Jonathan -- Jonathan Brandenburg, KF5IDY

1 0

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/[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