VEGAS Old To Do List

This page is obsolete, and is for historical information only. For the new list, go to VegasToDoList

Updated 14th September 2015 RMP/MAB

For DIBAS

For GBT

In priority order

Urgent (to be delivered as soon as possible)

Upgrade analog IF modules

  • needs to be done, but further commissioning does not need to wait for this.
  • Upgrade has been postponed, we'll attempt to mitigate existing modules per JF and SW. -GW
    • Needs coordination with observations (three banks for a period) JF will talk w/Toney
  • [18 May 15] On hold until summer maintenance when schedule allows for removal
  • [1 June 2015] Module 'H' removal for analysis by Watts
  • [4 June 2015] Attempted modifications did not improve response to desired levels, further testing and modifications planned for June 22-25. -GW
  • [15 June 2015] Look at next week.
  • [22 June 2015] Galen is removing a module today
  • [25 June 2015] Further modifications did not improve response to desired levels.
  • [29 June 2015] Requires a complete re-design. Electronics to create plan
  • [02 July 2015] Plan is single channel modules based on current circuit. New modules phasing-in early September.
  • [06 July 2015] September mid-late installations best case. October is first observing target
    • Stick with I2C architecture would be much simpler. Jason to design interface board.
  • [20 July 2015] Jason finished design & layout. Reviewed w/Randy - will send off this week. Next task is working on bill of materials.
  • [27 July 2015] No update - Galen just returning from travel
  • [3 Aug 2015] IF cases in NRAO shop que, IF PC boards out for fab.
  • [10 Aug 2015] IF Cases being machined. Circuit boards in house and soon to be populated.
  • [17 Aug 2015] Circuit boards partially complete and beginning testing, cases almost ready from shop.
    • This replacement will likely extend beyond the end of GBT maintenance. Bench tests can be undertaken to minimize risks of issues
    • Companion software changes will be needed when boards are installed
  • [31 Aug 2015] Two channels will be ready for testing 1 Sept.
    • If all goes well we can use these two to replace a module, or two, currently in use. From those older modules Galen will extract the filters and assemble two, or four, new modules, test those, and substitute those in for older modules, extract their filters, assemble, etc
    • Scientists (Adam) test can occur this week (Wed. ?)
    • Adjustments to the manager are needed to utilize more I2C interfaces
    • I2C board tested out okay
    • Some changes in how to address filters are identified, but not fully. Jason and Joe/Ray to discuss and complete by Wednesday tests.
  • [2 Sep 2015] New IF Modules installed between CMs 4 and 8 and blade D. AK doing testing.
  • [8 Sep 2015] Tested and report circulated.test on sky 9/9/15 and begin rotation of other modules. I2C control should be ready 9/9/15
    • no preference as to the next two modules to upgrade
  • [14 Sep 2015] Four to be installed Thursday morning (C&D). Location (banks) is not critical.
    • Quick balance and spectral tests should follow.

New non-linearity problem

  • Added by RMP 7 May 2015
  • See recent emails from Ron
  • Data analysis appears to identify a linearity problem. Adam to get sky data after final bof files
    • 14 May 15 Gathered some data, early results suggest a gain instability, at the level standardly accepted for the receiver (not a vegas problem)
  • [18 May 15] On-sky observation data of continuum sources is not showing as bad linearity as Ron suspected,
    • Tested with modes 4-9 and new bof files, 10-29 bofs do not have Randy's latest adjustments so linearity issues likely exist in those files.
    • Some on/off gain stability was noted.
    • Results should be documented in a GBT memo once confirmed with more data.
    • 1 June 2015: Keeping open until Mode > 9(?) tested, and system documented.
  • [27 July 2015] v. 185 now should fix these issues in modes.10-19.
    • Adam may test this Wed if build succeeds without timing errors
  • [17 Aug 2015] Waiting for final bof files to test - one remains
    • Config tool for 4-29 tested, just needs release after successful linearity tests
  • [31 Aug 2015] Modes 10-29 released
    • BOF builds of Modes 7-9 tested okay, but some peculiarities with individual spectra remain, but 4-6 have problem with bandpass structure and Tsys.
      • Could run a diagnostic of modes 4-6 at the 7-9 clock speeds
      • Config tool changes have not been released yet - may be additional table changes if released in parts
  • [8 Sep 2015] compile Modes 4-6 with latest build version. First effort failed. Will retry.
    • Config tool is ready to go. Will make last change and release concurrent with modes.
  • [14 Sep 2015] Retest Tuesday

Timely

We would like these tasks to be completed in a timely fashion (i.e. not wait until next quarter), to support continued BOF file building / commissioning

VEGAS BOF builds

  • Need to build every BOF, in Green Bank, with a stable, consistent CASPER environment.
  • We need to do this before we do any final (major) astronomical characterization.
  • We (GB Electronics) needs to take over BOFs, making any remaining required upgrades.
  • We are essentially ready to move to 14.7
    • Need to fix "sawtooth" problem in Modes 2/3 in this version.
  • Proposed path forward
    • Build current L1 and H1 BOFS under 14.7, and make available for testing soon
    • Fix and build H16K
    • Fix and build L8
  • In simulation by McCullough L1 and H1 problem has not existed, but actual implementation shows under certain conditions. More engineering work remains. (still v. 14.6). Target to have in place during this week's GBT maintenance.
  • [18 May 15] Randy working on H16k before L8 - should this order be reversed? [agreed]
  • [08 June 15] New Casper library with bug fixes is now available. Arindam and Vereese are testing to see if it should become the GB library.
  • [22 June 2015] Likely the final library has been assembled
    • We should see whether the "saw-tooth" problem is fixed in this version.
  • [29 June 2015] Action: Jason to build this mode
    • Action John: contact UCB to work on remaining sawtooth artifact
  • [13 July 2015] No update
  • [20 July 2015] John: We've been corresponding with them. Randy is going to try a few things. As usual "It works for them" is what they found, but we were using a mishmash of old and new stuff, I think, since our FFT was precompiled.
  • [17 Aug 2015] Only the 'sawtooth' problem remains. Some retesting with rebuilds of recompiled bofs might clear problem.
  • [31 Aug 2015] Jason has not worked on this yet. Hopefully this week.
  • [8 Sep 2015] Some work has been done and some techniques learned from Dave M. will be attempted.
  • [14 Sep 2015] 1080MHz version built successfully 1800 MHz version has sawtooth and timing issues

Commissioning / Astronomical Tasks

VEGAS spikes

  • Produce / confirm algorithm to locate spikes
  • Write MR and provide GBTIDL routine to identify and/or flag spikes.
  • Attempt to test this week of 5/11 (Adam)
  • [01 June 2015]
  • [29 June 2015]
    • Action: Adam to review engineering memos to see how they apply to the VEGAS issues
    • Work continues - tests this week
  • [20 July 2015] Adam has taken data but not had the time to analyze
  • [27 July 2015] Adam found an indexing problem which he fixed. Analysis resumed.Some spurs remain that are not multiples/divisors of fs
  • [17 Aug 2015] Adam to share results for team evaluation & discussion
  • [31 Aug 2015] Results have been shared.
    • A visual evaluation of the binary values for FFT shift for an overflow problem may be a clue as to the source to the non-ADC spikes
    • should see if spikes shift with LO shift
  • [8 Sep 2015] rough GBTIDL scripts in place to flag spikes - forms baseline data to draft MR for SDFITS and GBTIDL changes. Adam will draft MR.
    • A visual showed that spikes would only be in the Modes 1-3, since floating point modes are affected this is not a solution
    • Haven't tested LO shift suggestion
  • [14 Sep 2015] Retest if GBT maintenance time is available

Regular Commissioning tests

  • Does the noise integrate down correctly for long integrations (radiometer equation)
  • Are baselines flat and stable (waterfall plots)
  • What is the linear range of VEGAS input power (calibrate on continuum, and weak and strong lines, at a range of input levels).
  • Adam to give Toney a heads-up on time requirements, and to include Ron and Dave in the planning loop.
  • The careful commissioning of VEGAS should result in a refereed journal paper, and formal GBT memos which will survive a web site reorganization.
  • [11 May 15] On-hold. Revisit after non-linearity report is closed by repair or report is withdrawn.

Documentation

  • review Proposers Guide (mainly cleanup of tables and minor text adjustments)
  • review Observers Guide
  • Merge LateX source for Proposers Guide
  • Review LO switching memo.
  • Produce definitive VEGAS tables excel spreadsheet, and Excel -> LaTeX python scripts
  • Update Status Update page

Polarization Commissioning

  • Not really sure what this means independent of "telescope / receiver" polarization commissioning.
  • Instrument response is probably best measured using a correlated noise source (injected where)?
  • [11 May 15] As part of SDSS, Heiles scripts may be used to see the extent of this issue.
  • [29 June 2015] Observer is doing analysis of existing data (independent of SDSS)

Spectrometer Decommissioning

  • Complete and implement the plan

Items needing scientists to re-confirm as issues with all the new fixes now in place

VEGAS Q/W band balancing, and warning / error messages

VEGAS KFPA ghosting problem (Needs to be coordinated with receiver on GBT)

  • Reported by Jeremy Darling via Ron Maddalena
  • [11 May 15] Adam to attempt to recreate

VEGAS KFPA subbeam nod problem (Needs to be coordinated with receiver on GBT)

  • Reported by Jeremy Darling via Ron Maddalena
  • [11 May 15] not yet replicated

wideband KFPA channel problem (Needs to be coordinated with receiver on GBT)

  • Reported by Jeremy Darling via Ron Maddalena
  • [11 May 15] not yet replicated

Lower Priority

Will be scheduled as part of Q4 planning process

Mode 10-19 hardware implementation

  • Need to rebuild with new e.g. re-quantization balancing and test.
  • Needs small amount of Joe's time for initial testing.
  • Once we confirm this version works, we need to make the other L8 changes (see below).
  • Randy has provided a bof for testing
    • "full scale" needs new bof and manager(?) changes by Ray
    • Wait for version 14.7? No.
  • Update delivered (version 160) by Joe and is ready for tests week of 5/11.
    • [14 May 15] Version 160 failed, baselines unstable from scan to scan
  • [18 May 15] Randy is investigating
    • It might be worth comparing to the 'software mode' result
    • since no bandpass filters are in use there is no explanation how filters could be the issue
  • [01 June 2015] problem is not seen in FFTs of sb1snap data, or in simulated packets being set to HPCs. Implies problem is in Roach packet creation.
  • RMP: We wanted to check the last BOF, which we have now done (unsuccessfully). But since we have the software workaround, I believe the filter shape is higher priority that the packet problem.
  • Action: Joe dump a 64Mb (or larger) block of data to disk, and record simultaneous VEGAS spectra. Then run data block through off-line processing pipeline.
  • The decimation problem should be fixed before further action taken
  • [29 June 2015] With software version working for some modes do we wish to still make the firmware corrections? a) Yes.
  • [13 July 2015] Move hardware fix to 'Lower Priority'. Adam to research one last parameter.
  • [17 Aug 2015] Completed

"Divots" in spectrum.

  • Only appears on strong continuum sources?
  • may be related to ADC spike?
  • Important to characterize and document, since that is where people put their lines.
  • Adam needs sky time to look at continuum sources (may be combined with data for non-linearity runs)
    • 14 May 15 Divots notable in many continuum sources.
  • [18 May 15] Visible in the recent continuum plots from last week. Suggestions on the results from the team are encouraged. Adam will ask Dave M. for thoughts.
    • separate meeting may be scheduled to address this issue in isolation
    • Reinforce to observers their ability to move their lines off of the center bin
    • DONE Action: Adam, to draft an Observer¬ís Alert based on this Ron's email, and send it to Toney.
      • Emails sent to gbsci and gbtinfo [27 May 15]
      • Check w/Toney during Observers Meeting to see of Observer Alert is needed.
    • DONE Action: Adam, to FFT the ADC snapblocks corresponding to one of the total power spectra that shows a pronounced bump, and see if it is there also.
      • Bump can be seen in ADC snapblocks. Unclear how bandpass may affect shape.
    • DONE Action: Adam, create a wiki page with our knowledge to date on the symptoms, and arrange a telecon with UCB.
    • Action: Adam, to inspect ADCSNAP data as proposed by Dave MacMahon
      • [01 June 2015] Remains TBD
  • [01 June 2015] Results of "OGP perturbation" tests?
  • From Dan:
    • for a better simulation, it would be useful if you can send us the spectrum of the signal going into the adc. can you please put a spectrum analyzer on the adc input signal and send us the results? (or perhaps you already know what this spectrum looks like? and can you please send us the adc sample rate setting, of the mode where you see the bumps/dimples?"
    • "Alternatively (or additionally?), can you amplify and/or pad as needed the GBT spectrometer analog input and send that to VEGAS to see whether VEGAS still shows the same bump and dimple using that analog path?"
    • "If so, does the bump appear in ADC snapshot data from on-sky observations when driving the ADC inputs directly from an appropriately band-limited analog noise source?"
  • [01 June 2015] OGP 5% perturbation tests completed, but some further analysis is necessary to make determination.
    • Action: Jason: Send picture of X-band bandpass shape to Dan do that they can better simulate the signals going into the ADC
    • DONE Action: Adam: Repeat X-band Specta/snapblock test with eight sub-bands overlapped, to see relative location of bump; record many hours of data to improve snapblock S/N
    • ALERT! Action: Richard conduct a 12.5 GHz GBT Spectrometer test and report results to combined team. Reschedule wk of 8-Jun.
  • [8 June 2015]
    • Adam observed overlapping 8 subbands to cover the f./4 spots and did see bumps (1).
    • Other offline tests by Joe with noise have not produced the bump
    • still could simulate interleaved adc, simulate f/4 spike and see if a bump occurs
    • UCB/Dan: white noise with simulated ADC offsets after Fourier transfer showed f/4 spike but not the bump
      • (1) recommends another round of more tests (Adam version) with more snapblock data (e.g. overnight)
      • Action: Jason Move introduction of digital noise to replace the ADC to see if FPGA processing is source of bump. Run as normal first to verify bump then substitute ADCs
    • [15 June 2015] Action: Jason Feed quality noise source directly into ADC to see if the bump remains.
      • If ADC then two options 1) replace 20 ADC ($$), or 2) use config tool to move the band out of the fs/4 area of the band
      • Adam to test modes 1-3 to see if bump occurs
  • [22 June 2015] Final solution: move spectrum to avoid the 'bump' frequency for all modes > 3. subband will be centered at 3fs/16.
    • Need to document the presence of the bump for modes 1-3.
    • Config tool would flag fs/4 for modes > 19 with observer warning
    • Adam and Melinda: MR to be drafted [w/Melinda]
      • center frequency change for manager will be needed too
  • [29 June 2015] Draft MR circulated and details are under construction. Affects Config tool & Manager. Test BOF files complete before software is needed. Target software changes in place week of 13-July.
  • [06 July 2015] Action Melinda : document in MR the proposed solution to recent questions.
    • Arindam is working on ADC timing errors in modes 4-6, 1500 MHz. Modes 7-9 ready 800 MHz for test.
    • Action Joe: Make manager changes and test basic manager functionality changes - believed complete
  • [13 July 2015] Arindam resolved some timing issues and sent ADC files to Joe for testing
    • Config tool version ready for testing. Melinda needs some additional test cases (e.g. to test out of range condition)
      • Action Adam: Provide above test case. Test with Melinda.
  • [20 July 2015] Testing occurred. Went well. Ready to deploy after testing a couple new BOFs (for completeness)
  • [27 July 2015] These issues have been addressed for modes 10-19 in build 185
  • [17 Aug 2015] Move to low priority as a "research problem". ADCs are the underlying cause and only replacing them constitutes a hardware fix

"Bump" Science Project

  • Research possible causes for the bump artifact.

Operational Issues

  • Arm time is in the past bug
  • VEGAS HPC program taking too long to be ready.
  • VEGAS aborted due to detection of invalid data.
  • VEGAS hangs in aborting
  • "IF_BITS" problem
  • Need to revisit integration / scan length algorithms
    • Don't want to produce little "runt" integrations
  • Bank c aborting every scan or two
    • Using mode 15 in Banks A,C,E,G. Only bank C was aborting. It looked like it was getting garbage data/header info.
    • Swapped the bank C HPC to Bank B's HPC
    • The bank swap seemed to have fixed the issue
    • May want to check operating temperature
    • Current configuration [13-July]: What was Bank B's HPC is now Bank C and vice versa.

VEGAS Balance Problem

  • Still need to improve and differentiate between warnings and errors in IF rack balancing, Converter Module balancing and VEGAS internal requantization balancing.

Can't set short integration times correctly for Mode 1

  • Need to be able to request SWPER and TINT of 0.5ms, through both config tool and Manager, and have these appear in the FITS file correctly.

Clean out old parameter cobwebs

  • Ray would like to do this at some point. May have a minor impact on the config tool.

Open VEGAS MRs

  • 17Q414 - VEGAS Spur Detection (Adam drafting)
  • 6Q115 - remove "res" keyword (Awaiting implementation)

Valon Synthesizer Programming

  • May be buggy? Problem for pulsar observing
  • Need to improve the Valon programming code (where does this reside?)

I think the programming code is fine. We do need to make sure that we set the options on the synthesizers when we create/initialize the device. (JMF)

Other

ADC calibration

  • The proposal was to use the receiver IF as the input for the O and G measurements, since this will look more typical than a test tone.
  • If we wanted to do that, we could prototype using existing manager and snapblocks.
  • Proposed path forward:
    • redo the calibration (using the current method) on all banks (including currently unused ones); making sure this is independent of the VEGAS analog IF modules
    • perform astronomical commissioning with this setup
    • If we identify a particular need to improve calibration (e.g. poor baselines, we will revisit this as a later upgrade.
  • MR: https://safe.nrao.edu/wiki/bin/view/GB/Software/ModificationRequest7Q115

Provision of VEGAS (DIBAS) code to the community

  • As a professional courtesy, we should make sure the stand-alone VEGAS code (i.e. the DIBAS code) is up to date for the astronomical community to use.
  • Includes BOFs, Dealer/Player code, ADC calibration algorithms, what else?

Completed or withdrawn - here for archival purposes:

Missing Prepare?

From Toney: "I have had the "more info" cleo tabs open for VEGAS bankA and bankE during my observations this evening. For every scan there are a large number of values that are highlighted in yellow in these cleo tabs. This indicates that the values have been set but that a prepare has not be done. This is while VEGAS is running and taking data. So could the VEGAS manager be missing a prepare before it goes into running?"
  • [04 May 15] Three possibilities:
    • Believed to be a display issue (VEGAS-CLEO)
    • Something is actually changing values after 'prepare' is executed
    • Is it occurring in banks currently out of service?
  • Ray to investigate with Toney
  • Has been seen by Melinda in other manager (LO-1). Tony and Ray to attempt to replicate (Richard to follow up).
  • [18 May 15] No action beyond request for information (re-run Toney's scripts to confirm it is a Cleo bug or not)
  • [01 June 2015]. Toney did not provide scripts. Ray confirmed this is a VEGAS bug. Item closed.

L1 BOF (Mode 4-9) switch to "new" re-quantization gain and digital filter

  • Needs change to Manager
  • Needs release of new VEGASDM utility, working in dBFS
  • is dBFS change simply a naming change or have the actual calculated values changed for the same input power?
  • Jason to organized BOF rebuild, and coordinate release with Ray
  • Jason to target installation during Wednesday (5/13) maintenance if possible. Adam to test after installation.
  • [14 May 15] Jason built BOF. Adam tested, all looks good, though there are some features in the high resolution modes which could be RFI, but more data is needed to verify that these features are RFI. Manager may need an update in order to work with this BOF. Testing time allocated for this week.
  • [18 May 15] Based on recent tests, need to decide if we release modes 4-9. (Richard & Adam to discuss with Ron)
    • DBFS calculation was revised by Ray - needs to be tested/confirm vs. old calculations (e.g. dBm levels)
  • [01 June 2015] New BOFs tested and released, dB calculations confirmed, this item is closed.

ADC calibration check

  • Redo the calibration (using the current method) on all banks (including currently unused ones); making sure this is independent of the VEGAS analog IF modules, as a final sanity check of current approach
  • [11 May 15] Complete

VPM Instance name rationalization

From Joe: [Updated with Actions and Effects 05-11-15 ASG]
  1. In both the HBW and LBW bof control code, there are both "trig" and "raw_adc_trig" in our code. (It probes for either and uses the one it finds.) Has this been normalized?
    • Action: The use of "raw_adc_trig", along with the data capture blocks (p0_dc/p1_dc), to be deprecated in future VPM builds. Only "trig" is to be used to drive snap blocks in pulsar modes and spectral-line builds. As it turns out, the latest versions of both H1K and H16K include only the "trig" software register.
    • Effect on the current spectral-line firmware/manager: No effect on firmware. The manager might have to slightly modify in order to deprecate the use of "raw_adc_trig" (or, no effect on manager if it doesn't hurt to just leave the variable in there?)
  2. These changes modify the current register naming of the switching signal registers by prefixing 'ssb_' to them. Impacts all spectral line bofs. (Minor changes required.)
    • Action: The subsystem "ssb" in the VPM models to be dissolved in the future builds. This will resolve this issue.
    • Effect on the current spectral-line firmware/manager: No effect on firmware. No effect on manager.
  3. The change of network tap name from tGX8_tGv20 to tgx8_gbe0 seems like a step in the right direction, however, why not just label them gbe0 through gbe7? (That would be consistent with the incoherent and spectral line naming.)
    • Action: Name the 10GbE blocks "gbe0", "gbe1" .... "gbe7" as Joe has suggested. This will resolve this issue.
    • Effect on the current spectral-line firmware/manager: No effect on firmware. Manager needs to be slightly modified to accommodate gbe1-gbe7 (only used in VPM designs) .
  4. If their is only one 10 gigabit overflow register and all designs, why include an index. e.g. gbe0_overflow could be gbe_overflow. (Note: This would be a change to the current name. However, Vegas spectral line code does not monitor/access this register.)
    • Action: All the firmware (pulsar-modes and spectral-lines) to use "gbe_overflow", as rightly suggested by Joe. However, it has to be monitored in both the cases in order to ensure appropriate 10GbE "reset" operation.
    • Effect on the current spectral-line firmware/manager: Minor changes to the firmware. Slight naming modification in the manager.
  5. I didn't see a 'status' register which according to my notes appears in all spectral line bofs. Perhaps my notes are out of date? However, I don't see any place we use the register.
    • Action: No changes to the VPM firmware. The composite 'status' register (in-use in H1K / H16K) to be deprecated in future builds. Adding "gbe_overflow" instead should suffice.
    • Effect on the current spectral-line firmware/manager: Minor changes to the firmware. Manager to be slightly modified to discontinue the use of "status" (or, no effect on manager if it doesn't hurt to just leave the variable in there?).
  • The updated instance naming convention can be found here. [05-11-15 ASG]
  • [04 May 15] There may be a few items that affect VEGAS spectral. Arindam to reconcile and post results to wiki page. Minor VEGAS manager changes anticipated after Pulsar manager is complete and all crossover points verified.
  • [11 May 15] Arindam has completed.

VEGAS Analog IF filter control

  • Needs to be set for the banks that are not being controlled by their own Roach
  • proposed solution is to provide a Y cable for the I2C bus.
  • [04 May 15] Cable in place and is working. No further action in near term (moved to lower priority in case any further actions needed later)

RCO / SCAL / RFI rationalization

  • Provide a unified set of scripts, and make sure everyone is using them.
  • [11 May 15] Moved out of Vegas to GBT operations for action

L8 BOF (Modes 10 - 29) Upgrades

  • We need to make all the changes we want for L8, including, but not limited to:
    • L8 CIC filter
    • L8 re-quantization gain
    • Anything else arising from discussions with Dave MacMahon.
  • [18 May 15] Change sequence to move L8 ahead of H16k.
  • [01 June 2015] snapblock data acquired and analyzed - next steps?
  • Dan and Hong to contact Randy & Jason to discuss approaches,
    • [08 June] Resulting decimation rate did not match the filter bandwidth so higher frequency noise is being aliased back down into band. Resulting suggestions:
      • Could reduce decimation rate
      • move from a 1/2 band to 1/4 band filter (may still not be a acceptable bandpass)
    ACTION
    Randy to release a BOF which fixes the re-quantization and filter problems ASAP, and then improve the bandpass shapes as a second step. Could be FPGA resource problem when filter gets too sharp.
    • [15 June 2015] in process
  • [22 June 2015] no update
  • [29 June 2015] New decimation topology devised with Dave in recent design. Resource usage is significantly reduced with this design
  • [06 July 2015] Tested version 172 which had better bandpast, but it was mirror image. Randy fixed incorrect "wiring" on FPGA mixers in version 174 which is now ready for test Action Joe.
    • Action Randy: Re-quantization and bistable features fixed this week.
  • [13 July 2015] Version 176 has CIF and inverse sync FIR. Achieves 92% of bandwidth. Building now, preliminary tests in a day or so.
  • [20 July 2015] Took a few tries to obtain a successful build - version 181 released to Joe for tests. Initial look at filter shape looks good.
    • More thorough tests this week (Monday)
    • Still requires hardware fix which improves temporal capability, so needs to be completed (priority level tbd w/Richard)
part of builds
  • [17 Aug 2015] Complete

Quantization of LBWGAIN in mode 21 (presumably all 8 sub-band modes)

  • Balser et al took data on 19th June, tuning all eight sub-bands to the identical frequency. For some unknown reason, the lbw_gain appears to be identical in pairs of sub-bands (i.e. 1/2, 3/4, etc), and small systematic offsets can be seen in the resulting spectra. This effect was not present in similar data taken in April (I have not checked LBWGAIN for those data).
    • [22 June 2015] LBWGAIN pairs can be explained by the way the snapblocks are taken - also in pairs. Resultant (larger than expected) impact on spectra may be due to the (known) re-quantization bug.
      • Repeat test with new BOFs from Randy. Final diagnosis rests with software group for now.
      • See what happens once re-quantization block (above) is implemented.
  • [29 June 2015] Resolved based on L8 BOF. Final tests at that point.
  • [13 July 2015] Fixes are in place with Version 176 above. Needs retesting after L8 modes accepted.
  • [20 July 2015] The revised mathematics are in version 181. Needs tests with higher power levels. Will be part of Monday afternoon tests.
  • [27 July 2015] Tests completed. Test data provided to Randy to adjust filter power levels.
  • [17 Aug 2015] Complete tests

-- MartyBloss 2015-05-04
Topic revision: r1 - 2015-09-23, RichardPrestage
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback