On Sun, Jan 12, 2025 at 01:13:36AM +0000, Cameron Castillo via pacsat-dev wrote:
Hi Bill,
Interesting presentation! A couple notes:
On the FPGA design for the SDR, a significant amount of the work can be done via Xilinx IP. I think the team has the idea that most of the DSP and hardware would have to be built from scratch in verilog. For almost any design today, many people use the block diagram editor from Xilinx instead of writing their own verilog. Not only are these guaranteed to work but all the driver code is also available in their software platform (Vitis). I've looked into some of the DSP blocks they have available and the list is fairly comprehensive (IIR/FIR filters, FFTs, Freq. Synthesizer to name a few off the top of my head).
Yes, I'm aware of this. From what I can tell, the licensing is not open source on these. If that's so we can't use them on our platform. But maybe I'm wrong.
Second, I am planning on custom modulation, so those would have to be written in VHDL or Verilog. Not a show-stopper, though.
One of the other benefits is that many of Xilinx's products have hard integrated processors or have the ability to integrate soft processors (See Zynq and MicroBlaze respectively). The nice thing about these is that they support Linux development and bare-metal/RTOS configuration. We might even be able to remove the TMS570 and replace it with one of the multi-core devices. Perhaps we could have a system where Direwolf and the other processing functions are run on the same chip as the DSP. The downside to this is that I'm not sure how parallelable that would be (i.e. could we maintain four Rx channels).
If you are going to use something like a Zynq processor, why do you even need a DSP or an FPGA for this application? ;-) You could even get those fancy Zynq processors that have built-in RF subsystems. They just cost $2000 and need gobs of power. I don't know much about the MicroBlaze, how powerful it is or whatnot.
The big problem with these things is power. Zynq or Versal is right out. I'm looking to keep the entire power budget for everything outside of the PA to <1W. I think I can be successful if I play some tricks. I have no idea how much a MicroBlaze on an FPGA would use.
Also, there's a lot of functional safety things tied into the TMS570 processors. Things like lockstep processing, parity/ECC on everything, extended temperature, etc. The MicroBlaze can do lockstep, it appears, meaning that it can't be superscalar and it will be slow. I guess it says it's Harvard architecture. I don't know how it would compare to a Cortex-R5F.
I do a lot of work with Xilinx products and FPGAs at work. It's mostly for video functions, but I've found it pretty easy to understand the fundamentals of Vivado/Vitis in only a few months. With integrated peripherals like AXI and the IP blocks, it probably wouldn't take as long as everyone is thinking. I hardly ever touch verilog at work anymore...
I'm not against using an FPGA, but it would take some research. Do you have any idea of the power they would use?
As far as the amplifier project is coming, I'm back in the lab at work and want to get some more prototyping done with our actual amplifier. Does anyone on the team have extra stock of the transistor we're using for the Tx amplifier (ATF05MS004NT1)? I'd also like to get an inductor kit like this one https://www.amazon.com/First-Inductor-Assorted-1nH-270nH-42Valuesx50pcs/dp/B074QM4HNP as the one I have at work is all 0201s and I can't reliably solder it...
A book of inductors :-).
On that note, I'm happy to keep prototyping it if the team wants to go in that direction, but I think it'd be faster to go with a premade power amp. I've already created a schematic for a PA as a backup to the work I'm doing now. If we want something for Jim's test board, I could probably get something to at least prototype with a lot sooner even if we think we could do better with the discrete option. Just a suggestion.
Are you talking about a PA module as something that can be used on the satellite, or just something as a temporary solution to plug into Jim's board? And as I mentioned before, power is a big issue. I don't know much about these things, though.
Thanks,
-corey
Thanks,
Cameron Castillo
Cameron Castillo
KJ7ILB
*P*: (503) 752-8877
On Fri, Jan 10, 2025 at 8:47 AM Bill Reed [email protected] wrote:
This is a better URL...
https://github.com/AMSAT-NA/PacSatDocs/blob/main/SDR/MinyardSDR_1-9-2024.web...
-------- Forwarded Message -------- Subject: Last nights recording Date: Fri, 10 Jan 2025 09:31:07 -0600 From: Bill Reed [email protected] [email protected] To: Cameron Castillo [email protected] [email protected]
We discussed 2 things last night.
1: Start of SDR development to replace AX5043. Exciting stuff!
https://github.com/AMSAT-NA/PacSatDocs/SDR/MinyardSDR_1-9-2024
2: Discussion of 2025 budgets that haven't been approved yet. More to come....no video.
I would like to discuss your project with you at some point. Can it be prototyped on the new launchpad that Jim is working on?
Bill
pacsat-dev mailing list -- [email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
On Sat, Jan 11, 2025 at 8:15 PM Corey Minyard [email protected] wrote:
On Sun, Jan 12, 2025 at 01:13:36AM +0000, Cameron Castillo via pacsat-dev wrote:
Hi Bill,
Interesting presentation! A couple notes:
On the FPGA design for the SDR, a significant amount of the work can be done via Xilinx IP. I think the team has the idea that most of the DSP and hardware would have to be built from scratch in verilog. For almost any design today, many people use the block diagram editor from Xilinx instead of writing their own verilog. Not only are these guaranteed to work but all the driver code is also available in their software platform (Vitis). I've looked into some of the DSP blocks they have available and the list is fairly comprehensive (IIR/FIR filters, FFTs, Freq. Synthesizer to name a few off the top of my head).
Yes, I'm aware of this. From what I can tell, the licensing is not open source on these. If that's so we can't use them on our platform. But maybe I'm wrong.
Also, for the record, you have all those same building blocks with a DSP. Functions already exist to do pretty much everything you need. So from the point of view of building blocks available, I'd guess they are about the same. I think they are open source, but I need to double-check that.
I am biased towards a DSP because that's what I've used in the past, and I recognise that. But it really all comes down to:
1) Surviving the rigors of space.
2) Power usage
3) Open source
4) Accessibility - we want to build a platform that is easy for others to use.
I don't know FPGAs very well; I have done a little bit of VHDL and programmed PALs (you probably don't even know what one of those is...) so for the analysis I'm going to have to lean on others.
-corey
Second, I am planning on custom modulation, so those would have to be written in VHDL or Verilog. Not a show-stopper, though.
One of the other benefits is that many of Xilinx's products have hard integrated processors or have the ability to integrate soft processors (See Zynq and MicroBlaze respectively). The nice thing about these is that they support Linux development and bare-metal/RTOS configuration. We might even be able to remove the TMS570 and replace it with one of the multi-core devices. Perhaps we could have a system where Direwolf and the other processing functions are run on the same chip as the DSP. The downside to this is that I'm not sure how parallelable that would be (i.e. could we maintain four Rx channels).
If you are going to use something like a Zynq processor, why do you even need a DSP or an FPGA for this application? ;-) You could even get those fancy Zynq processors that have built-in RF subsystems. They just cost $2000 and need gobs of power. I don't know much about the MicroBlaze, how powerful it is or whatnot.
The big problem with these things is power. Zynq or Versal is right out. I'm looking to keep the entire power budget for everything outside of the PA to <1W. I think I can be successful if I play some tricks. I have no idea how much a MicroBlaze on an FPGA would use.
Also, there's a lot of functional safety things tied into the TMS570 processors. Things like lockstep processing, parity/ECC on everything, extended temperature, etc. The MicroBlaze can do lockstep, it appears, meaning that it can't be superscalar and it will be slow. I guess it says it's Harvard architecture. I don't know how it would compare to a Cortex-R5F.
I do a lot of work with Xilinx products and FPGAs at work. It's mostly for video functions, but I've found it pretty easy to understand the fundamentals of Vivado/Vitis in only a few months. With integrated peripherals like AXI and the IP blocks, it probably wouldn't take as long as everyone is thinking. I hardly ever touch verilog at work anymore...
I'm not against using an FPGA, but it would take some research. Do you have any idea of the power they would use?
As far as the amplifier project is coming, I'm back in the lab at work and want to get some more prototyping done with our actual amplifier. Does anyone on the team have extra stock of the transistor we're using for the Tx amplifier (ATF05MS004NT1)? I'd also like to get an inductor kit like this one https://www.amazon.com/First-Inductor-Assorted-1nH-270nH-42Valuesx50pcs/dp/B074QM4HNP as the one I have at work is all 0201s and I can't reliably solder it...
A book of inductors :-).
On that note, I'm happy to keep prototyping it if the team wants to go in that direction, but I think it'd be faster to go with a premade power amp. I've already created a schematic for a PA as a backup to the work I'm doing now. If we want something for Jim's test board, I could probably get something to at least prototype with a lot sooner even if we think we could do better with the discrete option. Just a suggestion.
Are you talking about a PA module as something that can be used on the satellite, or just something as a temporary solution to plug into Jim's board? And as I mentioned before, power is a big issue. I don't know much about these things, though.
Thanks,
-corey
Thanks,
Cameron Castillo
Cameron Castillo
KJ7ILB
*P*: (503) 752-8877
On Fri, Jan 10, 2025 at 8:47 AM Bill Reed [email protected] wrote:
This is a better URL...
https://github.com/AMSAT-NA/PacSatDocs/blob/main/SDR/MinyardSDR_1-9-2024.web...
-------- Forwarded Message -------- Subject: Last nights recording Date: Fri, 10 Jan 2025 09:31:07 -0600 From: Bill Reed [email protected] [email protected] To: Cameron Castillo [email protected] [email protected]
We discussed 2 things last night.
1: Start of SDR development to replace AX5043. Exciting stuff!
https://github.com/AMSAT-NA/PacSatDocs/SDR/MinyardSDR_1-9-2024
2: Discussion of 2025 budgets that haven't been approved yet. More to come....no video.
I would like to discuss your project with you at some point. Can it be prototyped on the new launchpad that Jim is working on?
Bill
pacsat-dev mailing list -- [email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
I did not intend to suggest using an FPGA over the DSP processors you suggested, but only that development might not be as difficult as we expect. That being said, without the use of Xilinx IP (of which most of the source code is hidden) the above is not true. The IP blocks take a lot of the effort that goes into configuring DSP slices (hard MAC blocks) and associated pipelining. It would be a significant amount of effort to recreate that.
Do you have any idea of the power they would use?
I'm working on a fairly large design at work with a Zynq, and last I checked I was at around 4.3W. As far as I've seen, that's pretty typical for our applications. I've never worked on a DSP system though. Datasheet values put one of the lower end Zynqs (ZC7Z2010) at almost 200 mA for all sources, which would end up being a max of 355 mW quiescent (assuming all supplies are 1.8V, where most of them are below that). With an application running, I'm not sure you could maintain the <1W requirement.
Are you talking about a PA module as something that can be used on the
satellite, or just something as a temporary solution to plug into Jim's board? And as I mentioned before, power is a big issue. I don't know much about these things, though.
Both. I'm saying that I can get something prototyped up for Jim's board which we can take power measurements on quickly that will also work for the flight model. If those are deemed inadequate, we can continue prototyping the discrete transistor option. I think that after looking at a lot of the options available on the Tx side and the desired voltage, efficiency is not great with either the discrete transistors or integrated amplifiers. The transistor we're using now is one of the better options, and even its efficiency is pretty bad (40-50%) considering the output power we desire. The option on the IC side sits at little less than 61% efficiency. In all, I'd say both options are comparable in terms of efficiency.
Thanks,
Cameron
-------------------------------------------------
Cameron Castillo
KJ7ILB
*P*: (503) 752-8877
--------------------------------------------------
On Sun, Jan 12, 2025 at 7:32 AM Corey Minyard [email protected] wrote:
On Sat, Jan 11, 2025 at 8:15 PM Corey Minyard [email protected] wrote:
On Sun, Jan 12, 2025 at 01:13:36AM +0000, Cameron Castillo via
pacsat-dev wrote:
Hi Bill,
Interesting presentation! A couple notes:
On the FPGA design for the SDR, a significant amount of the work can be done via Xilinx IP. I think the team has the idea that most of the DSP
and
hardware would have to be built from scratch in verilog. For almost any design today, many people use the block diagram editor from Xilinx
instead
of writing their own verilog. Not only are these guaranteed to work
but all
the driver code is also available in their software platform (Vitis).
I've
looked into some of the DSP blocks they have available and the list is fairly comprehensive (IIR/FIR filters, FFTs, Freq. Synthesizer to name
a
few off the top of my head).
Yes, I'm aware of this. From what I can tell, the licensing is not open source on these. If that's so we can't use them on our platform. But maybe I'm wrong.
Also, for the record, you have all those same building blocks with a DSP. Functions already exist to do pretty much everything you need. So from the point of view of building blocks available, I'd guess they are about the same. I think they are open source, but I need to double-check that.
I am biased towards a DSP because that's what I've used in the past, and I recognise that. But it really all comes down to:
Surviving the rigors of space.
Power usage
Open source
Accessibility - we want to build a platform that is easy for others to
use.
I don't know FPGAs very well; I have done a little bit of VHDL and programmed PALs (you probably don't even know what one of those is...) so for the analysis I'm going to have to lean on others.
-corey
Second, I am planning on custom modulation, so those would have to be written in VHDL or Verilog. Not a show-stopper, though.
One of the other benefits is that many of Xilinx's products have hard integrated processors or have the ability to integrate soft processors
(See
Zynq and MicroBlaze respectively). The nice thing about these is that
they
support Linux development and bare-metal/RTOS configuration. We might
even
be able to remove the TMS570 and replace it with one of the multi-core devices. Perhaps we could have a system where Direwolf and the other processing functions are run on the same chip as the DSP. The downside
to
this is that I'm not sure how parallelable that would be (i.e. could we maintain four Rx channels).
If you are going to use something like a Zynq processor, why do you even need a DSP or an FPGA for this application? ;-) You could even get those fancy Zynq processors that have built-in RF subsystems. They just cost $2000 and need gobs of power. I don't know much about the MicroBlaze, how powerful it is or whatnot.
The big problem with these things is power. Zynq or Versal is right out. I'm looking to keep the entire power budget for everything outside of the PA to <1W. I think I can be successful if I play some tricks. I have no idea how much a MicroBlaze on an FPGA would use.
Also, there's a lot of functional safety things tied into the TMS570 processors. Things like lockstep processing, parity/ECC on everything, extended temperature, etc. The MicroBlaze can do lockstep, it appears, meaning that it can't be superscalar and it will be slow. I guess it says it's Harvard architecture. I don't know how it would compare to a Cortex-R5F.
I do a lot of work with Xilinx products and FPGAs at work. It's mostly
for
video functions, but I've found it pretty easy to understand the fundamentals of Vivado/Vitis in only a few months. With integrated peripherals like AXI and the IP blocks, it probably wouldn't take as
long
as everyone is thinking. I hardly ever touch verilog at work anymore...
I'm not against using an FPGA, but it would take some research. Do you have any idea of the power they would use?
As far as the amplifier project is coming, I'm back in the lab at work
and
want to get some more prototyping done with our actual amplifier. Does anyone on the team have extra stock of the transistor we're using for
the
Tx amplifier (ATF05MS004NT1)? I'd also like to get an inductor kit
like this
one <
https://www.amazon.com/First-Inductor-Assorted-1nH-270nH-42Valuesx50pcs/dp/B...
as the one I have at work is all 0201s and I can't reliably solder it...
A book of inductors :-).
On that note, I'm happy to keep prototyping it if the team wants to go
in
that direction, but I think it'd be faster to go with a premade power
amp.
I've already created a schematic for a PA as a backup to the work I'm
doing
now. If we want something for Jim's test board, I could probably get something to at least prototype with a lot sooner even if we think we
could
do better with the discrete option. Just a suggestion.
Are you talking about a PA module as something that can be used on the satellite, or just something as a temporary solution to plug into Jim's board? And as I mentioned before, power is a big issue. I don't know much about these things, though.
Thanks,
-corey
Thanks,
Cameron Castillo
Cameron Castillo
KJ7ILB
*P*: (503) 752-8877
On Fri, Jan 10, 2025 at 8:47 AM Bill Reed [email protected] wrote:
This is a better URL...
https://github.com/AMSAT-NA/PacSatDocs/blob/main/SDR/MinyardSDR_1-9-2024.web...
-------- Forwarded Message -------- Subject: Last nights recording Date: Fri, 10 Jan 2025 09:31:07 -0600 From: Bill Reed [email protected] [email protected] To: Cameron Castillo [email protected] <
We discussed 2 things last night.
1: Start of SDR development to replace AX5043. Exciting stuff!
https://github.com/AMSAT-NA/PacSatDocs/SDR/MinyardSDR_1-9-2024
2: Discussion of 2025 budgets that haven't been approved yet. More to come....no video.
I would like to discuss your project with you at some point. Can it
be
prototyped on the new launchpad that Jim is working on?
Bill
pacsat-dev mailing list -- [email protected] View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/[email protected]
To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at
On Sun, Jan 12, 2025 at 07:52:53PM -0800, Cameron Castillo wrote:
I did not intend to suggest using an FPGA over the DSP processors you suggested, but only that development might not be as difficult as we expect. That being said, without the use of Xilinx IP (of which most of the source code is hidden) the above is not true. The IP blocks take a lot of the effort that goes into configuring DSP slices (hard MAC blocks) and associated pipelining. It would be a significant amount of effort to recreate that.
Thanks Cameron. Yeah, I realized that later. It's probably easier than I think.
Some of the things you would need to do:
Be able to take a signal, shift its frequency down, filter, and downsample, for each receive channel. On a DSP I would probably do an FFT, rotate it, filter it, then use that to convert back to time domain at a lower sample rate. I assume that's a bog-standard kind of thing to do in an FPGA. Then you get an output for each channel at a more managable sample rate.
For FM you would need to do an FM demodulator. Though if you are doing AFSK, you might be able to directly work with the signal without converting to FM.
If you do OFDM directly (not on top of FM) you have to analyze the signal and adjust for frequency deviation.
For OFDM in both cases, then you do an FFT and decode from there. You also have adjust for time alignment on each frame. There's also the initial detection and time alignment of the signal. Some radios invert the signal and some don't (I had this problem playing with OFDM); then you have to compensate for that. Then you really need coding for ECC, both for error correction and detectiing channel conditions. You also probably want to be adaptive; changing the data rate based upon channel conditions.
You have the opposite for each channel on transmit, of course. You can transmit on mulitple frequencies with a single transmit channel, but you would divide the power between each transmit channel, so that's probably not something we would want to do.
All of this could be hybrid; you could do parts in the FPGA/DSP and parts in the host processor.
Getting off of FM is a big thing I think we need to do. FM doesn't perform well (or at all) in poor channel conditions where you could otherwise do modulation techniques that can operate very near the noise floor. It also takes forever to get a normal VHF/UHF radio to turn on the transmitter.
I also think we need to be pushing the envelope somewhere in the modulation world.
I'll go back the the list I had in the email before, with some additions. My goals are:
1) Surviving the rigors of space
2) Minimizing power usage
3) Minimizing board space
4) Open source hardware and software
5) Accessibility - we want to build a platform that is easy for others to use.
6) Pushing the envelope in modulation
Do you have any idea of the power they would use?
I'm working on a fairly large design at work with a Zynq, and last I checked I was at around 4.3W. As far as I've seen, that's pretty typical for our applications. I've never worked on a DSP system though. Datasheet values put one of the lower end Zynqs (ZC7Z2010) at almost 200 mA for all sources, which would end up being a max of 355 mW quiescent (assuming all supplies are 1.8V, where most of them are below that). With an application running, I'm not sure you could maintain the <1W requirement.
I don't think a Zynq design is going to work. They are just too big, and they don't have the reliability sorts of things you need in a satellite.
The MicroBlaze with an FPGA looks workable, though. I'm pretty sure the Zynq processors are not running in the FPGA; we support them at work and I don't remember anything like that. It would be hard to get the levels of performance the Zynq provides running in an FPGA. It does appear the MicroBlaze is running in the FPGA. I don't know what that means for us.
Thanks again,
-corey
Are you talking about a PA module as something that can be used on the
satellite, or just something as a temporary solution to plug into Jim's board? And as I mentioned before, power is a big issue. I don't know much about these things, though.
Both. I'm saying that I can get something prototyped up for Jim's board which we can take power measurements on quickly that will also work for the flight model. If those are deemed inadequate, we can continue prototyping the discrete transistor option. I think that after looking at a lot of the options available on the Tx side and the desired voltage, efficiency is not great with either the discrete transistors or integrated amplifiers. The transistor we're using now is one of the better options, and even its efficiency is pretty bad (40-50%) considering the output power we desire. The option on the IC side sits at little less than 61% efficiency. In all, I'd say both options are comparable in terms of efficiency.
Thanks,
Cameron
Cameron Castillo
KJ7ILB
*P*: (503) 752-8877
On Sun, Jan 12, 2025 at 7:32 AM Corey Minyard [email protected] wrote:
On Sat, Jan 11, 2025 at 8:15 PM Corey Minyard [email protected] wrote:
On Sun, Jan 12, 2025 at 01:13:36AM +0000, Cameron Castillo via
pacsat-dev wrote:
Hi Bill,
Interesting presentation! A couple notes:
On the FPGA design for the SDR, a significant amount of the work can be done via Xilinx IP. I think the team has the idea that most of the DSP
and
hardware would have to be built from scratch in verilog. For almost any design today, many people use the block diagram editor from Xilinx
instead
of writing their own verilog. Not only are these guaranteed to work
but all
the driver code is also available in their software platform (Vitis).
I've
looked into some of the DSP blocks they have available and the list is fairly comprehensive (IIR/FIR filters, FFTs, Freq. Synthesizer to name
a
few off the top of my head).
Yes, I'm aware of this. From what I can tell, the licensing is not open source on these. If that's so we can't use them on our platform. But maybe I'm wrong.
Also, for the record, you have all those same building blocks with a DSP. Functions already exist to do pretty much everything you need. So from the point of view of building blocks available, I'd guess they are about the same. I think they are open source, but I need to double-check that.
I am biased towards a DSP because that's what I've used in the past, and I recognise that. But it really all comes down to:
Surviving the rigors of space.
Power usage
Open source
Accessibility - we want to build a platform that is easy for others to
use.
I don't know FPGAs very well; I have done a little bit of VHDL and programmed PALs (you probably don't even know what one of those is...) so for the analysis I'm going to have to lean on others.
-corey
Second, I am planning on custom modulation, so those would have to be written in VHDL or Verilog. Not a show-stopper, though.
One of the other benefits is that many of Xilinx's products have hard integrated processors or have the ability to integrate soft processors
(See
Zynq and MicroBlaze respectively). The nice thing about these is that
they
support Linux development and bare-metal/RTOS configuration. We might
even
be able to remove the TMS570 and replace it with one of the multi-core devices. Perhaps we could have a system where Direwolf and the other processing functions are run on the same chip as the DSP. The downside
to
this is that I'm not sure how parallelable that would be (i.e. could we maintain four Rx channels).
If you are going to use something like a Zynq processor, why do you even need a DSP or an FPGA for this application? ;-) You could even get those fancy Zynq processors that have built-in RF subsystems. They just cost $2000 and need gobs of power. I don't know much about the MicroBlaze, how powerful it is or whatnot.
The big problem with these things is power. Zynq or Versal is right out. I'm looking to keep the entire power budget for everything outside of the PA to <1W. I think I can be successful if I play some tricks. I have no idea how much a MicroBlaze on an FPGA would use.
Also, there's a lot of functional safety things tied into the TMS570 processors. Things like lockstep processing, parity/ECC on everything, extended temperature, etc. The MicroBlaze can do lockstep, it appears, meaning that it can't be superscalar and it will be slow. I guess it says it's Harvard architecture. I don't know how it would compare to a Cortex-R5F.
I do a lot of work with Xilinx products and FPGAs at work. It's mostly
for
video functions, but I've found it pretty easy to understand the fundamentals of Vivado/Vitis in only a few months. With integrated peripherals like AXI and the IP blocks, it probably wouldn't take as
long
as everyone is thinking. I hardly ever touch verilog at work anymore...
I'm not against using an FPGA, but it would take some research. Do you have any idea of the power they would use?
As far as the amplifier project is coming, I'm back in the lab at work
and
want to get some more prototyping done with our actual amplifier. Does anyone on the team have extra stock of the transistor we're using for
the
Tx amplifier (ATF05MS004NT1)? I'd also like to get an inductor kit
like this
one <
https://www.amazon.com/First-Inductor-Assorted-1nH-270nH-42Valuesx50pcs/dp/B...
as the one I have at work is all 0201s and I can't reliably solder it...
A book of inductors :-).
On that note, I'm happy to keep prototyping it if the team wants to go
in
that direction, but I think it'd be faster to go with a premade power
amp.
I've already created a schematic for a PA as a backup to the work I'm
doing
now. If we want something for Jim's test board, I could probably get something to at least prototype with a lot sooner even if we think we
could
do better with the discrete option. Just a suggestion.
Are you talking about a PA module as something that can be used on the satellite, or just something as a temporary solution to plug into Jim's board? And as I mentioned before, power is a big issue. I don't know much about these things, though.
Thanks,
-corey
Thanks,
Cameron Castillo
Cameron Castillo
KJ7ILB
*P*: (503) 752-8877
On Fri, Jan 10, 2025 at 8:47 AM Bill Reed [email protected] wrote:
This is a better URL...
https://github.com/AMSAT-NA/PacSatDocs/blob/main/SDR/MinyardSDR_1-9-2024.web...
-------- Forwarded Message -------- Subject: Last nights recording Date: Fri, 10 Jan 2025 09:31:07 -0600 From: Bill Reed [email protected] [email protected] To: Cameron Castillo [email protected] <
We discussed 2 things last night.
1: Start of SDR development to replace AX5043. Exciting stuff!
https://github.com/AMSAT-NA/PacSatDocs/SDR/MinyardSDR_1-9-2024
2: Discussion of 2025 budgets that haven't been approved yet. More to come....no video.
I would like to discuss your project with you at some point. Can it
be
prototyped on the new launchpad that Jim is working on?
Bill
pacsat-dev mailing list -- [email protected] View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/[email protected]
To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at
participants (2)
-
Cameron Castillo -
Corey Minyard