I've been reading some of the documents and since there are a lot of references to Pacsat generically, I'm using "FoxPac" here to mean specifically the design that we are talking about on this mailing list.
As I was reading the documentation, one thing stood out to me: There are lots of assumptions, and appropriately so, that the data rate and format is 9600 bps GMSK. One problem with this speed/format is that it is not supported by the most popular satellite radio these days, the ICOM 9700. Heaven knows why ICOM did not choose to support it, but they seem not to be doing anything about it. My thoughts below may be partly selfish since the 9700 is MY radio, but on the other hand, it IS very popular.
One workaround: According to Mark Hammond, N8MH, the 9700 CAN be used for 9600 baud reception (by collecting the IQ (essentially IF) output) and decoding it in software. Thus the big problem is the uplink. Bill's initial design calls for 4 uplink receivers and one downlink transmitter. Suppose that the uplink receivers were designed to switch baud rates on command. We could set it by default to have (say) two receiving at 1200 bps and two at 9600 (or some other number). Alternatively, choose certain days when there were 1200 baud receivers operating.
Another alternative: This is not a workaround so much as an offshoot project: Design a simple 9600 baud uplink transmitter. There already exists software and hardware for a AX5043 Raspberry Pi shield. We would "only" need to produce more shields (I believe Jonathan has that design), design a power amp for the output of the 5043, and design and write the software on the Pi. TBD whether the Pi software would do the doppler calculations, or whether it would accept commands from a traditional satellite tracking program (the latter certainly seems easier).
I just wanted to send these ideas out for people to think about. It's up to Bill whether this is anything to talk about tonight or not. Maybe it is too soon anyway.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
It’s never too soon to bring up these topics.
I really like the idea of supporting both 1200 and 9600 baud. I also really like the idea of building a 9600 transmitter.
As for the 5043 board I designed… I feel it has good potential. The only challenge I had was limited time to assemble them myself. In the end, I hand assembled 42 of them and had great success. If we build a few of them we should be able to get the assembly cost down when using an assembly shop. (Somewhere, I have an old quote from the place we assemble the RT-IHU) Given the pace I sold them I think there could be a little room to raise the price for some professional assembly, too. It seems like 100 or 200 (or more?) wouldn’t be too large a financial risk.
Alternatively, we could preassemble the key component(s) like the AX5043 and leave the simpler passive components for the end-user to assemble (a kit). It’s likely we could replace some/all of the passive components with through-hole to ease the end-user burden.
As you say, up to Bill and the vision and I love the discussion Jonathan
Sent from my iPhone
On Sep 22, 2022, at 9:12 AM, Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
I've been reading some of the documents and since there are a lot of references to Pacsat generically, I'm using "FoxPac" here to mean specifically the design that we are talking about on this mailing list.
As I was reading the documentation, one thing stood out to me: There are lots of assumptions, and appropriately so, that the data rate and format is 9600 bps GMSK. One problem with this speed/format is that it is not supported by the most popular satellite radio these days, the ICOM 9700. Heaven knows why ICOM did not choose to support it, but they seem not to be doing anything about it. My thoughts below may be partly selfish since the 9700 is MY radio, but on the other hand, it IS very popular.
One workaround: According to Mark Hammond, N8MH, the 9700 CAN be used for 9600 baud reception (by collecting the IQ (essentially IF) output) and decoding it in software. Thus the big problem is the uplink. Bill's initial design calls for 4 uplink receivers and one downlink transmitter. Suppose that the uplink receivers were designed to switch baud rates on command. We could set it by default to have (say) two receiving at 1200 bps and two at 9600 (or some other number). Alternatively, choose certain days when there were 1200 baud receivers operating.
Another alternative: This is not a workaround so much as an offshoot project: Design a simple 9600 baud uplink transmitter. There already exists software and hardware for a AX5043 Raspberry Pi shield. We would "only" need to produce more shields (I believe Jonathan has that design), design a power amp for the output of the 5043, and design and write the software on the Pi. TBD whether the Pi software would do the doppler calculations, or whether it would accept commands from a traditional satellite tracking program (the latter certainly seems easier).
I just wanted to send these ideas out for people to think about. It's up to Bill whether this is anything to talk about tonight or not. Maybe it is too soon anyway.
73,
Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------- 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
participants (2)
-
Burns Fisher (AMSAT) -
Jonathan Brandenburg (KF5IDY)