<div dir="ltr">Hi,<div><br></div><div>I have had another look through and had a number of thoughts, some may be useful, others maybe not.</div><div><br></div><div>Listed in order that appeared in document, not necessarily by importance:</div><div><br></div><div><b>Specific Items</b></div><div>1.2 - p4. "adapts to digital subsystem failures"<br>What about analogue (power) and RF faults?  Could be even more critical than digital sub-system failure<br><br>1.3 - p8.<br>The RAM is indicated as volatile, however if FRAM is used - which is a sound choice for this application - it is non-volatile<br><br>1.4 - p8.<br>How is FPGA/SoC instruction storage managed? Will there be EEC on the data in the PROM(s)?<br><br>1.5 - p8.<br>There is no filter after the MMIC amplifier.  I suspect the non-linearities will violate the CCSDS spectral masks and we should consider a filter here.<br><br>1.6 - p8.<br>How is the Rx-Tx isolation achieved on the UHF channels? Strictly half-duplex or some frequency separation?<br><br>1.7 - p9.<br>What is the purpose of the UHF transponder loopback - added functionality or backup system?  If backup system, how is the fault condition detected?<br><br>1.8 - p10.<br>The diagram seems to indicate that the processor interfaces with the SDR ADC and DAC ("SDR ADC/DAC Thread").  I would've expected the FPGA logic to interface to the data convertors.<br><br>1.9 - p10.<br>Assuming this is a Zynq device there are anywhere between 2 - 6 processors.  May be interesting to think about how the threads are segmented between processors. For example the safety thread running on two R-5s in lockstep.<br><br>1.10 - p10.<br>I see the C-band BB is routed to the TT&C processor. Does the processor have the capability to deal with the bandwidth of this analogue signal? Is an analogue channel pre-selector required?<br><br>1.11 - p13.<br>The failover from FPGA to transponder is specified as controlled by a state machine (presumably inside the TT&C controller).  A more reliable approach would be to do this in hardware, an AC coupled BJT buffer and a high time constant filter fed to comparator is drastically lower risk from hardware failure and removes the complexity of FSM inside a controller (or more specifically the thread switching of the FSM and everything else) - getting the coding wrong of these mission critical FSMs is probably the bigger risk (see KickSat as an example).<br><br><b>General Items  </b><br>2.1 <br>Do you know anything about local interference (other systems on Gateway) and the required out-of-band rejection on UHF/C band receive?  Is a filter required to stop the LNA saturating?  Is there a band plan/frequency list for the mission yet? <br><br>2.2<br>There is no information about the antennas even though they are quite important, are they covered by a different document?<br>How will the antenna spatial switching be implemented?<br><br>2.3<br>Will over-the-air updates of the SDR be supported? If so, how are the backup, primary, secondary images managed?<br><br>2.4<br>The camera interface is not mentioned.  I'm guessing this will be something like a LVDS/MIPI interface to the SDR board?<br><br>2.5<br>There's no real numbers anywhere.  Since the architecture should be driven by quantitative factors (I'm a big believer of Akin's 1st law of spacecraft design) in my opinion these (estimated) numbers would be informative to justify the architectural decisions:<br>  - X/C/UHF bandwidth / symbol rate</div><div>  - Number of channels  <br>  - Transmit power<br>  - Antenna gains<br>  - System power usage<br>  - Volume<br>I suspect many people close to the project 

instinctively

 know the order of magnitude numbers, but as a stand alone document, it's not mentioned.  Could reference to system requirements if you wanted to limit this document purely to architecture.<br></div><div><br></div><div>2.6</div><div>There's no explicit mention of design for radiation.  TID is not really a problem due to mission length but SEE is certainly of interest - particularly latch up.</div><div><br></div><div>Cheers,</div><div>Thomas</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 17 Jun 2020 at 20:09, <ground-station-request@lists.openresearch.institute> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send Ground-Station mailing list submissions to<br>
        ground-station@lists.openresearch.institute<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.openresearch.institute/listinfo.cgi/ground-station-openresearch.institute" rel="noreferrer" target="_blank">http://lists.openresearch.institute/listinfo.cgi/ground-station-openresearch.institute</a><br>
<br>
or, via email, send a message with subject or body 'help' to<br>
        ground-station-request@lists.openresearch.institute<br>
<br>
You can reach the person managing the list at<br>
        ground-station-owner@lists.openresearch.institute<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Ground-Station digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. System Architecture (17 June 2020) - Review Request<br>
      (Michelle Thompson)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 17 Jun 2020 11:08:48 -0700<br>
From: Michelle Thompson <<a href="mailto:mountain.michelle@gmail.com" target="_blank">mountain.michelle@gmail.com</a>><br>
To: Michelle Thompson via Ground-Station<br>
        <ground-station@lists.openresearch.institute><br>
Subject: [Ground-station] System Architecture (17 June 2020) - Review<br>
        Request<br>
Message-ID:<br>
        <<a href="mailto:CACvjz2Wd7spuS2O_AQhVCMuW19Q_4L4H3hAGwFD%2Bke3cA7M8UA@mail.gmail.com" target="_blank">CACvjz2Wd7spuS2O_AQhVCMuW19Q_4L4H3hAGwFD+ke3cA7M8UA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Attached is today's cut of the System Architecture document for AREx. This<br>
is also our baseline design.<br>
<br>
We have a significant milestone coming up in the 25 June 2020 hardware<br>
meeting for AREx.<br>
<br>
I need this document to be as good as it can be by then.<br>
<br>
Please review. All comment and critique welcome and encouraged.<br>
<br>
-Michelle W5NYV<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20200617/fbb86ae2/attachment.html" rel="noreferrer" target="_blank">http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20200617/fbb86ae2/attachment.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: 20200617-AREx-System-Architecture.pdf<br>
Type: application/pdf<br>
Size: 1089034 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20200617/fbb86ae2/attachment.pdf" rel="noreferrer" target="_blank">http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20200617/fbb86ae2/attachment.pdf</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Ground-Station mailing list<br>
Ground-Station@lists.openresearch.institute<br>
<a href="http://lists.openresearch.institute/listinfo.cgi/ground-station-openresearch.institute" rel="noreferrer" target="_blank">http://lists.openresearch.institute/listinfo.cgi/ground-station-openresearch.institute</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Ground-Station Digest, Vol 27, Issue 9<br>
*********************************************<br>
</blockquote></div>