Документ взят из кэша поисковой машины. Адрес оригинального документа : http://hea-www.harvard.edu/~garcia/ixo/htrs_comments.pdf Дата изменения: Tue Jun 28 21:40:22 2011 Дата индексирования: Tue Oct 2 01:34:59 2012 Кодировка: Поисковые слова: п п п п п п п п

Smithsonian Astrophysical Observatory

Memorandum

To: D. Barret Cc: J. Grady, T. Buckler, J. Bookbinder, R. Smith From: M. Garcia Date: Aug 2, 2010 Re: HTRS data rates, observing profile

mrg-2010-08-02

Hi Didier: I've read over HTRS-RP-21B-019-CESR (really only the section on data rates/compression/storage). This looks like exactly the sort of study that needed to be done. Compressing the data is a good idea, as is having a flexible data collection mode (ie, spectral binning ala RXTE). Nice thing about spectral binning is that then the actual downlinked data rate is nearly independent of the source flux, especially if one assumes a constant compression factor as this study does. One just needs to make sure there are enough bits in each spectral bin so that the bins do not roll over, and with 16 bits and 256 channels this is not a problem even at >20 Crabs. I have a few questions and comments, which I hope you will find useful. Please pardon me if they are answered in other documents, or other sections of this document. Is there also a plan to have a full photon counting mode (ie, `native mode'), where each event is tagged by energy, time, and positional info and then sent down? If so, how many bits per event are planned for this mode? Note that later in this note I took a guess at how many bits this native mode would take. What amount of compression can be obtained in this mode?

It would be good to list the raw and compressed data rates in section 3.1, `Assumptions'. These rates are derivable from the data in other sections, but a summary here would be very useful. What are the chances of getting a faster processor, so that increased compression rates can be achieved on board? A factor of 3 is nice, but It would be great to get the larger factors possible with a faster processor. Did the one-year observing plan include also non-HTRS targets? If so, what list was used, and what telemetry requirements were assumed for the non-HTRS targets? Page 7 describes using the peak rate from the 10 year ASM lightcurve for all the sources. It would be good to provide a table of the peak fluxes for these sources.


Re Figure 2, Do you have a feeling for what causes the mass memory to fill up? The caption says 'memory fills during observations of bright sources....and downloading during observations of faint sources....', but the data rate in spectral binning mode is largely independent of the source brightness given the assumption in the study that the compression rate is 2.5 or 3.0, and no higher. Maybe the caption means 'during observations of bright sources with the HTRS....and downloading during observations with the other focal plane instruments....'?? The co-ordinates of the targets in Appendix I are labeled as RA/DEC, but with 2 exceptions they are Galactic lat/longitude. Below is a table with all the co-ords in RA/DEC. Target scox1 x1636-536 x0614+091 x1820-303 x1735-444 x1705-250 cygx2 gx17+2 serx1 gx340+0 gx349+2 saxj1808-3658 hetej1900-2455 Crab x1728-34(gx340) velax1 ks1731-260 lmcx3 xtej1550-564 xtej1650-500 cygx1 gx339-4 groj1655-40 grs1915+105 aqlx1 x1608-522 A0620 xtej1859+226 TOO TOO2 RA(deg) 244.98 250.23 94.28 275.92 264.74 257.06 326.17 274.01 279.99 251.45 256.44 272.109 285.04 83.63 262.9875 135.53 263.554 84.74 237.74 252.5 299.59 255.711 253.499 288.8 287.82 243.181 95.685 284.67 279.1 272.5 DEC(deg) -15.64 -53.75 9.141 -30.36 -44.45 -25.09 38.32 -14.04 5.04 -45.61 -36.42 -36.98 -24.92 22.01 -33.8328 -40.55 -26.086 -64.08 -56.48 -49.96 35.199 -48.79 -39.85 10.95 0.589 -52.42 -0.346 22.66 -23.91 -19.73


Below is a plot of the target positions vs RA(mod 12 hours), vs. order in the above list.

On page 8 the memo describes spreading the ordered list of targets over the year. Were they spread _uniformly_ over the year? I'm not sure it is possible to do this, given the plot above. The limited off-solar pitch range of IXO, at +/- 20 degrees, will make only ~20% of the sky visible at any one time, so if the targets are grouped in one area of the sky (ie, Galactic plane, Galactic center) the target list may have preferred times of year. The +/- 20 degree range corresponds to a `visibility window' that is roughly +/- one month (total two months) wide, centered around the nominal time which is when the target RA is 90 degrees away from the sun position. The histogram below is based on target list in the report (HTRS-RP-21B-019-CESR). It shows the ecliptic (~celestial) RA of the targets modulo 12 hours. The peak at 6 hours (equivalent to 18 hours) is due to the concentration of sources near the Galactic center at 18H RA. Optimal viewing time for sources at 6H and 18H RA is ~late March



The compressed data rate is either 1.7Mbps (Timing mode or Spec mode) or 5.6Mbps (Full mode). These numbers are calculated from those provided on page 7 of TN-21-016, as shown in Table 1. Table 1: Spectral Binning Mode data rates Frame #energy Bits/ Frame Raw Data Assumed Compressed R at e Channels channel Size R at e Compression Data rate HTRS-F 4096/sec 256 16 4096 16.8Mbps 3.0 5.6Mbps HTRS-T 4096/sec 64 16 1024 4.2Mbps 2.5 1.7Mbps HTRS-S 1000/sec 256 16 4096 4.1Mbps 2.5 1.7Mbps Mode

My understanding of the data flow from the HTRS to the s/c telemetry stream is shown in the data flow diagram below.

There are ~equal numbers of targets at each of the two data rates, so I will assume the average rate of 3.6Mbps in order to estimate how full the buffer gets (entry A in table below). Given the peak in the histogram around March/April, it appears that 20 out of the 30 HTRS targets must get done in these 2 months (or six months later). While one could extend this window by scheduling targets near the extremes of the allowable pitch range, doing so would place additional constraints on the observing schedule and likely result in lowered overall efficiency, making it difficult to obtain the required 85% observing efficiency. In what follows we assume that the observations take place when the targets are ~90 degrees from the sun.

Total amount of time for all 30 targets is 5Ms, so that means that 3.3Ms (=20/30 * 5Ms) of these observations will occur during these 2 months (or 6 months later). Let us consider a 6 months observing plan, and assume that half of these 20 targets are observed during these six months (the other 10 would be done 6 months later). During the 2 month window (2months=5Ms clock time) for Galactic center observations we will have 1.65Ms of HTRS observations (half of the 3.3Ms), generating


3.6Mbps*1.65Ms = 5.8x10e12 bits of compressed data. Given our observing efficiency of 85%, the 5Ms of clock time corresponding to 2 months will allow 4.25Ms of observing time. The HTRS observations will require 39% of this observing time (=39% of 4.25Ms = 1.65Ms). Therefore roughly 1 out of every ~3 targets will be HTRS during these 2 months (entry C in table 2), IF we assume that the typical HTRS observing length is the same as that for other instruments. Telemetry rate allocated to science is 0.84Mbps (entry B in table 2). Given that we are accumulating data at the average rate of 3.6Mbps during HTRS observations and that the telemetry stream will accommodate 0.84Mbps, we are building up a back-log of 2.8Mbps during the HTRS observations. Even if the two non-HTRS observations that follow each HTRS observation use essentially none of the allocated 0.84Mbps data stream (entry D in table 2), only 0.84Mbps x 2 observations would be available to download the 2.8Mbps backlog, so over these three observations we are accumulating a backlog at the average rate of 1.1Mbps (entry E in table 2, E=A-B-(C*B*D)=3.6-0.84-(2*0.84*1.0)Mbps). This back-log will accumulate during the 2 month window for Galactic center HTRS observations, and at the end of the two months will amount to 1.1Mbps*4.25Ms = 4.7e12 bits. Therefore we need at least 4.7TeraBits of board data storage to hold the data until it could be sent to the ground in the 4 months after the Galactic center season ended. Table 2: Telemetry Backlog or (margin) A: Average HTRS B: Telemetry Compressed limit Data rate 3.6Mpbs 0.84Mbps 3.6 0.84 3.6 0.84 C: #open telem Slots per HTRS observation 2(=15% HTRS) 4(=7% HTRS) 6(=5% HTRS) D: Fraction of that E: Data Non-HTRS telem Backlog Slot open R at e 1.0 1.1Mbps 0.82 0 0.55 0 F: March/April Backlog total 4.7Tbits 0 0

Future work: One could increase the fidelity of the above estimate by using the straw-man observing catalog (ie, as in Obsplan_May27_2010 on the IXO WIKI, described in our 2010 SPIE paper, Garcia, Smith et al) to estimate the actual telemetry requirements for the other instruments. Note that Obsplan_May27_2010 allocates 7% of the time to HTRS observations rather than the 15% assumed in HTRS-RP-21B-019-CESR. At this lower allocation there would be ~4 non-HTRS observations for every HTRS observation, as indicated in the second line in Table 2. In this case one needs 82% of the telemetry bandwidth during non-HTRS observations in order to stream the HTRS data to the ground during the Galactic center season. A more modest requirement of 55% of the bandwidth is sufficient if the HTRS observations make up 5% of the total for the year (third line in table 2). Alternatively, one could increase the number of non-HTRS observations to 1 in 6 by increasing the Galactic center observing season to 3 months rather than 2 months, and accept the possible (temporary?) decrease in observing efficiency. It would be good to study such and observing plan and determine the impact on the observing efficiency. Clearly there is a range of possible observing scenarios that would allow all the data to be downlinked, with a modest buffer required to hold a few observations. It would be worthwhile to carefully look at the allocations and anticipated usage of the 0.84Mbps telemetry stream by the non-HTRS instruments.


In addition, there are likely to be times when the HTRS usage would increase beyond the average values assumed here (ie, during the outburst of a bright Galactic binary), and such an event would likely require a larger on-board buffer and/or increased telemetry contacts. It would be worthwhile to model such an event. Note that by buffering the data, we may be ensuring that it will not get down within 24 hours of the observation. This is longer than the required data latency for typical observations, so users will need to be aware of the delay in data receipt. Cc: Jean Grady, Tom Buckler, Jay Bookbinder, Randall Smith