Small Sat SDR Paper + Outernet + BY70-1
Mamatha R. Maheshwarappa 2E0CZO has released her paper “Improvements in CPU & FPGA Performance for Small Satellite SDR Applications” https://amsat-uk.org/2017/01/10/small-satellite-sdr-paper/
BY70-1 FM transponder contact video https://amsat-uk.org/2016/12/30/by70-1-fm-transponder-contact/
Chertsey Radio Club article - Getting started with FM satellites http://chertseyradioclub.blogspot.co.uk/2017/01/getting-started-with-fm-sate...
Video of Daniel Estévez EA4GPZ / M0HXM talk - Reverse Engineering the Outernet - at Chaos Communication Congress #33c3 http://www.southgatearc.org/news/2017/january/reverse-engineering-%20the-out... Blog update http://destevez.net/2017/01/updated-format-for-outernet-ldp-protocol/
ITF-2 CubeSat 437.525 MHz to deploy from ISS Monday https://www.facebook.com/amsatuk/posts/1269720816404298
73 Trevor M5AKA ---- AMSAT-UK http://amsat-uk.org/ Twitter https://twitter.com/AmsatUK Facebook https://facebook.com/AmsatUK YouTube https://youtube.com/AmsatUK ----
I found the paper on CPU & FPGA performance in satellite communications to be very interesting, and mostly very well-done. However there seemed to be some obvious places in the paper where the authors could have better conveyed their findings.
1. Throughout the paper, they never identify the x86 processor that was present in their Dell Optiplex 745 computer. Several different Intel x86 processors have been used in that machine, including Pentium D and Core 2 Duo processors. I presume it was the latter. 2. Figures 8, 10, and 11 would have been much improved if they showed a fourth data series, namely the Cortex A9 CPU % Consumption (Figures 8, 10) and Success Rate (Figure 11) when assisted by moving critical code to the FPGA from the GPP. 3. I find Table VII mostly impossible to understand. In the first two columns, I don't understand what the percentage numbers are referring to. And the tabulated items under Post Implementation are not defined, and seem to be a mix of physical circuits in the FPGA (such as Flip Flops) and software subroutines (DSP48). It is poor practice to use descriptors such as "LUT", "MemoryLUT", "BRAM", "DSP48", "BUFG", and "MMCM" which are never defined in the paper. Without knowing what a "MMCM" is, I can barely appreciate that it stayed at 50% (half of what, I am uncertain) before and after FPGA implementation of critical software routines, giving an Overhead of 0% (no change). And the pictures of "Implementation on FPGA Fabric" are meaningless without any explanation of what they are and what they mean. The only thing I can offer as assistance in interpreting this table is to remind the reader that the dual Cortex A9 CPUs of the Zedboard are actually implemented using a portion of the FPGA. Therefore a pure GPP software implementation still uses some of the FPGA. What fraction of the FPGA capacity is consumed by the dual A9 implementation? What fraction of the FPGA capacity is consumed by the A9 implementation plus the software SDR implementation? What fraction of the FPGA capacity is consumed by the A9 + software SDR + FPGA implementation of the SDR? I can't figure this out from the paper. 4. The purpose of the paper, to show the improvement in functionality of an SDR by moving critical functions from GPP to FPGA, was accomplished in that it was shown that the FPGA implementation could receive more satellite signals concurrently at low data rates. But it appears that neither a dual-core A9, dual-core A9 + FPGA, nor a quad-core A15 + quad-core A7 could keep up with a lowly Intel Core 2 Duo processor. It seems that a ground station with a built-in SDR processor would do best with a modern x86 processor rather than any of the ARM processors available at the present time. Given the higher power consumption of fast x86 processors than fast ARM processors, it may be best to handle the SDR functions in a desktop PC or at least in a high-end laptop PC, instead of embedding an ARM processor inside the ground terminal.
Anyway, that's my take on the paper. I congratulate the authors and acknowledge their hard work. I sincerely hope that they continue their efforts in this field. Maybe we should personally invite them to join the team working on the AMSAT Ground Terminal for future digital satellites using the "5 and Dime" frequencies (5 GHz up and 10 GHz down).
John Toscano, W0JT/5 AMSAT LM
On Thu, Jan 12, 2017 at 2:49 PM, M5AKA via AMSAT-BB [email protected] wrote:
Mamatha R. Maheshwarappa 2E0CZO has released her paper “Improvements in CPU & FPGA Performance for Small Satellite SDR Applications” https://amsat-uk.org/2017/01/10/small-satellite-sdr-paper/
BY70-1 FM transponder contact video https://amsat-uk.org/2016/12/30/by70-1-fm-transponder-contact/
Chertsey Radio Club article - Getting started with FM satellites http:// chertseyradioclub.blogspot.co.uk/2017/01/getting-started- with-fm-satellites.html
Video of Daniel Estévez EA4GPZ / M0HXM talk - Reverse Engineering the Outernet - at Chaos Communication Congress #33c3 http://www.southgatearc.org/news/2017/january/reverse- engineering-%20the-outernet.htm Blog update http://destevez.net/2017/01/updated-format-for- outernet-ldp-protocol/
ITF-2 CubeSat 437.525 MHz to deploy from ISS Monday https://www.facebook.com/amsatuk/posts/1269720816404298
73 Trevor M5AKA
AMSAT-UK http://amsat-uk.org/ Twitter https://twitter.com/AmsatUK Facebook https://facebook.com/AmsatUK YouTube https://youtube.com/AmsatUK
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
I sure hope we never have to know any of this to talk on a satellite. If so, my Arrow antenna becomes a multi-hot dog skewer.
Steve AI9IN
On 2017-01-16 15:01, John Toscano wrote:
I found the paper on CPU & FPGA performance in satellite communications to be very interesting, and mostly very well-done. However there seemed to be some obvious places in the paper where the authors could have better conveyed their findings.
- Throughout the paper, they never identify the x86 processor that was
present in their Dell Optiplex 745 computer. Several different Intel x86 processors have been used in that machine, including Pentium D and Core 2 Duo processors. I presume it was the latter. 2. Figures 8, 10, and 11 would have been much improved if they showed a fourth data series, namely the Cortex A9 CPU % Consumption (Figures 8, 10) and Success Rate (Figure 11) when assisted by moving critical code to the FPGA from the GPP. 3. I find Table VII mostly impossible to understand. In the first two columns, I don't understand what the percentage numbers are referring to. And the tabulated items under Post Implementation are not defined, and seem to be a mix of physical circuits in the FPGA (such as Flip Flops) and software subroutines (DSP48). It is poor practice to use descriptors such as "LUT", "MemoryLUT", "BRAM", "DSP48", "BUFG", and "MMCM" which are never defined in the paper. Without knowing what a "MMCM" is, I can barely appreciate that it stayed at 50% (half of what, I am uncertain) before and after FPGA implementation of critical software routines, giving an Overhead of 0% (no change). And the pictures of "Implementation on FPGA Fabric" are meaningless without any explanation of what they are and what they mean. The only thing I can offer as assistance in interpreting this table is to remind the reader that the dual Cortex A9 CPUs of the Zedboard are actually implemented using a portion of the FPGA. Therefore a pure GPP software implementation still uses some of the FPGA. What fraction of the FPGA capacity is consumed by the dual A9 implementation? What fraction of the FPGA capacity is consumed by the A9 implementation plus the software SDR implementation? What fraction of the FPGA capacity is consumed by the A9 + software SDR + FPGA implementation of the SDR? I can't figure this out from the paper. 4. The purpose of the paper, to show the improvement in functionality of an SDR by moving critical functions from GPP to FPGA, was accomplished in that it was shown that the FPGA implementation could receive more satellite signals concurrently at low data rates. But it appears that neither a dual-core A9, dual-core A9 + FPGA, nor a quad-core A15 + quad-core A7 could keep up with a lowly Intel Core 2 Duo processor. It seems that a ground station with a built-in SDR processor would do best with a modern x86 processor rather than any of the ARM processors available at the present time. Given the higher power consumption of fast x86 processors than fast ARM processors, it may be best to handle the SDR functions in a desktop PC or at least in a high-end laptop PC, instead of embedding an ARM processor inside the ground terminal.
Anyway, that's my take on the paper. I congratulate the authors and acknowledge their hard work. I sincerely hope that they continue their efforts in this field. Maybe we should personally invite them to join the team working on the AMSAT Ground Terminal for future digital satellites using the "5 and Dime" frequencies (5 GHz up and 10 GHz down).
John Toscano, W0JT/5 AMSAT LM
On Thu, Jan 12, 2017 at 2:49 PM, M5AKA via AMSAT-BB [email protected] wrote:
Mamatha R. Maheshwarappa 2E0CZO has released her paper "Improvements in CPU & FPGA Performance for Small Satellite SDR Applications" https://amsat-uk.org/2017/01/10/small-satellite-sdr-paper/
BY70-1 FM transponder contact video https://amsat-uk.org/2016/12/30/by70-1-fm-transponder-contact/
Chertsey Radio Club article - Getting started with FM satellites http:// chertseyradioclub.blogspot.co.uk/2017/01/getting-started- with-fm-satellites.html
Video of Daniel Estévez EA4GPZ / M0HXM talk - Reverse Engineering the Outernet - at Chaos Communication Congress #33c3 http://www.southgatearc.org/news/2017/january/reverse- engineering-%20the-outernet.htm Blog update http://destevez.net/2017/01/updated-format-for- outernet-ldp-protocol/
ITF-2 CubeSat 437.525 MHz to deploy from ISS Monday https://www.facebook.com/amsatuk/posts/1269720816404298
73 Trevor M5AKA
AMSAT-UK http://amsat-uk.org/ Twitter https://twitter.com/AmsatUK Facebook https://facebook.com/AmsatUK YouTube https://youtube.com/AmsatUK
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
Sent via [email protected]. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
participants (3)
-
John Toscano -
M5AKA -
skristof＠etczone.com